SharePoint 2013 offers multiple ways to import user accounts to the User Profile Service Application (UPSA). Our formerly
best friend, the Forefront Identity Manager (FIM), which was introduced in SharePoint 2010, is still the default option to get this job done in SharePoint 2013. Good news for all of you folks who never liked this one: the simple LDAP querying AD import option (that was used in SharePoint 2007) is available again. Spencer wrote
a really good article about AD Import for all of those who are not familiar with it.
Most customers are typically still setting up and operate their SharePoint farms using FIM. Eventually some are switching to the AD Import mode later. Those customers did not find any guidance on this task, that is the reason why I am writing this article.
There might be multiple reasons for customers to make the decision to move away from FIM. Performance and reliability are probably the most important ones, but there could be other reasons as well. Switching to AD Import might also be a good idea as a preparation for SharePoint 2016, that no longer contains FIM.
This article is supposed to give you a further insight and configuration guidance as well as the possibility to understand the differences between FIM and AD Import.
General Understanding and Comparison
The most important message right upfront: The light-weight Active Directory Import option is having limitations. Make sure you are aware of the differences before changing a productive FIM operated synced User Profile Service Application.
The most important facts (there are much more in total) at a glance:
- AD Import is one way only (Import)
- Replicating Directory Changes permissions are still necessary for to the account used within the sync connection
- User Profile Sync DB is no longer used. Existing FIM Sync Connection information are stored in the Sync DB. This needs your urgent attention in the need of manually recreating sync connections and configuration (sync filters, profile property mappings, etc). I’ll explain this later in detail
- Any additional data coming from line of business systems (via BDC) cannot be imported using AD Import. FIM is required for such Scenarios
Comparison matrix
How to switch to AD Import – Step by Step
1. Preparation: Do some important reading upfront
Before you switch from an existing SharePoint Profile Synchronization (FIM) to the lightweight AD Import mode, you should understand that these two models are not doing the same things. AD Import is having limitations. Carefully read this article and carefully read TechNet documentation. I did see customers skipping this step and they caused themselves extra work and trouble.
Read and understand:
2. Preparation: Create a documentation of current settings
This step is crucial.
Skipping this one might get you in big trouble. Make sure you create a current documentation of all existing:
- Sync Import Connections
- Fully Qualified Domain Name
- Sync Service Account
- OUs to Sync
- Sync Port
- SSL yes/no
- Sync Import Filters
- Profile Property Mappings
- User Profile Import Service Account credentials
3. Modify SharePoint Service Monitoring
If any monitoring software is surveilling the Forefront Identity Manager Synchronization Service (FIMSynchronizationService), which is running in FIM / SharePoint Profile Synchronization mode, you should disable this monitoring rule before touching anything. Changing the sync to AD Import is going to stop this service. This would cause monitoring software to create alerts about stopped services.
4. Change/Configure Synchronization Settings
This is where we are finally changing the import behavior. In Central Administration (User Profile Service Application) you pick the Configure Synchronization Settings and change the Synchronization Options to Use SharePoint Active Directory Import.
After applying this setting, following things are happening within seconds:
- The Windows Forefront Identity Manager Synchronization Service (FIMSynchronizationService) is changing its state from started to stopped and is disabled
- Sync Connection list in the UPSA is now empty, due to the fact, that the existing FIM sync connections are stored within the UPSA sync database, which is no longer in use
- Any Profile Property Mappings that have been in place must be reconfigured. Again, this is because the UPSA Sync DB is no longer in use.
- The timer job that is triggering the sync jobs is enabled: ([Name-of-UPSA] – User Profile ActiveDirectory Import Job)
5. Create Sync Connection
With switching from FIM to Active Directory Import Sync Connection information must be created again. So go ahead, grab your documentation and set up all of your required sync connections.
6. Create Import Filters
Apply all import filters that you need for each sync connection. This must be done using LDAP queries. This is something, that is different than it used to be using FIM. You are not using the GUI based filter builder, you need to specify what you want to import using a LDAP query. Benefit from that is that you have more control and possibilities, because any valid LDAP query could be used.
Be aware LDAP filters in AD Import mode are “include” filters, so you must define which accounts should be imported.
Example LDAP User Filters
- Default user filter:
(&(objectCategory=Person)(objectClass=User))
- Exclude accounts with no email address and disabled accounts:
(&(objectCategory=Person)(objectClass=User)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(mail=*))
- Exclude disabled accounts:
(&(objectCategory=Person)(objectClass=user)(!userAccountControl:1.2.840.113556.1.4.803:=2))
- Exclude accounts with passwords set to expire:
(&(objectCategory=Person)(objectClass=user)(!userAccountControl=65536))
- Include only the accounts with valid email addresses
(&(objectCategory=Person)(objectClass=User)(mail=*com)
- Include only the accounts that are part of the LocationXY organizational unit
(&(objectCategory=Person)(objectClass=User)(memberof:1.2.840.113556.1.4.1941:=(CN=AuthenticatedUsers,OU=LocationXY,DC=domain,DC=local)))
- Exclude accounts that don’t have a first name
(&(objectCategory=Person)(objectClass=User)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(!(!givenName=*)))
- Exclude all service accounts (Accounts must have a valid title naming convention)
(&(objectCategory=Person)(objectClass=User)(!(title=*Service Account*)))
7. Create Profile Property Mappings
After sync connections are created and possible filtering is in place you should reconfigure any previous existing AD profile property mappings.
Example on how mappings look in FIM, before switching to AD Import mode:
All previously existing property mappings will be missing after switching to AD Import:
To create profile property mappings navigate to the UPSA and to Manage User Properties. Select the property to modify and click on Edit in the context menu.
Be aware, that the GUI components are looking slightly different than they do using FIM. You have to explicitly enter the AD attribute name, you cannot choose existing attributes from the formerly existing drop down menu. Do not wonder about this. It’s not a bug it’s a feature
How property mapping is looking while using FIM:
How to create a property mapping for AD Import
Also be aware of following limitations:
“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). “
“You cannot add multiple mappings or edit a mapping. To change mapping settings for a property, you must first remove the existing mapping, and then create a new mapping.”
8. Disable the daily FIM Synchronization Timer Job
After switching to AD Import a new sync schedule / timer job is in place. Unfortunately, the timer job that took care about the daily FIM synchronization is still enabled ([Name-of-UPSA] – User Profile Incremental Synchronization). This job obviously causes errors, because there is no more FIM sync service running, that could be triggered. This is the reason why you must disable the timer job manually to prevent this timer job to fail daily what would result in Windows Event log errors:
Log Name: Application
Source: Microsoft-SharePoint Products-SharePoint Foundation
Event ID: 6398
Task Category: Timer
Level: Critical
User: DOMAINFarmaccount
Computer: SERVER.DOMAIN.COM
Description:
The Execute method of job definition Microsoft.Office.Server.UserProfiles.UserProfileImportJob (ID 12413dce-9263-48bb-8fc2-ed6d71a920cb) threw an exception. More information is included below.
Operation is not valid due to the current state of the object.
Disable the timer job to prevent running into this trap:
9. Take care about AD accounts missing from import
This is a known issue using AD Import. To make a long story short: Any accounts that are disabled or deleted in AD and therefor are not imported, are not properly handled by AD Import. FIM could pick up these missing accounts and flag them properly, later timer jobs would delete the accounts from SharePoint. This process is not working using AD Import.
Final Note
I hope this article helps you achieving the shift from FIM to AD Import.
Please share your experiences in the comments. Any feedback or additions for this post is highly welcome.
Thank you for rating this article if you liked it or it was helpful for you.
SQL Server Reporting Services (2016) 
Power BI Report Server 