Best practice to avoid feature missing issue during SharePoint 2013 upgrade

If you upgrade SharePoint 2010 content to 2013 , you might get many feature missing issue during content migration even those features have already upgraded and deployed on SharePoint 2013!  So, what is the reason and how to resolve it?

The main reason is the content from SharePoint 2010 has reference to feature that is inside 14 hive! As a result, the solution is to remove the reference on SharePoint 2010 before the content detach as I have already mentioned in Fab 40 upgrade blog.

There are many good blogs to explain SharePoint 2013 upgrade in detail steps or bestpractice. I’ve put together an TEN step migration SharePoint 2013 upgrade architectand design. You might notice one of the key step is clean up as we described in previous blog. There are many clean up tasks you MUST perform before the upgrade. In this blog, I would just focus two major clean ups – master page and webpart cleanups that will remove the reference on SharePoint 2010 14 hive to reduce missing feature issue.

1. The first step for this is to disable the features from all scopes (farm, web application, site, and web) that are refer to your master mages and webparts. 

This will remove the feature reference to features deployed to 14 hive. If you deactivate some webpart solution like Quest Webparts, it will automatically remove the webparts from webpart gallery. If you do not deactivate the Quest Webparts feature on SharePoint 2010, you will have issues like we discussed in previous blog.

2. The second step is to switch the master pages to out OoB V4 master pages. This will remove the dependencies to any features on 14 hive.

3. The third step is to remove the customized master page from master page gallery. 

If you do not remove the customized SharePoint 2010 master page from master page gallery, you will NOT be able to remove them on SharePoint 2013 easily that will cause upgrade issues in the future! 

In addition to the three steps above, you should follow the cleanup procedure published before to elimination potential upgrade errors. Make sure that your environment is functioning in a healthy state and that you clean up any content that you do not have to upgrade. Clean up any unnecessary components, unsupported features, orphaned sites or features, address any large lists and large ACLs, remove extraneous document versions, and replace using OoB features as in the below picture. 

You should generate the inventory and reports to determine the 2013 farm topology plus a performance baseline and information about the environment. One of the report you need to do is the customized master pages so you could following the three steps above to fix the issue.

 

SharePoint 2010 claims migration issues and possible workarounds

If you migrate SharePoint 2010 to claims, you will be one step closer to leverage SharePoint 2013 architecture. We have followed the instruction provided in previous blog "What you need to know to migrate SharePoint 2010 from classic-mode to claims-based authentication as IT Pro, developer, or end user?". However, there are some issues issues we are facing after the migration. It might worth to discuss the symptom and possible workarounds. 

1. The first issue is exception when calling all SharePoint 2010 web services within browser based InfoPath 2010 forms.

Opening this form works fine as long as you open the form using InfoPath on the client. When attempting to view the form in the browser the error occurs as described in Russ Maxwell's blog.

Several blogs have explained some workarounds and I've summarized as below.

• Call a Web Application configured to use Classic Authentication from Russ Maxwell
• Configure a security store and use it for authentication
• Modify UDCX from the data connection string user name and password

When we worked with Microsoft, we found following message from IIS logs.

POST /_vti_bin/userprofileservice.asmx - 80 0#.w|nt+authority\iusr 172.30.36.22 HTTP/1.1 InfoPathDA

It seems like the InfoPath web form is using “nt authority\iusr” to access web service instead of the app pool account. The fix is to modify the web.config as follows to disable anonymous impersonation.

<add key="aspnet:AllowAnonymousImpersonation" value="false" />

After the changes, you should be able to call the web service without error. However, the user name display will be application pool account anme instead of the end user! There is major difference when execute using InfoPath client vs. browser. When you run a form from InfoPath client, it uses credentials from the user currently logged in to the computer. When you run it from the browser, it runs as the application pool identity when web.config key is set to false.

