Monday, April 29, 2013

Upgrade to SP2013, part 5: Setup the User Profile Service Application

One thing that is introduced (or has come back actually) in SP2013 is: AD import. The big benefit of using ADI is that it is fast and easy to setup. Also, the filters are ready so you can just check a box to filter out disabled accounts!! Great! Not much can go wrong there.

But, if you want to fully use the UPS and maybe import extra attributes from the AD like user profile pictures, employee information etc then you must setup the User Profile Synchronization import. And I want to do that, especially import the photos, since I have a profile picture of the user up in the right corner of our intranet. This means a bit more work, but it is still quite easy to configure and setup:

Start with creating the User Profile Service Application in "Manage service applications" and map it to a new application pool (which I add the farm account to). You need to have that user in the local admin group on your server also. And yes, you will have a message about this in the Health Analyzer but just ignore that.

When that is done, go to the Services on Server and launch the two services “User Profile Service” and “User Profile Synchronization Service”. Enter the farm admin password on the page where you launch the second service. Now the last one will take some time to start, just leave it for 5-10 minutes and it will be started. One important thing I learned at the SPEVO13 conference, at a session by Spencer Harbar, was that the field where you enter the farm account password is actually not validated so if you enter an incorrect password there you might run into the famous “hang” when starting this service. So be sure you enter the correct password! I tried it and it does hang AND it did lockout my account until it finally stopped trying (new account policy for some admin accounts at my company) but it really does not tell you that the password is incorrect when you press OK on this page. Bad!!

Anyway, when you have the services started like this you can make an IISRESET:


I always do that, because I know this can give you errors or trouble otherwise when you want to create the AD connection and I am always better safe than sorry.

Now, go back to your User Profile service application and make sure the “Configure synchronization settings” are set to “Use SharePoint Profile Synchronization” and (optional) deselect the “Include existing BCS Connections for synchronization” for now since we don’t use that yet.

To setup the connection to your AD, go to “Configure synchronization connections”. When that is done, we need to setup the connection filters, in the most complicated and non logical way you can think of… to filter out the disabled accounts. Do this:
On your new AD connection, hover it and select “Connection filters”:





Make sure you have the “All apply (AND)” checked
Select “userAccountControl” in the list and wait for it to update the page!
Select operator “Bit on equals” and set the Filter to “2”
Click on “Add”:















If this is enough filters, just click OK to apply.

Now go back to your User Profile Service Application using the breadcrumb…. Hahaha NOT. Spencer made that joke at the SPEVO conference, not sure how many got that… I was laughing anyway!

So go all the way back to your UPS and start the synchronization, and yes it has to be a Full the first time.

Optional: before you start the import you can import some extra attributes from the AD. I want to add the user profile pictures:

Go to the “Manage User properties” and find the one called Picture. Change the settings to “Do not allow users to edit” if you don’t want your users to upload their own pictures (can result in everything from pics of cats, beers, strange positions etc if you allow this!) and then select the “thumbnailPhoto” from the attributes list. “Direction” should be “import” and click on Add:


 



Now start the full import and the time it takes to import of course depends on how many users you import and how many extra attributes. For me it took about 7 minutes to import 1700 users.

One last thing I do, is to select the User Profiles service app (go to "Manage service applications" view), select the UPS and click on “Administrators”. I add the Search account and set it to “Retrieve People Data for Search Crawlers” so I know that the People search will work also.

Sunday, April 28, 2013

Upgrade to SP2013, part 4: Upgrade Managed Metadata Service App

I will only upgrade one service app and that is the Managed Metadata service application, since I have built the company wiki based on a taxonomy tree there.

There is an article on technet that I followed to update this, but it failed. I tried it twice and got the same error and I am sure I missed something or did something wrong somewhere, but there is a limit on how many trials you do before you give up. So I did my own workaround and got it to work finally.

These are the recommended steps that I followed from Technet:
Detach the Managed metadata database on the SP2010 test server
Copy it to the new SP2013 server
Attach it to the SQL server
Then run this command in Powershell to upgrade the database:

