So we’re going out of the box here, standard disclaimer is that MS won’t support the use of the cmdlets referenced in this post for on premises deployments.

Interestingly, SharePoint 2013 does not officially support the importing of AD Lightweight Directory Services, and it is generally recommended that we approach it with the same sneakernet approach of LDIF files.  Interesting that with 2013’s new method of importing user attributed from Active Directory (AD Direct Mode) they did not include support for LDS.  But at least they managed to bypass the somewhat clumsy method of using Forefront Identity Manager (FIM) and the UPS service (Everyone remember the “stuck on starting” issue and having the Farm Admin in the local admin group?).  This is especially confusing as they also refer to it as the “light-weight Active Directory Import option”.  In our case, we’ll need the UPS to get LDS attributes into our SharePoint environment.  Still have to use the “old” ways, and in general this method is not something you want to do for a production environment.



There are numerous limitations to this method, and of course there are numerous reasons why reading users and attributes from LDS would be useful, especially when dealing with test data LDS.

I think MS gives their reasons for not officially supporting due to Admin limitations (really???)  However, PowerShell again comes to the rescue for those of us looking to get our environments up quickly with an LDS set.

Even though SharePoint 2013 does not officially support importing from AD LDS, one can import users from AD LDS using the *-SPProfileSyncConnection  SharePoint PowerShell cmdlets:

#First get our UA and say we're not going to use the ILM
$UA = @(Get-SPServiceApplication | ? {$_.TypeName -eq "User Profile Service Application"})
$UA.NoILMUsed = 1

#Now set up the connection to the LDS
Add-SPProfileSyncConnection -ProfileServiceApplication $UA -ConnectionForestName <FQDN of the AD LDS Server> -ConnectionDomain <Domain of the AD LDS User with Replicate Directory Permissions> -ConnectionUserName <AD LDS User with replicate directory permissions> -ConnectionPassword <AD LDS Password of user with Replicate DIrectory Permissions> -ConnectionSynchronizationOU <DN of OU To be imported>


While this does work, it has some major drawbacks, as the cmdlet is meant for Office 365 installs, not on premise and has other drawbacks such as ignoring the NetBIOSDomainNamesEnabled flag and various other limitations.:

  1. The account running the PowerShell host must be added as an administrator for the UPA

    This isn’t really a limitation but it upsets purists. Instead of using the Proxy, we need the UPA itself, and this means we must have at least the Manage User Profiles administration rights on the UPA. If you don’t have this and attempt to run the cmdlet, you will receive the generic error from FIM, “MOSS MA Not Found”.
  2. There is no DisplayName parameter

    The name of the connection will be the NETBIOS name of the domain, i.e. the ConnectionDomain parameter. This will also be used for the Description. This also means that you can add only one connection per domain. Now this is strong recommended practice, but it prevents some scenarios from being possible with this cmdlet and is a major oversight.
  3. There’s no option to create more than one connection per forest

    Since you have to specify the ConnectionDomain parameter. Again more than one connection per forest is strongly discouraged but there are numerous scenarios where this is needed. Again this cmdlet is no use to you if you are in that boat.
  4. If you specify the same ConnectionDomain parameter, the system will overwrite the ConnectionSynchronizationOU, ConnectionUserName and ConnectionPassword parameters.
  5. If the connection cannot be created due to a FIM error, the command completes

    No errors are reported at all! We still need to use miisclient.exe to verify things have worked!
  6. Remove-SPProfileSyncConnection does not delete sync connections!

    The Remove-SPProfileSyncConnection cmdlet only removes the ConnectionSynchronizationOU specified, will not delete the connection itself. There is no way to use these cmdlets to delete sync connections.
  7. These cmdlets only work for Active Directory Sync Connections

But as I said, it’s good for loading in all sorts of test data without having to deal with the production AD server on the network and most of the limitations will not affect small installs or test farms.