Hope This Helps

Ich stelle hier ein paar Skripte zur Verfügung, welche einem die Migration eines Printservers etwas vereinfachten. Selbstverständlich kann man das auch mir Printmig oder anderen Tools durchführen. Ich wollte meinen neuen Printserver from scratch neu installieren, daher der etwas andere Weg. Die Migration wird in vier Teile erfolgen:

Part #1: Export TCP- und LPR-Ports
Part #2: Export Drucker mit allen Settings in eine XML-Datei
Part #3: Import TCP- und LPR-Ports
Part #4: Import aller Drucker mit allen Settings

Part #1: Export TCP- und LPR-Ports
Für den späteren Import der zwei Port-Typen werden unterschiedliche Informationen benötigt, daher habe ich hierfür zwei Skripte erstellt, welche die Konfigurationen exportieren:

Export-PrinterPorts_TCP_to_CSV.ps1

<# 
.NAME
    Export-PrinterPorts_TCP_to_CSV.ps1

.AUTHOR
    Ralf Entner

.SYNOPSIS
    Script exports all TCP Printer Ports to a csv file.

.DESCRIPTION 
    Script exports all TCP Printer Ports with all settings to a csv file. In the csv file there are address, port number and smtp settings.
 
.NOTES 
    The script exports only TCP Ports, not LPR Ports (see other script).

.COMPONENT 
    No powershell modules needed

.LINK 
    No Links
 
.Parameter ParameterName 
    $CSVPath - Define export path of the csv file
#>

# Export CSV path
$CSVPath = "C:\Printmig\PortsTCP.csv"

# Get Printerports with all nessesary informations
$Printerports = Get-PrinterPort | ?{$_.Description -like "*TCP*"} | select Name, PrinterHostAddress, PortNumber, SNMPCommunity, SNMPEnabled 

#Export informations to CSV
$Printerports | Export-Csv -Path $CSVPath -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Export-PrinterPorts_LPR_to_CSV.ps1

<# 
.NAME
    Export-PrinterPorts_LPR_to_CSV.ps1

.AUTHOR
    Ralf Entner

.SYNOPSIS
    Script exports all LPR Printer Ports to a csv file.

.DESCRIPTION 
    Script exports all LPR Printer Ports with all settings to a csv file. In the csv file there are name, protocol, port nubmer and printer host address.
 
.NOTES 
    The script exports only LPR Ports, not TCP Ports (see other script).

.COMPONENT 
    No powershell modules needed

.LINK 
    No Links
 
.Parameter ParameterName 
    $CSVPath - Define export path of the csv file
#>
# Export CSV path
$CSVPath = "C:\Printmig\PortsLPR.csv"

# Get Printerports with all nessesary informations
$Printerports = Get-PrinterPort | ?{$_.PortMonitor -eq "LPR Port"} | Select-Object Name, Protocol, PortNumber, PrinterHostAddress

#Export informations to CSV
$Printerports | Export-Csv -Path $CSVPath -Delimiter ";" -Encoding UTF8 -NoTypeInformation

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

Auslesen der vorhanden E-Mail Aliase eines Users. SamAccountName muss natürlich duch einen echten ersetzt werden

Get-AdUser -Identity 'SamAccountName' -Properties ProxyAddresses | select Name -ExpandProperty ProxyAddresses

Setzen eines zusätzlichen E-Mail Alias. SamAccountName muss natürlich duch einen echten ersetzt werden

Set-ADUser -Identity 'SamAccountName' -add @{ProxyAddresses="smtp:alias1@domain,smtp:alias2@domain" -split ","}

Problem:
Ich hatte das Problem, dass unsere .NET Anwendung für das Artikel-Update des Webshops plötzlich nicht mehr funktioniert hat - keine Verbindung zum Server mehr. Nach etwas Recherche hat sich gezeigt, dass es daran lag, dass die Webseite nur noch TLS 1.2 und 1.3 spricht aber unsere Anwendung mit TLS 1.0 die Verbindung herstellen und die Daten hochladen wollte.

Lösung:
Nach etwas Suche habe ich habe TLS 1.1 und TLS 1.2 am Windows-Client per Default aktiviert (TLS 1.3 ist noch nicht Standard). Das funktioniert über Registry-Keys am einfachsten (optional GPO bauen):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1\Client]
„DisabledByDefault“ = dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2\Client]
„DisabledByDefault“ = dword:00000000

