Office 365 DirSync experiences: synced OUs and user deletion
March 29, 2015 Leave a comment
We experienced an interesting situation the other day with DirSync that doesn’t seem to be documented elsewhere, so thought I’d write it up here for future reference in case anyone hits the same issue…
Our Active Directory is set up to sync users to Office 365 via specific OUs, rather than the entire directory (that includes system users and so on).
In our case we sync staff, students and a spare holding container. This has worked well for us until now with no need for any intervention and users appear in Office 365 once created in AD.
We also set up the “prevent accidental deletes” threshold to ensure we had a safeguard in place should a mass deletion event occur. In our case we went for 50 as our limit, which in day-to-day use tends to be about right.
Set-PreventAccidentalDeletes -Enable –ObjectDeletionThreshold 50
Sometimes we have to temporarily raise (then reset) the threshold if a batch of student accounts expire at once but it’s something we don’t need to do that often.
The trigger for our particular issue was related to a scheduled database job experiencing an error, which led to a batch of users being moved from a synced OU in Active Directory to one that holds expired accounts and as such wasn’t ticked in the Management Agent in DirSync.
As a result on the next run DirSync acted as you’d expect it to and tried to delete the affected accounts from Office 365. Fortunately the PreventAccidentalDeletes threshold kicked in as it should and stopped the action from taking place, then sent a warning to our Network Support email group.
What happens next?
Microsoft have a lot of documentation on setting up the threshold to prevent accidental deletes but don’t expand on the various situations that could cause sync deletions and how to resolve them. For instance, the link below talks only about accounts being deleted from the source Active Directory but this didn’t apply to us; our accounts were still there but had ended up out of scope due to being moved.
We resolved the initial issue and moved the affected accounts back into scope via their original OU; however DirSync still wanted to remove the accounts. We ran the standard sync command line…
…but to no avail. After each run the warning email was still being sent, with the same number of users to be deleted. We also noticed that any new account creation seemed to be stuck in limbo until we either resolved the situation or raised the threshold (second choice wasn’t an option!)
Searching around for suggestions didn’t give much away, although this older article did spark a thought in my head
The point about DirSync running Delta syncs made sense in our context; basically the sync engine was no longer looking for the affected accounts because on the next Delta sync it would assumed they’d been deleted. What I suspected we needed was some sort of Full Sync that would look at all accounts and then decide what to do with each one.
At this point although the theory made sense I didn’t want to take any chances so raised a ticket with Microsoft Support to explain the issue. To be fair to Microsoft the speed of response from their support team was excellent and we were soon on a remote session with an engineer.
Initially the suggestion was to re-run the DirSync configuration wizard and start a Full Sync that way. However I didn’t want to do this as we’d made quite a few custom attribute mappings (for GAL separation etc.) and I didn’t want to re-do all of that if at all possible.
The Microsoft support engineer then said he’d trigger a Full Sync another way and opened up PowerShell to run a slight variation on the usual command…
The process took about 10-15 minutes to complete but the next email we received showed the deletion threshold had gone right down, to a level we’d expect. We were able to verify that the accounts left to be deleted were expected (expired accounts) so we then raised the threshold, ran another sync and set it back to 50. New users in the queue were then created as expected and all was calm again in the office 🙂
Disclaimer: the information and commands above worked in our situation but are provided for reference only. Given the business-critical nature of mass user account changes in Office 365 I’d always recommend opening a case with Office 365 support before doing anything that could have potentially nasty side-effects!