Print | posted on Monday, July 23, 2012 4:55 PM
SharePoint Server 2013’s User Profile Service Application includes a “new” method for performing an import of user attributes from Active Directory into the SharePoint Profile store called Active Directory Import. You may also hear or see this referred to as “AD Direct Mode” in pre-release materials.
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 2013 Preview release. Things are likely to change between now and the final release of SharePoint Server 2013. 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?
When SharePoint 2010 shipped many were extremely happy, that after years of being asked for it, Microsoft finally decided to implement a mechanism to “write back” profile properties to Active Directory. This was by far and away the most requested capability within the Profiles arena. SharePoint chose to implement this by leveraging Forefront Identity Manager (FIM). This was absolutely the right call as FIM provides numerous other foundational capabilities necessary to enable key scenarios (e.g. Office 365) and many other benefits with respect to reaching a broader range of directory services.
However as I’m sure many of you are aware, the SharePoint implementation of FIM didn’t come without it’s fair share of pain. The phenomenon of “stuck on starting” was omni-present, just getting the User Profile Synchronization service instance up and running was one of the most common deployment challenges. 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 2010, this was a extremely painful aspect for many customers. It is worth noting at this point that virtually all of the “rough edges” of UPS have since been addressed. However an alternative approach is still desirable in many scenarios.
Furthermore customers were happy with their import filters from SharePoint 2007 to define which objects were imported. These LDAP filters could not be migrated to UPS. Many tried but they all failed. The filters needed to be re-implemented using the FIM approach (and a terrible UI in SharePoint, with no PowerShell alternative). Some things possible with an LDAP filter are simply not possible with a FIM filter.
Whilst User Profile “write back” was the most common feature request a great deal of customers had no need for it whatsoever. If we take a trip down memory lane, the capability to import AD users into SharePoint Server 2007 was just the ticket for lots of customers. No fiddly setup, no fiddly permission requirements. It just worked.
These considerations, and some more drove the decision to implement AD Import. It is important to understand though that they haven’t just brought back what was in 2007. This is a brand new implementation.
The first key aspect of AD Import, as it’s name suggests it’s import only. It’s also important to note that the AD Import method only supports importing from Active Directory. If this is your requirement in a nutshell then AD import is for you. Other LDAP directories are not supported and UPS is the right choice for these. You’ll need to wait for my future coverage of the changes to User Profile Synchronization.
How does it work?
Once configured AD Import Mode runs as part of the User Profile Service instance, not the User Profile Synchronization Service Instance (which is the wrapper for FIM). 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:
- no requirement to deploy the UPS service instance, no “stuck on starting”
- it runs in the UP service instance
- it’s wicked fast in comparison to the FIM approach
- you can leverage old skool LDAP filters to constrain the objects being imported
- by default an incremental import will run every five minutes
- no Farm Account in the local admins shenanigans
- you don’t have to worry about an esoteric configuration option with the mystical name NetBiosDomainNames
- get up and running quickly and easily, especially to enable key “social” scenarios in SharePoint 2013.
Aight, perfect. 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. NOT the UPS service instance, the plain old regular User Profile service instance.
Then we need a User Profile Service Application (UPA). No change here really from SharePoint 2010. There are a couple of notes however. The Profile Synchronization Instance property is still required to create a UPA. We won’t use it, but when we create the UPA SharePoint doesn’t know which mode we want, so it’s still here (and just as useless as it always was at this point). Secondly we still must create a Sync DB. For the same reason, even if we won’t be using it, the system doesn’t know that yet. So an empty database is created.
Once we have the UPA created, we can go ahead and manage it. In the Manage Profile Service page, we click the Configure Synchronization Settings link within the Synchronization section.
On the Configure Synchronization Settings page, in the Synchronization Options section, select the Use SharePoint Active Directory Import radio button. Notice when we do this, the other options above are disabled. Don’t even think of clicking on the Enable External Identity Manager option, more on that topic in a future post. Click OK.
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. Click the Configure Synchronization Connections link in the Synchronization Options section.
From the Synchronization Connections page, click the Create New Connection button.
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. As you will have already noticed the UI is being reused and has not been improved at all from 2010 in terms of usability and it is only partially aware of the "mode” of operation, hence the use of the word Synchronization everywhere.
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.
In the Connection Settings area, enter a domain name in the Fully Qualified Domain Name text box. 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. and there is no domain controller text box. Forests with multiple domains are fully supported, however a single connection per domain is required (and most would agree that’s a good thing). Shadow accounts are also fully supported for those in Resource/User domain scenarios.
Select an Authentication Provider Type (Windows Authentication, Forms (actually LDAP) or Trusted Provider Claims). 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. There’s no ifs or buts. It must have it. And that’s a good thing. 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.
At the end of the Connection Settings area is a text box, Filter in LDAP syntax for Active Directory Import. It’s what you’ve all been waiting for. But alas it’s quite a small text box :). I can’t see many valid LDAP filters fitting in this little box. But hey you’re gonna author that thing in ADSIEdit anyway and copy and paste it in. 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.
Further down the Add New Synchronization Connection page in the Containers area we have the Populate Containers button. Click it to populate the tree view. This will validate connectivity to the domain under the credentials provided. It will NOT validate that the account has Replicating Directory Changes permissions. This is something I really hope they add before RTM. Validating those permissions will save a ton of support incidents and customer confusion. And it’s five lines of PowerShell to do the check. 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. In my example I’m using the single OU SharePoint Users.
Use the utterly awesome breadcrumb to navigate back to the Manage Profile Service Page! :). Sadly this isn’t fixed either so find your way back there via the left hand side navigation or the browser back button!
By default we don’t need to do anything. 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. Let’s take a look at the ULS to see what’s happening in that timer job. The first thing we will see is that unlike UPS we have a ton of information. Because this is all part of the UP service instance it’s operations are bubbled up thru ULS which is much more difficult and in some cases impossible with UPS and FIM.
The initial entries show that the Import is being kicked off:
w3wp.exe (0x0780) aei7w High StartImport :: Starting profile full import.
w3wp.exe (0x0780) aei7y Medium StartImport :: All DNLookup table entries have been reset.
w3wp.exe (0x0780) aei70 Medium StartImport :: SyncCookie for connection 'corp.contoso.com' has been reset.
w3wp.exe (0x0780) aei74 Medium StartImport :: Profile Import has been started
Then we move into the timer service and start the actual work:
OWSTIMER.EXE (0x06EC) aei64 Medium UserProfileADImportJob: Begin executing.
OWSTIMER.EXE (0x06EC) aei67 Medium UserProfileADImportJob:ImportDC -- Importing from DC 'corp.contoso.com' at RootOU 'DC=corp,DC=contoso,DC=com' for UPA 'b3d5e852-5e29-4c9b-aeef-accb7ec6e0fb' with maximum errors '5000000', filter size '100' and batch size '2000'
OWSTIMER.EXE (0x06EC) aepu6 Medium GetDomain: Found NetBIOS Domain Name for entry# 3: at rootDN 'DC=corp,DC=contoso,DC=com', ConfigurationNamingContext 'LDAP://CN=Configuration,DC=corp,DC=contoso,DC=com', PartitionsContainer 'CN=Partitions,CN=Configuration,DC=corp,DC=contoso,DC=com', ncName 'DC=corp,DC=contoso,DC=com', nETBIOSName 'CORP'.
OWSTIMER.EXE (0x06EC) ags9z Medium Computed Search Filter for ScanDirSyncChanges (|(&(objectClass=user))(objectClass=group)).
OWSTIMER.EXE (0x06EC) aei4r Medium ScanDirSyncChanges: Entering with LdapServer 'corp.contoso.com', rootDn 'DC=corp,DC=contoso,DC=com', filter '(|(&(objectClass=user))(objectClass=group))'
OWSTIMER.EXE (0x06EC) aei4s Medium ScanDirSyncChanges: Retrieved stored dirSync cookie for rootDn 'DC=corp,DC=contoso,DC=com'
Note line 3. I entered a FQDN of corp.contoso.com in my connection, which is different from the Net Bios Domain Name (CORP). I didn’t have to set a property of the UPA to allow this to work correctly, because AD Import mode discovers this during the import itself.
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.
OWSTIMER.EXE (0x06EC) aei4u Medium ScanDirSyncChanges: Created DirSync Request Control and Request with LdapServer 'corp.contoso.com', rootDn 'DC=corp,DC=contoso,DC=com', filter '(|(&(objectClass=user))(objectClass=group))'
OWSTIMER.EXE (0x06EC) aei40 Unexpected ScanDirSyncChanges: Exception thrown by Dirsync request: page 0, LdapServer 'corp.contoso.com', rootDn 'DC=corp,DC=contoso,DC=com', exception 'System.DirectoryServices.Protocols.DirectoryOperationException: The user has insufficient access rights. at System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(Int32 messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, Boolean exceptionOnTimeOut) at System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout) at Microsoft.Office.Server.UserProfiles.ADImport.DirSyncWrapper.ScanDirSyncChanges(ProfileConfiguration profileConfig, LdapConnection ldapConnection, UserProfileADImportMapping adMapping, String rootDn, String filter, TimeSpan& externalTimeSpentInProfile, TimeSpan& externalTimeSpentInDirectory, Int64& totalSuccesses, Int64& totalFailures, Int64& totalIgnored, SPUserProfileADImportUsageEntry usage, Int64 defragIncrement, Int64 defragThresholdInMilliseconds, Int32 loopCount, Boolean& fEventLogged)'
OWSTIMER.EXE (0x06EC) agnx7 Medium ScanDirSyncChanges: bBailOut is TRUE set profileConfig Bailout and break
OWSTIMER.EXE (0x06EC) agnx8 Medium Setting profileConfig Bailout to value = True
OWSTIMER.EXE (0x06EC) aei68 Medium UserProfileADImportJob:ImportDC -- Regular DirSync scan: successes '0', failures '0', ignored '0', total duration '0', external time in Profile '0', external time in Directroy '0' (times in milliseconds)
OWSTIMER.EXE (0x06EC) aei7b Medium UserProfileADImportJob:ImportDC -- Error Item scan: successes '0', failures '0', ignored '0', total duration '0', external time in Profile '0', external time in Directroy '0' (times in milliseconds)
OWSTIMER.EXE (0x06EC) aepvd Medium UserProfileADImportJob:ImportDC -- Data Import from DC 'corp.contoso.com' at RootOU 'DC=corp,DC=contoso,DC=com' for UPA 'b3d5e852-5e29-4c9b-aeef-accb7ec6e0fb' is 'incomplete'.
OWSTIMER.EXE (0x06EC) aepvc High UserProfileADImportJob: Incomplete Data Import: NOT triggering post import operations!
OWSTIMER.EXE (0x06EC) aei66 Medium UserProfileADImportJob: End executing.
Line 1 makes the request for DirSync, and as I haven’t set that yet on purpose to show what happens, an exception is thrown (line 2). 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!) until we provide the account with replicating directory changes permissions.
Here is the activity once the permission is granted:
w3wp.exe (0x0BC8) aei7w High StartImport :: Starting profile full import.
w3wp.exe (0x0BC8) aei7y Medium StartImport :: All DNLookup table entries have been reset.
w3wp.exe (0x0BC8) aei70 Medium StartImport :: SyncCookie for connection 'corp.contoso.com' has been reset.
w3wp.exe (0x0BC8) aei74 Medium StartImport :: Profile Import has been started
OWSTIMER.EXE (0x06EC) aei64 Medium UserProfileADImportJob: Begin executing.
OWSTIMER.EXE (0x06EC) aei67 Medium "UserProfileADImportJob:ImportDC -- Importing from DC 'corp.contoso.com' at RootOU 'DC=corp,DC=contoso,DC=com' for UPA 'b3d5e852-5e29-4c9b-aeef-accb7ec6e0fb' with maximum errors '5000000', filter size '100' and batch size '2000'"
OWSTIMER.EXE (0x06EC) aepu6 Medium "GetDomain: Found NetBIOS Domain Name for entry# 3: at rootDN 'DC=corp,DC=contoso,DC=com', ConfigurationNamingContext 'LDAP://CN=Configuration,DC=corp,DC=contoso,DC=com', PartitionsContainer 'CN=Partitions,CN=Configuration,DC=corp,DC=contoso,DC=com', ncName 'DC=corp,DC=contoso,DC=com', nETBIOSName 'CORP'."
OWSTIMER.EXE (0x06EC) ags9z Medium Computed Search Filter for ScanDirSyncChanges (|(&(objectClass=user))(objectClass=group)).
OWSTIMER.EXE (0x06EC) aei4r Medium "ScanDirSyncChanges: Entering with LdapServer 'corp.contoso.com', rootDn 'DC=corp,DC=contoso,DC=com', filter '(|(&(objectClass=user))(objectClass=group))'"
OWSTIMER.EXE (0x06EC) aei4s Medium "ScanDirSyncChanges: Retrieved stored dirSync cookie for rootDn 'DC=corp,DC=contoso,DC=com'"
OWSTIMER.EXE (0x06EC) aei4u Medium "ScanDirSyncChanges: Created DirSync Request Control and Request with LdapServer 'corp.contoso.com', rootDn 'DC=corp,DC=contoso,DC=com', filter '(|(&(objectClass=user))(objectClass=group))'"
OWSTIMER.EXE (0x06EC) aei53 Medium CreateProfileImportExportId: Calling InitializeProfileImportExportProcess for end point 'direct://sp01:8080/_vti_bin/profileimportexportservice.asmx?ApplicationID=b3d5e852-5e29-4c9b-aeef-accb7ec6e0fb'.
OWSTIMER.EXE (0x06EC) aei6f Medium SendCurrentBatch: Sending '2' changes for Tenant '0c37852b-34d0-418e-91c6-2ac25af4be5b' by calling UpdateWithProfileChangeData on host 'direct://sp01:8080/_vti_bin/profileimportexportservice.asmx?ApplicationID=b3d5e852-5e29-4c9b-aeef-accb7ec6e0fb' with ImportExportId '2'.
OWSTIMER.EXE (0x06EC) ajk39 Medium UserProfileDBCache_WCFLogging::Begin ProfileDBCacheServiceClient.GetUserData.ExecuteOnChannel
OWSTIMER.EXE (0x06EC) ajk35 Medium MossClientBase_WCFLogging::Begin MossClientBase.ExecuteOnChannel
OWSTIMER.EXE (0x06EC) ajk36 Medium MossClientBase_WCFLogging:: MossClientBase.ExecuteOnChannel - Executing codeblock on channel
w3wp.exe (0x0780) ahqqu High "[Forced due to logging gap, Original Level: Verbose] DBCache.GetBulk: returning PersonalSpace={0}, FeedIdentifier={1}"
OWSTIMER.EXE (0x06EC) ajk37 Medium MossClientBase_WCFLogging:: MossClientBase.ExecuteOnChannel - Executed codeblock on channel
OWSTIMER.EXE (0x06EC) ajk4a Medium UserProfileDBCache_WCFLogging::End ProfileDBCacheServiceClient.GetUserData.ExecuteOnChannel
OWSTIMER.EXE (0x06EC) aer4e Medium "Exception while updating properties for 'CORP\test1': Property: Url, Exception Microsoft.Office.Server.UserProfiles.PropertyNotDefinedException: Property Not Defined: Url. An administrator must create this property in the Profile Administration tool. at Microsoft.Office.Server.UserProfiles.UserProfile.get_Item(String strPropName) at Microsoft.Office.Server.UserProfiles.UserProfile.GetProfileValueCollection(String propName) at Microsoft.Office.Server.UserProfiles.UserProfile.BulkPropertiesUpdate(Int64 importExportId, Hashtable properties, String strAccountName)."
OWSTIMER.EXE (0x06EC) aer4e Medium "Exception while updating properties for 'CORP\test1': Property: Member, Exception Microsoft.Office.Server.UserProfiles.PropertyNotDefinedException: Property Not Defined: Member. An administrator must create this property in the Profile Administration tool. at Microsoft.Office.Server.UserProfiles.UserProfile.get_Item(String strPropName) at Microsoft.Office.Server.UserProfiles.UserProfile.GetProfileValueCollection(String propName) at Microsoft.Office.Server.UserProfiles.UserProfile.BulkPropertiesUpdate(Int64 importExportId, Hashtable properties, String strAccountName)."
OWSTIMER.EXE (0x06EC) aer4e Medium "Exception while updating properties for 'CORP\test1': Property: DCId, Exception Microsoft.Office.Server.UserProfiles.PropertyNotDefinedException: Property Not Defined: DCId. An administrator must create this property in the Profile Administration tool. at Microsoft.Office.Server.UserProfiles.UserProfile.get_Item(String strPropName) at Microsoft.Office.Server.UserProfiles.UserProfile.GetProfileValueCollection(String propName) at Microsoft.Office.Server.UserProfiles.UserProfile.BulkPropertiesUpdate(Int64 importExportId, Hashtable properties, String strAccountName)."
OWSTIMER.EXE (0x06EC) ogvr High "User profile record of ""CORP\test1"" was changed by ""CORP\spfarm""."
OWSTIMER.EXE (0x06EC) ajk39 Medium UserProfileDBCache_WCFLogging::Begin ProfileDBCacheServiceClient.GetUserData.ExecuteOnChannel
OWSTIMER.EXE (0x06EC) ajk35 Medium MossClientBase_WCFLogging::Begin MossClientBase.ExecuteOnChannel
OWSTIMER.EXE (0x06EC) ajk36 Medium MossClientBase_WCFLogging:: MossClientBase.ExecuteOnChannel - Executing codeblock on channel
OWSTIMER.EXE (0x06EC) ajk37 Medium MossClientBase_WCFLogging:: MossClientBase.ExecuteOnChannel - Executed codeblock on channel
OWSTIMER.EXE (0x06EC) ajk4a Medium UserProfileDBCache_WCFLogging::End ProfileDBCacheServiceClient.GetUserData.ExecuteOnChannel
OWSTIMER.EXE (0x06EC) aer4e Medium "Exception while updating properties for 'CORP\test 2': Property: Url, Exception Microsoft.Office.Server.UserProfiles.PropertyNotDefinedException: Property Not Defined: Url. An administrator must create this property in the Profile Administration tool. at Microsoft.Office.Server.UserProfiles.UserProfile.get_Item(String strPropName) at Microsoft.Office.Server.UserProfiles.UserProfile.GetProfileValueCollection(String propName) at Microsoft.Office.Server.UserProfiles.UserProfile.BulkPropertiesUpdate(Int64 importExportId, Hashtable properties, String strAccountName)."
OWSTIMER.EXE (0x06EC) aer4e Medium "Exception while updating properties for 'CORP\test 2': Property: Member, Exception Microsoft.Office.Server.UserProfiles.PropertyNotDefinedException: Property Not Defined: Member. An administrator must create this property in the Profile Administration tool. at Microsoft.Office.Server.UserProfiles.UserProfile.get_Item(String strPropName) at Microsoft.Office.Server.UserProfiles.UserProfile.GetProfileValueCollection(String propName) at Microsoft.Office.Server.UserProfiles.UserProfile.BulkPropertiesUpdate(Int64 importExportId, Hashtable properties, String strAccountName)."
OWSTIMER.EXE (0x06EC) aer4e Medium "Exception while updating properties for 'CORP\test 2': Property: DCId, Exception Microsoft.Office.Server.UserProfiles.PropertyNotDefinedException: Property Not Defined: DCId. An administrator must create this property in the Profile Administration tool. at Microsoft.Office.Server.UserProfiles.UserProfile.get_Item(String strPropName) at Microsoft.Office.Server.UserProfiles.UserProfile.GetProfileValueCollection(String propName) at Microsoft.Office.Server.UserProfiles.UserProfile.BulkPropertiesUpdate(Int64 importExportId, Hashtable properties, String strAccountName)."
OWSTIMER.EXE (0x06EC) ogvr High "User profile record of ""CORP\test 2"" was changed by ""CORP\spfarm""."
OWSTIMER.EXE (0x06EC) aei56 Medium FlushProfileImportExportId: Calling FinalizeProfileImportExportProcess for importExportId '2' for end point 'direct://sp01:8080/_vti_bin/profileimportexportservice.asmx?ApplicationID=b3d5e852-5e29-4c9b-aeef-accb7ec6e0fb'.
OWSTIMER.EXE (0x06EC) aei68 Medium "UserProfileADImportJob:ImportDC -- Regular DirSync scan: successes '2', failures '0', ignored '52', total duration '265.2', external time in Profile '249.6', external time in Directroy '15.6' (times in milliseconds)"
OWSTIMER.EXE (0x06EC) aei7b Medium "UserProfileADImportJob:ImportDC -- Error Item scan: successes '0', failures '0', ignored '0', total duration '0', external time in Profile '0', external time in Directroy '0' (times in milliseconds)"
OWSTIMER.EXE (0x06EC) aepvd Medium "UserProfileADImportJob:ImportDC -- Data Import from DC 'corp.contoso.com' at RootOU 'DC=corp,DC=contoso,DC=com' for UPA 'b3d5e852-5e29-4c9b-aeef-accb7ec6e0fb' is 'complete'."
OWSTIMER.EXE (0x06EC) afoeg Medium UserProfileApplication.SynchronizationPostProcessing: About to call IMPORTEXPORT_PostImportUserProperties
OWSTIMER.EXE (0x06EC) afoeh Medium UserProfileApplication.SynchronizationPostProcessing: Returned from IMPORTEXPORT_PostImportUserProperties
OWSTIMER.EXE (0x06EC) aepva Medium UserProfileADImportJob: Completed Data Import: triggering post import operations
OWSTIMER.EXE (0x06EC) afoeg Medium UserProfileApplication.SynchronizationPostProcessing: About to call IMPORTEXPORT_PostImportUserProperties
OWSTIMER.EXE (0x06EC) afoeh Medium UserProfileApplication.SynchronizationPostProcessing: Returned from IMPORTEXPORT_PostImportUserProperties
OWSTIMER.EXE (0x06EC) afoei Medium UserProfileApplication.SynchronizationPostProcessing: About to call IMPORTEXPORT_PostImportMembers
OWSTIMER.EXE (0x06EC) afoej Medium UserProfileApplication.SynchronizationPostProcessing: Returned from IMPORTEXPORT_PostImportMembers
OWSTIMER.EXE (0x06EC) aepvb Medium UserProfileADImportJob: Completed post import operations.
OWSTIMER.EXE (0x06EC) aei66 Medium UserProfileADImportJob: End executing.
Naturally this time the DirSync request doesn’t bail out (line 11) and we continue on and get a batch of updates to make (line 13) and then update the profiles for the users (lines 23 and 32). Note that it states the profile was updated by the Farm account, not the account we entered in the Synchronization connection screen. This is because it’s a timer job and therefore in SPTimverV4 – which always runs as the Farm Account. 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’ve deliberately only used a couple of users to try and keep the ULS above semi-readable. But take my word for it with a real set of users it’s lightning fast in comparison to UPS. I am not going to talk specific performance numbers until RTM. It’s also smart enough to batch up changes so it won’t attempt to do 500,000 updates in one go. By default the batch size is 2,000. 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 2013:
Rock on! Time to get “social” or whatever these young people keep saying is the new new thing. Or is that the new old thing? At any rate, Profiles remain the critical foundation of “social” in SharePoint.
The SharePoint AD Import “mode” is a significant addition to the User Profile Service Application in SharePoint Server 2013, and provides some great benefits.
There is no need to even provision the UPS service instance, the Sync DB remains a empty database. We have no need to deal with the thorny problems of delivering HA for the UPS service instance as it’s not even there! We get it for free as part of the UP service instance. Furthermore we can use LDAP filters and it’s faster than Usain Bolt. We also get decent diagnostics via a first class job of instrumentation by the development team responsible. Who’d have thunked it. Using UPA as an example of how to do something right.
But remember two key things. It’s import only! Should be obvious right? Experience tells us that obvious doesn’t mean well understood. If you want to update your directory with changes made in SharePoint, this won’t cut the mustard. Second. You must provide Replicating Directory Changes permissions to the account you enter on the sync connection page. No debate. It’s how it is, and it makes it much more efficient.
There are some other limitations of the AD Import mode. We cannot map AD attributes to “system” SharePoint Profile properties. These are the guys whose name begins with the SPS- prefix. We also cannot map two different attributes to the same profile property. We cannot do cross string type mappings (a value string attribute to a multi value string property or vice versa).
If you are looking to augment profiles with additional data from a line of business system via BDC you cannot use AD Import, you must use UPS in that scenario.
Another really cool aspect is we can switch between modes. So we can start with AD Import, and later on move to UPS if we discover we need it. This is extremely good news.
Now there are caveats here. When we create a connection for AD Import that connection is stored in the Profile DB. With UPS the connection is in the Sync DB. The connection will not be migrated, neither are the filters and property mappings. And remember because the constraints for these are different, even if it was possible (it’s not) it wouldn’t be a good idea.
So there you have it, a first look at Active Directory Import in SharePoint Server 2013. It kicks ass. I hope this information is useful, stay tuned for more articles and rants about SharePoint 2013 over the coming months as things heat up on the road to RTM.
s.