Some Notes on the Machines

Sometimes Windows’ relationship with 365, or a user’s profile, or just a user on a PC or terminal server, will not log into 365. This appears to be the result of corruption of cached credentials.

The most straightforward way is probably to nuke all User/Windows/Azure relationship and recreate. As written, this would probably be very bad on a terminal server, because it will nuke the relationship for all users and all profiles. So far, no per-user commands identified.:

Remove 365 accounts from “Access Work and School”, then run these:

dsregcmd /debug /cleanupaccounts

dsregcmd /debug /leave

from administrative CMD, and also from SYSTEM (paexec or psexec can do this), then reboot, then remove from Access Work and School if still there, then set up user relationship(s) again.

But today we have a report that dsregcmd /status did something, unknown, which fixed one terminal server user. Not sure what. Next time I plan to run many tests with this info:

ss64.com/nt/dsregcmd.html

And if you see error CAA5021, do this:

Search for Manage user certificates in the search bar and open it from Best match. Then navigate to Current User\Personal\Certificates and make sure the MS-Organization-Access and MS-Organization-P2P-Access entries are deleted.

No reboot needed for that last.

So we have a PC that is Azure-joined, not AD, not standalone. Domain admin is obvious. And we can set PC-local admin using domain admin. But how do we give an Azure user local admin rights? Well, the simplest is in administrative Powershell:

net localgroup Administrators /add "AzureAD\userupn@domain.com"

where userupn@domain.com is the UPN of the user, the user’s login into Azure/365. Note that the text AzureAD is not the domain name, it is literal characters as you see it here. In other words, a breakage of historical syntax!

OK, so it started as DirSync, is still being called on some pages “Azure AD Connect”, including the download page as of this writing:

www.microsoft.com/en-us/download/details.aspx?id=47594

but it is, apparently, officially renamed Microsoft Entra Connect:

learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-azure-ad-connect-v2

except within the URL itself :-)

Please note that this is NOT the same as Microsoft Entra Cloud Sync. The above does LDAP, Cloud Sync does not.

In one swell foop, sync your AD to other domain controllers and Azure. Paste this into administrative Powershell, on the domain controller which does your Azure sync:

repadmin /syncall /AdeP
Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Initial

And here is the same command set, suitable for a batch file to be run as administrator:

repadmin /syncall /AdeP
@"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command ^
"Import-Module ADSync; Start-ADSyncSyncCycle -PolicyType Initial"

And one more, also a batch file, transmitting only to Azure, without the LAN-LAN AD sync. Needed when the synchronizer is not run on a domain controller:

@"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command ^
"Import-Module ADSync; Start-ADSyncSyncCycle -PolicyType Initial"

Version overview:

docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history

There are many ways of doing this. Here is one way to bring everything into a single consistent behavior, a landing place from which you can vary slightly at need.

This presumes that you have Azure/AD sync installed and working in general, and yielding errors in the Synchronization Service window for one or more users. Make sure that you don’t have duplicate email addresses in AD, that could be bad.

The first steps are in Active Directory Users and Computers.

1. Set the user’s email correctly in his/her AD object, in “E-mail” under General.
2. Set proxyAddresses in the Attribute Editor. The primary email address has to be the same, and in proxyAddresses has to be of the format “SMTP:email@domain.com”. There can be others in proxyAddresses but smtp must be lowercase. Also in proxyAddresses, set mailNickname blank.
3. Under Account, either the user login name plus the dropdown domain is to be the same as the above, or it is to be a valid login according to the O365 console. If the dropdown domain list is local only, you can add the Internet domain list in Active Directory Domains and Trusts, with a right-click on the root level in the left pane of that window, and then an add of one or more alternative UPN suffixes. Then restart ADUC and the domain(s) you just added will be available in the dropdown.

Now we do some other things.

4. Run Azure/AD sync, this is CMD, do it as administrator:

repadmin /syncall /AdeP
@"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command ^
"Import-Module ADSync; Start-ADSyncSyncCycle -PolicyType Delta"

5. If you see errors in the Synchronization Service window, you’ll need something called a “hard match”, which changes enough to connect the AD user with the Azure user. Here’s a script for it, in Powershell. You’ll need to run it as administrator on a domain controller, and it will ask you to log into the O365 tenant. Items of note:

• This uses something called UPN, UserPrincipalName. While Azure’s UPN is the O365 “primary email address”, Active Directory’s UPN is the double item under Profile in AD, the username plus the domain dropdown.
• If you use this approach, the Office 365 login is changed to be the same as the AD login — which is a good thing in the net result, it keeps things very consistent and predictable.
• Once the hard match is complete, you can change anything on the AD side and it will mirror up to Azure.

############################################
# Active Directory / Office 365 Hard Match #
############################################

