ADSync Preflight Check

Ehe Sie das DirSync Setup durchführen, müssen Sie "Vorab" ein Readyness Check" ihres Active Directory durchführen und Probleme beseitigen. Dies ist allemal besser als auf die Fehler zu warten und dann erst zu korrigieren. Einige Korrekturen sind durchaus nicht mal eben schnell durchgeführt sondern müssen abgestimmt werden.

Beachten Sie dazu auch das Hilfsprogramm IDFix.

Anforderungen

Microsoft beschreibt selbst auf folgenden Seiten die Anforderungen an AD-Objekte für den DirSync:

Es sind wesentlichen ein paar AD-Felder, die auf Länge, Inhalt und Eindeutigkeit zu prüfen sind. Zudem gibt es noch ein paar Test z.B. bezüglich des Windows Domain- und Forestmode

  • Windows 2003 Forest functional Mode oder höher
    Bedenken Sie, dass Firmen gerne "vergessen" oder unsicher sind den Mode anzuheben. Ich habe durchaus schon Umgebungen mit Windows 2008 DCs gesehen, die immer noch auf dem Windows 2000 Mode waren und damit nicht von dern Vorteilen einer schnellren Replikation, des AD-Papierkorbs etc. profitiert haben.
  • Domain darf keine "Single Label Domain" sein.
    Ich hoffe ihre AD-Domain ist ein FQDN mit einem "punkt" zwischen drin. Es muss aber keine "Public DNS Domäne" sein.
  • UPN-Domains müssen öffentliche DNS-Namen sein
    Ansonsten kann die Domain nicht anhand von DNS-Einträgen verifiziert werden und ist nicht für ADFS nutzbar

Hoffen wir, dass diese Voraussetzungen erfüllt sind. Speziell eine "Single Label Domain" ist nicht so schnell zu lösen und die Umstellung der UPNs auf öffentliche Namen ist im AD schnell gemacht aber kann Produkte stören, die diesen "String" also primären Schlüssel oder sonst wie verwenden, z.B. Unix-Anmeldungen etc.

Sizing

Die meisten Office 365 Firmen sind vermutlich kleiner und erreichen kaum die Menge von 50.000 Objekten mit einer Mailadresse, die für den DirSync eine erste kritische Grenze darstellen oder 300.000 als nächste Grenze. Sie sollten diese aber können:

  • 50.000 Objekte im Office 365 AD
    Per Default erlaubt Office 365 maximal 50.000 Objekte im Active Directory der Cloud pro Tenant. Diese Limit kann über einen Support Call oder die Einrichtung einer autorisierten Domäne angehoben werden.
  • 50.000 "Mail-Enabled Objekte" pro Tenant
    Um dieses Limit zu erhöhen, muss der Support angesprochen werden.
  • 50.000 Objekte im On-Prem-AD
    Der DirSync Server basiert auf FIM und nutzt eine SQL Express-Instanz als unterbau. Microsoft empfiehlt ab 50.000 Objekten die Installation oder Nutzung eines lizenzpflichtigen SQL-Servers, damit die Funktion aufgrund der Beschränkungen von SQL Express nicht behindert wird. Das kann Hauptspeicher und Performance aber auch die Datenbankgröße betreffen.
  • 300.000 Objekte
    Durch die Einrichtung einer "verifizierten" Domäne in Office 365 wird das Limit von 50.000 auf 300.000 Objekte im Office 365 Active Directory erhöht. Das sollte für die meisten Firmen reichen.

Auch bezüglich der Hardware liefert Microsoft Empfehlungen mit.

Bis zu 50.000 Objekte soll ein Server mit 1,6 GHz CPU,  4 GB Ram und 70 GB Festplatte reichen. Aber 50.000 User wird aber schon ein voller SQL-Server benötigt und wer dann 600.000 Objekte abgleichen will, ist schon bei 32 GB Ram und 450 GB Disk. Der Platz für das "Metaverse" in der SQL-Datenbank fordert hier seinen Tribut.

Nach meinem Verständnis ist die Größe des Metaverse relevant. Wer also per Filter aus dem On-Prem AD nur eine Teilmenge an Objekten überhaupt in die SQL-Datenbank importiert, sollte nach meinem Verständnis kein Problem damit haben, wen im AD deutlich mehr Objekte vorhanden sind.

Allerdings sollten Sie etwas "Geduld" bei der ersten Synchronisation mitbringen. Man kann davon ausgehen, dass vielleicht 5000 User/Stunde initial gepflegt werden. Eine Firma mit 50.000 Elementen kann hier durchaus einmal 10 Stunden brauchen. Spätere Updates sind schneller. Aber auch dann kann es bis zu 24 Stunden dauern, bis die neuen User z.B.: in Exchange Online im Adressbuch auftauchen. Der OAB-Generierung sei dank, die nur einmal am Tag läuft und erst dann kann der Outlook Client das OAB herunterladen. Auch das dauert bei vielen neu angelegten Benutzer etwas.