$applicationPool = Get-SPServiceApplicationPool -Identity 'SharePoint Web Services default'

$mms = New-SPMetadataServiceApplication -Name 'Managed Metadata Service Application' -ApplicationPool $applicationPool -DatabaseName 'Managed Metadata Service'
(If you use a variable like $mms (or whatever you want to call it), you can refer to that when you create the proxy group):
New-SPMetadataServiceApplicationProxy -Name ‘Managed Metadata Service Connection’ -ServiceApplication $mms -DefaultProxyGroup

Did an iisreset just to be sure...

Right. So the result was an error message when I tried to access the Managed metatadata service app.

Opened the Properties to make sure it had the correct database (the upgraded db name) and application pool. And I actually created a new application pool and assigned the correct service account to that. That did not change anything.

Then I verified that the same service account has permissions to the database on the SQL server also.
Checked the Health Analyzer. Found a message about the managed metadata not being associated to the service apps:



Checked the “Configure service application associations” and the service apps were correctly associated.
Went back to Health analyzer and clicked on “Reanalyze now” and the message disappeared. Did not change anything.

Went into “Upgrade and Migration” and clicked on “Check upgrade status” and found the successful upgrade message so the database seems to be OK:
 


Clicked on the second Managed metadata service connection level and checked the second box also. I did not expect any changes from this, but just in case….

Went into “Security” and “Configure Service Accounts” and changed to another pool account and made an iisreset to see if that helped. No, did not change anything, still same error.

Checked the ULS and found this error:
Failed to get term store for proxy 'Managed Metadata Service Connection'. Exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.     at Microsoft.SharePoint.Taxonomy.Internal.XmlDataReader.GetDateTime(String name)     at Microsoft.SharePoint.Taxonomy.Internal.SharedTermStore.Initialize(IDataReader dataReader, Guid termStoreIdValue, Boolean fromPersistedData)     at Microsoft.SharePoint.Taxonomy.Internal.SharedTermStore..ctor(IDataReader dataReader, Guid termStoreId, Boolean fromPersistedData)     at Microsoft.SharePoint.Taxonomy.Internal.DataAccessManager.GetTermStoreData(MetadataWebServiceApplicationProxy sharedServiceProxy, Boolean& partitionCreated) 3a24169c-4427-a0a0-8c09-185263be83c0
04/28/2013 14:01:11.13  w3wp.exe (0x2EDC)                        0x1E80 SharePoint Server              Taxonomy                       8088 Warning  The Managed Metadata Service 'Managed Metadata Service Connection' is inaccessible. 3a24169c-4427-a0a0-8c09-185263be83c0

Googled these errors and found nothing that really related and could solve my problem ("the given key was not present").

Gave up and tried my own solution, which worked immediately! Steps follows below:

My own solution
Detached the database
Deleted the Managed Metadata service application in CA that I had created in the steps above
Created a new managed metadata service application and also a new application pool account.
And I checked “Add this service application to the farms default list”.
Attached the upgraded database (from my former steps above, so the database needs to be upgraded)
Changed the properties of the service app, and added the name of the upgraded database
Iisreset just to be sure…
It worked immediately.

May not be the correct way, but at least this worked on first shot!

Thursday, April 25, 2013

Upgrade to SP2013, part 3: What to migrate

Content databases
Number and size of databases. Any old that should not be moved over?

Custom solutions and branding
Identify: customizations, branding files, style sheets, farm solutions, customized web parts and copy/install all these files on the new server.
Make sure the third party products or any farm solutions are compatible with SP2013.

Database structure
Should we split the database into smaller databases? The test migration will be a good test for this, to see how long the upgrade takes. I really don’t want to split our intranet into different db’s because we would have to use different host headers or managed paths and it will confuse the users. Also since we are replicating, it means even more work to enable all those extra db’s for replication. I am sure that our db is quite small compared to what Microsoft recommends. Our intranet db is separated from the project portal, so the large amount of files should be moved out of the intranet.

