How to Hard Match Office 365 Identities to On-Premise Users

Akins IT • January 8, 2020

When migrating from on-premise exchange to Office 365, IT administrators can experience failure when attempting to soft match identities. Soft matching (also known as "SMTP matching") can fail for many reasons, the common one being because Office 365 detects that the email is already associated with another object. In the case of a soft match failure, a hard match must be performed. The solution to this is to stamp the online identities immutable ID with the GUID from the on-premise user, which can be done on-premise on the Active Directory server.

This is a simple PowerShell solution to hard match an on-premise GUID to an immutable ID for an online user. This ensures that all on-premise identities are correctly matched and linked to the Office 365 identities, which allows for full Office 365 write-back functionality in an organization's environment.

Provided below is the step-by-step guide on how to carry out this solution:

Remove on-premise Identity from syncing with O365
Remove on-premise Identity from O365 and Remove from Recycle bin
Launch Powershell and run the following Commands
Set-ExecutionPolicy RemoteSigned
$credential = Get-Credential
Input admin credentials for Office 365 and run the following command
Import-Module MsOnline
Connect-MsolService -Credential $credential
Run “$ADGuidUser = Get-ADUser -Filter * | Select Name,ObjectGUID | Sort-Object Name | Out-GridView”
Select the on-premise user from the Grid
Run “$UserimmutableID = [System.Convert]::ToBase64String($ADGuidUser.ObjectGUID.tobytearray())” in powershell to convert GUID to the immutable ID format
Run $OnlineUser = Get-MsolUser | Select UserPrincipalName,DisplayName,ProxyAddresses,ImmutableID | Sort-Object DisplayName | Out-GridView -Title "Select The Office 365 Online User To HardLink The AD User To" -PassThru”
Select the Online identity to match on-premise identity
Run “Set-MSOLuser -UserPrincipalName $OnlineUser.UserPrincipalName -ImmutableID $UserimmutableID”
Set the Online identity with the new immutable ID
Run “Set-MSOLuser -UserPrincipalName $OnlineUser.UserPrincipalName -ImmutableID $UserimmutableID”
Check the immutable id matches
Run the following two lines and confirm IDs Match
“Write-Host "AD Immutable ID Used" $UserimmutableID”
“Write-Host "Office365 UserLinked" $Office365UserQuery.ImmutableId”

< Older Post

Newer Post >

AWS stumbled this morning. Here’s why multi‑cloud keeps you moving.

By Shawn Akins • October 20, 2025

October 20, 2025 — Early today, Amazon Web Services experienced a major incident centered in its US‑EAST‑1 (N. Virginia) region. AWS reports the event began around 12:11 a.m. PT and tied back to DNS resolution affecting DynamoDB , with mitigation within a couple of hours and recovery continuing thereafter. As the outage rippled, popular services like Snapchat, Venmo, Ring, Roblox, Fortnite , and even some Amazon properties saw disruptions before recovering. If your apps or data are anchored to a single cloud, a morning like this can turn into a help‑desk fire drill. A multi‑cloud or cloud‑smart approach helps you ride through these moments with minimal end‑user impact. What happened (and why it matters) Single‑region fragility: US‑EAST‑1 is massive—and when it sneezes, the internet catches a cold. Incidents here have a history of wide blast radius. Shared dependencies: DNS issues to core services (like DynamoDB endpoints) can cascade across workloads that never directly “touch” that service. Multi‑cloud: practical resilience, not buzzwords For mid‑sized orgs, schools, and local government, multi‑cloud doesn’t have to mean “every app in every cloud.” It means thoughtful redundancy where it counts : Multi‑region or multi‑provider failover for critical apps Run active/standby across AWS and Azure (or another provider), or at least across two AWS regions with automated failover. Start with citizen‑facing portals, SIS/LMS access, emergency comms, and payment gateways. Portable platforms Use Kubernetes and containers, keep state externalized, and standardize infra with Terraform/Ansible so you can redeploy fast when a region (or a provider) wobbles. (Today’s DNS hiccup is exactly the kind of scenario this protects against.) Resilient data layers Replicate data asynchronously across clouds/regions; choose databases with cross‑region failover and test RPO/RTO quarterly. If you rely on a managed database tied to one region, design an escape hatch. Traffic and identity that float Use global traffic managers/DNS to shift users automatically; keep identity (MFA/SSO) highly available and not hard‑wired to a single provider’s control plane. Run the playbook Document health checks, automated cutover, and comms templates. Then practice —tabletops and live failovers. Many services today recovered within hours, but only teams with rehearsed playbooks avoided user‑visible downtime. The bottom line Cloud concentration risk is real. Outages will happen—what matters is whether your constituents, students, and staff feel it. A pragmatic multi‑cloud stance limits the blast radius and keeps your mission‑critical services online when one provider has a bad day. Need a resilience check? Akins IT can help you prioritize which systems should be multi‑cloud, design the right level of redundancy, and validate your failover plan—without overspending. Let’s start with a quick, 30‑minute review of your most critical services and RPO/RTO targets. (No slideware, just actionable next steps.)