Tipp: Nutzen Sie Outlook Web App um die GAL schon früher einzusehen.

Feldchecks

Aus diversen Quellen habe ich mir folgende Checks zusammen gesucht.

Feldname Prüfungen

SamAccountname
  • 1-20 Zeichen
  • Ungültig: !#\$%\^&\{\}\\{`~"",\\/\[\]:@<>\+=;\?\*
  • Optional, wenn UPN vorhanden

UserPrincipalName
  • Erforderlich
  • UserPart: 1-64 Zeichen und darf nicht mit . (Punkt) oder & (Ampersand) oder @ oder Space enden
  • Domainname max. 256 Zeichen
  • @ erforderlich
  • Ungültig: ! # $ % & \ * + - / = ? ^ _` { | } ~ < > ( )` Space
  • Eindeutig im Forest

givenName
sn (Surname)
  • 1-64 Zeichen
  • Ungültig: ?@\+

displayName
  • 1-256 Zeichen
  • Ungültig: \?@\+

Mail
  • 1-256 Zeichen
  • Ungültig: [! #$ %&*+ / = ? ^ ` { }]
  • Muss ein "@" enthalten und auch sonst eine Mailadresse sein.
  • Eindeutig im Forest

MailNickName
  • 1-64 Zeichen
  • Ungültig: ""\\\[\]:><; a space

proxyAddresses
  • Multiline
  • 1-256 Zeichen pro Eintrag
  • Ungültige \)\(;><\]\[\\,
  • Eindeutig im Forest

targetAddress
  • 1-256 Zeichen
  • Ungültig: [! #$ %&*+ / = ? ^ ` { }]

ms-DS-ConsistencyGuid

 Das Feld sollte leer sein, wenn wirklich noch nie ein ADSync eingesetzt wurde und eine "Cross Forest Migration" von Objekten aus anderen Forests erfolgt ist. Siehe auch SourceAnchor

Zusätzlich müssen Gruppen und Kontakte ein "@" im Feld Mail haben, wenn das Feld gesetzt ist.

Doppelte Mailadressen

Es ist nicht ungewöhnlich, dass ihnen Office 365 eine Mail sendet, dass ein Objekte aufgrund von Problemen der Mailadresse nicht importiert werden kann. In der letzten Spalte steht die MailboxGUID der On-Premises-Mailbox. Allerdings BASE64 codiert, so dass Sie diese erst wieder ein ein lesbares Format überführt werden muss. Ein bisschen PowerShell hilft hierbei.

# Hier muss der TEXT aus der Mail addiert werden
$Base64="Z4KTdsddaay1JJU/Q=="

# Konvertieren der BASE64 Information in eine GUID
$MailboxGUID=[System.Guid]([System.Convert]::FromBase64String($Base64))

# Mit der GUID kann dann die Mailbox gefunden werden
$Mailbox = Get-Mailbox $MailboxGUID.Guid

Ich habe es durchaus schon erlebt, dass das Azure AD hier auch Dubletten gemeldet hat, die gar keine waren. Es bleibt aber ihre Aufgabe als Admin die Probleme einzukreisen, denn erwarten Sie nicht, dass der Office 365 Helpdesk ihnen bei On-Premises Problemen helfen kann. Das ist im Preis nicht machbar.

Linked Mailbox

Dieser Abschnitt ist auch auf MSXFAQ.DE:Office 365:DirSync mit Exchange zu finden.

Beachten sie, wenn ihre aktuelle Exchange On-Prem-Umgebung noch Objekte vom Typ LinkedMailbox hat. Diese Objekte gibt es bei Umgebungen mit einem Ressourceforest und sind normalerweise Disabled Accounts. Es soll aber schon vorgekommen sein, dass diese Objekte auch bei Migrationen eingesetzt werden und nach Abschluss aller Umstellungen dennoch nicht zu "normalen Postfächern" konvertiert wurden. Das ist so kein Problem, da das Konto ja im AD durchaus aktiviert werden kann und Outlook und andere Clients sich problemlos an dieses Postfach auch anmelden.

Vom Konzept her sind aber solche Objekte eben keine aktiven Anmeldekonten. Der DirSync geht daher davon aus, dass "von woanders" noch das Anmeldekonto in die Cloud synchronisiert wird. Siehe dazu auch Multi-Forest Identity. Wenn der DirSync also aus einem anderen Forest das aktive Anmeldekonto in die Cloud repliziert hat, dann kann der DirSync dann auch die Exchange Properties dort anwenden.

Wenn Sie allerdings keinen weiteren Forest mehr haben, dann konvertieren Sie die Linked-Mailbox einfach in eine normale Mailbox

# Linked mailbox in Usermailbox verwandeln
[PS] C:\>set-User User1 -LinkedMasterAccount $null'

Siehe dazu auch

Lync bzw. Skype vor Business

Die meisten Firmen, die Office 365 nutzen wollen, haben bislang noch nicht mit OCS, Lync oder Skype für Business in ihrer eigenen lokalen Umgebung (On-Prem) gearbeitet. Sicher gibt es einige Firmen, die dies schon tun und die bei einer Office 365 Einführung dann auch bezüglich des Hybrid-Mode etwas aufpassen müssen, aber die Mehrzahl hat lokal keinen IM-Server stehen.

Wobei man genauer sagen müsste: "Es gibt keinen mehr". Es ist gar nicht so ungewöhnlich, dass in den letzten Jahren nicht doch es mal versucht wurde, mit OCS, Lync oder Skype für Business zu arbeiten. Und so kommen wir immer wieder in Firmen, bei denen der DirSync funktioniert aber die Benutzer in der Cloud einfach keinen Skype für Business Account bekommen. Die Ursache sind hier meist "Altlasten" in Form von AD-Einträgen On-Prem, die durch den DirSync in die Cloud übertragen werden und letztlich die Aktivierung des Skype für Business Kontos in Office 365 verhindern.

UPN mit Office 365

Ein Schlüsselelement des DirSync ist der UserPrincipalName, der natürlich On-Premises und "in der Cloud" identisch sein sollte. Er ist der "Matchcode" um bei ADFS und anderen Anmeldungen das Objekt korrekt zu identifizieren. Idealerweise ist das auch die Mailadresse, weil damit die Anwender sich das einfacher merken können aber vor allem auch weil damit der Eintrag weltweit eindeutig ist.

Siehe dazu auch UPN / Anmeldename

Achtung: Es kann Personen geben, die den gleichen Namen schon als "LiveID", "Passport", Microsoft Konto" verwenden. Hier sollten Sie darauf drängen, dass die Mitarbeiter vorher ihre LiveID ändern. Es gibt durchaus Webseiten, die eine Anmeldung mit einer LiveID als auch einem ADFS-Konto aus Office 365 erlauben und dann durcheinander kommen.

Nun ist es aber so, dass der UPN On-Prem oft nicht gesetzt ist oder der DNS-Name der AD-Domäne als Suffix verwendet wird. Der ist aber in vielen Fällen eben nicht identisch mit der Mailadresse. Entsprechend müssen Sie dies gerade ziehen:

  • UPN Suffix addieren
    Damit sie einem Benutzer einen UPN mit einer Domäne vergeben können, die nicht zugleich als Active Directory Domain fungiert, müssen sie diese "Domain" erst mal im AD festlegen
    Siehe dazu auch 243629 HOW TO: Add UPN Suffixes to a Forest
  • UPN der Windows Benutzer anpassen
    Dann müssen Sie den Benutzer in ihrem Active Directory den passenden UPN eintragen. Wenn sich die Anwender heute noch mit "Domäne\Username" anmelden und es keine Kopplung z.B. an Unix-Systeme gibt, dann sollte diese Änderung keine Probleme machen. Nur wer sich heute schon mit dem "alten UPN" anmeldet, muss diese dann umstellen. müssenÄnderungen macht man am besten per PowerShell.
# Liste der Benutzer ermittlen, für die der UPN umgestellt werden muss
$Userlist = Get-ADUser `
   -Filter {UserPrincipalName -like ‘*msxfaq.local’} `
   -Properties UserPrincipalName,mail | `
$Userlist | foreach { `

# UPN aus dem Feld NAME zusammenbauen
   Set-ADUser $_ -UserPrincipalName ("{0}@{1}" -f $_.name,"msxfaq.net")

# UPN aus der Mailadresse nehmen
   Set-ADUser $_ -UserPrincipalName ("{0}@{1}" -f $_.mail)
}
  • DirSync in die Cloud
    Leider ist der UPN der Name, der vom Office 365 DirSync nicht mit in die Cloud übertragen wird. Hier müssen Sie also von Hand nacharbeiten. Hier am Beispiel, wenn Sie die primäre Mailadresse nutzen.
Get-MsolUser | `
%{ `
   Set-MsolUserPrincipalName `
      -ObjectID $_.objectid `
      -NewUserPrincipalName ($_.ProxyAddresses | where {$_.startswith("SMTP")}).substring(5)}