Service apps
Search service app – NO
We are using pretty much out of the box for Search, I have only made some branding. So no, it will be fairly quick for us to setup a new index.

User Profiles - NO
Managed metadata – YES
We have not setup any company metadata because of the issue with editing multiple documents, that was in SP 2010. But now that you actually can make good use of it, we might consider adding it back. But I have used it for our company wiki so this will be needed.

Web Analytics – NO and shut down services
Analytics processing for SharePoint 2013 is now a component of the Search service, so stop the services before moving the content db’s. Web Analytics Data Processing Service and Web Analytics Web Service  services should be stopped and also go into “Monitoring” and disable the timer jobs for it. Maybe overkill but… better safe than sorry. Did not do that for this WSS_Content DB since the web app was not configured anyway! Test to see if any errors comes out of that.

PowerPoint Service App and Word Viewing Service App – NO
These apps were created to support our Chrome users, it is OfficeWebApps service applications. But they are moved out to their own server in SP2013, OfficeWebApps server.

SSL certificates
We use SSL on all our sites so this needs to be imported to the IIS.

AAM
Make sure all host headers are added to the AAM.

Quotas
We have increased our quota templates on the SP server so these values needs to be added. And of course the upload size limit.

Workflows
They should work as in SP2010, but that needs to be tested and verified.
 

Upgrade to SP2013, part 2: Clean up first!

I had a look at what Technet suggests as upgrade steps, and here is the table. I don't see anything about preparing your database for Claims authentication, as was so much spoken of at the conference. It will have to be a trial and error.
 
 
On my SP2010 test server, I have a restored copy of our intranet and I will use that to test upgrade to SP2013 so I get as a real scenario as possible. Will be interesting to see what happens with our branding and structure... :)
 
Before I moved the content database to the new SP 2013 server, I did a clean up on my SP2010 server. Better of not moving shit over if it can be resolved first.


Looked inside Health Analyzer, and of course there are some messages in there about farm accounts (you know what I mean, I am sure about that!) but there are also stuff that really matters like orphan items, missing server side dependencies etc. I had a message about orphan items in the database, so I just clicked on “Repair automatically” and refreshed and it was gone. For the "missing server side dependencies" it requires a bit more work!

I ran this powershell command to test the content databases:
Test-SPContentDatabase -name WSS_Content -webapplication https://intranet.xxxxx | out-file e:\upgrade\upgrade.txt -width 500
Got the following results from that:

Category  : MissingFeature
Error        : True
UpgradeBlocking : False
Message         : Database [xxx] has reference(s) to a missing feature: Id = [xxx], Name = [Weather Web Part], Description = [Displays the Weather], Install Location = [WeatherWebpart].
Remedy          : The feature with Id xxx is referenced in the database [xxx], but is not installed on the current farm. The missing feature may cause upgrade to fail. Please install any solution which contains the feature and restart upgrade if necessary.

Category      : MissingSetupFile
Error           : True
UpgradeBlocking : False
Message         : File [Features\Taxonomy_WebPart_Feature1 \Taxonomy_WebPart\Taxonomy_WebPart.webpart] is referenced [1] times in the database [xxx], but is not installed on the current farm. Please install any feature/solution which contains this file.
Remedy          : One or more setup files are referenced in the database [xxx], but are not installed on the current farm. Please install any feature or solution which contains these files.

Category        : MissingAssembly
Error           : True
UpgradeBlocking : False
Message         : Assembly [xxx.Eventhandler, Version=1.0.0.0, Culture=neutral, PublicKeyToken=xxx] is referenced in the database [xxx], but is not installed on the current farm. Please install any feature/solution which contains this assembly.
Remedy          : One or more assemblies are referenced in the database [xxx], but are not installed on the current farm. Please install any feature or solution which contains these assemblies.
Since the UpgradeBlocking status False on all of them, then I guess it’s no need to worry but I have tried to resolve most of these errors anyway to clean up the database. First thing is to check where a solution is added, and to do that just run this SQL query on your content db:

