Active Directory: Tips from the front line

In the fourth part of his diary of implementing SharePoint 2010, Robert Schifreen starts to encounter some of the intricacies of Active Directory integration.

As you should expect with a Microsoft product, Active Directory is central to user authentication and permissions management.

If only its importance was matched by its implementation.

If a user is logged into their Windows PC in the corporate domain, there is an in-built single sign-on with SharePoint. Visiting the SharePoint URL will get them straight in and authenticate them. But it knows nothing about the user except their username, which initially puts paid to doing social-networking stuff.

AD Sync

SharePoint can't look up users' information in Active Directory (AD) on the fly. Instead, it has a User Profiles database which, alongside each person's username, holds their full name, job title, location, photograph, boss's name, and dozens more attributes besides. You need to set up AD Sync to regularly and automatically copy everyone's up-to-date details from AD into the User Profile database.

Unfortunately, despite this being one of the key facets of running a successful corporate SharePoint installation, it's also buggy as hell.

It's a pain to set up, and it's prone to stop working for no particular reason at any time while displaying a helpful diagnostic report such as "an unexpected error has occurred", followed by the customary 20-odd character hex string, which is the "correlation ID" via which you're supposed to be able to look through the log files for further information.

AD sync issues, and especially failing to get the underlying Windows service to start at all, is a common complaint on all of the support forums.

When it does work, AD sync is great. When I log into my test rig it displays my name, job title, location, phone number, and all the other information that I've chosen to import. Except that my name appears as Schifreen Robert. Everyone else is back-to-front too, as for historical reasons that no one remembers, our AD is configured to show names in reverse order.

AD sync issues, and especially failing to get the underlying Windows service to start at all, is a common complaint on all of the support forums.

The users have become accustomed to it in Outlook (it makes searching for people much easier), but I really didn't want my SharePoint farm to present the information that way. So I spent the next day or so learning just enough PowerShell to write a little program that runs on the SharePoint server every morning and, for each user profile in its database, sets the PreferredName field to Firstname Surname.

Another couple of hours Googling for more PowerShell tips and tricks, and I found a solution to another outstanding problem: SharePoint takes about two minutes to log you in if you're the first user of the day. I don't quite know what it does overnight, but apparently it's a general Internet Information Services (IIS) thing rather than specific to SharePoint. A wake-up script that automatically logs into each site before our users are awake fixed it just fine. I found a free one online.

Occasional use of PowerShell, not to mention other deep techie SharePoint techniques such as Feature Stapling, will need to become part of the repertoire of anyone looking after a corporate SharePoint setup. As I mentioned earlier, any claim by Microsoft that it can do everything you need out of the box is slightly wide of the mark.

Creative AD

SharePoint complements Active Directory beautifully, as you might expect from two key Microsoft technologies.

SharePoint can automatically generate an org chart for your team or department, based on information in AD about who each staff member reports to. There's a facility to define people as your colleagues, but anyone in your team is automatically assigned so there's often no need for you to do anything at all.

Assuming, of course, that your AD actually contains the relevant information regarding managers and reports. Ours, I discovered, didn't. Hopefully we can rectify this in due course, but extracting the data from the deepest recesses of Personnel's own systems isn't something that can be done overnight. My people will clearly have to talk to their people.

This is just one example of where a key SharePoint feature actually relies on other parts of your existing infrastructure in order to function. If the infrastructure isn't there, the feature simply won't work.

SharePoint's link to AD isn't just a one-way street. As well as reading, SharePoint can write to AD too. So a SharePoint user can edit specified (by the administrators) parts of their profile within SharePoint and have that information written back into the Active Directory. If you want to be able to do this, that's great. In our case, we absolutely didn't want to allow it. Our AD is fed from all sorts of carefully tested internal and external systems and we're not ready for students or staff to edit their data directly. At least, not yet.

SharePoint complements Active Directory beautifully, as you might expect from two key Microsoft technologies.

According to TechNet, SharePoint can't write back to AD unless it's been given explicit permission to do so by the AD administrator, and the account that's used for syncing SharePoint and AD is read-only by default. But this didn't satisfy our AD admin people, who insisted on setting up an entirely new test domain controller, SharePoint server and separate AD in order to ensure that it was indeed the case. 

To be fair, I don't blame them. The delay gave me time to read yet more SharePoint books, and to attend some useful events. There's a UK SharePoint User Group, which meets occasionally and also has a website. I attended a useful meeting at Southampton University, which was a good opportunity to talk to like-minded people and which helped to convince me that nothing we'd encountered or decided so far was out of the ordinary or particularly stupid.

I also attended a SharePoint Saturday event at the University of Nottingham that served a similar purpose while also allowing me to listen to lots of very interesting presentations. If there's ever a SharePoint Saturday event near you, go. It's great.

Next: Scripts and profiles. Robert gets to grips with PowerShell

Robert Schifreen has reported on and implemented online technology since the early 1980s. His latest project has been a large SharePoint 2010 installation in tertiary education. We will be serialising his experiences, positive and negative, in getting it to the stage where it's ready for action; the entire series will also be available as a downloadable white paper.