Microsoft VAMT: The specified product key is invalid or is unsupported

Problem
Ich habe einen KMS Server aufgesetzt und das Volume Activation Management Tool (VAMT) installiert um die Produkt Keys zu aktivieren. Dabei konnte ich die Server 2019 Keys nicht hinzufügen. Server 2016 und Server 2022 haben problemlos funktioniert. Beim Server 2019 habe ich immer die folgende Fehlermeldung erhalten:

The specified product key is invalid or is unspported by this version of VAMT.
An update to support additional products may be available online.

Ursache
Nach einiger Internetsuche bin ich auf ähnliche Einträge mit anderen Windows Versionen gestoßen. Scheinbar kann das VAMT den Schlüssel nicht korrekt identifizieren. Die Identifikation erfolgt über die pkconfig Files im Ordner
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\VAMT3\pkconfig
auf dem VAMT Server.

Lösung
Nach etwas Recherche hat sich gezeigt, dass diese Dateien auch auf den jeweiligen Server-/Client-Betriebssystemen existieren. Diese findet man unter C:\Windows\System32\spp\tokens\pkeyconfig
Hier geht es um die dort befindliche Datei pkeyconfig-csvlk.xrm-ms
Diese ist auf dem VAMT-Server auch bereits vorhanden. Die Lösung sieht nun wie folgt aus:
- Datei pkeyconfig-csvlk.xrm-ms auf dem VAMT-Server umbenennen
- Datei vom zu aktivierenden OS in das Verzeichnis kopieren (in meinem Fall von einem Server 2019)
- VAMT starten und Produkt Key eintragen
- VAMT schließen und originale Datei pkeyconfig-csvlk.xrm-ms auf dem VAMT-Server wieder umbenennen

Ich habe das Problem nicht bei Mircrosoft identifizieren können. Es gab scheinbar beim Server 2012 R2 schon mal das Problem. Dieser Artikel hat mich zumindest auf die richtige Spur gebracht.

Quelle: Microsoft Learn: VAMT known issues

Teams / Office 365 : Aufzeichnen von Meetings nicht möglich - Teil 2

Nachdem ich ja den Eintrag gemacht hatte wie man das mit Powershell fixen kann gingen komischerweise die Linux und die Mac Clients. Diese konnten Meetings aufzeichnen, jedoch gab es unter Windows 10 weiterhin Probleme das Meetings nicht aufgezeichnet werden konnten. Ich konnte das auf den Punkt "new meetings experience" zurückführen. Im aktuellen Client (11.12.2020) gibt es hier Probleme Meetings aufzunehmen. Wir haben das dann bei den betroffenen Clients deaktiviert und schon lief das recording ohne Probleme.

MS-Teams recording

Teams / Office 365 : Aufzeichnen von Meetings nicht möglich

Problem : Die Recording Funktionalität von Microsoft Teams ist ausgegraut.
Leider hab ich nur einen Screenshot wo das nicht mehr der Fall ist ;-)

Teams Recording
Lösung : Erstmal muss die Verbindung zu MS Teams aufgebaut werden.
# connect to MS Teams
Import-Module MicrosoftTeams
$sfbSession = New-CsOnlineSession
Import-PSSession $sfbSession
Anzeigen kann man die Einstellungen der Policy mit dem Befehl :
# get teams policy
Get-CsTeamsMeetingPolicy -Identity Global
Powershell Teams Policy
Dann kann man das mit dem Powershell Schnipsel fixen :
# set AllowRecordingStorageOutsideRegion 
Set-CsTeamsMeetingPolicy -Identity Global -AllowRecordingStorageOutsideRegion $True

Erklärung :
Bei uns liegt es daran das Teams bereits in der Germany Location ist der Service Stream aber selbst dort noch nicht verfügbar ist. Dieser ist im Moment nur in der Europe Region verfügbar. Die Einstellung sorgt dafür das Teams auch außerhalb Germanys die aufgezeichneten Daten ablegen darf. Was hier bedeutet unsere Recordings liegen auf Servern in der Europa Region

