Overview
Recently, a customer reported an issue to me with the following symptoms. His infrastructure has an on-premises Active Directory forest and leverages Microsoft Intune as a component of System Center Configuration Manager (SCCM) 2012 R2 to manage his mobile devices.
In the pilot phase of his project, he attempts to synchronize users he has successfully discovered into SCCM (using Active Directory User Discovery) only to have it fail. When looking into the CloudUserSync.log file, he discovered he had received the following error:
Failed to add user <UPN of User Account>; reason UserNotFound
After this, at 5 minute intervals the CloudUserSync.log file reported the following messages over and over:
UserDeltaSync:- Users Added = 0, Users Removed = 0
Starting user delta sync, raise failure status messages = True
Total received users from SCCM to be removed from cloud = 0
Successfully removed users from cloud 0
NotifyAccountAddition - SCCM user to add = <UPN of User Account>
Total received users to add from SCCM = 0, Total Successfully added users to Cloud = 0
Technical Details
In order to use Intune to manage mobile devices when a company has an on-premises Active Directory infrastructure, it is necessary to use the DirSync process to ensure those users have a presence in the Windows Azure Active Directory (Azure AD) directory. To understand the process of directory synchronization between your on-premises AD forest and Azure AD, check out the following TechNet article:
In order to leverage SCCM 2012 to manage Intune functionality, it is also necessary that the users which have been discovered using SCCM’s Active Directory User Discovery process be synchronized with their user accounts in Azure AD. To do this, SCCM has a new role known as the Windows Intune Connector Site System Role. This role becomes available when SCCM is leveraged to manage Intune functionality. You will need to configure an Intune Subscription and link it to your SCCM hierarchy (set it up on the CAS or a stand-alone Primary), and can then set up the Windows Intune Connector as shown below:
The specific steps of how to configure Windows Intune to be managed by SCCM can be found here:
How to Manage Mobile Devices by Using Configuration Manager and Windows Intune
Once DirSync is set up and the Windows Intune Connector has been configured, synchronization can proceed. For synchronization to be successful, the following must happen:
- DirSync must have synchronized the specified users into Azure AD from the company’s on-premises Active Directory forest
- SCCM must have discovered the same specified users from the company’s on-premises Active Directory forest
If both of these steps have not been completed successfully, synchronization will fail.
Synchronization Schedules
At this point, it’s important to note that the DirSync and Windows Intune Connector synchronization schedules are not the same. Their default schedules are below:
- Windows Intune Connector: every 5 minutes
- DirSync: every 3 hours
Solving the Problem: The Cause
In the case of the customer who raised this issue, they were seeing ‘UserNotFound’ messages in CloudUserSync.log the first time they tried to sync a newly discovered user. The reason for this was fairly straightforward…the user had not been synchronized via DirSync into Azure AD from their on-premises Active Directory forest.
The problem was made worse because of the way the Windows Intune Connector works. If a user is not found in Azure AD when the first synchronization happens, Windows Intune Connector will attempt delta synchronization every 5 minutes from that point on. But a delta sync will never cause the user to be discovered after this first try even if that user has been synchronized into Azure AD by DirSync.
In SCCM 2012 R2, a change was made to the Windows Intune Connector to deal with this problem. Now, if a user is not present in Azure AD when the Windows Intune Connector attempts its first sync of that user, a 24 hour clock is started. After 24 hours of delta sync attempts have occurred, that user will undergo a full sync. At this point, as long as he has an account in Azure AD, the sync will be successful.
This can be validated by creating a user in AD and discovering it using AD User Discovery in SCCM. Make sure DirSync does not run until after the Windows Intune Connector has had the chance to try and synchronize this user. This can be validated by looking for the following in CloudUserSync.log:
Failed to add user <UPN of User Account>; reason UserNotFound
Once you get this message, go ahead and DirSync the user into Azure AD and watch the logs. After 24 hours of failed synchronizations, you will see an entry showing that the user has now successfully synchronized with its account in Azure AD. We have validated that this 24-hour timer is on a per-user basis (so if you have a user on Friday at 3 p.m. that doesn’t synchronize and another at 5 p.m. that has the same problem, you can expect the first user to automatically synchronize at 3 p.m. on Saturday and the second user to do the same thing at 5 p.m.).
The following edited log file excerpts from CloudUserSync.log illustrate this:
9/14/2014 10:23:54 AM
Starting user delta sync, raise failure status messages = True
NotifyAccountAddition - SCCM user to add = scott@contoso.com
Failed to add user scott@contoso.com; reason UserNotFound
Total received users to add from SCCM = 1, Total Successfully added users to Cloud = 0
UserDeltaSync:- Users Added = 0, Users Removed = 0
9/15/2014 10:24:12 AM
Starting user delta sync, raise failure status messages = True
NotifyAccountAddition - SCCM user to add = scott@contoso.com
Total received users to add from SCCM = 1, Total Successfully added users to Cloud = 1
UserDeltaSync:- Users Added = 1, Users Removed = 0
This illustrates that a user who failed to sync with the UserNotFound condition will do so 24 hours later so long as there is a user to synchronize with at that point.
Solving the Problem: Managing Synchronization
It is clear that if nothing else is done beyond setting up these two synchronization mechanisms, there may be times when users are added to Azure AD but are not managed by SCCM for a full day. There are several options to work around this issue which customers may want to consider. Below is a list of options, though other options might be possible which are not included below:
- Restart the SMS Executive service on the SCCM site server where the Windows Intune Connector is installed. This will cause the next synchronization to be a full sync and if the users are in Azure AD at this point, synchronization will happen.
- Modify the intervals of the DirSync connector. By default, DirSync runs every 3 hours. If necessary to accommodate the 5-minute interval of the Windows Intune Connector, this interval can be changed to minimize the times that a user is synchronized via the Windows Intune Connector when it has not yet been added to Azure AD via DirSync
- Set specific times when users can be added to Azure AD. This is similar to #2, but the idea here is to set a synchronization window for all newly added user accounts to be synchronized via DirSync to Azure AD. In this case, also schedule SCCM User Discovery to run after DirSync completes. This way, when the Windows Intune Connector runs, the users will already be present.
There are various ways that a company might work out a schedule to ensure that most, if not all, of their users are present in Azure AD before the Windows Intune Connector runs. This should take care of the vast majority of cases and minimize the time when ‘UserNotFound’ shows up in CloudUserSync.log. In the cases where synchronization schedules miss a user, the option of waiting 24 hours or restarting the SMS Executive service are available.