Click on the Category button to get more articles regarding that product.
TIP: Cleanup everything LOCAL before you even think of moving anything to M365 or Azure or even starting the Connector
PRO TIP: Full manual list of Objects/attribute to check on your local ADS in this blog.
This blog entry is mainly about those two steps of the MS Technet: https://learn.microsoft.com/en-us/microsoft-365/enterprise/prepare-for-directory-synchronization?view=o365-worldwide
- Directory Clean-up Tasks
- Directory object and attribute preparation
which are often just skipped because people think all is fine because they logon to their client an IT runs. Normally the things we talk about here are checked and cleaned with any serious IT-Service company who migrated something in direction of LDAP/Windows Domain Controller/Active Directory or Exchange inhouse.
But time may have passed since then so it’s time to check again like the OnPremise migrations and one of the reasons why it’s was a little more expensive inhouse. However, daily business shows that it’s the same related to cloud. The difference is just that people who never really done such complex things inhouse now think all the problems are gone.
This is a collection of things we noticed during some test and inspection of logs and dumps from existing migrations.
As with Exchange 2 Exchange Onpremise or with Active Directory Domain Controller Migrations. It is recommended to clean-up the source that means your existing environment as clean as possible.
You do not want to run into errors during the sync or setup. Prevent it, think ahead, and do not be too naive. Problems want go away just because you move everything to the cloud that were there before.
All the things that are wrong come up with a migration even if things worked before and you lived with it.
Warning
MS describes it in a clear warning on most of their pages somewhere. In addition, as always on Technet if something is mentioned with a “!” in that form read it.
Like if, you remove last Hybrid in Onpremise and you remove the Exchange ORG. You do not ready no E-Mail next day for the cleaners who wanted to make all proper and nothing in the server room!
But maybe someone who migrated you last on-premise to on-premise fixed those for you already? Mainly most of these did happen in an environment, which have grown over the years from NT/2000/2003/2008/2016 etc.
So if someone cleaned already you may have an easy ride and even do not understand what those Exchange Experts done all the time because it was so easy now for you as cloud Manager. Forums are full with those it happens in Azure/M365 too 😉
Some things we did see: and to check:
- Things like special Chars somewhere where they not should be like “\ < > ( ) ; , [ ] [ \ ” | , / : < > + = ; ? * ‘] > IN: sAMAccountName or userPrincipalName
- Too many groups in other groups or user in too many groups (Everything is possible in Enterprise with Academic naming convention and strategy)
- User get’s it done to get a special Category Color in Public Folders events? Yes possible and failure did happen.
Then there are points which may have been changed after the last person did a serious Exchange<>Exchange inhouse migration otherwise they would not be there.
PROXYADDRESSES > those get built by Exchange itself and are not relevant inhouse except for routing in ENT until mig or now
For their DFB-11 DE, EMEA Region 😉
Stop using ö, ä, ü in IT identifiers we tell you since 30 years. Let them Mary and change the name it’s cheaper! Or just don’t use them.
Every 5 years there is a technology, which does not swallow UMLAUT it and that fails because of it.
Your Smartcard to enter the last ship, which will fly to Mars, will fail because you have müller on it instead of mueller
All other steps please reference the MS KB. We just wanted to highlight something, which should NOT be there. If you find ANY
Of those mentioned above, we recommend checking all other points VERY carefully. Find as much info as you can about the pre checks.
No Easy Solution?
- There are many scripts around from ADS/DC and Exchange Migrations to check these things
- CLOUD MANAGER: Also below see the IDFIX which may help with some errors.
- PRO: Check the list below we made “Manual Reference Butsch what to check on on-premise enviroment before you start any Hybrid M365/Azure project, collected from different sources 02.02.2023”
Be careful with script that also Change things in same step. Best is a script which checks and reports and then has an option to change and also logs.
Also do not be Junior System Powershell-just-back-from-education and just run it first thing you find on google without a backup before?
- Check the regular Backup before you touch (Really do it open the console view the job or let the Backup Admin show you): Acronis, NetB, BEXEC, veeeam, and for Windows Domain just a regaultr Windows Backup so Tier3 MS will support it!
- Make an LDAP Export of ADS just as second backup (Example: ldifde -f C:\edv\export.ldf -d “CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=ch” -p subtree)
https://www.butsch.ch/post/ADSIEDIT-replacement-and-tools
Believe us:
https://redmondmag.com/articles/2017/08/22/edit-the-active-directory-using-adsi-edit.aspx
MS Links in general to that:
AD DS Preparation
To help ensure a seamless transition to Microsoft 365 by using synchronization, you must prepare your AD DS forest before you begin your Microsoft 365 directory synchronization deployment.
Your directory preparation should focus on the following tasks:
- Remove duplicate proxyAddress and userPrincipalName attributes
- Update blank and invalid userPrincipalName attributes with valid userPrincipalName attributes
Remove invalid and questionable characters in the givenName, surname ( sn ), sAMAccountName, displayName, mail, proxyAddresses, mailNickname, and userPrincipalName attributes. For details about preparing attributes, see List of attributes that are synced by the Azure Active Directory Sync Tool.
PITFALLS: The TOP or First Level Domain of the FQDN of your Active Directory has to Routable in Internet
If you Windows Active Directory Domain is like it was learned correct in 1999 then i will end as .local as best practice.
What is what if you did not work for an ISP and have other things to do in life…
Secondleveldomain    firstleveldomain (top domain)
mycompany        local
mycompany.local < This is a non routable DNS Domain
ads.meinfirma.local < This is a non routable DNS Domain
ads.meinefirma.ch < This is a routable DNS Domain
If your internal Windows Domain is something green above > Good
If you have something that is like red above > Not good but can fix here is how:
You may have to adapt a second Domain name as you maybe already own from your Internet Web Site or if you have an SMTP MX from your E-Mail system. (Check you Internet Provider/Domains/DNS/MX). You will have to prove to Azure that you own the Domain with a special DNS entry.
Maybe you noticed the time where you could not get a Security Certificate for your .local domain. Maybe you already have a second UPN per user?
Microsoft explains it here maybe you understand maybe not. Clear up with Exchange People and security before you do this on Active Directory. It may have a lot if impact if you have a third party software, which enumerates these, fields wrong [Yes seen….] (Breaking things on other side).
| MS |
| When you synchronize your on-premises directory with Microsoft 365, you have to have a verified domain in Azure Active Directory (Azure AD). Only the User Principal Names (UPNs) that are associated with the on-premises Active Directory Domain Services (AD DS) domain are synchronized. However, any UPN that contains a non-routable domain, such as “.local” (example: billa@contoso.local), will be synchronized to an .onmicrosoft.com domain (example: billa@contoso.onmicrosoft.com).
If you currently use a “.local” domain for your user accounts in AD DS, it’s recommended that you change them to use a verified domain, such as billa@contoso.com, in order to properly synchronize with your Microsoft 365 domain. |
You can do this DOMAIN Wide is MS Explains this will be for further users.
As with Exchange Domains this is not adapted at once to existing users in some enviroments.
Ir you can do this just for one user maybe for testing or the ones who you will have Hybrid etc.
For sure you can do this with Powershell but as always TEST on a VM DC lab and limit the change to an OU if possible so you don’t HIT service accounts, IT accounts etc.
$LocalUsers = Get-ADUser -Filter “UserPrincipalName -like ‘*contoso.local'” -Properties userPrincipalName -ResultSetSize $null
$LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace(“@contoso.local”,”@contoso.com”); $_ | Set-ADUser -UserPrincipalName $newUpn}
External Links to blogs:
https://www.essential.co.uk/blog/articles/office-365-upn-smtp-mismatch-fix/
PITFALL 3: Fixing UPN on-premise by Markus Vilcinskas (Scripts moved to EXE solution called IDFIX)
As example, somehow, people get it done that on both sides on-premise and in Azure you have objects with the same UPN name.
There where once some Powershell script sets posted under the links below. However, you are unable to download those mentioned.
MS replaced and consolidated on a .NET EXE tool so the Cloud Managers can also run it. The Script seemed to have a too large impact when running
Wrong by people who suddenly run and unerstood PS and never used ADSIedit or DCDIAG.exe before 😉
https://redmondmag.com/articles/2017/08/22/edit-the-active-directory-using-adsi-edit.aspx
Here is the tool which will report all errors on your ADS on-premise:
idFix is used to perform discovery and remediation of identity objects and their attributes in an on-premises Active Directory environment in preparation for migration to Azure Active Directory. IdFix is intended for the Active Directory administrators responsible for directory synchronization with Azure Active Directory.
The purpose of IdFix is to reduce the time involved in remediating the Active Directory errors reported by Azure AD Connect. Our focus is on enabling the customer to accomplish the task in a simple expedient fashion without relying upon subject matter experts.
The Microsoft Office 365 IdFix tool provides the customer with the ability to identify and remediate object errors in their Active Directory in preparation for deployment to Azure Active Directory or Office 365. They will then be able to successfully synchronize users, contacts, and groups from the on-premises Active Directory into Azure Active Directory.
Info:
https://microsoft.github.io/idfix/
Download:
https://raw.githubusercontent.com/Microsoft/idfix/master/publish/setup.exe
Microsoft is working to reduce the time required to remediate identity issues when onboarding to Microsoft 365. A portion of this effort is intended to address the time involved in remediating the Windows Server Active Directory (Windows Server AD) errors reported by the directory synchronization tools such as Azure AD Connect and Azure AD Connect cloud sync. The focus of IdFix is to enable you to accomplish this task in a simple, expedient fashion.
The IdFix tool provides you the ability to query, identify, and remediate the majority of object synchronization errors in your Window’s Server AD forests in preparation for deployment to Microsoft 365. The utility does not fix all errors, but it does find and fix the majority. This remediation will then allow you to successfully synchronize users, contacts, and groups from on-premises Active Directory into Microsoft 365. Note: IdFix might identify errors beyond those that emerge during synchronization. The most common example is compliance with rfc 2822 for smtp addresses. Although invalid attribute values can be synchronized to the cloud, the product group recommends that these errors be corrected.
This was sourced from those scripts before:
FIXID Proxyaddress Error:
For the PROXY Error we assume this will be changed by the latest version of the Hybris Wizard because MS describes that RUS on-premise will be changed.
We assumed AS long as the Primary (FAT) SMTP: address is the correct this would work. But we also see that MS changes it on-premise with the wizard (new or since ever)
https://learn.microsoft.com/en-us/exchange/hybrid-configuration-wizard
Primary SMTP proxy address is replaced by targetAddress value in a hybrid environment
You find following code which is run through the wizard on-premise:
Set-EmailAddressPolicy -Identity “Default Policy” -ForceUpgrade “True” -EnabledEmailAddressTemplates (“SMTP: @domain.com”, “smtp:%m@domain.mail.onmicrosoft.com”, + “SMTP: @domain.com” + “smtp:%m@domain.mail.onmicrosoft.com”)
Update-EmailAddressPolicy -Identity “Default Policy” -UpdateSecondaryAddressesOnly “True” -DomainController “GlobalCatalog.domain.com”
If you want to make a script which changes that PLEASE note:
The field “email” (Under Street/address) should be in sync with PROXYaddress but often it’s not.
The field E-Mail main focus is for CRM/ERP reference or for vcards.
The PROXYaddress primary SMTP is for routing that’s the one you should select to fetch the E-Mail address for the Hybrid Wizard selection.
That’s also what ID FIX checks.
As per MS Reference the field email is Synced FROM Proxyaddress but depending on the WAY you handle the ADS user not anytime. (See posts below link)
| If you’ve already set up directory synchronization, the user’s UPN for Microsoft 365 may not match the user’s AD DS UPN that’s defined in your AD DS. This can occur when a user was assigned a license before the domain was verified. To fix this, use PowerShell to fix duplicate UPN to update the user’s UPN to ensure that the Microsoft 365 UPN matches the corporate user name and domain. If you’re updating the UPN in the AD DS and would like it to synchronize with the Azure Active Directory identity, you need to remove the user’s license in Microsoft 365 prior to making the changes in AD DS. | ||||
|
n Microsoft Office 365, an administrator receives the following email message warning when directory synchronization finishes:
 The error report in the email message may contain one or more of the following error messages:
