Nur eine kurze Notiz, da es dazu insbesondere im Deutschen Internet keine brauchbaren Texte gibt:
Solltet ihr beim Versuch, einen Host bzw. dessen LCM (Local Configuration Manager) bei einem Pull-Server zu registrieren einen derartigen Fehler bekommen:
Als Text:
Fehler bei der Registrierung des Dsc-Agents beim Server https://SRV1.lab.hertes.net:8080/PSDSCPullServer.svc. Der zugrunde liegende Fehler ist:
Beim Versuch, den DSC-Agent mit AgentId C60FE00B-9EB7-11E6-B56F-00155D003B07 beim Server https://srv1.lab.hertes.net:8080/PSDSCPullServer.svc/
Nodes(AgentId='C60FE00B-9EB7-11E6-B56F-00155D003B07') zu registrieren, wurde der unerwartete Antwortcode Unauthorized zurückgegeben..
+ CategoryInfo : InvalidResult: (root/Microsoft/...gurationManager:String) [], CimException
+ FullyQualifiedErrorId : RegisterDscAgentUnsuccessful,Microsoft.PowerShell.DesiredStateConfiguration.Commands.RegisterDscAgentCommand
+ PSComputerName : SRV2.lab.hertes.net
Die wesentliche Message im Fehlertext ist wohl:
“Unauthorized”
Die Lösung des Problems ist zwar denkbar einfach, dafür aber auch aus der Kategorie “Schnell mal vergessen”:
In der Konfiguration des Pull-Servers wird diesem ein Verzeichnis mitgeteilt, in dem er die zulässigen Registration-Keys finden kann:
Wenn man nun einfach vergessen hat, die vom neuen Host zu verwendende GUID dort abzulegen, dann wird dieser eben als nicht autorisiert abgelehnt…
Abhilfe schafft hier eine Zeile im Code der Registrierung des neuen Hosts, die man dann idealerweise direkt vom Pull-Server aus auslöst:
Die wesentliche Zeile habe ich rot markiert. Ich schreibe die GUID zusätzlich in ein einzelnes File in einem anderen Pfad, um leichter prüfen zu können, ob ich für den Server bereits eine GUID vergeben hatte…
Vor zwei Wochen habe ich nun endlich die E-Mail-Kommunikation meiner Firma auf Office 365 umstellen können. Diese eigentlich gar nicht so aufwändige Projekt war leider durch zu viele kleine Dinge im Alltag zeitlich in die Länge gezogen worden.
Aus den Erfahrungen bei der Migration möchte ich hier ein paar Hürden und Stolpersteine, die mir im Zusammenhang mit Azure AD Connect begegnet sind, erläutern, in der Hoffnung, dass andere diese so umgehen können.
Azure AD Connect zu früh benutzt I
Ich hatte Azure AD Connect bereits aktiviert, bevor ich den Migrationsendpunkt (Migration Endpoint) für die Cutover-Migration angelegt hatte. Danach ließ sich die Option “Übernahmemigration” (Das ist die Cutover-Migration) nicht mehr auswählen, diese war ausgegraut (siehe mein Blogpost vom 12.09.2016)
Erkenntnis: Azure AD Connect erst benutzen, wenn der Migrationsendpunkt angelegt ist. (siehe auch nächster Punkt!) Alternativ kann AD Connect auch wieder abgeschaltet werden: (kann ggf. einige Stunden dauern)
Azure AD Connect zu früh benutzt II
Ich hatte, bevor alle Postfächer durch Cutover-Migration umgezogen waren, schon Azure AD Connect (früher DirSync) auf unseren Systemen installiert und einige Benutzer aus unserem Active Directory zu Azure bzw. Office 365 synchronisiert. Für diese Benutzer konnte ich dann keine Postfächer mehr per CutOver-Migration migrieren, weil dann bemängelt wird, dass es bereits Objekte mit der selben Mailadresse gibt.
Erkenntnis: Azure AD Connect erst benutzen, wenn alle Postfächer migriert sind.
Azure AD Connect kommt mit multiplen Mail-Adressen im AD nicht so gut klar
Neben der finalen Mailadresse unserer Public Domain hatten die Exchange-Postfächer (und damit auch die AD Objekte der Benutzer) mehrere Mailadresse, u.a. die der lokalen internen AD Domäne. Diese sind u.a. im Attribut “ProxyAddresses” gespeichert. Die primäre Mailadresse hat dabei ein großgeschriebenes “SMTP:” vorangestellt, alle anderen ein kleingeschriebenes:
“SMTP:username@contoso.com” is an acceptable value.
“username@contoso.com” and “smtp:username@contoso.com” are not acceptable values.
Als Fehler kommt “Das Objekt kann nicht aktualisiert werden, weil die folgenden dem Objekt zugeordneten Attribute Werte aufweisen, die möglicherweise bereits einem anderen Objekt in Ihren lokalen Verzeichnisdiensten zugeordnet sind” – und zwar für jeden User der Domäne.
Also habe ich vorübergehend alle kleingeschriebenen “smtp” durch großgeschriebene ersetzt (ACHTUNG: Das ist nur temporär, in der Zwischenzeit solltet ihr keine Exchange-Konsolen benutzen, da diese damit ein Problem haben, dass es mehrere primäre Adressen gibt! Alternativ könnte man auch alle sekundären Adressen entfernen – das kam für mich aber nicht in Betracht). Dies habe ich natürlich mit PowerShell erledigt:
Selbst nach dem ich dies bei allen Benutzer gemacht hatte kam ausgerechnet für mein eigenes Konto noch immer der selbe Fehler:
Dabei hatte ich meinen Account ebenso behandelt wie alle anderen. Dieses Mal war die Ursache aber eine andere: Es gab noch einen gelöschten O365-Benutzer mit dieser Adresse! Also musst auch noch der gelöschte Benutzer endgültig gelöscht werden. Dies habe ich ebenfalls per PowerShell gelöst:
Da ich die letzten Tage im Ausland unterwegs war diese Meldung etwas verzögert:
Sowohl Windows Server 2016 als auch System Center 2016 sind seit gestern “General Available” also für die Allgemeinheit verfügbar. Dadurch sind die Produkte nun also auch in der MSDN…
… als auch im VLSC verfügbar:
Natürlich könnt ihr die Produkte auch weiterhin über das Evaluation Center herunterladen. Viel Spaß damit!