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!
Schreibe einen Kommentar...Kategorie: PowerShell
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.
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...Auf einem Test-Host unter Windows Server 2016 mit Hyper-V ist mir heute folgende Fehlermeldung im Eventlog aufgefallen:
(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
Als Lösung habe ich die MAC des Teams (mittels PowerShell, da es ein Core-Server ist) geändert:
Schreibe einen Kommentar...Get-NetAdapter “Name” | Set-NetAdapter –MacAddress 00-00-00-00-00-00
Wenn man Office 365 Konten hat, die keinem Benutzer fest zugeordnet sind (in meinem Fall für Konferenz-Telefone), dann ist es eher ungünstig, wenn das Kennwort abläuft. Auch bei regulären Benutzern kann es gewünscht sein, dass das Kennwort nicht abläuft.
Wenn der Benutzer aus dem lokalen Active Directory synchronisiert wird, dann kann man diese Option einfach im lokalen AD einstellen. Aber bei einem Benutzer, der nur online existiert geht das nicht. Wie also dort das Ablaufen eines Kennwortes deaktivieren? Natürlich per PowerShell!
Dazu muss erst mit
Connect-MsolService
eine Verbindung mit Azure AD aufgebaut werden. Danach kann dann mit
Set-MsolUser -UserPrincipalName USER@MAIL.DE -PasswordNeverExpires $True
die entsprechende Einstellung vorgenommen werden.
Viel Spaß damit!
Schreibe einen Kommentar...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:
Daran aber stört sich anscheinend Azure AD Connect. Darauf deutet auch ein älterer Blog-Artikel bei Microsoft hin. Dort heisst es:
- “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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | Get-ADUser -SearchBase "OU=SOMEOU,DC=MYDOMAIN,DC=local" -Filter * | Get-ADObject -Properties proxyAddresses | ForEach-Object { $ProxyA = $_.proxyAddresses.Replace("smtp","SMTP") ForEach($Adress in $_.proxyAddresses) { if($Adress -like "*@THEDOMAIN.COM") { $ProxyA = $Adress } } $_.ProxyAddresses = $ProxyA Set-ADObject -Instance $_ } |
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:
1 | Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin –Force |
(Achtung: Das löscht ALLE gelöschten Benutzer endgültig! Will man nur einen einzelnen Benuter löschen geht dies mittels:
1 | Remove-MsolUser -UserPrincipalName Lynn@office365bootcamp.com –RemoveFromRecycleBin |
Danach klappte auch die Synchronisierung des letzten Kontos problemlos…
Microsoft hat meine Session zu PowerShell DSC (Arbeitstitel “Windows PowerShell 5.0 DSC: The not too deep dive”) ausgewählt, somit werde ich also auf dem Microsoft Technical Summit 2016 in Darmstadt als Speaker dabei sein – das zweite Jahr in Folge also. Ich freu mich drauf!
Die genaue Agenda steht noch nicht fest, aber alle Speaker und Sessions könnt ihr hier schon sehen:
https://www.microsoft.com/germany/technical-summit/agenda.aspx
Schreibe einen Kommentar...Die “Übernahmemigration” (Englisch: Cutover-Migration) ist eine nette Option, um alle Postfächer eines Exchange-Servers in einem Rutsch nach Office 365 zu migrieren. Allerdings gibt es ein paar Dinge zu beachten. Und manches erfährt man nur durch Ausprobieren, auch das möchte ich euch hier nicht vorenthalten…
Zu beachten:
- Die Option “Übernahmemigration” bzw. “Cutover Migration” ist ausgegraut, wenn “Azure DirSync” bzw. “Azure AD Connect” aktiv sind. Am einfachsten ist es, dies im Azure-Portal abzuschalten. Erst danach steht die Option zur Verfügung.
- Konten, die bereits per Azure AD Connect oder Vorgänger-Techniken nach Azure bzw. Office 365 synchronisiert wurden, können nicht durch die Übernahmemigration “befüllt” werden. Diese Konten müssen gelöscht und neu angelegt werden.
Allgemein hin liest man immer wieder, das man mit der Cutover-Migration nur ALLE Postfächer auf einmal (bzw. nacheinander, aber in einem Rutsch) migrieren kann. Das ist so nicht ganz richtig… Insbesondere für Tests vor der eigenen Migration ist es sinnvoll, nur ein paar wenige (Test)Postfächer zu migrieren. Jedoch hat man bei dem Assistenten keine Möglichkeit zur Auswahl. Der Trick ist, die Postfächer vor Office 365 zu “verstecken”. Office 365 liest nämlich einfach nur die Global Address List (GAL, Globales Adressbuch) aus. Wenn dort nun nur die Postfächer drin stehen, die migriert werden sollen, dann wird der Rest einfach ignoriert.
Um jetzt ein Postfach aus der GAL zu entfernen, gibt es zwei Wege:
1 2 | Get-Mailbox | Set-Mailbox -HiddenFromAddressListsEnabled $true Get-DistributionGroup | Set-DistributionGroup -HiddenFromAddressListsEnabled $true |
Mit der PowerShell-Variante werden ALLE Postfächer und Verteiler aus dem Adressbuch entfernt. Danach können die gewünschten Postfächer wieder händisch hinzugefügt werden. Nach der (Test)Migration sollte man dann nicht vergessen, die Postfächer wieder im Adressbuch sichtbar zu machen:
1 2 | Get-Mailbox | Set-Mailbox -HiddenFromAddressListsEnabled $false Get-DistributionGroup | Set-DistributionGroup -HiddenFromAddressListsEnabled $false |
Auf dem Bild ist zu sehen, dass nur 2 (von insgesamt deutlich mehr) Postfächern synchronisiert wurden!
Wichtig ist noch, dass Benutzer, die bereits in Office 365 von Hand angelegt wurden (! – wichtig, das geht nicht bei synchronisierten Benutzern – !), nicht gelöscht werden müssen! Die Cutover-Migration kann diese einfach mit dem passenden Postfach vom Exchange-Server verbinden und auffüllen. Wichtig ist dazu nur, dass der O365-Account als primäre Mailadresse die selber hat wie auf dem Exchange-Server und eben noch keine AD-Attribute synchronisiert wurden.
Schreibe einen Kommentar...Nachdem ich meinen Webcast-Kurs zur PowerShell Pipeline in den letzten Tagen (oder eher Nächten…) fertiggestellt habe, ist dieser nun seit heute auf Channel9 online.
In den nächsten Tagen wird der Kurs dann auch in der Microsoft Virtual Academy (MVA) zu finden sein.
Der Link zur Channel9 Serie:
https://channel9.msdn.com/Series/Fortgeschrittene-PowerShell-Techniken
Schreibe einen Kommentar...Was für uns MVPs schon etwas länger bekannt war, wurde heute durch Microsoft offiziell bekannt gegeben (und daher darf ich nun auch darüber schreiben):
Die Windows PowerShell ist seit heute OpenSource! Das Projekt ist auf GitHub zu finden:
https://github.com/powershell/powershell
Außerdem gibt es eine erste Alpha-Version der PowerShell für Linux und MacOS!
(Ubuntu 14.04 / 16.04, CentOS 7.1 und MacOS X 10.11)
Weitere Infos auf dem offiziellen Microsoft PowerShell Team Blog:
https://blogs.msdn.microsoft.com/powershell/2016/08/18/powershell-on-linux-and-open-source-2/
Schreibe einen Kommentar...