Man hat gerade frisch aus dem VLSC das Windows Server 2019 ISO heruntergeladen und möchte die installierte Maschine nun mit dem zugehörigen MAK-Schlüssel aktivieren.
Nach Eingabe des Keys zeigt einem der Aktivierungsassistent allerdings nur die Fehlermeldung:
Der eingegebene Produkt Key funktioniert nicht. Überprüfen Sie den Produkt Key, und versuchen Sie es noch einmal, oder geben Sie einen anderen Produkt Key ein. (0x80070490)
Lösung:
Es gibt wohl einen Bug in dem Grafischen Produkt Key Assistenten. Man muss den Key entweder bereits während der Installation angeben oder an der Konsole per slmgr installieren:
slmgr /ipk AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
Danach könnte es noch einen Moment dauern, bis die Aktivierung in den Windows Einstellungen auch korrekt angezeigt wird. Von eventuellen Fehlermeldungen, welche dort direkt nach der Key-Installation angezeigt werden, sollte man sich also zunächst nicht irritieren lassen.
Der geneigte Administrator verbindet sich in der Regel fast täglich mit den Office 365 Diensten. Seit der umfassenden Einführung der MFA/2FA (Mehrfaktor-Authentifizierung) lässt sich dier Prozess nicht mehr ganz so einfach automatisieren.
Bisher reichte eine entsprechende Funktion im PowerShell Profil:
In der schönen neuen Welt der sicheren Authentifizierung ist das nicht mehr so einfach; man benötigt überhaupt ersterinmal das entsprechende PowerShell Modul, das im Office 365 Tenant versteck ist.
Außerdem sind die ConnectionUri’s nun deutlich verteilter als früher, um eine Verbindungzu allen Services herzustellen sind nun deutlich mehr Schritte notwendig.
„The Lazy Administrator“ hat sich bewundernswerter Weise diesem Problem umfassend gewidmet und eine traumhafte Funktion geschrieben, die folgende Verbidnungen unterstützt:
SFA und MFA (Parameter „-MFA“)
Exchange Online
Skype for Business
SharePoint Online
Security and Compliance Center
Azure AD v2
Azure AD v1 (MSOnline)
Microsoft Teams
Services einzeln oder zusammen nutzbar (Parameter „-Service“, zum Beispiel „-Service Exchange, MSOnline“)
Auf der Projektseite dazu gibt es den vollständigen Download und die zugehörige Dokumentation.
Ich werde die Übersicht hier nicht noch einmal wiederholen, aber großen Respekt und ein echtes Admin-Dankeschön für echten neuen Lebenskomfort an TheLazyAdmin übersenden 🙂
Manchmal ist es hilfreich zu wissen, wann ein VMware Gast zuletzt eingeschaltet gewesen ist. Es soll ja schon mal vorkommen das „tote“ virtuelle Maschinen jahrelang auf der Infrastruktur liegen aber eigentlich nicht mehr gebraucht werden.
Lösung
Es gibt keine „eingebaute“ Möglichkeit, Einschaltdaten von VMs nachzuschlagen. Am einfachsten ist es aber, das Ereignisprotokoll rückwärts nach dem letzten „Power on“ Event zu durchsuchen.
An der PowerCLI Powershell geht das beispielsweise so:
Wobei hier „MaxSamples“ ein Beispiel ist; möglicherweise muss man mehr Events durchsuchen. Wenn man beispielsweise oft Sicherungen von Gästen via VCB erstellt, reichen 1000 Events nicht aus.
Ohne die Angabe „GASTNAME“ gibt es eine Liste aller verbundenen virtuellen Maschinen.
Die Office 365 Exchange Online Powershell benötigt eigentlich keine Powershell Modul-Installation, weil zu Exchange nur eine Remote-Session hergestellt wird.
Anders sieht da aus, wenn man die MFA (Mehr-Faktor-Authentifizierung) eingeschaltet hat. Dazu unten mehr.
Das erste Kommando fragt die Credentials ab und speichert diese in der Variable $credential, das zweite verwendet diese für die Verbindung und das dritte importiert die Remote-Sitzung.
Exchange Online Powershell mit 2FA (Mehr-Faktor Authentifizierung)
Hierfür muss man zuerst doch noch manuell ein Modul herunterladen, das „Exchange Online Remote PowerShell-Modul„. Man findet den Download für die Offline-Installation innerhalb seines Office 365 Portals in der EAC. Mann kann diese Spezial-Powershell aber auch direkt ohne Umwege herunterladen und starten; der Link dazu steht weiter unten.
Hat man das Modul heruntergeladen und installiert, sollte man einmal sein WinRM-Konfiguration testen. Ein lauffähiges WinRM-System mit eingeschalteter Basic-Authentifizierung (Default) ist Voraussetzung.
WinRM-Konfiguration in der Powershell „als Administrator“ anschauen:
winrm get winrm/config/client/auth
Sollte da „Basic = false“ in der Ausgabe stehen, muss man zwingend Basic-Auth einschalten:
winrm set winrm/config/client/auth @{Basic="true"}
Dann kann man auch schon endlich fast eine Verbindung herstellen; dazu das „Microsoft Exchange Online Powershell Module“ im Startmenü öffnen. Dier hier ist der direkte Download-Link zur Exchange Shell:
Nachdem der letze Beitrag zum Thema Office 365 Powershell ja mittlerweile veraltet ist, hier die aktuelle Methode eine Verbindung zu Office 365 herzustellen.
„Heute“ nutzt man direkt die AzureAD Module die man via NuGet installiert und nicht mehr die MSOnline „Extra“ Shell.
Installation des AzureAD Module (Lizenzen, Office 365 Benutzer …)
Öffnen der Powershell „Als Administrator“ und das Modul installieren:
PS C:\> Install-Module -Name AzureAD
Nicht vertrauenswürdiges Repository
Sie installieren die Module aus einem nicht vertrauenswürdigen Repository. Wenn Sie diesem Repository vertrauen, ändern
Sie dessen InstallationPolicy-Wert, indem Sie das Set-PSRepository-Cmdlet ausführen. Möchten Sie die Module von
'PSGallery' wirklich installieren?
[J] Ja [A] Ja, alle [N] Nein [K] Nein, keine [H] Anhalten [?] Hilfe (Standard ist "N"): j
PS C:\>
2. Herstellen der Verbindung zum AzureAD (Office 365)
