FAB40.....not so fabulous after SharePoint 2010 Upgrade

I don't mean to belittle the famous FAB40 templates, they were valuable addition to any MOSS2007 farm and users were writing poems, praises and a love song here and there in their honor. However, upgrading these farms to SharePoint 2010 come with their own set of problems.

When trying to do DB attach upgrade, I kept getting thousands of errors in the new farm, and lots of sites would simply not come up. After some googling, I run across Joel's post that suggests deploying the needed legacy FAB40 solution files, followed by hiding site templates and resolving duplicate content types.

BTW, if you are wondering how to hide site templates from your users (the easy way that is), go to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\1033\XML and edit xml files deposited by these solution packages.

File names kind of match the solution, but the dead giveaway is DisplayCathegory="Application Templates" flag. Just change Hidden flag from FALSE to TRUE (on all WFEs that is).

Anyways, back to the reason for this post.....if you have good remedy for short-term memory problem, please do share :).

After the upgrade and the universe being at peace for a month or so, some user was trying to create site template and reuse it elsewhere. Creating a template would fail with:

Error exporting the site field named "Asset" 

Suspecting FAB40, I retracted all solutions from the farm, the error was gone, and site template creation started working OK.

As I was getting ready to pop the cork and call it a day, the most unfortunate news came in....now what!?

Yes, the site template is there but we are now getting this error when trying to create a site based on it:

The content type name ‘$Resources:er,ExpenseFormsTitle’ cannot contain: \ / : * ? “ # % < > { } | ~ & , two consecutive periods (..), or special characters such as a tab.

After playing with applicationtemplatecore.wsp solution package, I eventually realized that:

a) in order to create site template, the applicationtemplatecore.wsp needs to be RETRACTED
b) in order to use this site template, the applicationtemplatecore.wsp needs to be DEPLOYED

As much as I like looking at Central Administration, doing this every single time someone needs site templates just wouldn't cut it, so it was time to call the backup, aka Microsoft Support.
The guy I worked with was great and right on the spot.

So for all of you dear SharePoint admins, here's the solution (minus call to MS support):

1. deploy applicationtemplatecore.wsp

2. look for er.resx under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Resources

3. save it somewhere, and retract applicationtemplatecore.wsp (and the rest of FAB40 if you have them) - this will remove files from the folder

4. copy er.resx back under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Resources


As of right now, the fix looks promising and the universe is back at peace. But then, popping the cork on the champagne may anger the SharePoint gods, so for now I'll just keep it on ice.

User Profile Service Synchronization Timeouts

If there is one service application in SharePoint 2010 that's anything but boring, that's certainly the User profile Service App. I was recently building out a farm and after the UPS synchronization connection was successfully built, I tried importing user profiles form AD.

Looking at the  Forefront Identity Manager applet located at C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\Miisclient.exe , I noticed timeouts.

DS_FULLIMPORT step would start and after about 5-10 min would fail with stopped-connectivity error, WCF Endpoint failure.

I was on the phone with MS for couple of hours going through the logs, and trying to sync over and over (and over) again, each time being a failure.
The proposed solution was to increase timeouts values for service endpoints. Apparently, each SharePoint 2010 service has two endpoints (bindings), one for HTTP and another one for HTTPS, and their configuration files are located under:

C:\Program Files\Microsoft Office Servers\14.0\WebService


Now I am sure if you are a developer you probably already knew this, but infrastructure guys like myself don't often have to deal with the inner workings of web services. Anyways, this is where these files are located, and you are looking for web.config

Look for

There are two bindings: HTTP/HTTPS, 4 timeout intervals each: receive, send, open and close, all 20 sec by default. We had them increased to something like 5 minutes each. 


There are couple of more locations the same process was repeated:

C:\Program Files\Microsoft Office Servers\14.0\WebClients\Profile\client.config

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebClients\client.config 

Indeed, the UPS sync was more robust and did not time out as quickly as before. What I think ultimately was a fix (or part of the resolution at least) was very simple. I looked at another farm which was importing AD profiles OK, and compared the connections in Miisclient.exe side by side. 

Turns out, the farms were attaching to different domain controllers when trying to pull profiles, and my theory is that the problem child was looking at a DC that was either particularly slow, or at a distant physical location. 

I don't want to assume the latter, since I would think that any MS product would be site-aware and always use local domain resources based on SRV records and Domain sites and services subnet information. So I'll just blame it on a bad DC :)

All I had to do was to specify the same DC that the "good" farm was using, when building the synchronization connection in the "bad" farm. I never had to do that before, but hey, whatever it takes to get it fixed. After that, UPS Sync was running with no issues, and I was finally able to import my profiles.