Depending on the size of the company and the schedule for testing, piloting, and migrating one must decide what approach to use to populate objects into the online directory. In the past this was limited to one of two options for BPOS, either manually creating user accounts through the Microsoft Online Services Administration Center (MOAC) or establishing Directory Synchronization in an on-premise Active Directory forest. Both approaches have benefits and drawbacks, but almost 100% of the time Directory Synchronization is used due mainly to the reduced workload in initially getting account established online and the added management features and control offered.
Now that a host of new PowerShell-based cmdlets have been added to the Migration Command Shell (previously discussed in this article) there is a third approach that can be used which falls in the middle of the previous choices. Before if you had a customer not planning or able to use Directory Synchronization but had more than ~50 users then setting up the users, groups, and contacts manually via MOAC could be an arduous task. In these cases MOAC does allow for specially formatted CSV files to be used to bulk-create user accounts, but this process can be very slow when used for hundreds of accounts and often took hours and multiple stages to complete. Also groups and contacts must still be created one at a time, no import process exists in MOAC to do this today.
So what I used to do was setup a temporary AD domain in a virtual lab and then import all the objects via CSVDE or LDIFDE scripts and then establish a one time DirSync process to populate all the objects. The downside to using this solution was that each object created would be stamped with an ObjectGUID specific to that Directory Synchronization deployment matching everything back to what would be temporary objects in a temporary AD forest. After the initial sync the source environment was torn down and DirSync disabled. The danger here is that if the company later wanted to establish synchronization with a future AD forest they may be planning to deploy then the existing objects would not be available to match as their GUIDs were already stamped with a value.
But this approach is no longer needed as you can now go straight from similar CSV import files into the online directory using the Add-MSOnlineUser cmdlet. What I recently discovered though is that this new command emulates a manual synchronization process, in that you must first enable Directory Synchronization on the site before the cmdlet will function correctly:
This lead me to realization that if the cmdlet is emulating a Directory Synchronization process, does this mean we will run into the same problem regarding populated GUIDs? Unfortunately, yes. When the account is created via the cmdlet the ObjectGUID is stamped with a ‘fake’ value which means that later attempts to match these accounts with an on-premise directory will not work.
So the general approaches are:
- If there is any chance that a company may want to or need to utilize Directory Synchronization in the future to manage objects with an on-premise Active Directory forest, then do not initially populate objects into the cloud using either a temporary DirSync process nor the Add-MSOnlineUser cmdlet. Only use MOAC to either manually create objects or import them from a CSV file.
- But if there is no chance that Directory Synchronization will ever be used then either manually create objects in MOAC or use the Add-MSOnlineUser cmdlet.
It is worth noting that if accounts are created via MOAC using an import script (or established via DirSync) the new Enable-MSOnlineUser cmdlet can still be used to activate the accounts in bulk instead of performing this manually in the console. This is a huge time saver as the console only allows a handful of users to be enabled at a time and each user can take 15-60 seconds to activate. Using the cmdlet is typically much quicker in that all accounts can be processed in one script and the individual execution is faster.
