I was really stuck for about 2 days with this and the “really helpful” URL log entry System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.Office.Server.Intl.resources
before I was able to recover thanks to a slew of Microsoft PFEs who requested to remain anonymous because they don’t want to fix User Profile synchronization errors for the rest of the lives.
User profile synchronization is one the most fun issues one can encounter in SharePoint. Specifically, starting it can be a real pain in the neck if it doesn’t just happen without the sprinkling of fairy dust.
I’m assuming that read [and followed] Spencer Harbor excellent Rational Guide. If you didn’t, please stop reading now; follow that to the end and you can donate to my pension fund at another time.
You also need to read this http://www.harbar.net/articles/sp2010ups2.aspx.
We wanted to publish our internal portal, running on SharePoint 2010, to company-approved mobile devices (we mostly have iPads and iPhones.) Since these devices are not sitting on the internal network we needed to publish the sites so they are available externally. We use Forefront Unified Access Gateway (UAG) from Microsoft for secure access. UAG is a software-based reverse proxy with built-in capabilities to publish SharePoint sites. A good place to start installing and configuration UAG is Ben-Ari articles and books on the subject http://blogs.technet.com/b/ben/archive/2010/12/29/sharepoint-publishing-concepts-and-considerations.aspx. other resources are available on the web as well http://bit.ly/XnBqHQ.
Smaller devices are good for many things, but typing user ID and passwords of any complexity are tasks that make most corporate users cringe. Since we “own” the device and can impose policy and push data and links into it, we have more options to offer better login experience than an open web site.
UPA – user profile application can be pretty fickle, but this one was a real head scratcher. Once we started getting some users in our staging environments the User Profile Application would occasionally stop responding resulting in the entire farm being unresponsive. There were no recorded errors regarding the actual services.
Our environment is set up on private cloud with a separate domain. We have a two-way trusts between the private domain and our enterprise domain. I mention that because it turns out that the UPA has a nasty “feature” whereby each call to UserProfileManager results in the service trying to authenticate each and every entry in the “Administrators” collection. it takes about a second for each group and 2 seconds for each individual on that list to authenticate. So, if you added a few users there you are looking at 10 seconds or so for each call on a good day.
In our case some of the requests were getting rejected with “No logon servers are available to authenticate your request”. The queue grew large enough and the system will not come back until we rebuilt the UPA. Distributing the service across multiple servers provided a temporary relief, but the system ended up crashing again anyway.
So, what is the solution? until Microsoft fixes the bug (promised in SP2) you need to
- Reduce the number of UPA administrators to a minimum of required groups. 3 at most.
- work with Active Directory team to trace authentication issues, setup, and speed especially if you have multiple domains or even subdomains
- Monitor the Worker Processes queue for the UPA application pool to see the speed of resolution
- run a script to test the length of time it takes to hydrate a UserProfileManger in PowerShell
Here is a script to do a bulk update of file properties, including the pesky properties describing the read-only Author and Editor and the times in which the file was Created and Modified.
To do the bulk upload, first we create a tab delimited file with a column for the complete document URL, and one column for each property that we need to update. A file like that will either be created from a secondary system, or be created by users.