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)
Der Microsoft SQL Server Express Edition ist sehr praktisch, aber leider nach der Installation auch leicht zu übersehen. Nach einem Domänenwechsel, Domänen-Autritt oder einem Crash (der zum Verlust der Anmeldekonten führte) ist eine SQL-Express-Instanz nicht mehr zugänglich. Standardmäßig sind nur Windows-Anmeldungen erlaubt, die es nun ja nicht mehr gibt.
„Zugriff verweigert“ oder „Access to Database denied“ lauten die Fehlermeldungen dazu.
Lösung
Man kann die Authentifizierung im SQLEE insofern zurücksetzen, als das man sein eigenes Anmeldekonto (sofern administrativ) zum SYSADMIN in der Datenbankinstanz macht. Dann kann mann sich wieder anmelden, die Rechte zurücksetzen und seine Datenbanken richtig konfigurieren.
Dazu muss die Datenbank im „Einzelbenutzermodus“ gestartet werden:
SQL Server Configuration manager („SQL Server 2014-Konfigurations-Manager“) öffnen
Links im Baum unter den „SQL Server-Diensten“ rechts den SQL Server auswählen
Eigenschaften > Startparameter > „-m“ hinzufügen („Add“), ohne Anfürungszeichen
Dienst neu starten (nun ist die DB im Einzelbenutzermodus)
Unter Windows Server 2016 möchte der PHP Manager für den IIS via Plattform-Installer nicht so recht installiert werden. Das Logfile dazu sagt:
...
MSI (s) (2C:10) [ZEIT]: Product: PHP Manager 1.2 for IIS 7 -- Installation failed.
MSI (s) (2C:10) [ZEIT]: Windows Installer installed the product. Product Name: PHP Manager 1.2 for IIS 7. Product Version: 1.2.0. Product Language: 1033. Manufacturer: . Installation success or error status: 1603.
...
Ähnlich wie die scheinbar von Selbstzweifeln geprägte Aussage „Installation success or error“ ist auch der Rest des Logfiles nicht wirklich hilfreich.
Lösung
Die Lösung ist einfach, wenn auch (bis heute zumindest) nicht dokumentiert. Es geht nicht – der IIS PHP Manager ist nur für Windows 8.1 oder kleiner (IIS 8) gedacht, nicht für den IIS 10.0 (Windows 10 / Server 2016). Glücklicherweise lässt sich die IIS-Versionserkennung recht einfach patchen:
Ändere diesen REG_DWORD auf 8 (dezimal): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\MajorVersion
Instaliere den PHP Manager
Ändere den Schlüssel wieder zurück auf 10
Uns sind bisher keine negativen Folgen der Änderungen bekannt.
