Share this question

Welcome to Teachnovice Q&A, where you can ask questions and receive answers from other members of the community.

This is a collaboratively edited question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Migrate user accounts from Azure AD to on-premise AD?

0 like 0 dislike
My company uses Office 365 for Exchange, SharePoint, Lync etc. including the build-in user administration via Azure Active Directory.

Now we want to switch to a local AD on a Windows Server. It shall sync changes to Azure, but the primary user and group policy administration happens on the windows server.

How do we initially get the user accounts from the Azure AD into the on-premise (windows-server) AD?

edit1: Has anybody looked into this using Microsoft Forefront Identity Manager? It looks like this tool comes with DirSync. Open “miisclient.exe” on the DirSync server (Located in “C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell”). It may be possible to configure it to sync the other direction... may.
asked Apr 16, 2015 by sinned  

Add a new DC? That's how it works for on-premises AD.

@NathanC what do you mean? You can't connect a traditional domain controller to Azure Active Directory the same way op you would with on-premises domain controllers.

@MDMarra - Nathan was confused...same as he was on the other similar question:

@TheCleaner: I have read the possible duplicate before but I wouldn't say it's a duplicate, because I just want to migrate the users, not sync them permanently from Azure to on-premise. So I thought there could be other solutions here like offline tools or something which would not work with permanent sync

2 Answers

0 like 0 dislike
Best answer

@MDMarra: Thanks for the hints, so I did:

The users from O365 can be exported by powershell using

Get-MsolUser | Select-Object City, Country, Department, DisplayName, Fax, FirstName, LastName, MobilePhone, Office, PasswordNeverExpires, PhoneNumber, PostalCode, SignInName, State, StreetAddress, Title, UserPrincipalName | Export-Csv C:\Temp\Azure_Export_2014_12_05.csv -Encoding UTF8

This exports all columns to CSV where I could find a mapping that looked appropriate. Those are not all columns, but many of them cannot be mapped to attributes in AD. Others, like the password, cannot be exported.

To import the users to AD, run in powershell

import-csv C:\Temp\Azure_Export_2014_12_05.csv -Encoding UTF8 | foreach-object {New-ADUser -Name ($_.Firstname + "." + $_.Lastname) -SamAccountName ($_.Firstname + "." + $_.Lastname) -GivenName $_.FirstName -Surname $_.LastName -City $_.City -Department $_.Department -DisplayName $_.DisplayName -Fax $_.Fax -MobilePhone $_.MobilePhone -Office $_.Office -PasswordNeverExpires ($_.PasswordNeverExpires -eq "True") -OfficePhone $_.PhoneNumber -PostalCode $_.PostalCode -EmailAddress $_.SignInName -State $_.State -StreetAddress $_.StreetAddress -Title $_.Title -UserPrincipalName $_.UserPrincipalName -AccountPassword (ConvertTo-SecureString -string "Secret!" -AsPlainText -force) }

This creates new users with the name Firstname.Lastname. Other attributes like SignInName could not be used because they are not a valid AD account name.

Country cannot be imported because AD requires the country to actually exist while O365 accepts free text.

The password will be set to "Secret!", because if no password is provided, the account will be created, but disabled.

It may be handy to edit the CSV-file in Excel or something, but I would recommend using PowerShell only. Excel deletes leading zeros from phone numbers or reformats other stuff. Also, mind UTF8.

answered Apr 16, 2015 by sinned  
0 like 0 dislike
You can use the Get-MsolUser PowerShell cmdlets to export user data from Azure Active Directory and then use the New-ADUser cmdlets to take that data and create the accounts on-premises. That said, there's no turnkey way to do this. You'll have to script something.
answered Apr 16, 2015 by MDMarra  

Azure Directory Synchronization is a one-way street

I just looked into it and of the 56 attributes I can get out of O365, I can map 17 attributes to their on-premise-analogy. For the rest, I hope they are not that important...