This issue may occur if mail-enabled objects in the on-premises Active Directory Domain Services (AD DS) have duplicate or invalid values, and these user objects are not synchronized from the AD DS to Office 365 correctly during directory synchronization. |
| Manual Reference Butsch what to check on on-premise enviroment before you start any Hybrid M365/Azure project, collected from different sources 02.02.2023 |
| Group objects:
http://support.microsoft.com/kb/2256198 * List of attributes that are synchronized to Office 365 and attributes that are written back to the on-premises Active Directory Domain Services * NOTE: these are list as group filters in the article, but they appear to be an inaccurate mix of filters and errors.
SecurityEnabledGroup: * isCriticalSystemObject = TRUE * mail is present AND DisplayName is not present * Group has more than 15,000 immediate members * Cannot start with Group_ MailEnabledGroup: * DisplayName is empty * ProxyAddress does not have a primary SMTP address) AND (mail attribute is not present/invalid – i.e. indexof (‘@’) <= 0) * Group has more than 15,000 immediate members DISPLAYNAME * DisplayName is empty * ProxyAddress does not have a primary SMTP address) AND (mail attribute is not present/invalid – i.e. indexof (‘@’) <= 0) * Group has more than 15,000 immediate members * Value is non-blank if present * Max Length = 255. * The attribute being present check is done in mtChecks, however, the errorBlank check is done only if the attribute is missing, so that has been updated to check for blanks if attribute present. new ComposedRule(StringLiterals.DisplayName, ProxyAddresses have additional requirements: * Cannot contain space < > () ; , [ ] * There should be no “:” in the suffix part of ProxyAddresses. * SMTP addresses should conform to valid email formats MailNickName: * Cannot start with period (.) * Max Length = 64, document doesn’t restrict, schema says 64 You could find out what to correct also in the AZURE Connector, Synchronization Rules Editor. There are some FILTERS in which they select objects to Sync from Local Active Directory to Azure AD. As example for the Exchange Users:
https://learn.microsoft.com/de-de/azure/active-directory/hybrid/how-to-connect-sync-configure-filtering Active Directory Synchronization in Office 365 http://technet.microsoft.com/en-us/library/hh852469.aspx#bkmk_adcleanup
* Remove duplicate proxyAddress and userPrincipalName attributes. * Update blank and invalid userPrincipalName attributes with a valid userPrincipalName. * Remove invalid and questionable characters in the givenName, surname (sn), sAMAccountName, displayName, mail, proxyAddresses, mailNickname, and userPrincipalName attributes. Appendix F Directory Object Preparation http://technet.microsoft.com/en-us/library/hh852533.aspx Any object is filtered if: match well known exclusion pattern UPN Checks * Should confirm to rfc2822 — checked in mtChecks * @ needs to be present — checked in mtChecks as part of rfc2822 * Length before @ = 48 — checked in mtChecks Length * Length after @ = 64 — checked in mtChecks Length * Cannot contain space \ % & * + / = ? { } | < > ( ) ; : , [ ] “ umlaut — RegEx * @ cannot be first character — RegEx * period (.), ampersand (&), space, or at sign (@) cannot be the last character — RegEx * No duplicates — checked in mtChecks |
As table from other source:
Some braindump’s from productive Azure Connector so you see it’s once after it’s base configured in 300+ store:
Blank Server 2016
- Local SQL Express 2019 (Limit is 100’000 Objects in your Active Directory on the SQL Express, Maybe pro check?)
- The Components C++ which get installed pre req.
- Azure AD Connect Components installed (From: AzureADConnect.msi file)
SRV2016
Menu strcuture
Log for the Connectors and a sample chage he synced.
The Connectors and their Options:
What to SYNC and not >
You will understand when your program ADI in Script or PS or used ADSIEDIT then you may have used such a table with the Attributes.
