Spence Harbar discussed the User Profile Service and considerations for Enterprise Deployments. Right off, he stated that the MCM class spends 6 hours on UPS! Certainly, 90 minutes is not sufficient to cover everything but I took some notes that you’ll find in this article.
Spence spoke about Identity Management as a key foundation for UPS and the fact that it’s a very political topic (10% technology, 90% business/politics). To help ensure a good identity management foundation exists, we need to answer some key questions:
- Ownership: Who owns the data? Where’s the authoritative source?
- Data Quality: Does the data exist? Is it up to date and accurate? Is it compliant?
- System Quality: What’s the health of systems managing the data (AD Health?)
- Access: How do you authenticate and access the systems managing identity data.
Tip: Be friendly to your directory services management team. You’ll need coordination, communication, and change control.
Architecture
There are 3 related databases for user profiles:
- SocialDB: This holds things like tags, notes, and ratings.
- ProfileDB: Hold the profile data for users and the organization and activity feeds. Should grow very large if your SharePoint deployment is focused on social networking.
- SyncDB: Hold configuration and staging information for synchronization data.
The User Profile Application (UPA) talks directly to SQL, this is why it’s not supported over the WAN (as a federated service).
SharePoint includes FIM “light,†provisioning UPS Service Instance is effectively installing and configuring FIM.
Tip: The SyncDB is a temporary holding area for synchronization data. Deleting (and re-creating) it should not be an issue. All the important (actual) data is stored in the other two related databases, SocialDB and ProfileDB.
Provisioning
Using Central Administration for provisioning UPS is not recommended. Using PowerShell for UPA provisioning provides more options, control and provides a repeatable process (since issues could easily arise). However there are some limitations or problems when using PowerShell to create the User Profile Application.
Limitations:
When using PowerShell to create the UPA, there is a Default Schema issue. The Farm Account default schema is set incorrectly in Sync DB, UPS will never start under this case. Because the user is logged in as the server administrator, that account will be dbo (rather than the Farm account).
Workarounds
- Log on to machine as Farm Account and under UAC elevation run the PowerShell to create UPA; not recommended.
- Fix default schema manually (not supported) using SQL Server Management Studio or TSQL; not recommended.
- Best method is to start PowerShell process using RunAs, pass the Farm Account credentials, and run the PowerShell script to create UPA. Essentially, you’re running a PowerShell script from a PowerShell script. AutoSPInstaller uses this method (I believe). See Spence’s post here for details: http://www.harbar.net/articles/sp2010ups.aspx
Deployment Guidance
Planning is paramount! Define what properties you’ll need and how “social†features will be used in your organization. Plan, plan, plan.
Ensure the data is accurate (remember: garbage in, garbage out) and ensure systems managing the user directory are healthy. Consider using Microsoft services to deliver an Active Directory Risk Assessment (AD RAP) when deploying large scale social deployment.
Design Constraints
You can only have one UPS Service Instance per Service Application. “Effectively replaces the Index role (from MOSS 2007) as the single point of failure.†The only way to get high-availability (HA), is to start UPS on another machine (will automatically un-provision on first machine).
Keep in mind that you cannot log ship Sync DB (its unsupported – see this article for other databases that cannot be log-shipped). Clustering is the only option to get some level of high availability. Since the Sync DB is just a temporary staging environment, you can easily create a new UPA and use your existing Profile and Social DB with no data loss.
Deploy Sync DB on dedicated SQL instance (it loves RAM) to get best sync time for large number of users.
MySites
- MySite Host can only be in a single language. Recommend using primary language of your organization. Only the default will be used for phonetic matching during search.
- Pre-creating MySites is not recommended, you’ll end up with tons of empty or unused site collections. Its very unlikely that every user will try to create a MySite during the launch of your new SharePoint Farm.
- Limit the profile properties you want to manage, it can add too much complexity and unnecessary load. Get the important things but don’t go overboard.
- Using the full version of FIM to change configuration settings with SharePoint puts your in unsupported state.
- You can use distributed MySites by creating multiple farms and a UPA in each Farm. Each MySite is added to Trusted MySite Locations. Audiences are used to redirect users to correct host. Multiple UPAs in a single Farm is not supported.
Considerations for Claims
The following are some considerations when using a SharePoint Farm in Claims-mode:
- Audiences can only be property based. No groups.
- Mapping to claims user requires manual configuration. FULL Sync required after configuration.
- You’ll need custom code for people picker to work as expected.
- Outlook Social Connector is Windows authentication only.
Tip: Deploy Service Pack 1 and the June 2011 Cumulative Update (CU) for SharePoint 2010 as these provide enhancements related to the User Profiles.
Service Pack 1 provides many enhancements including the following:
- Activity feed enabled by default
- Performance increase during synchronization
- Organization Browser fixes
- Customized security trimming
In addition, the June 2011 CU provides enhancements including the following:
- A 33% performance improvement during sync
- Improved ULS logging
Major Farm Lifecycle Events
Finally, Spence addressed some consideration for major farm lifecycle events (such as upgrades, updates, and backups). For example, installing a Cumulative Update (CU) requires re-provisioning of UPS. There is no “pause†method for UPS and PSConfig is not aware of Sync DB. Therefore, schema updates are taken care of during UPS provisioning.
UPS is stopped before a backup occurs and requires re-provisioning with many 3rd party backup solutions. Farm account must be a local admin during provisioning. If not, it will not provision (correctly).
Maintaining databases is important, however be careful. The SyncDB can become large, don’t use TSQL to fix – it’s unsupported. Spence mentioned there are scripts on the interwebz that show you how to do this but remember, they are unsupported. So, what can you do?
Just throw away UPA and recreate, use existing ProfileDB and SocialDB, no data loss incurred.
Conclusion
This was truly a 400-level session and there was much too much information to consume and regurgitate! I hope I’ve captured some key points and hope this is helpful. Spence did say that TechNet is an excellent resource. In addition, visit Spence’s blog and the resources listed here: