The error is apparently not uncommon and appears to generate from a number of different causes. In the Beta a common cause was a missing WCF hotfix KB 976462 (now installed as part of the Prerequisites). In my case the hotfix was installed, the Web Service was definitely started, there were no errors in the Event Log to indicate a cause, and nothing looked amiss. An IISReset fixed the issue and I was able to access the page, so I will chalk it up to not starting the MMS service before creating the service application.
Configuring the Managed Metadata Service Connection settings came next. Accessing the connection settings is not intuitive. Click on the line for the MMS proxy (highlighted in the screenshot below) and then click Properties in the ribbon:
The MMS Service Connection settings will pop up:
I checked the second setting so that new term sets can be created by users with the proper permissions when they create a Managed Metadata column. The third setting is checked so that this MMS can publish the associated hub’s content types.
Using SharePoint Consultant and MSCT Octavie van Haaften’s blog post Setting Up Managed Metadata Service Application, I created a term group, term sets, and terms to get my feet wet with Taxonomy. Back at the Hub site I created a content type and a managed metadata site column for the content type using one of the term sets, then published the content type successfully. After the timer job ran it was visible in the Intranet site collection ready to be consumed.
Digress: I noticed that when I went back into the Term Store and looked at the settings for a Term Set, a SID (Security Identifier) appeared instead of the user or group name:
After finding this forum thread http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/bbbfe004-b5ff-440d-add7-1b9f208311e4 I saw that sure enough, the SID appeared when a group was specified. This behavior happens every time: If I click Check Name the SID resolves to the user or group name and if I click Save the name stays. But when I exit the Term Store Management Tool and go back in the SID is back.
13. Added "my" as an explicit inclusion path (/my) and "personal" as a wildcard inclusion path (/personal) under Managed Paths in My Site web application, and...
14. Created the My Site Host site collection in the My Site web application at the /my explicit path URL using the My Site Host site template
These steps are in preparation for the My Site parameters in the User Profile Service Application settings.
Big sticky note to remember to change to the correct web application before creating the My Site Host site collection.
You must use the My Site Host site template (listed on the Enterprise tab in Template selection) for the My Site Host site collection. I bantered back and forth about creating the My Site Host at the root of the My Site web application but went with the publicly popular choice of the /my explicit managed path and /personal wildcard inclusion managed path setup below the root. Coming from WSS I had no experience with and little knowledge of the My Site workings; choosing the popular approach for the test network seemed prudent. I’ve since come across numerous mentions that placing the My Site Host at the root is best practice, so that is what it will be for production deployment, with /personal for the individual sites path.
15. Set up User Profiles
Lots of helpful information abounds, and I sat hand-in-hand with TechNet documentation, SharePoint MCM Spencer Harbar’s article Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization, and SharePoint MVP Liam Cleary’s article SharePoint 2010 - My Sites, which I had also used during the Beta.
In sum, per the aforementioned various instructions: I first created a User Profile Service Application (UPSA). This needs to be done because when you later start the User Profile Synchronization service it will ask you to specify one. It’s a good idea after the UPSA is created to verify the farm account is listed as an UPSA Administrator with Full Control. I then started the User Profile service, which requires no input, followed by the User Profile Synchronization service (UPS), which uses the farm account as the Service Account -- the farm account is required -- and requires you specify the farm account's password. After a while (wait, wait…) the UPS service showed Started. Checking the Services MMC snap-in I saw that the two Forefront Identity Manager services showed Started and their Startup type was now set to Automatic. First major hurdle over.
I then did the required IISReset. Before proceeding to set up the Synchronization Connection for Active Directory I added the logged in account (still the SharePoint setup account) to the UPSA's Administrators group and granted Full Control. I did this even though the setup account is a member of the farm administrators group, which has Full Control over all service applications, because in the Beta the sync connection did not save until I did this. I could complete the New Connection settings page and click Save but no connection showed up on the Synchronization Connections page. This time I had no issues when saving. What happened in the Beta was likely a fluke but I am relating this in case it helps someone. I did have another weird issue (lose one, gain one) when I specified the domain’s FQDN for the “Connection Name”. Afterwards, on the Synchronization Connections page the connection name showed weird characters instead of the dots and looked awful/unreadable. I deleted the connection and recreated it using the NetBIOS name instead (one word can’t be mucked up). Second major hurdle over.
Finally, I started a synchronization which took a while to complete (wait, wait…) but I did end up with a match between the number of users and profiles. To watch the progress I used the miisclient.exe that Spencer Harbar cited. Third major hurdle over, and done. Except that prior to starting synchronization I should have (1) placed all service accounts in a separate OU (and then wait for AD replication to occur), and (2) prevented disabled users from being imported. I later found KB 827754: How to import user profile information of enabled user accounts from Active Directory to SharePoint. The KB provides information for SharePoint 2003, 2007, and 2010. In actuality the KB steps through setting a connection filter to exclude disabled users. See http://blogs.msdn.com/b/brporter/archive/2010/02/20/excluding-disabled-user-accounts-in-sharepoint-2010.aspx and http://www.tcscblog.com/2010/11/29/user-profile-imports-how-to-filter-out-disabled-users/. A new full sync with full import eliminated the disabled users.
Aaaacckkk! There were a number of errors in the Event Log:
Events 1001, 1004 and 1015, MsiInstaller, SharePoint server
The errors stopped after I gave the Network Service account Full Control NTFS permissions to the \Program Files\Microsoft Office Servers\14.0\* directory structure. [Found this fix in blog and forum posts; some said Read, some Full Control. I opted for the latter.]
Events 4874 and 4875, MSDTC Client 2, SharePoint server
Event 3, Forefront Identity Manager, SharePoint server
These errors are related to DTC access. The errors stopped after enabling “Inbound Access” for DTC and, in Windows Firewall, Inbound Rules, enabling Allow DTC TCP-In. I did this on both the SharePoint and SQL servers. After enabling Inbound Access the errors did not reoccur, but this did a week later:
And Event 4876, MSDTC 2 which occurred at the same time on the SQL server:
I enabled Outbound Access for DTC and enabled Allow DTC TCP-Out in Windows Firewall Outbound Rules on the SQL server. The errors did not reoccur.
Now, before anyone jumps on this particular bandwagon, I just this week reversed the changes while doing research for this article. In his “Stuck on Starting”: Common Issues with SharePoint Server 2010 User Profile Synchronization article, Spencer Harbar instructs to check “Allow Remote Clients” for a reliable start of UPS if using an SQL Alias (we are), but makes no mention of enabling any other DTC setting. And he says that it is common to see an Event Log error about lack of local DTC access during UPS provisioning. Too, searching turns up maybe two people who have posted the same errors. The caveats in our case are (1) UPS had started just fine with an SQL Alias and without DTC access, (2) the fact that the errors regarding outbound communication happened a week after enabling “Allow Inbound”, and (3) the references to “Transaction Manager Communication".
So, to test the exact settings that might actually be needed I unchecked “Allow Inbound” and “Allow Outbound”, and checked “Allow Remote Clients” on the SharePoint server only. I did leave the Windows Firewall DTC settings as is. A few days later and no MSDTC errors to report.
Some general information on MS DTC: DTC settings are found in the Component Services snap-in under Component Services --> Computer --> My Computer --> Distributed Transaction Coordinator --> Local DTC. Right-click Local DTC, click Properties and, on the General Tab, the “Allow Inbound” and “Allow Outbound” settings are found under “Transaction Manager Communication” (screenshot was taken before enabling Allow Outbound):
This TechNet article Enable Network Access Securely for MS DTC (Windows Server 2008) and this KB article, KB 899191: New functionality in the Distributed Transaction Coordinator service in Windows Server 2003 Service Pack 1 and in Windows XP Service Pack 2, explains the MSDTC settings. And http://searchsqlserver.techtarget.com/tip/Demystifying-the-Microsoft-Distributed-Transaction-Coordinator by SQL Server MVP Denny Cherry should also be helpful for those not familiar with MSDTC.
Event 4879 MSDTC Client 2
This error occurred on the SharePoint and SQL server when the MSDTC service stopped/started after enabling Inbound Access.
Event 22, Microsoft.ResourceManagement.ServiceHealthSource, SharePoint server
This error occurs anytime User Profile Synchronization is provisioned or re-provisioned, and anytime there is no connectivity to the SQL server. Along with the zillion other errors that flood the Application Event Log when SQL connectivity is lost.
Events 6125, 6126 FIMSynchronizationService, SharePoint server
These errors stopped after I did another full synchronization with full import. I am perplexed as to why they occurred to begin with. I had not changed any UPS settings or added users to the AD Organizational Unit (OU) UPS synchronizes against.
Event 10016, DCOM, SharePoint server
This error started after the Forefront Services started but before setting up the Synchronization Connection. The error reoccurred six times over the next 2 days, during which time I did various tasks related to User Profiles (synchronization, setting the My Site parameters in the User Profile service application, creating My Site Host and a personal My Site). With those tasks completed, the error occurred only once nightly, at the end of the SharePoint reconfiguration process run by MsiInstaller, until the day I gave the Network Service account Full Control NTFS permissions to the \14.0\* directory structure. The error has not occurred since.
Note that the CLSID referenced is different than that for the well-known issue “Grant Local Activation Permissions to the IIS WAM REG admin service” for which the fix is readily available on the Internet. [For applying that fix on Windows Server 2008 R2 see Wictor Wilen’s Fix the SharePoint DCOM10016 error on Windows Server 2008 R2 walk-through.] This CLSID refers to the Windows Installer service. Searching on DCOM 10016 + the CLSID did not turn up much information but did lead to Rickey Whitworth’s comments in this forum thread http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/dacb4d0c-817b-42cd-8c29-f6fc4c38904a about running into issues after granting the Network Service local activation rights to Windows Installer. As my success matched Mr. Whitworth's success after ignoring the errors I decided not to do anything.
Tidbit: If the same error occurs with the same CLSID but references the farm account, adding the farm account to the Local Administrators group eliminates the error. Poking around, I found that the Administrators group has Full Launch and Activation permissions for the MSiInstaller service. But of course, you are not supposed to have the farm account in the local Administrators group after UPS provisioning is completed. And the DCOM error, though annoying (partcularly to those of us who like clean Event Logs), is supposedly benign.
Event 5555, SharePoint Portal Server
This is the error I blethered about in this series Introduction. The short version: It occurred once daily at 6:11 AM for each content database except every once in a while it did not occur. It also flea-hopped between the SharePoint server and SQL server (meaning, it would stop on one server, miss a day or so, then start up on the other server). It did not appear to affect the User Profile system (UPSA, UPS) in any way. The fix, obtained by a forum poster from MSFT Support, was to change the Timer Service Recycle Job from 6 AM to 6:30 PM. The error did occur several times after that on the SQL server but then disappeared. Incidentally, a 5555 error will occur once every hour when network connectivity between SQL and SharePoint is down, but network connectivity was not our issue.
Next up in Part 4 of the never ending post-install configuration saga: Creating an Enterprise Search Center, BI Center, personal My Site, and more.