Select * from Webs where SiteId in (select SiteId from Features where FeatureId = 'guid')

And then I could go to that site and remove for instance webparts from the web part gallery that was no longer referenced. Removed them from both Recycle bin and Site collection recycle bin. Ran the test-spcontentdatabase cmdlet again and it was gone.

I also used FeatureAdmin2010 (amazing tool from Codeplex!) to search through the farm and removed the files that it suggested.

Upgrade to SP 2013, part 1: Hardware reqs (on test server)

And so let the fun begin! This will be a post with many parts, I begin with the easiest part... :)

After attending the awesome SharePoint Evolution Conference in London this April, I was so inspired to get started with SP2013 that I immediately put up a migration plan when I got back to the office. Although I had installed an SP2013 server a few months ago, I had not really had any time to test much. But now it's time!

So I had an "old" test server that I created a few months ago with the following installed. I run all on the same machine since it is my test server:
- Windows Server 2012
- SQL Server 2012
- SharePoint 2013 (no updates installed yet)

But the machine needed more juice, I could barely start it. As I had seen at the conference the least minimum reqs for a server is to have 8 GB RAM and I only had 4 (!) but I got 12 GB so now it's more responsive.

Minimum reqs according to Technet:

 
What I had on the server:


 
And what it was upgraded to:
 

 
 

Wednesday, April 10, 2013

InfoPath forms do not work with replication - Updated!

10 April update: That last version 5.1.7322.8 did not help solving this issue with InfoPath. It seems like the problem with templates has to do with forms that uses Data Connections. There is a new version 6 out that I have not installed yet, will come back with an update after that.

5 March: Awesome news! I got a mail from the vendor that the newest version will have a hotfix that will correct this issue. It will be released in a few weeks. Look forward to that, and will of course update this blog post if things go well.

This post is about enabling replication between servers using a replication software and the problems related to that. It works well for exchanging content, but when it comes to InfoPath there are some real problems. This is not yet solved so there will probably be a part 2 of this post.

I have published a lot of web forms (InfoPath forms services) on the intranet and when they start replicating they run into the problems listed below. Same thing happens to a list that you have customized, the customised form is lost so it looks like a regular list again. The replication vendor has no solution so far.

The error will run in circles because if you make an update on one server, that will replicate to the others and the errors will just keep on coming back. Here are the errors and why they happen.

Advanced settings are not replicated
The first time you set up replication on an InfoPath form and try to open a form on the site, it will load in InfoPath and not in the browser. That is because the “Advanced settings” of the library are not replicated. You need to go in to the library and set the “Open in browser” again and then you also have to open your form template and republish it:


Data connections are lost
When you have done this change, the form gives you a new message. Now the data connections can’t be accessed, since they have lost the connection to the secondary data sources:
 

So you have to go in and add those back again in the IP form template:



By this time, your form has start replicating and now all other target servers has gotten those same errors. So this will just keep on going around in circles.

So what I did was to stop replicating the “Content types” and it works HALFWAY. Because then another problem came up...

The xsn version of the form template changes
Of course when you have done a change locally on a template it will get a new version number. So now all versions of this template is not in sync. And the result of that is that the users get the below error message. If they click “OK” the form loads but still annoying:

 
I have the setting on my IP forms to “Automatically upgrade form version”, which is the default setting. If the user clicks on OK the form loads, but I don’t want that message! I compared versions of the form and on the source server we have version 1.0.0.1701 and on the target server we have 1.0.0.1709 and that is of course because I had to open the form and add the data sources and all the other steps I wrote about before, that were lost while replicating:




So I changed the version to be the same on both servers. And that helped. So now that message was gone. But this is only a temporary help, not a SOLUTION! Once a form is updated again, the problems will all come back. So I will test publishing a new template that has "Do nothing" instead of "Automatic update version" to see if that can help.

My hope now is that the vendor will deliver a solution for this soon, otherwise this is turning into a big EPIC FAIL.