$ADUPN = 'active_directory_user@companynetwork.com'
$AzureUPN = 'azure_user@companynetwork.com'

'############################################'
'# Active Directory / Office 365 Hard Match #'
'############################################'
''

'Initiating prep for hard match.'
"Active Directory : $ADUPN"
"Azure AD :         $AzureUPN"
''

# Sets TLS version.  Necessary for some platforms.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

$reportStatus = ''
$currentOp = ''
function ShowProgress {
	param( [string]$reportStatus, [string]$currentOp )

	Write-Progress -Activity "Hard Match" -Status $reportStatus -PercentComplete -1 -CurrentOperation $currentOp
	# Write-Progress is not compatible with some remote shell methods.

}

Function PrepareModule {
	param( [string]$ModuleName )

	If (Get-Module -ListAvailable -Name $ModuleName)
		{ Update-Module $ModuleName }
	Else
		{ Install-Module $ModuleName }
	}

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted -Force > $null

'Preparing Powershell environment...'

ShowProgress("Preparing Powershell environment...","Setting up to use Powershell Gallery...")

ShowProgress("Preparing Powershell environment:","Setting up to use page provider NuGet...")
Install-PackageProvider -Name NuGet -Force | Out-Null

# This appears to set PSGallery nicely when need be
Register-PSRepository -Default -InstallationPolicy Trusted 2> $null
Set-PSRepository -InstallationPolicy Trusted -Name PSGallery

ShowProgress("Preparing Powershell environment...","Checking/preparing module NuGet...")
PrepareModule("NuGet")
ShowProgress("Preparing Powershell environment...","Checking/preparing module AzureAD...")
PrepareModule("AzureAD")

''
'Setting up hard match...'
''

'Connect to AzureAD:'
Connect-AzureAD

''
'Turn off AZ/AD Sync...'
''

Set-ADSyncScheduler -SyncCycleEnabled $false

"Now get original Azure ImmutableID for $AzureUPN ..."
$AzureUser = Get-AzureADUser -SearchString $AzureUPN
$OriginalAzureImmutableID = $AzureUser.ImmutableID
"Extracted Azure ImmutableID: $OriginalAzureImmutableID"
""
""
"And now extract AD GUID for $ADUPN ..."
ldifde -f export.txt -r "(Userprincipalname=$ADUPN)" -l *
$ADGUID = (-split (type export.txt | select-string "ObjectGUID"))[1]

''
"Extracted AD GUID: $ADGUID"
""
""
'Set AD GUID as Azure ImmutableID...'
Set-AzureADuser -ObjectID $AzureUser.ObjectID -ImmutableID $ADGUID

''
'New Azure ImmutableID retrieved as confirmation:'
$AzureUser = Get-AzureADUser -SearchString $AzureUPN
$AzureUser.ImmutableID

''
'Finally, turn on AZ/AD Sync again...'

Set-ADSyncScheduler -SyncCycleEnabled $true

'Done!'

Search the machine for the “Synchronization Service Manager”. That’s the GUI debugger.

1. Install the Azure Active Directory Module for Powershell.

2. Connect to Azure AD, and disable sync:

Set-MsolDirSyncEnabled –EnableDirSync $false

3. Check status, repeatedly, until it returns False. It can take 72 hours for sync to be fully deactivated.

(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled 

Rather interesting diagnostic.

http://azurespeedtest.azurewebsites.net/

When you do an Office 365 / EOL migration with Azure AD Sync in place, mailboxes may freeze up, where in the O365 console under “Mail Settings” for one or more mailboxes, it says “This user’s on-premises mailbox has not been migrated to Exchange Online. The Exchange Online mailbox will be available once migration is completed.” One may spend a whole lot of time, even with Microsoft on the line, not fixing this problem.

There may be more than one cause. But a very important cause and fix is outlined here:

https://mikeparker365.wordpress.com/2016/01/07/how-to-filter-out-msexchmailboxguid-from-aad-connect-sync/

The gist of it is, one of the user attributes synched up from the on-prem server is “msExchMailboxGuid”, and this is trouble, because if this is synched up, EOL thinks it is trying to make a duplicate of an existing mailbox, rather than a new one, and it will not make a duplicate, it is in fact waiting for this attribute to be deleted before proceeding.

So what we do, is we go to Synchronization Service, right-click on “Active Directory Domain Services”, make sure “Connector Designer” is selected, and then scroll down to msExchMailboxGuid , and uncheck it. Then click OK.

The next step is to kick off a sync. The easiest way is in Powershell on the server which has AD Sync installed:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Initial

You can watch the progress in “Synchronization Service” if you like; after the two final exports are complete it is done. But we’re not done yet.

The next step, is to remove the licenses from all of the O365 accounts which are marked as not yet migrated.

Then run another sync.

Then add the licenses back.

And run another sync.

That did it this morning!