This method provides numerous advantages over the Forefront Identity Manager based approach which is still available, more on that at a later date for certain common scenarios. This article provides an introductory overview of the feature and why it might be useful in your deployments. Please note that this article applies to the SharePoint Server Preview release. Things are likely to change between now and the final release of SharePoint Server I will update this post shortly after RTM.
In the meantime, give the SharePoint team a break when it comes to fit and finish in the UI: Why Active Directory Import? This was by far and away the most requested capability within the Profiles arena. This was absolutely the right call as FIM provides numerous other foundational capabilities necessary to enable key scenarios e.
Office and many other benefits with respect to reaching a broader range of directory services. My previous article on the setup and configuration is by far and away the most popular item on this blog. And then there was the incredible slowness of importing users. Until later builds of SharePoint , this was a extremely painful aspect for many customers.
However an alternative approach is still desirable in many scenarios. Furthermore customers were happy with their import filters from SharePoint to define which objects were imported. Many tried but they all failed. If we take a trip down memory lane, the capability to import AD users into SharePoint Server was just the ticket for lots of customers. No fiddly setup, no fiddly permission requirements.
These considerations, and some more drove the decision to implement AD Import. This is a brand new implementation. If this is your requirement in a nutshell then AD import is for you. How does it work? In fact we have no need to even deploy a UPS service instance in the farm at all. That right there is a huge win for many! We can then go ahead and configure a Synchronization Connection and schedule the import process to run in virtually an identical fashion as we did with UPS.
What are the key benefits? You might like some of these: Let me at that bad boy. How do we configure it? The first step is to start the User Profile service instance UP on a server in the farm. No change here really from SharePoint There are a couple of notes however. Secondly we still must create a Sync DB. So an empty database is created. Once we have the UPA created, we can go ahead and manage it.
Notice when we do this, the other options above are disabled. You will notice that the Profile Synchronization Settings display towards the bottom right of the page has been updated to reflect that something is now scheduled to happen and that we have a status indicator.
The next step is to configure a Synchronization Connection. On the Add New Synchronization Connection page, we have a broadly similar bunch of options as we had before with a couple of notable differences.
Enter a name for the connection in the Connection Name text box. Note that the Type combo box has only the single option, Active Directory Import. Note that the help text is simply reused from the UPS sync connections screen and is not accurate. This is a domain name, not a forest name. To keep things simple for this walkthrough choose the default, Windows Authentication. Then enter in the Account Name and Password for the account which you wish to use to perform the import.
This should ideally be a specific account used for this purpose and it does not need to be a Managed Account. UPA is still wholly ignorant of managed accounts. This part is very important. This account must have Replicating Directory Permissions on the domain we wish to import from.
It must have it. I will follow up on this in more detail in a later post. For now all you need to know is the account must have these permissions or it will NOT work. The point is that you can do it.
Remember this is a preview release. Note that if all we wish to filter are disabled accounts, we can check the Filter out disabled users check box, and no filter is necessary. We can use both this option and filters together if needed. Click it to populate the tree view. This will validate connectivity to the domain under the credentials provided. This is something I really hope they add before RTM. Validating those permissions will save a ton of support incidents and customer confusion.
If you agree with me, tell them by posting feedback via the Preview mechanism. And tell them Spence sent you! Select the objects you wish to import from in the tree view and click the OK button to save the changes. Use the utterly awesome breadcrumb to navigate back to the Manage Profile Service Page!
Our import will kick off in five minutes time. We can change that schedule if we wish and we probably should in the Configure Synchronization Timer Job page. Or we can kick it off immediately by going to the Start Profile Synchronization page, and selecting the Start Full Synchronization radio button and clicking OK. In a few moments the import will start. The first thing we will see is that unlike UPS we have a ton of information. The initial entries show that the Import is being kicked off: Starting profile full import.
All DNLookup table entries have been reset. SyncCookie for connection 'corp. Profile Import has been started Then we move into the timer service and start the actual work: Entering with LdapServer 'corp. I entered a FQDN of corp. The next step checks for a thing called DirSync. This is the Replicating Directory Changes permission mentioned earlier. DirSync is simply the geek speak term for it. Exception thrown by Dirsync request: The user has insufficient access rights.
ImportDC -- Error Item scan: NOT triggering post import operations! A bunch of additional diagnostics are written and then it bails out. Sadly nothing it provided in the Central Admin UI. This will repeat as long as the timer job is enabled and it will just keep going not doing any import! Here is the activity once the permission is granted: Sending '2' changes for Tenant '0cbdecac25af4be5b' by calling UpdateWithProfileChangeData on host 'direct: ExecuteOnChannel - Executing codeblock on channel w3wp.
An administrator must create this property in the Profile Administration tool. Completed post import operations. Note that it states the profile was updated by the Farm account, not the account we entered in the Synchronization connection screen. Ignore the exceptions above — these are expected with the out of the box property mappings and need to be wired up.
We then tidy the batch up and finish execution. I am not going to talk specific performance numbers until RTM. By default the batch size is 2, This may change come RTM based on performance and scalability testing. The end result, of course, is that our profiles are now imported and can be leveraged across UPA and the rest of SharePoint Or is that the new old thing?