Same users but new domain with AD Connect...

Copper Contributor

Hi,
I explain my future problem;) but I can't find information about it
I have a local AD that is synchronized with Azure AD connect for my Office 365 (Exchange Online) accounts. I will change my local domain (name change) and redo all my users (migration seems too risky for the few accounts - it's on a W2008 yet... to W2016) but it will be important that the new accounts synchronize on Azure AD and keep the existing Exchange accounts.
How to:

- disconnect my old domain then reconnect my new domain but keeping the Exchange / Sharepoint / etc ... accounts of my users ?

Thanks and Sorry for my english ... I'm french 

AM 

5 Replies
One way, and I'm not an expert on this topics, is just stop to sync your AD with Office 365 so all your users will be cloud users, do the migration and then setup up again AD Sync with Azure AD Connect

Thanks for your reply, 

I did not know that disconnecting AD sync, O365 would convert accounts to Cloud account.

it would be really good :) 
however, when I'm going to reconnect the AD sync with my new domain, how will it link to the cloud accounts and accounts of my new AD? just with the email address? the SID is not the unique reference as locally?

After you are finished with the migration, you can prepare the user objects in order to "match" them against the users already existing in O365. You have two options:

 

1) Soft-match, based on the primary SMTP address: http://support.microsoft.com/kb/2641663. This will require you to clear the immutableID first.

2) Hard-match, based on the objectID: http://blogs.technet.com/b/praveenkumar/archive/2014/04/12/how-to-do-hard-match-in-dirsync.aspx

 

Both methods will yield same results, after you re-enable DirSync the accounts should be "linked".

@Alexis MONIOT 

 

Hey Alexis,

we faced a similiar issue. We had one old On-Premise AD which was synced to our AzureAD. They all were in the Domain "example.old". We manually migrated all our users to our new domain "example.com" in the new On-Premise AD. During the migration we changed the usernames (sAMAccountname) to a new schema as well. (side note: The old groups weren't neccessary in the new domain, so we didn't have to migrate the old groups)

 

The problem: example.old\john.doe was already synced with the corresponding user in the AzureAD. So if we would just start the new AD Connect from the new AD (example.com) the synchronization would fail, because AzureAD doesn't allow two "john.doe"s.

 

Our solution: We stopped the sync on the old "example.old" AD before we configured the new AD Connect. We then configured the new AD-Sync like the old one, with the only difference that two ADs are synching into AzureAD and both ADs have unique users. Infact that's not the case, but we wanted to shut down the old AD. Don't worry that users might be deleted, because the new AD won't delete users of the old AD. The only issue might be newly created users.

Before starting the actual synchronization we ran the following script from the new AD. This script replaces the ImmutableIDs of the AzureAD users with the ones from the new On-Premise AD. This ID is used by ADSync to hard-match those entries.

 

Import-Module ActiveDirectory

# get all users from new On-Premise AD that should be synced
$users = Get-ADUser -Filter "*" -SearchBase "OU=Users,DC=example,DC=com"

# Rewrite all ImmutableIDs of these users
foreach($user in $users)
{
   Write-Host "Processing user: " $user.Name $user.ObjectGUID
   C:\tmp\CreateID.ps1 -valuetoconvert $user.ObjectGUID -username $user.Name
}

 

We slightly modified the following script (see source) so the users are edited automatically.

CreateID.ps1 (source: https://gallery.technet.microsoft.com/office/Covert-DirSyncMS-Online-5f3563b1)

 

#------------------------------------------------------------------------------   
#  
# Copyright © 2012 Microsoft Corporation. All rights reserved.  
#  
# This Sample Code is provided for the purpose of illustration only and is not intended to be used in a production environment.  
# THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,  
# INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.  
# We grant You a nonexclusive, royalty-free right to use and modify the Sample Code and to reproduce and distribute the object code  
# form of the Sample Code, provided that You agree: (i) to not use Our name, logo, or trademarks to market Your software product in  
# which the Sample Code is embedded; (ii) to include a valid copyright notice on Your software product in which the Sample Code is  
# embedded; and (iii) to indemnify, hold harmless, and defend Us and Our suppliers from and against any claims or lawsuits,  
# including attorneys’ fees, that arise or result from the use or distribution of the Sample Code.
#  
#------------------------------------------------------------------------------  
#  
# PowerShell Source Code  
#  
# NAME:  
#   GUID2ImmutableID.ps1  
#  
# VERSION:  
#   1.0  
# Author: Steve Halligan
#  
#------------------------------------------------------------------------------  
param(
   [string]$valuetoconvert,
   [string]$username
)

function isGUID ($data) {
   try {
       $guid = [GUID]$data
       return 1
   } catch {
       #$notguid = 1
       return 0
   }
}
function isBase64 ($data) {
   try {
       $decodedII = [system.convert]::frombase64string($data)
       return 1
   } catch {
       return 0
   }
}
function displayhelp  {
   write-host "Please Supply the value you want converted"
   write-host "Examples:"
   write-host "To convert a GUID to an Immutable ID: GUID2ImmutableID.ps1 '748b2d72-706b-42f8-8b25-82fd8733860f'"
   write-host "To convert an ImmutableID to a GUID: GUID2ImmutableID.ps1 'ci2LdGtw+EKLJYL9hzOGDw=='"
   }
   
if ($valuetoconvert -eq $NULL) {
   DisplayHelp
   return
}
if (isGUID($valuetoconvert))
{
   $guid = [GUID]$valuetoconvert
   $bytearray = $guid.tobytearray()
   $immutableID = [system.convert]::ToBase64String($bytearray)
   write-host "ImmutableID"
   write-host "-----------"
   $immutableID
} elseif (isBase64($valuetoconvert)){
   $decodedII = [system.convert]::frombase64string($valuetoconvert)
   if (isGUID($decodedII)) {
       $decode = [GUID]$decodedii
       $decode
   } else {
       Write-Host "Value provided not in GUID or ImmutableID format."
       DisplayHelp
   }
} else {
   Write-Host "Value provided not in GUID or ImmutableID format."
   DisplayHelp
}

# START our modifications:
Import-Module AzureAD
$usernameAzure = "adminuser@example.com"
$passwordAzure = ConvertTo-SecureString "yoursupersecretpassword" -AsPlainText -Force
$credentials = New-Object System.Management.Automation.PSCredential ($usernameAzure, $passwordAzure)
$connect = Connect-AzureAD -Credential $credentials
# This is the important part:
# here we replace the immutableIDs in AzureAD with the ones from the "local" AD
$user = Get-AzureADUser -Filter "DisplayName eq '$username'"
$user | Set-AzureADUser -ImmutableId $immutableID

 

 

@bisonMitch 

 

You wrote "Our solution: We stopped the sync on the old "example.old" AD before we configured the new AD Connect.". How did you stop the sync? Did you remove AD Connect on the old server?