Nur beim ersten Abgleich wird der UPN der eigenen Umgebung an ein neues Objekt on der Cloud übertragen. Änderungen am UPN müssen Sie also anders abfangen. Spätestens wenn der Benutzer bei Anmeldeproblemen sich meldet, wäre das ein Prüfpunkt.

Matching mit dem Ziel

In vielen Fällen haben Sie vielleicht vorher schon einige Objekte in ihrer Office 365 Umgebung eingerichtet. Vielleicht zum Test von ADFS sogar schon mit dem gleichen UPN wie On-Premises. Dann ist es wichtig zu wissen, wie der DirSync beim ersten Lauf Objekte zuordnet. Dieses Wissen um die Zuordnung ist noch aus einem anderen Grund wichtig: Wenn ihr DirSync Server einmal ausgefallen ist und nicht wieder hergestellt werden kann, dann können Sie den DirSync einfach neu installieren. Auch ein Update des DirSync-Servers ist eigentlich eine Deinstallation und Neuinstallation mit den gleichen Einstellungen. Auch ein Wechsel von DirSync auf ADSync ist eine Neuinstallation.

  • AD: ObjectGUID = Office 365: ImmutableID
    Zuerst versucht der DirSync die GUI aus dem AD als Base64-codierten String im Ziel als "ImmutableID" zu finden. Die ObjectGUID im lokalen Active Directory sollte nicht nur einmalig sondern auch beständig bleiben. Selbst wenn Sie Konten zwischen Domänen verschieben, kann die ObjectGUID mitgenommen werden. Insofern ist dies ein sehr starker Key zum wiederauffinden bereits früher synchronisierter Objekte. Da Sie das Feld ImmutableID in der Cloud aber auch beschreiben und ändern können, ist es eine gute Basis um im Ziel die Vorarbeiten für ein erstmaliges Matching zu schaffen