The solution is to change the call to use userName(0 to get from the context the user who's logged in, instead of the process account as in the following screen shot. You can associate userName() as the value of any text box controls.

2. The second issue is user/group display names as SID from two places.

One place is the display name for both user or group will append the SID if you add them directly to SharePoint NOT to the SharePoint groups as in the below screen shot. 

There is no workaround at this time. You should educate the users not to grant permissions directly but through SharePoint groups. The good news is this issue will be automatically resolve after you upgrade the site to 2013. All the names will be displayed correctly.

Another place is the display name for group for managed metadata term store if added to "Group Manager" or "Contributor". The group will be displayed as SID instead of the name. The good news is by click the person icon when in edit mode, you could "convert" the SID to group name. The bad news is it will be displayed as SID after you saved it again. This will be same when you upgrade to SharePoint 2013. We will work with Microsoft to find a good solution.

3. The third issue you may not find user "Permission level" through check permission UI for users who have not logged in to the site AFTER claims conversion. The permission chek result will be "None" as in the below screen shot. In addition, these users will not able to email to the email enabled list!!!

The display issue is only happens for certain AD instance with AD group level in previous version NOT on 2008.

The email issue is major issue for those users. This issue seems to be same on 2013!

We are working with Microsoft now and suspect this might be related to AD function group version. We will keep you posted.

4. The forth issue there will be two duplicated owner entries for any mySite created after claims conversion as in the below screen shot.

You may noticed one entry is window authentication and the other one is claims with SID. If you modify the owner permission, it will only affect the one in claims.

We have verified this will still be the issues on SharePoint 2013 and it's even worse since it will display user name only as in the below screen shot and you will not see the difference for these two entries.

Although there is no impact to the permission, we could like to remove the unused duplicate Window based owner entry. The workaround is to remove the window authentication owner entry from event receiver code. We are working with Microsoft to find a final fix.

5. The fifth issue is the designer workflow using user field issue. The workflow will stop working and the work around is to republish the workflow.

If you have any other issues after claim conversion, please share your findings.

 

How to debug user missing picture issues on SharePoint 2013

If you are supporting SharePoint application long enough, you might constantly get support request that users are missing pictures. There are many different reasons that users are missing pictures. We will discuss the how to debug and some tips to resolve in details.

SharePoint 2013 now has three methods for sync process.

• SharePoint Profile Synchronization (lightweight FIM)
• Active Directory Import
• External Identity Manager (C#)

As we described before, you should not use SharePoint 2013 new Active Directory Import feature for picture sync at this time since it does not seem to sync the AD’s thumbnailPhoto attribute. We are still working with Microsoft to debug this issue. In this article, we will focus the tips on SharePoint 2013 User Profile Synchronization Service Application for picture sync.

The most common issue is some users missing pictures everywhere inside SharePoint. In this case, those users’ pictures may not synced to SharePoint. You would need to review the User Profile Synchronization Service Application. There are many good articles to provide step by step importing user photos from active directory into SharePoint 2013 from User Profile Synchronization Service Application.  Here is the summary for the procedure.

1. Create UPA AD Sync Connection using FIM

2. Configure the Picture profile property as the following:

a. Picture (Type URL), replicable, do not allow user to edit values for this property

b. Attribute: thumbnailPhoto , Import

3. Make sure sync process account have Replicate Directory Changes permission on the domain with which you'll synchronize. See Microsoft site for details.

4. Run a full synchronization

5. Run Update-SPProfilePhotoStore –MySiteHostLocation http://mysitehost –CreateThumbnailsForImportedPhotos:$true

a. Make sure you use the optional parameter CreateThumbnailsForImportedPhotos

b. Make that both the Distributed Caching process account and the account you’re using to run the cmdlet have Full Control permissions in UPA, otherwise you’ll get an exception.

There are several ways to debug User Profile Synchronization Service Application missing picture issue.
 

One way is to verify mysite user photos list - go to http://my/User%20Photos to see the imported photos and thumbnails for the user as in the picture.

The second way is to verify the FIM logs - invoke the file

..\Program Files\Microsoft Office Servers\15.0\Synchronization Service\UIShell\miisclient.exe. You could select the users whether the Picture attribute filled in binary.

The third way is to verify user Sync database on sync process - check User_Sync_DB and run the query after FLL sync completed

Select sAMAccountName,PictureURL from MMS_Metaverse  with(nolock) Where SAMAccountName = 'userID'

The forth way is to verify profile database - check User_Profile-DB after run the Update-SPProfilePhotoStore command

Select NTname,PictureURL from UserProfile_full with(nolock) where NTName = 'domain\userID'

The fifth way is to verify whether AD  thumbnailPhoto attribute has the binary photo - See blog for details.

Another common issue is some users have pictures inside users photos but are missing pictures when you view the permissions. You could go to display the hidden user list http://webapp/siteURL/_catalogs/users/simple.aspx. If you select "Detailed View" you could verify which user is missing picture. You could set the pictures from user photo list to the site using powershell script. We will share the script in later time.