Office 365 : Probleme beim Zugriff auf One Drive aus der UI heraus

Problem : Wir hatten hier einige User in unserem Tenant die aus dem Portal nicht auf ihr One Drive zugreifen konnten. Die Fehlermeldungen waren nicht wirklich hilfreich. Es sind immer wieder solche Fehler aufgelaufen.
one drive errors
Ein Ticket bei Microsoft hat uns dann die Lösung gebracht, auch wenn wir es nicht 100% nachvollziehen können. Vermutlich wird durch das Get-SPOSite ... | Select Owner ein neues provisioning angetriggert der dann das Feld füllt und dann auch der Zugriff aus der UI funktioniert. Ok einfach in Kurz .. davor ging es nicht danach konnte der User zugreifen ;-)
Lösung : Das Provisioning auslösen mit diesem Powershell Befehl
Get-SPOsite https://contoso-my.sharepoint.com/personal/user1_contoso_onmicrosoft_com | Select-Object -Property Url, Owner

Wir haben das alles nochmal in ein Skript geschrieben das noch andere Sachen checkt & korrigiert :-)
Hier gehts zum Skript : jhochwald/FixPersonalSPOSite.ps1

Office 365 : Anzeigen aller Gäste incl. Team

Unser Datenschützer wollte eine Übersicht über alle Gäste und den dazugehörigen Teams. Das kleine Skript erledigt diese Aufgabe für euch.

# Connect to Microsoft Teams
Connect-MicrosoftTeams
# Get all Guests and Teams
$Teams = Get-Team
$GuestUser = foreach ($Team in $Teams) 
{    
Get-TeamUser -GroupId $Team.GroupId | Where-Object -FilterScript {$_.Role -eq 'Guest'} | Select-Object -Property User, Role, @{n = 'TeamName';e = {$Team.DisplayName} }
}
#Export-CSV
$paramExportCsv = @{
   Path              = "c:\Externe\ExterneUser.csv"
   Force             = $true
   Encoding          = 'UTF8'
   Delimiter         = ';'
   NoTypeInformation = $true
}
$GuestUser | Export-Csv @paramExportCsv

Microsoft Excel/Word zeigt falschen, sperrenden Benutzer im "Dokument wird verwendet" Dialog an

Ich erhalte in letzter Zeit gehäuft die Meldung, dass Benutzer Dateien sperren, aber ein falscher Name bei der Sperre angezeigt wird.

Als Beispiel zur Erklärung:
Herr X öffnet eine Excel-Datei und erhält die Meldung, dass Herr Y die Datei bereits geöffnet hat. Herr Y hat diese Datei aber nicht geöffnet, sondern Herr Z. Trotzdem wird Herr Y als sperrender Benutzer angezeigt!
Warum der falsche Name?
Wenn man eine Office-Datei öffnet, dann wird im gleichen Verzeichnis eine temporäre Datei mit einer „~“ vorweg erstellt (z.B.: ~$Mappe1.xlsx). Darin wird festgehalten, welcher Benutzer die Datei geöffnet hat. Normalerweise sollte die „~“-Datei nach dem schließen automatisch gelöscht werden, was augenscheinlich aber nicht immer funktioniert und die Datei bleibt erhalten. Beim nächsten Öffnen kann keine NEUE „~“-Datei erzeugt werden und die Benutzerinformationen bleiben bestehen. Wenn jetzt ein anderen Benutzer die Datei öffnen will, werden die veralteten Informationen angezeigt.

LÖSUNG: Wenn man die „~“-Datei löscht, dann werden die Informationen beim nächsten Öffnen wieder richtig angezeigt.
Schaut man mal in die „~“-Datei mit einem Editor rein, dann sieht man, dass hierin der bearbeitende Benutzer vermerkt ist. Auffällig ist meiste das veraltete Erstellungsdatum. Generell könnte man auf seinem Fileserver nach solchen Dateien suchen und alle, die älter als zwei Tage sind löschen!

“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)