Hier ein Beispielcode, um die ObjectGUID eines AD-Objects zu lesen und als Base64-Wert an einen User mit übereinstimmendem UPN zu schreiben.

$dn = "cn=User,dc=msxfaq,dc=local"
$adUser = get-adUser -identity $dn properties objectguid
$guid = $adUser.objectguid
$upn = $adUser.UserPrincipalName
$ImmutableID = [System.Convert]::ToBase64String($guid.ToByteArray())
set-msolUser -UserPrincipalName $upn -immutableID $ImmutableID
  • SMTP-Address matching
    Als zweite Option kommt die SMTP-Adresse in Frage. Dabei bedient sich der DirSync der primären SMTP-Adresse in der Quelle, die im Feld "mail" steht und sucht ein entsprechendes Objekt in der Cloud mit der gleichen SMTP-Adresse im Feld Mail. Bei einem Match wird das bestehende Zielobjekt mit den Daten des Quellobjekts aktualisiert und auch die ImmutableID aktualisiert.

Erst mit ADSync gibt es mehr Funktionen. Hier wird aber schon beim Setup bestimmt, wie das Matching erfolgen soll:

Max 500 Deletions

Es kann ja schon mal passieren, dass beim ersten DirSync etwas schief gegangen ist oder es einen Tenant in Office 365 gibt, der für frühere Tests mit einer Testumgebung genutzt wurde. Dann haben Sie natürlich zuerst mal die Aufgabe, diesen Tenant aufzuräumen. Sie können natürlich einfach den alten DirSync mit dem Testforest abschalten, den Tenant wieder zurückdrehen und dann die Objekte löschen. Denken Sie daran, dass Sie dann aber auch die Objekte im "Papierkorb" richtig löschen.

Aber auch wenn Sie einen produktiven Forest mit DirSync zu einem Tenant verbunden haben, kann es notwendig sein viele Objekte noch einmal zu löschen. Das passiert besonders, wenn Sie die Objekte z.B.: anhand von LDAP-Feldern oder OUs filtern und eine größere Anzahl an Objekten in eine OOU außerhalb des Scope verschieben oder das LDAP-Filterfeld ändern.

Das kann auch gerne mal unabsichtlich passieren. Wenn Sie z.B. alle Objekte in die Cloud replizieren, die im Feld "Company" einen bestimmten String haben und dann durch eine Namensänderung dieses Feld geändert wird. Wenn ein Objekt aus dem DirSync-Scope fällt, wird es im Ziel eigentlich gelöscht. Bei Office 365 ist das Objekt natürlich nicht komplett entfernt sondern "nur" im Papierkorb. Der Anwender kann aber nicht mehr arbeiten aber sie können ihren Fehler mit minimalem Datenverlust wieder rückgängig machen.

Microsoft hat aber auch selbst ein Schutz-Limit eingeführt. Anscheinend löscht der DirSync per Default nicht mehr als 500 Objekte. Dieses Limit können Sie mit dem PowerShell-Befehl "Set-PreventAccidentalDeletes" ändern.

Permanente Kontrolle

Dieses Programm ist natürlich immer "interaktiv" auszuführen und ich habe noch keinen Weg gefunden, dass es regelmäßig überprüft. Insofern plane ich ein Modul für CheckADObjects, welches bei einer ObjektÄnderung sofort die Konformität überprüft.

Weitere Links