Drücke "Enter", um den Text zu überspringen.

Kategorie: Microsoft

Einsteiger Kurs zu PowerShell DSC in MVA online!

Der Einsteigerkurs zu PowerShell Desired State Configuration, den Jan-Henrik Damaschke (ebenfalls CDM MVP) und ich letztes Jahr erstellt haben, ist nun auch endlich in der Microsoft Virtual Academy (MVA) online, und zwar zu finden unter diesem Link:

https://mva.microsoft.com/de-de/training-courses/powershell-dsc-einsteigerkurs-17238

dsc

Viel Spaß damit!

Pssst: Wir beide werden schon bald den Fortgeschrittenen-Kurs aufzeichnen, bleibt also dran!

Schreibe einen Kommentar...

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=Useraccounts,DC=DOMAIN,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

3 Comments

Zu Gast bei #Geeksprech – Podcast zum Thema PowerShell

Gestern Abend war ich zu Gast bei #Geeksprech. Cloud and Datacenter MVP Eric Berg hat mir viele Fragen zu PowerShell gestellt und ich habe Sie nach bestem Wissen beantwortet. Außerdem sind wie über das eine oder andere Randthema ins Gespräch gekommen.

logo_haiko

Die Aufzeichnung findet ihr als Podcast auf verschiedenen Plattformen:

Podcast.de

SoundCloud

iTunes

ShowNotes dazu

Facebook-Auftritt von Geeksprech

Hört mal rein – es lohnt sich! Und an Eric: Danke für die Einladung Zwinkerndes Smiley

Schreibe einen Kommentar...

Passwort Self-Service für Office 365 und Azure AD – nur mit Premium-Lizenz

Nur als kurze “Randnotiz”: Wenn man eine Office 365 Subscription hat und seine Benutzerkonten aus einem On-Premise Active Directory nach Azure AD synchronisiert, dann kann man zwar an verschiedenen Stellen Dinge wie Passwort-Reset und andere Self-Service-Angebote aktivieren, diese aber nicht (so ohne Weiteres) benutzen. Der Benutzer bekommt beim Versuch, das Kennwort zu ändern eine Fehlermeldung, in etwa so:

kennwort1

oder so:

kennwort2

Im Wortlaut für die Suche:

“Ihr Konto ist für ein Zurücksetzen des Kennworts nicht aktiviert. Leider hat der Administrator Ihr Konto nicht zum Verwenden dieses Dienstes eingerichtet.”

bzw.

“Sie können Ihr Kennwort hier nicht ändern. Eine Kennwortänderung auf dieser Website wird von Ihrer Organisation nicht gestattet.”

Das Problem dabei ist: Mit dem in Office 365 enthaltenen Azure AD Lizenzen (Entspricht der Lizenzstufe Azure AD Basic) ist das nicht möglich – man bräuchte dazu Azure AD Premium! Und das wiederum wäre nur für dieses eine Feature (wenn man den Rest nicht braucht) in meinen Augen zu teuer…

Zitat aus der Microsoft Doku (https://docs.microsoft.com/en-us/azure/active-directory/active-directory-passwords):

Pricing and availability

Azure AD Password Reset is available in 3 tiers, depending on which subscription you have:

  • Azure AD Free – cloud-only administrators can reset their own passwords
  • Azure AD Basic or any Paid O365 Subscription – cloud-only users and cloud-only administrators can reset their own passwords
  • Azure AD Premium – any user or administrator, including cloud-only, federated, or password synced users, can reset their own passwords (requires password writeback to be enabled)

Heisst also, man kann nur die nicht-synchronisierten Accounts in der kostenlosen Stufe ändern bzw. zurücksetzen lassen.

2 Comments

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/

8 Comments

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

Schreibe einen Kommentar...

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

2 Comments

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

Schreibe einen Kommentar...

Windows Server NIC-Teaming: Problem mit doppelter MAC beheben

Auf einem Test-Host unter Windows Server 2016 mit Hyper-V ist mir heute folgende Fehlermeldung im Eventlog aufgefallen:

lbfo1

(MAC Conflict: A port on the virtual switch has the same MAC as one of the underlying team members on Team Nic Microsoft Network Adapter Multiplexor Driver) – Source: MsLbfoSysEvtProvider / Event-ID 16945

Wenn man mittels PowerShell nach den MACs schaut bestätigt sich das auch schnell:

Get-NetAdapter | Sort MacAddress

lbfo2

Als Lösung habe ich die MAC des Teams (mittels PowerShell, da es ein Core-Server ist) geändert:

Get-NetAdapter “Name” | Set-NetAdapter –MacAddress 00-00-00-00-00-00

lbfo3

Schreibe einen Kommentar...