Monat: Februar 2019

„Diese Kopie von Microsoft Office kann auf einem Computer, der die Terminaldienste ausführt, nicht verwendet werden.“ mit Office 365 ProPlus

Veröffentlicht am von — 2 Kommentare ↓

Trotz korrekter Terminalserver-Installation kommt es seit Ende der Jahres 2018 unter Windows Server 2016 in einer RDS-Umgebung häufiger zu diesem Fehler beim Start der Office-Anwendungen:

Diese Kopie von Microsoft Office kann auf einem Computer, der die Terminaldienste ausführt, nicht verwendet werden. Damit Microsoft Office auf einem Computer, der die Terminaldienste ausführt, verwendet werden kann, müssen Sie eine Volumenlizenzedition von Office verwenden.
Diese Kopie von Microsoft Office kann auf einem Computer, der die Terminaldienste ausführt, nicht verwendet werden. Damit Microsoft Office auf einem Computer, der die Terminaldienste ausführt, verwendet werden kann, müssen Sie eine Volumenlizenzedition von Office verwenden.

Der Inhalt dieser Meldung ist mit Office ProPlus natürlich Unsinn und nur ein Überbleibsel aus vergangenen Tagen. Office ProPlus (oder auch „O365ProPlusRetail“) dürfen durchaus in RDS-Umgebungen genutzt werden.

Eigentlich sorgt bei der Installation der Klick-und-Los Variante („setup /configure“) der Eintrag „SharedComputerLicensing“ in der XML-Datei für die richtige Konfiguration; das scheint aber nicht immer so richtig zu klappen. Vor allem unter Office 2019 (das nur Office365 heißt) ist das der Fall – vermutlich weil sich der zugehörige Registry-Schlüssel geändert hat. Früher wohnte dieser in Office\<version>\ClickToRun, nun entfällt <version>.

„Richtige“ Bereitstellungsdatei

<Configuration>
  <Add OfficeClientEdition="32" Channel="Monthly">
    <Product ID="O365ProPlusRetail">
      <Language ID="de-de" />
    </Product>
  </Add>
<Updates Enabled="TRUE" Channel="Monthly" />
<Display Level="NONE" AcceptEULA="TRUE" />
<Property Name="AUTOACTIVATE" Value="1" />
<Property Name="SharedComputerLicensing" Value="1" />  <--_HIER____
</Configuration>

Lösung

Wenn das mal wieder nicht so recht geklappt zu haen scheint, kann man den notwendigen Registry-Eintrag jederzeiot von Hand hinzufügen und schon ist Office wieder Terminalserver-Fähig.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
   Name: SharedComputerLicensing
   Typ: REG_SZ ("Zeichenfolge")
   Inhalt: 1

Es ist kein reboot notwendig, nach einem Neustart der Anwendungen läuft Office ohne Fehler.

Windows Server 2019 Aktivierung – Der eingegebene Produkt Key funktioniert nicht (0x80070490)

Veröffentlicht am von — 7 Kommentare ↓

Problem:

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)

Produkt Key Assistent

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.

PowerShell Funktion um sich mit Office 365 mit MFA (Mehrfaktorauthentifizierung) zu verbinden

Veröffentlicht am von — Keine Kommentare ↓

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:

function Connect-o365 
{
$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://ps.outlook.com/powershell/" -Credential $UserCredential -Authentication Basic -AllowRedirection -AllowClobber
Import-PSSession $Session
Connect-MsolService -Credential $UserCredential
}

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.

https://www.thelazyadministrator.com/2019/02/05/powershell-function-to-connect-to-all-office-365-services-with-support-for-mfa/

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 🙂

VMware ESXi/vCenter: Wann war eine VM das letzte mal eingeschaltet?

Veröffentlicht am von — Keine Kommentare ↓

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:

Get-VM GASTNAME | Get-VIEvent -Types Info -MaxSamples 1000 | Where-Object {$_.fullFormattedMessage -match "Power On"} | %{Write-Host $_.vm.name $_.createdTime | Out-Default}

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.