Nach Windows-Update können Point-and-Print Treiber nicht mehr von Nutzern installiert werden

Windows Updates nach dem 10.8.2021 erfordern standardmäßig Administratorrechte, um Druckertreiber installieren oder aktualisieren zu können. Bisher konnten Benutzer ohne Administratorrechte:

  • Neue Netzwerkdrucker mithilfe von Treibern auf einem Printserver installieren
  • Aktualisieren vorhandener Druckertreiber mit Treibern vom Printserver

Das geht jetzt nicht mehr. Stattdessen kommt die gute alte Vertrauensfrage und der Admin muss seine Credentials eingeben. Das ist auch unabhängig von den Einstellungen in der GPO.

Lösung

Ein Registry-Eintrag stellt das „alte“ Verhalten wieder her. Leider einschließlich der Sicherheitslücke bei der Installation von Druckertreiber, die es einem Hacker erlaubt weitere DLL-Dateien an einen Druckertreiber anzuhängen.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint]
"RestrictDriverInstallationToAdministrators"=dword:00000000

vSphere 7 „Ein allgemeiner Systemfehler ist aufgetreten: Internal error“ beim ändern von Syslog.global.logdir

Aus uns nicht erfindlichen Gründen kann man im vSphere Client den Konfigurationseintrag Syslog.global.logdir nicht ohne Fehlermeldung ändern. Wenn man das versucht erhält man die spannende Fehlermeldung „Ein allgemeiner Systemfehler ist aufgetreten: Internal error“

Man erreicht den Eintrag im vSphere Client auf dem Host > Konfigurieren > System/Erweiterte Systemeinstellungen > Bearbeiten

Lösung

Man kann den Eintrag problemlos an der Console via esxcli setzen. Das geht sowohl via SSH als auch remote. Das „neue“ Verzeichnis muss auch schon existieren, sonst beschwert sich esxcli.

mkdir /vmfs/volumes/<NEUESVOLUME>/logs

esxcli system syslog config set --logdir=/vmfs/volumes/<NEUESVOLUME>/logs

Nach der Änderung muss Syslogd neu geladen werden. Das tut das GUI eigentlich automatisch, aber an der Konsole müssen wir etwas nachhelfen:

esxcli system syslog reload

Die gesetzten Parameter erfährt man via GET

esxcli system syslog config get

AzureAD Application App-Registrierungen mit Secret erstellen, das nicht abläuft

Microsoft hat zu Beginn des Jahres die Auswahl „niemals“ aus der Gültig-Bis Auswahl für geheime Clientschlüssel bei neuen AzureAD Apps entfernt. Hier ist im Azure WebGUI die Auswahl seither nur noch bis „2 Jahre“ möglich.

Die Auswahl ist auf bis zu 24 Monate eingeschränk

Die Limitierung beschränkt sich aber auf das GUI, die PowerShell kann weiterhin geheime Clientschlüssel erstellen, die deutlich länger gültig sind.

Lösung

Sofern die App selbst schon im WebGUI erstellt ist (Neue Registrierung > Name, URL > Registrieren) lässt sich für diese App schnell ein Secret erstellen.

AzureAD Anwendung geheimen Clientschlüssel via PowerShell hinzufügen, mit deutlich längerer Laufzeit

# Mit AAD Verbinden
Connect-AzureAD

# Apps auflisten, passende ObjectId kopieren
Get-AzureADApplication

# "Gültig von" und "bis" holen
$startDate = Get-Date
$endDate = $startDate.AddYears(99)

# Secret erstellen lassen
$aadAppsecret01 = New-AzureADApplicationPasswordCredential -ObjectId <ID> -StartDate $startDate -EndDate $endDate -CustomKeyIdentifier <ANZEIGENAME-DES-SECRETS>

# Secret anzeigen (um es zu kopieren und sicher zu verwahren)
echo $aadAppsecret01.Value

Dynamic Disks mit Windows RAID mit PowerShell verwalten

Wie kann man die Windows PowerShell verwenden, um dynamische Datenträger zu verwalten, wie zum Beispiel den Status eines RAID zu untersuchen?

Nicht.

Die „dynamischen Datenträger“, die seit Windows 2000 integraler Bestandteil von Windows und Windows Server, sind „veraltet“ und werden irgendwann entfernt. Obwohl die dynamischen Laufwerke weiterhin verfügbar sind und relativ viel genutzt werden, stellt Microsoft keine PowerShell-Cmdlets zum Verwalten der dynamischer Datenträger zur Verfügung.

Das einzige Cmdlet das helfen könnnte (das wir kennen) ist Get-Volume, das immerhin auch dynamische Volumes anzeigt. mit Get-PhysicalDisk und Get-StorageAdvancedProperty kann man dann noch den Status der Physischen Disks ansehen, aber damit war es das auch schon.

Hinweis: Das selbe geschieht auch im ServerManager. Der kann dynamische Laufwerke auch schon nicht mehr anzeigen.

Es bleibt wohl nur die Migration in Richtung StorageSpaces …

Schade 😑

AADConnect synchronisation manuell starten oder erzwingen

Dies ist wieder so ein „Schnipsel den man ständig braucht“ Beitrag.

Der ActiveDirectory Admin möchte nach einer Objektänderung diese „sofort“ ins Azure AD synchronisiert wissen und nicht die üblichen 30 Minuten warten.

Synchronisation starten

An der PowerShell auf dem AADConnect-Server ist das in zwei Zeilen (ausgeführt als Admin) erledigt:

Start-ADSyncSyncCycle

Gegebenenfalls ist vorher noch der Import des ADSync Moduls erforderlich (sollte ab PowerShell 3.0 aber automatisch erfolgen.)

Das Cmdlet stößt den Sync nur an, daher sollte die Rückmeldung Success recht schnell erfolgen.

Der eigentliche Prozess dauert (je nach Objekt- und Änderungsmenge) etwas länger, kann aber einfach im Synchronization Service überwacht werden. (Auch ersichtlich an der CPU-Last der Maschine 😉)

Neue Vollsynchronisation starten

Das Cmdlet startet standardmäßig nur einen „Delta“ Sync (-PolicyType Delta). In seltenen Fällen ist allerdings eine neue „Vollsynchronisation“ notwendig. Auch diese lässt sich „sofort“ via PowerShell starten:

Start-ADSyncSyncCycle -PolicyType Initial 
Hinweis:

Dieses Vorgehen sollte ausschließlich als manuelle „Ausnahme“ des herkömmlichen Intervalls dienen und sollte nicht verwendet werden um automatisiert das „AllowedSyncCycleInterval“ des AADConnect schedulers zu unterschreiten. Dies könnte bei zu häufiger verwendung dazu führen, dass Microsoft weitere Sync-Vorgänge vorübergehend nur in *noch größeren* Abständen zulässt um einer Überlastung der AAD Dienste vorzubeugen.