Sollten die Schlüssel „TLS 1.1“ und „TLS 1.2“ und „Client“ noch nicht existieren, dann bitte anlegen.

Damit aber noch nicht genug, da .NET Framework sich NICHT an den Systemstandard hält, sondern seine eigene TLS-Konfiguration macht.
Man kann das aber ändern, indem man ein paar Registry-Tweaks setzt, damit .NET das Systemdefault-TLS-Protokoll verwendet. Wichtig hier ist zuprüfen, ob die .NET Anwendung 32- oder 64-Bit ist und entsprechend die Keys setzen.

Hier für x64 bzw. Eine 64-Bit .NET-Anwendung

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

Und für x86 bzw. eine 32-Bit .NET-Anwendung

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

Windows-Client neu starten und damit sollte die Verbindung wieder laufen und die Verbindung zur Webapplikation wieder funktionieren.

Quellen:
Microsoft: So aktivieren Sie TLS 1.1 oder TLS 1.2 als Standard sichere Protokolle WinHTTP in Windows Update
Aktualisieren und Konfigurieren von .NET Framework zur Unterstützung von TLS 1.2.

Problem:
Wenn wird unter Windows 8/10 freigegebene Drucker hinzufügen oder entfernen, dann dauert es teilweise mehrere Minuten, bis diese erscheinen bzw. verschwinden.

Lösung:
Nach einer langen Suche der Ursache, haben wir dann doch die Wurzel des Übers gefunden. Windows lädt Metadaten über den Drucker im Hintergrund herunter. Bis das nicht abgeschlossen ist, wird der Drucker nicht angezeigt bzw. schwindet dieser nicht aus der Übersicht. Diesen Download kann man deaktivieren und es scheint keine Nachteile zu geben.

Man findet diese Einstellung verzwickt im System. Entweder man sucht nach "Geräteinstallationseinstellungen ändern" oder man beendet den Spuk mittels einer GPO:
Computerkonfiguration > Administrative Vorlagen > System > Geräteinstallation
Abrufen von Gerätemetadaten aus dem Internet verhindern

Oder auch das Setzen des folgenden Registry-Keys führt zum Erfolg:

Pfad: HKLM\SOFTWARE\Policies\Microsoft\Windows\Device
Valuename: MetadataPreventDeviceMetadataFromNetwork
Valuetyp: DWORD
Vlaue: 0|1

Zusätzliche Informationen für GPO und Registry: admx.help: Abrufen von Gerätemetadaten aus dem Internet verhindern

Problem:
Ich habe eine Published App für die Benutzer zur Verfügung gestellt und veröffentlich diese entweder über die RDWeb-Webseite des Terminalservers oder ich hänge die Apps direkt bei den Windows-Clients unter "Remote-App zugreifen" ein. Dabei wird beim Starten immer folgende Fehlermeldung angezeigt:


Lösung:
Zur Lösung müssen zwei Sachen umgesetzt werden:
1. Man muss das Zertifikate des RDS-Servers als "Vertrauenswürdige Stammzertifizierungsstelle" und als "Vertrauenswürdige Herausgeber" veröffentlichen (z.B. mittels GPO)
2.) Man muss den Thumbprint des veröffentliche Zertifikates als vertrauenswürdig einstufen (z.B. mittels GPO)

Also bauen Sie sich eine Zertifikats-GPO, soweit noch nicht vorhanden. Hierin importieren Sie das RDS-Zertifikat unter "Computerkonfiguration" -> "Windows-Einstellungen" -> "Sicherheitseinstellungen" -> "Richtlinien für öffentliche Schlüssel" unter den Punkten "Vertrauenswürdige Stammzertifizierungsstellen" und unter "Vertrauenswürdige Herausgeber".
Jetzt öffnen Sie das Zertifikat und kopieren sich den Thumprint unter den Eigenschaften heraus.
Diesen Thumprint fügen Sie dann in folgender GPO ein, um das Zertifikat vertrauenswürdig zu machen:
"Computerkonfiguration" -> "Administrative Vorlagen" -> "Windows-Komponenten" -> "Remotedesktopdienste" -> "Remotedesktopverbindungs-Client" ->"SHA1-Fingerabdruck von Zertifikaten angeben, die vertrauenswürdige RDP-Hersteller darstellen".

HINWEIS:
Der Thumbprint muss OHNE Leerzeichen eingegeben werden und mein 2016er-Server wollte unbedingt die Buchstaben als Großbuchstaben.