Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

5Feb/170

Office 365: Letzten Exchange-Server entfernen

Nach einer Migration zu Office 365 kann es sinnvoll bzw. gewünscht sein, alle on-premise Exchange-Server zu deinstallieren. Microsoft selbst beschreibt dies z.B. in der Schritt-für-Schritt-Anleitung für eine Cutover-Migration (Übernahmemigration):

Außerbetriebnahme der lokalen Exchange Server.    Nachdem Sie sich vergewissert haben, dass alle E-Mails direkt an die Office 365-Postfächer weitergeleitet werden, und wenn Sie Ihre lokale E-Mail-Organisation nicht mehr benötigen oder nicht planen, eine Lösung für einmaliges Anmelden zu implementieren, können Sie Exchange auf Ihren Servern deinstallieren und Ihre lokale Exchange-Organisation entfernen.

(https://support.office.com/de-de/article/Durchf%C3%BChren-einer-%C3%9Cbernahmemigration-von-E-Mails-zu-Office-365-9496e93c-1e59-41a8-9bb3-6e8df0cd81b4?ui=de-DE&rs=de-DE&ad=DE#postmigration)

Im Nachsatz dazu heisst es dann interessanterweise:

HINWEIS : Eine Außerbetriebnahme von Exchange kann unerwartete Folgen haben. Vor der Außerbetriebnahme Ihrer lokalen Exchange-Organisation sollten Sie Kontakt mit dem Microsoft-Support aufnehmen.

Ich für meinen Teil wollte in erster Linie den Alten Exchange 2010 loswerden. Vermutlich werde ich später einen neuen Exchange 2016 installieren…

ACHTUNG: Wenn DirSync bzw. Azure AD verwendet werden, dann können AD-Attribute nur on-premise und nicht in Azure geändert werden. Wenn Exchange entfernt wird, können einige Mail-relevante Attribute nicht mehr geändert werden. Einige Attribute könnten zwar über ADSIEdit geändert werden, das wird aber offiziell nicht unterstützt!

Aber reden wir weniger über das WARUM als viel mehr über das WIE…

Wenn man sich nun also entschieden hat, den (letzten) Exchange-Server los zu werden und die Deinstallation gestartet hat, wird man relativ schnell feststellen, dass es nicht ganz so einfach ist! Die Deinstallation stört sich nämlich daran, dass es noch Postfächer gibt:

Exch1

Nun könnte man natürlich einfach alle Mailboxen löschen (bzw. deaktivieren – löscht man eine Mailbox, löscht man den dahinterstehenden AD Benutzer, also keine gute Idee), aber: Nach dem Deaktivieren der Mailbox hat der entsprechende AD-Benutzer keine E-Mail-Adresse mehr (und er verliert auch auf anderen Attributen die Werte), was durchaus ein Problem für DirSync bzw. eine Synchronisation zu Azure AD sein kann. Was ist nun also der richtige Weg?

Im wesentlichen sind zwei Schritte notwendig:

  1. Mailbox deaktivieren
  2. Benutzer in einen so genannten “Mail-Enabled-User” umwandeln

Die Schwierigkeit dabei besteht darin, dass die E-Mailadresse “zwischengespeichert” werden muss, damit diese dem Mail-Enabled-User zugewiesen werden kann (oder man hat eine Syntax, nach der sich ALLE E-Mail-Adressen bilden lassen, da könnte man das weglassen)

Das Ganze habe ich natürlich mit PowerShell gelöst. Das folgende Skript soll ein Anhalt sein, passt es bitte an eure Gegebenheiten an!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
Import-Module ActiveDirectory
 
$mbxs = Get-Mailbox # This will disable ALL mailboxes! Pay attention...
 
foreach ($mbx in $mbxs) 
{
    $adusr = Get-ADUser $mbx.SamAccountName -Properties mail,mailNickname,msExchShadowProxyAddresses,proxyAddresses,UserPrincipalName
 
    # Getting Mailboxes mail adress befor disabling it
    If($adusr.Mail -eq "")
    {
        [string]$MailAdress = $mbx.UserPrincipalName
    }
    else
    {
        [string]$MailAdress = $adusr.Mail
    }
 
    Disable-Mailbox -Id $mbx.Identity -Confirm:$False
    Enable-MailUser -Id $mbx.Identity -ExternalEmailAddress $MailAdress
    Set-MailUser -Id $mbx.Identity -EmailAddresses $MailAdress
}
 
# Make users MailEnabled users that never had a mailbox
 
$newUsersWithoutMailbox = Get-ADUser -Filter * -SearchBase "OU=TempOuForNewEmps,OU=internal_users,OU=users,OU=API-Leipzig,DC=API-Leipzig,DC=local" -Properties Mail,UserPrincipalName
foreach($user in $newUsersWithoutMailbox)
{
    $FullDistinguishName = “LDAP://+ $user.distinguishedName
    $AccountEntry = New-Object DirectoryServices.DirectoryEntry $FullDistinguishName
    $AccountEntry.PutEx(1, “msExchHomeServerName”, $null)
    $AccountEntry.SetInfo()
 
    If($user.Mail -ne "")
    {
        [string]$MailAdress = $user.Mail
    }
    else
    {
        [string]$MailAdress = $user.UserPrincipalName
    }
    # Enable-MailUser 
 
    If((Get-MailUser $user.SamAccountName -ErrorAction SilentlyContinue).RecipientType -ne "MailUser")
    {
        Enable-MailUser -Id $user.SamAccountName -ExternalEmailAddress $MailAdress
    }
 
    Set-MailUser -Id $user.SamAccountName -EmailAddresses $MailAdress
}

 

Nach dem nun keine Mailboxen mehr vorhanden sind, wäre es möglich, dass der Deinstallationsassistent weitere Probleme meldet, u.a. könnten:

  • noch Public Folder Databases mit Replikaten,
  • Arbitration-Mailboxes oder
  • weitere Inhalte in der Mailbox Database

vorhanden sein.

Für die Replicas in der Public Folder Database bzw. die Database selbst könnten folgende PowerShell-Aufrufe nützlich sein:

1
2
3
4
5
Get-PublicFolder -Identity \ -GetChildren | Remove-PublicFolder -Recurse 
 
Remove-PublicFolderDatabase -Identity "My Public Folder Database" 
 
Get-PublicFolderDatabase | Remove-PublicFolderDatabase –RemoveLastAllowed

 

Für das Entfernen der (ggf. letzten) Arbitration Mailbox hilft

1
Get-Mailbox –Arbitration | Disable-Mailbox –Arbitration –DisableLastArbitrationMailboxAllowed

Danach sollte es möglich sein, Exchange “normal” zu entfernen:

Exch4

10Jan/172

Active Directory: Benutzer GPOs mit Sicherheitsfilterung funktionieren nicht

Ja, ich weiß, ich erzähle jetzt hier nichts brandneues mehr. Aber vielleicht geht es anderen so wie mir diese Woche, daher also dieser Artikel. Aber erst mal von Anfang an:

Ich habe diese Woche in unserer ActiveDirectory Umgebung eine neue GPO angelegt. Mein Ziel war, damit eine neue Mailsignatur an alle Benutzer auszurollen. Die nötigen Einstellungen befinden sich im Benutzer-Zweig der GPOs, daher spreche ich gerne von einer “Benutzer-GPO”, was man bei mir auch immer im Namen sieht. Um das Ganze erstmal sinnvoll testen zu können, habe ich auf die Sicherheitsfilterung zurückgegriffen. Ihr wisst schon, damit kann man die GPO statt auf die gesamte verknüpfte OU auf einzelne Benutzer oder Gruppen anwenden. Also habe ich die “Authentifizierten Benutzer” entfernt, und stattdessen mich und einen weiteren Kollegen dort eingetragen:

gpo1

Das Problem

Leider wirkte sich die GPO dann nicht wie gewünscht aus. Auffällig war aber, dass ich plötzlich auch das Verzeichnis, in dem sich die GPO-Daten und damit auch das Skript, dass die GPO ausführen sollte, befanden, nicht mehr lesen konnte. Selbst mit einem Domänen-Admin-Konto nicht! Sobald ich die “Authentifizierten Benutzer” bzw. in meinem Fall “Authenticated Users” wieder hinzugefügt hatte, konnte ich die Dateien wieder lesen. Natürlich hätte ich damit aber auch die GPO für die gesamte GPO ausgerollt.

Die Ursache

Ein bisschen Recherche im Internet brachte mich dann auf die Ursache des Problems und damit auch auf dessen Lösung:

Microsoft hatte durch ein Update, dass bereits im Juni 2016 erschienen war, eine wesentliche Arbeitsweise von GPOs geändert:

Bisher war es so, dass für das Wirksamwerden von Computer-GPOs das Computerkonto für die GPO das Lesen-Recht haben musste und bei Benutzer-GPOs das Benutzerkonto. Das Ganze passte auch zur Logik, dass Computer-Richtlinien nur auf Computerkonten wirken und Benutzer-Richtlinien nur auf Benutzerkonten (Ausnahme: Loopback-Verarbeitung). Das hat man auch nicht geändert. Was allerdings geändert wurde ist, dass auch bei Benutzer-Richtlinien das Computerkonto die Leserechte auf die GPO braucht.

Wenn man entweder keine Benutzer-GPOs benutzt oder bei diesen immer die “Authenticated Users” in der “Security Filtering” drin lässt (womit dann faktisch nur noch eine Steuerung über die verknüpfte OU oder über WMI-Filter möglich wird, wenn man nicht vom “verweigern” der Berechtigungen Gebrauch machen will) ändert sich für einen selbst nichts.

Wenn man aber so wie ich gerne mal auch bei Benutzer-GPOs auf die Gruppen- oder Benutzerkonten-bezogene Filterung zurückgreift, dann muss man diese Änderung unbedingt kennen!

Die Lösung

Die Lösung des Problem ist eigentlich recht einfach – wenn man die Ursache kennt. Das Computerkonto des Computers, an dem der jeweilige Benutzer arbeitet muss also in die Lage versetzt werden, die GPO zu lesen. Da man nicht immer weiß, wer gerade wo arbeitet und sich das ja auch täglich ändern könnte, bleibt fast nur, den “Domänen-Computern” das Leserecht zu geben. Und das funktioniert über den Reiter “Delegation” bzw. “Delegierung”:

gpo2

Hier findet ihr noch den Blog-Artikel bei Microsoft, der mich zum Problem und dessen Lösung brachte:

https://blogs.technet.microsoft.com/askpfeplat/2016/07/05/who-broke-my-user-gpos/

3Jan/170

Microsoft Technical Summit 2016: Meine Session ist live auf Channel 9

 

msts16

Ihr könnt die aufgezeichnete Session über PowerShell DSC auf dem MSTS in Darmstadt jetzt auf Channel9 ansehen:

https://channel9.msdn.com/Events/microsoft-techncial-summit/Technical-Summit-2016/Windows-PowerShell-50-Desired-State-Configuration-DSC

Viel Spaß dabei!

Die Slides dazu gibt es hier:

https://download.microsoft.com/download/7/9/D/79DF0CF6-F98C-423B-87A6-1C92E71118DD/211645_WindowsPowerShell50DesiredStateConfiguration.pdf

14Dez/161

Hyper-V auf Windows Server 2012 R2 / 2016: VMs mittels Kerberos verschieben

Im Windows Server 2012 R2 und 2016 steckt ja nun schon seit einer Weile die so genannte “Shared Nothing Live Migration”, die es möglich macht, VMs zwischen Hyper-V-Hosts zu verschieben (auch im laufenden Betrieb), ohne, dass die VM auf einem Hyper-V-Cluster laufen muss, entsprechend ist hier auch kein Storage nötig.

Für die Shared Nothing Migration gibt es zwei Protokolle zur Authentifizierung: CredSSP und Kerberos.

CredSSP ist an sich sehr einfach in der Benutzung, bedarf es doch keiner echten Einrichtung. Lediglich den richtigen Radio-Button auswählen, einmal ab- und wieder anmelden und das war’s. Aber die Sache hat einen Haken: Bei CredSSP kann man nur dann eine VM verschieben, wenn man (lokal oder z.B. per RDP) an dem Hyper-V-Host angemeldet ist, von dem man die VM weg-verschieben will. MMC-Remoting mit dem Hyper-V-Manager geht hier nicht! Versucht man es doch, bekommt man folgende Fehlermeldung:

kerberos00

Im Wortlaut: “Failed to establish a connection with host HOSTNAME. The credentials supplied to the package were not recognized (0x8009030D).”

Insbesondere bei Core-Servern, auf denen es keinen Hyper-V-Manager gibt, wird das Verschieben also einigen Administratoren schwer fallen (wenngleich PowerShell eine nutzbare Lösung wäre).

Auch wenn man jetzt einfach im Hyper-V-Manager auf Kerberos umstellt:

kerberos7

..kommt es immer noch zu einem Fehler:

kerberos0

Im Wortlaut: “The Virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: The specified target is unknown or unreachable (0x80090303).”

Was hier fehlt ist die sogenannte “Constrained Delegation”. Diese einzurichten ist an sich nicht kompliziert, bei steigender Host-Anzahl aber etwas aufwändiger (eine einfachere PowerShell-Lösung versuche ich zeitnah nachzuliefern).

Zur Einrichtung benötigt man Schreibrechte auf den Computer-Objekten der Hyper-V-Hosts im Active Directory oder einfacher gleich einen Domain-Admin-Account.

Über die “Active Directory Users and Computers” öffnet man sich nun der Reihe nach die Computerkonten aller Hyper-V-Hosts und führt dort folgende Einstellung durch:

kerberos1kerberos2kerberos3

kerberos4kerberos5

Im Ergebnis muss es auf jedem Host so aussehen:

kerberos6

Jeder Host muss jedem anderen bei den Diensten “cifs” und “Microsoft Virtual System Migration Service” vertrauen. Kerberos alleine genügt.

Danach muss man natürlich die Hyper-V-Hosts auf Kerberos-Migration umstellen (oder dies zumindest noch einmal überprüfen!)

kerberos7

Das war’s dann schon! Jetzt kann man von jedem Client oder Server aus mittels Hyper-V-Manager auf die Hosts zugreifen und eine Verschiebung initiieren. Viel Spaß dabei!

Hinweis: In einem neueren Artikel zeige ich, wie man die Delegierung unkompliziert per PowerShell einrichten kann:

Hyper-V & PowerShell – Kerberos Delegierung für LiveMigration für mehrere Server gegenseitig eintragen

7Dez/160

PowerShell DSC: Demnächst auch in der “Microsoft Cloud Deutschland”

Unmittelbar vor meiner heutigen Session auf dem Summit hat mit ein Vögelchen gezwitschert, dass die Microsoft Entwickler gerade daran arbeiten, PowerShell DSC in den nächsten Wochen, vermutlich noch im Januar oder Februar 2017, auch in der Deutschen Cloud verfügbar zu machen. Ein Grund mehr, das Ganze mit der bald verfügbaren Free Trial zu testen! 

7Dez/160

Microsoft Technical Summit 2016 – meine Slides und Samples

Für all diejenigen, die meine Demos aus der Technical Summit Session zu PowerShell DSC ausprobieren wollen oder einfach nur die Inhalte nochmal nachlesen wollen, biete ich hier meine Slides und Samples an.

MSTS16_Haiko_Hertes_PowerShell_DSC_-_The_not_too_deep_dive_V3

Zum Ausprobieren braucht ihr einfach nur 3 Windows Server 2016, am besten als VM in Hyper-V. Meine VMs heissen SRV1, SRV2 und SRV3, aber wenn ihr die Skripte anpasst sind natürlich auch andere Servernamen ok.

Hier nun also die Links zum Download:

Die Samples (also die PowerShell Skripte):

MSTS16_Haiko_Hertes_PowerShell_DSC_-_The_not_too_deep_dive_Samples.zip

Die PowerPoint-Slides:

MSTS16_Haiko_Hertes_PowerShell_DSC_-_The_not_too_deep_dive.pdf

30Okt/160

PowerShell DSC: RegisterDscAgentUnsuccessful Fehler

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:

lcm1

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:

lcm2

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:

lcm3

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…

30Okt/160

Skype for Business – jetzt auch endlich für Mac!

Diese Woche hat Microsoft – fast schon “still und heimlich” die vorerst finale Version des “Skype for Business” Clients für den Mac herausgegeben.

Dieser kann hier direkt herunter geladen werden:

https://www.microsoft.com/en-us/download/details.aspx?id=54108

Skype-for-Business-announces-new-Mac-client-and-new-mobile-sharing-experiences-1

In diesem Blogbeitrag des Microsoft Office Teams könnt ihr Näheres lesen:

https://blogs.office.com/2016/10/27/skype-for-business-announces-new-mac-client-and-new-mobile-sharing-experiences/

13Okt/160

Windows Server 2016 und System Center 2016 sind jetzt GA und damit im Download verfügbar!

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…

image

… als auch im VLSC verfügbar:

image

Natürlich könnt ihr die Produkte auch weiterhin über das Evaluation Center herunterladen. Viel Spaß damit!

 

Einige Ressourcen dazu:

Evaluation Version

Leitfaden zu Windows Server 2016

28Sep/160

Windows Server 2016 und System Center 2016 Launch

Nur als kurze “Randnotiz”: Microsoft hat den Windows Server 2016 auf der Ignite in Atlanta vor nicht ganz 2 Tagen gelauncht. Den Blog-Artikel des Windows Server Teams findet ihr hier:

https://blogs.technet.microsoft.com/hybridcloud/2016/09/26/announcing-the-launch-of-windows-server-2016

Leider stehen die Bits noch nicht zum Download zur Verfügung, auch nicht in der MSDN. Allerdings kann man die Evaluation-Version als ISO oder VHD herunterladen, siehe hier:

https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2016

14445094_10154021146281636_2895277330281932190_o

Außerdem wurde am selben Tag das System Center 2016 gelauncht. Infos siehe hier:

https://blogs.technet.microsoft.com/hybridcloud/2016/09/26/announcing-the-launch-of-system-center-2016-and-new-services-for-operations-management-suite/

Die Evaluierungsversion gibt es hier:

https://www.microsoft.com/de-de/evalcenter/evaluate-system-center-2016

 

Viel Spaß mit den neuen Spielsachen!