Sometimes servers, used for migrating data from file shares to Microsoft 365, are restricted to non-domain joined environments. All though this introduces some challenges, there are also solutions to work around some limitations.
Shared hosting
Imagine an environment with the migration servers not joined to a an on-premises Active directory domain. This could be the case if the organization depends on an external shared hosting platform linked to a single directory service for all customers.
Such a hosting platform is bound to certain security regulations not allowing third parties to have directory service access for obvious reasons. As a result of this, the migration servers cannot not be joined to the (same) domain as the file servers.
Typical limitations
Some of the typical limitations you can encounter for such environments are:
- The migration servers do not have direct access to the file servers containing the files. A network mapping with credentials would have to be setup to resolve this.
- There is no access to user related metadata like the ACL-data (user) linked to ‘CreationTime’ and ‘LastWriteTime’ which is mapped to ‘Created by’ and ‘Modified by’ in SharePoint Online. The only thing that can be accessed, is the Security Identifier (SID) for the ACL, but not the actual username.
Microsoft Migration Manager
Fortunately, Microsoft Migration Manager has some interesting capabilities that can to cope with these limitations.
First, when you are installing the agent software, it automatically detects if the server is not joined to a domain.
In that case, the agent can be installed as an app. And if you have the network drive mapping setup, you will be able to authenticate with a domain account that has access to the data on the file servers.
SID-based user mapping
As mentioned, the environment does not have access to the ACL’s for data on the file servers. So that makes it difficult to do the typical Username to UPN user mapping.
Migration Manager provides the option to upload CSV-files containing a comma separated user mapping. This is documented in Create a user-mapping file for data content migration in Migration Manager. Usually this is something like this:
cgreen,cgreen@contoso.com,FALSE
The last element is set to TRUE if If the user principal name on the destination site is an Active Directory (AD) group. In the example, this is not the case.
To workaround the ACL access issue, the first element (username) can be replaced with the Secure Identifier (SID) for the user. As Migration Manager is capable of reading this data in the non-domain joined scenario, it can be mapped to the user principal name in Microsoft 365:
S-1-12-1-141847199-1327055587-1706215590-3578058593,cgreen@contoso.com,FALSE
I have also tested this with another popular migration tool that I often use, but the SID-based mapping did not work there.
To gather data for the mapping, you can get the ‘UserPrincipalName’ and ‘OnPremisesSecurityIdentifier’ properties for a hybrid user from Azure AD. The latter holds the SID from the local Active Directory environment.
Please note that the ‘AzureAD’ PowerShell module has been deprecated in favour of Microsoft Graph PowerShell in case this data needs to be retrieved via PowerShell.
Another thing to consider: depending on the duration of the migration, the user mapping needs to be updated on a regular basis to reflect new employees joining the organization.
Inconvenient user mapping inheritance
One final note: when you upload a new bulk tasks file to Migration Manager, it automatically inherits the user mapping uploaded in ‘Global Settings’.
But if you then update the user mapping in ‘Global Settings’ after the first tasks are uploaded, it is not inherited by the existing tasks. In that case, you would have to re-upload the tasks file. That can be inconvenient if a large set of tasks need to re-run incrementally.
For smaller sets, you can of course go through each task and update the user mapping under ‘Settings’ for that specific job.
