• Betrifft: automatische Anmeldung trotz Kennwort
• System: Microsoft Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10
• Problem: Unter Microsoft Windows soll trotz Kennwort die automatische Anmeldung beim Hochfahren aktiviert werden. Der Computer befindet sich in einer Domäne. Es soll ein Domänenbenutzer verwendet werden.

Hintergrund

Einfachhalber soll der Computer direkt nach dem Hochfahren mit einem bestimmten Benutzer angemeldet werden. Der Benutzer hat ein Kennwort zugewiesen. Für gewöhnlich geht man dabei nach dem Tutorial unter Automatische Anmeldung unter Microsoft Windows vor. Leider passt da aber etwas nicht…

Wie man sieht, sobald der Computer Mitglied einer Domäne ist, ist die notwendige Option nicht mehr verfügbar. Wie kann man dies nun doch nutzen? Beispielsweise für eine Kiosk-Computer könnte dies nützlich sein…

Behebung

Die Möglichkeit ist weiterhin gegeben. Diese wird aber anders verwaltet. Idealerweise mit einer Gruppenrichtlinie, die auf den jeweiligen Computer zugewiesen wird. Bei einer neuen Gruppenrichtlinie kann man dabei die notwendigen Registrierungseinträge anlegen.

Unter „Computerkonfiguration“ => „Einstellungen“ => „Windows-Einstellungen“ => „Registrierung“ einfach mittels Kontextmenü den Punkt „Neu“ => „Registrierungselement“ aufrufen.

Hier müssen folgende vier Einträge erstellt werden:

Nach dem Zuweisen der Gruppenrichtlinie und Übernahme der Einstellungen sollte mit dem nächsten Neustart automatisch der Domänenbenutzer angemeldet werden.

Hinweis: Die Registrierungswerte wie z.B. „DefaultPassword“ kann von jedem Benutzer bzw. darauf laufenden Programmen ausgelesen und verarbeitet werden. Ich denke es sollte zudem klar sein, dass jeder mit Zugriff auf das Gerät wo die automatische Anmeldung aktiviert wurde, einen Vollzugriff auf den Computer und womöglich weiteren Zugriff auf Domänenressourcen hat.

• Betrifft: Flight Simulator 2020
• System:  Microsoft Windows 10
• Problem: Nach einem Update oder direkt bei Erstinstallation kommt bei der digitalen Version die Fehlermeldung „Please insert the Microsoft Flight Simulator Game Disc“. Das Spiel wurde via Microsoft Store installiert.

Hintergrund

Direkt nach dem Start und entsprechender Wartezeit erscheint eine Fehlermeldung mit dem Hinweis: „Please insert the Microsoft Flight Simulator Game Disc“. Zuvor wurde entweder das erste Mal der Flight Simulator 2020 installiert oder der Flight Simulator war bereits installiert und ein neues Update ist veröffentlicht worden. Dabei wurde über dem Microsoft-Store bereits ein Update heruntergeladen, aber anstatt dem Installationsmanager kommt die erwähnte Fehlermeldung.

Bei Auswahl von „Continue“ kommt die Meldung nach kurzer Zeit erneut. Bei „Quit“ wird das Spiel beendet. Es steht kein Spielmedium (DVD) zur Verfügung, da das Spiel direkt im Microsoft Store erworben bzw. aktiviert wurde. Kein Neustart von Windows hilft.

Neuinstallation? Nein, auf keinen Fall machen. Die Behebung geht ohne, dass man die >100 GB neu herunterladen muss.

Behebung

Zuerst muss „Apps und Features“ aufgerufen werden. Wie nachfolgend zu sehen geht das mittels Rechtsklick auf „Start“.

Im nun erscheinenden Fenster muss „Microsoft Flight Simulator“ gesucht und markiert werden. Danach wechselt man in die „Erweiterte Optionen“.

Nun sucht man den Bereich „App-Add-Ons und herunterladbare Inhalte“. Dies ist für gewöhnlich ganz am Ende zu finden.

Hier sollte zumindest eine App gefunden werden: „Microsoft Flight Simulator Digital Ownership“. Exakt diese mit 10,1 MB deinstallieren. In einigen Fällen konnte der Microsoft Flight Simulator 2020 sofort normal genutzt werden. Zeitweise läuft dann der ausstehende Updatevorgang an.

Obwohl es bei mir im Testversuch ohne dem „Microsoft Flight Simulator Digital Ownership“ funktionierte, ist meine Empfehlung diesen wieder sauber zu installieren. Dazu sucht man diesen über den Microsoft-Store. Dort ist dies als „Digital Ownership“ bezeichnet.

Zum leichten Auffinden ist mein Tipp im Microsoft-Store unter „Meine Bibliothek“ z.B. bei „Alle in meinem Besitz“ zu suchen. Dies hat zumindest bei mir die Angelegenheit sehr vereinfacht. Der entsprechend gesuchte Punkt war unter den ersten fünf zu finden.

• Betrifft: Ordnersymbol bei Netzwerkordner bzw. Ordner auf Netzwerkfreigaben festlegen
• System:  Microsoft Windows 8.1,  Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
• Problem: Bei einem lokalen Ordner kann über die Eigenschaften ein Ordnersymbol festgelegt werden. Bei einem Netzwerkordner bzw. Ordner auf einem Netzwerklaufwerk kann kein Netzwerksymbol festgelegt werden.

Hintergrund

Bei einem lokalen Ordner kann man einfach über die Ordnereigenschaften ein Ordnersymbol festlegen. Dies ist bei bestimmten Systemordner bereits vordefiniert.

Dies macht je nach Organisation ebenfalls für Ordner auf Netzwerklaufwerken Sinn. Entweder um auf bestimmte Ordner direkt hinzuweisen bzw. diese gesondert hervorzuheben. Diese Netzwerklaufwerke liegen zumeist auf Netzwerkfreigaben und diese wiederum sehr oft auf Windows Server – mittlerweile sehr häufig in der „Server Core“ Variante.

Die Zuweisung gestaltet sich jedoch etwas schwierig. Lokal wird die entsprechende Option für Ordnersymbol nicht angezeigt. Am Server selbst gibt es aus diversen Gründen ebenfalls keine Möglichkeit zur Konfiguration.

Grundsätzlich wird das Ordnersymbol über die versteckte Systemdatei „desktop.ini“ konfiguriert. Es sind dazu drei Ordneroptionen notwendig bzw. empfohlen – siehe vorherige Screenshots. Nun sollte die Systemdatei im jeweiligen Ordner angezeigt werden.

Wird diese Datei z.B. mit Notepad geöffnet, dann kann im Bereich „[.ShellClassInfo]“ unter „IconResource“ das genutzte Icon gefunden werden. Entweder kann hier eine dll-Datei mit mehreren Icons oder direkt eine ico-Datei angeführt werden. Der Versuch einfach selbst so eine „desktop.ini“ anzulegen scheitert ohne genaueren Grund – selbst wenn man eine korrekte Datei in einen anderen Ordner kopiert.

Behebung

Vergesst Drittherstellerprodukte. Es gibt unter Windows und Windows Server (inkl. Server Core) eine integrierte Möglichkeit zur Generierung. Dabei muss man nur auf zwei bestimmte Punkte aufpassen. Die „desktop.ini“ muss in einer bestimmten Reihenfolge erstellt werden. Attribute sind kein Zwang. Der Ordner benötigt ein bestimmtes Attribut. Daher nachfolgend die einzelnen Schritte – abschließend folgt ein Skript.

1.) Erstellung „desktop.txt“

Im gewünschten Ordner muss einfach eine „desktop.txt“ (nicht „desktop.ini“) erstellt und mit Notepad folgenden Eintrag ergänzt werden:

[.ShellClassInfo]
IconResource=R:\*Pfad*\*Ordnersymbol*.ico,0

Werte mit Sternchen müssen klarerweise angepasst werden. Neben einem Laufwerksbuchstaben ist ebenso eine Netzwerkfreigabe (Laufwerksbuchstaben) möglich.

2.) „desktop.txt“ umbenennen

Nun erst die Datei von „desktop.txt“ in „desktop.ini“ umbenennen. Sollte dies zuvor bereits „desktop.ini“ gewesen sein, dann wird es nicht funktionieren.

3.) Korrekte Ordnerattribut festlegen

Nun muss der Ordner das richtige Attribut bekommen. Ansonsten wird die „desktop.ini“ ignoriert. Dazu am besten die Windows-Befehlszeile bzw. „Command Prompt“ öffnen. Die Windows PowerShell hat bei mir nicht funktioniert. Je nach Ordnerrecht ist es möglich, dass dies lokal direkt am Windows Server gemacht werden muss. Es funktioniert grundlegend mit Laufwerksbuchstaben für Netzwerkfreigaben.

attrib +r *Ordnerpfad*

Das gewählte Ordnersymbol sollte nun angezeigt werden.

4.) Bei Bedarf kann für die „desktop.ini“ die gleichen Dateiattribute gesetzt werden, wie es Windows selbst tun würde. Dies geht weiterhin mit der Windows-Befehlszeile bzw. „Command Prompt“.

attrib +s +h *Ordnerpfad*\desktop.ini

Ergänzung: Seit längerem habe ich für diesen Zweck ein Befehlsskript in Verwendung. Dies vereinfacht die Angelegenheit und wird aus dem jeweiligen Ordner gestartet. Dieses Skript habe ich nun überarbeitet und als Download zur Verfügung gestellt:

Ordnersymbol Skript

Skript zum leichterem Setzen eines Ordnersymbols bei lokalen Ordnern. Sollte reibungslos unter Windows 10 und ab Windows Server 2012 R2 (inkl. Server Core) laufen. Das Skript muss sich im jeweiligen zu konfigurierenden Ordner befinden und wird von dort aufgerufen.

Größe: 0,67 KB

Version: 1.0a

Published: 4. Dezember 2020

Jetzt herunterladen!49 Downloads

• Betrifft: Nvidia Quadro und GeForce Treiber im Netzwerk verteilen
• System: Microsoft Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, Windows Server 2022
• Problem: Aktuellste Quadro oder GeForce Grafikkartentreiber sollen im Netzwerk auf Clients oder womöglich Remotedesktophosts aktualisiert werden. Verteilung über Microsoft Update funktioniert nicht oder kommt nicht in Frage.

Hintergrund

Bereits vor langer Zeit irgenwann Anfang 2018 hatte ich auf mehreren Computern veraltete Treiber für jeweils eine Quadro-Grafikkarte mit bekannten Treiberproblemen. Diese sollten damals auf die aktuellste Variante aktualisiert werden. Über Microsoft Update waren zu diesem Zeitpunkt nur ältere vorhanden. Bei Nvidia konnte bereits eine viel aktuellere Variante heruntergeladen werden. Selbst heute hat sich dieses Phänomen nicht viel verändert… – zudem sind immer wieder Sicherheitlücken in Grafikkartentreiber vorhanden. Da bietet sich ebenso eine schnellere Aktualisierung an.

Das zuvor genannte Setup-Paket kann zwar automatisiert werden, aber die Verteilung über einen vorhandenen Windows Server Update Services (= WSUS) scheiterte aufgrund der Setup-Architektur. Damals wurde daher nach einer Lösung gesucht, die über das Netzwerk automatisch eben dieses Setup-Paket an mehrere Computer und Server verteilt. Vor allem, da dies wiederholt durchgeführt werden sollte.

Behebung

Die Lösung wurde schlussendlich als PowerShell-Skript entwickelt und ist seit der ersten Fertigstellung mittlerweile vielfach reibungslos eingesetzt worden.

Für die Nutzung wird die Komponente PsExec64.exe von einem Dritthersteller benötigt: Mark Russinovich von Sysinternals. Windows Sysinternals gehört seit längerem zu Microsoft (inkl. weiterhin vorhandener Anstellung des ursprünglichen Entwicklers). Diese Sysinternals Tools werden weiterhin gepflegt und sind bei Microsoft als freier Download verfügbar. Im Falle von PsExec lautet der Link: https://docs.microsoft.com/de-at/sysinternals/downloads/psexec. Die erwähnte Datei sollte im selben Pfad wie das Skript liegen.

Neben dem Skript und PsExec64 wird eine CSV-Datei benötigt, in dieser alle Computer aufgelistet werden. Hier gilt pro Zeile ein Computername – ob NetBIOS oder FQDN ist dabei egal. Der Computer muss für die Aktualisierung gestartet und über das Netzwerk erreichbar sein. Angemeldet muss niemand sein bzw. ist dabei meine Empfehlung. Sofern doch ein Benutzer angemeldet ist, dann sollten zum Zeitpunkt der Installation keine 3D-Spiele oder 3D-Anwendungen genutzt werden. Diese reagieren etwas allergisch auf den Treiberaustausch und stürzen gerne ab.

Der Grafikkartentreiber sollte entpackt vorliegen. Dies wird beim Ausführen des heruntergeladenen Treiberpaketes auf jedem Computer (egal ob mit oder ohne passender Grafikkarte) durchgeführt und liegt dabei für gewöhnlich auf dem Windows-Laufwerk im Ordner “C:\Nvidia\…”. Es wird nur der letzte Ordner mit darin befindlichen Daten (z.B. die “setup.exe”) benötigt. Hinweis: Die vollständigen Daten vor dem Beenden bzw. Abbrechen des zuvor aufgerufenen Treiberpaketes kopieren, den dieser löscht nach dem Beenden des Setups die entpackten und benötigen Daten.

Die Ausführung ist danach recht einfach und sieht wie folgend aus:

.\run_nvidia-driver-setup.ps1 .\liste.csv C:\nv_quadro_win10

Die CSV-Datei und der Ordner mit den entpackten Grafikkartentreiber müssen nicht im selbem Pfad wie das Skript liegen. Bei Leerzeichen muss die Angabe in Anführungszeichen erfolgen. Liegt die Datei oder der Ordner im selben Pfad, dann sollte “.\” vor der Datei angesetzt werden. In meinem obigen Beispiel liegt die CSV-Datei im selben Pfad und der Grafikkartentreiber direkt auf dem Windows-Laufwerk “C:\” und enthält demnach den vollständigen Pfad (in diesem Fall ohne Leerzeichen).

Nach der Ausführung folgt eine kurze Prüfung der angeführten Pfade und der Drittherstellerkomponente. Anschließend wird mit dem ersten Computer aus der Liste begonnen. Sofern dieser gestartet und erreichbar ist, so wird das extrahierte Setup über das Netzwerk kopiert und das Setup lokal gestartet und ausgeführt. Anschließend werden die kopierten Daten wieder gelöscht.

Nvidia Driver Setup Skript

Skript zum Verteilen von Nvidia Quadro oder GeForce Treiberpaketen. Sollte reibungslos ab Windows 10 bzw. Windows Server 2016 funktionieren. Das Skript benötigt “PsExec64.exe” von Windows Sysinternals: https://docs.microsoft.com/de-at/sysinternals/downloads/psexec.

Entwicklung via Github: BlackSeals/run_nvidia-driver-setup

Größe: 4 KiB

Version: 1.1

Published: 9. September 2022

Jetzt herunterladen!9 Downloads

• Betrifft: Meistverwendete Apps anzeigen
• System: Microsoft Windows 11
• Problem: Die Funktion “Meistverwendete Apps anzeigen” kann nicht aktiviert werden bzw. ist ausgegraut. Es soll die Funktion aktiviert werden.

Hintergrund

In den “Einstellungen” soll unter “Personalisierung” => “Start” die Funktion “Meistverwendete Apps anzeigen” aktiviert werden.

Behebung

Der Grund hierfür liegt an den Datenschutzeinstellungen von Windows 11. Es fehlt an der Berechtigung zu “Lassen Sie Windows die Start- und Suchergebnisse verbessern, indem Sie App-Starts verfolgen”.  

Dies kann in den “Einstellungen” unter “Datenschutz und Sicherheit” => “Allgemein” mit der dritten angeführten Option “Lassen Sie Windows die Start- und Suchergebnisse verbessern, indem Sie App-Starts verfolgen” aktiviert werden.

Sobald dies geschehen ist, kann wieder zu den “Einstellungen” unter “Personalisierung” => “Start” gewechselt werden. Jetzt kann die Funktion “Meistverwendete Apps anzeigen” aktiviert werden. Die Darstellung von “Meistverwendet” dauert aber etwas und wird erst ab jetzt abgespeichert. Daher kann für die nächsten Stunden (bis Tage) Standardwerte wie “Tipps”, “Rechner” oder “Editor” angezeigt werden. Das sollte sich somit mit zunehmender Nutzung ändern.

• Betrifft: Logitech G HUB Gaming-Software
• System: Microsoft Windows 11, Windows 10
• Problem: Die Logitech G HUB Gaming-Software soll nach dem Anmelden automatisch gestartet werden. Die Option in der Software selbst ist entsprechend eingestellt und hat keine Wirkung.

Hintergrund

Die Logitech G Hub Gaming-Software ist die Verwaltungsoberfläche für Logitech G Produkten, wie Maus, Tastatur, Headset, Lautsprecher, Webkamera und weiteren. Neben Firmware-Aktualisierung können ebenso Profile und RGB-Farbverläufe konfiguriert werden.

Es macht dabei durchaus Sinn, die Software im Hintergrund laufen zu lassen. Nur so werden je nach Anwendung oder Spiel unterschiedliche Profile geladen bzw. genutzt.

Logitech G HUB wird laut Einstellungen beim Startvorgang automatisch geladen. In der Praxis tut es das zumindest bis zur Version 2024.1.515200 nicht. Will man die automatische Profilfunktion für eines oder mehrere Geräte nutzen, so muss man jedes Mal den Logitech G HUB manuell starten.

Behebung

Abhilfe ist zum Glück relativ leicht und übrigens unabhängig davon ob man im Logitech G HUB mit einer Logi ID angemeldet ist. Teilweise kann man im Internet lesen, es klappt nur mit einer Logi ID. Hinter Logi ID befindet sich der eigene Account bei Logitech.

Ich habe einfach die originale Verknüpfung kopiert und am Ende nach einem Leerzeichen folgendes angehängt:

--background

Diese Verknüpfung habe ich in “Logitech G HUB Autostart” umbenannt und unter dem Pfad:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

abgelegt. Nun wird (für jeden Benutzer) nach der Anmeldung die Logitech G HUB Gaming-Software im Hintergrund geladen.

Update 10.03.2024:

Mit dem kürzlich erschienen Update zu Logitech G HUB 2024.2 wird die Verknüpfung nicht mehr benötigt. Die Funktion mit dem automatischen Start sollte nach dem Update wieder korrekt funktionieren.

• Betrifft: Active Directory Federation Service 4.0 (und womöglich älter)
• System: Microsoft Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows Server 2022
• Problem: Der SQL Server wird ersetzt und die SQL Datenbank soll vom alten SQL Server zum neuen übernommen werden.

Hintergrund

Der ADFS nutzt demnach nicht die integrierte Datenbank, sondern bereits als Backend-Server einen anderes System mit SQL Server. Die Angelegenheit für die Migration kann immer wieder aus unterschiedlichen Gründen vorkommen. Im meinem Fall ist dies meistens, wenn der Backend-Server – also der dort genutzte Microsoft SQL Server oder Microsoft Windows Server – langsam außerhalb des Supports gelangt und durch einen neuen ersetzt werden soll.

Daneben gibt es ebenso Möglichkeiten bei Wiederherstellungsszenarien. Theoretisch wäre damit auch eine Migration von der internen Windows Datenbank zu Microsoft SQL Server denkbar. Wird aber für gewöhnlich (durch Microsoft) abgeraten und über die Backup und Restore Funktion eines zusätzlichen Produktes (von Microsoft) empfohlen.

Behebung

Nachfolgend die dazu notwendigen Schritte zur Durchführung:

• Aktuelle Sicherung (der Server)
• Auslesen der aktuellen Konfiguration
• Beenden des ADFS-Dienstes (aller Server)
• Umzug der SQL Datenbanken
• Konfiguration aller ADFS auf neuen SQL Server
• Umzug des ADFSArtifactStore
• Finaler Test

Aktuelle Sicherung (der Server)

Sofern virtuelle Maschinen, einfach einen Snapshot anlegen und fertig. Möglichkeiten gibt es hierbei viele und besser haben und nicht brauchen, als nicht haben, aber dann brauchen 😉 .

Auslesen der aktuellen Konfiguration

Es gibt zwei wichtige Befehle zur Anzeige der aktuellen Konfiguration:

Get-WmiObject -namespace root/ADFS -class SecurityTokenService

Get-AdfsProperties | fl artifactdbconnection

Beenden des ADFS-Dienstes (aller Server)

Sofern eine ADFS-Farm in Verwendung ist, so sollten nun bei allen Servern der ADFS-Dienst beendet werden.

Stop-Service -Name adfssrv

Umzug der SQL-Datenbanken

Der ADFS nutzt zwei Datenbanken: AdfsConfigurationV3 und AdfsArtifactStore. Diese sollten über das SQL Server Management Studio getrennt werden. Dabei darf keine Fehlermeldung kommen – wenn doch, dann wurde vermutlich die ADFS-Rolle nicht auf allen Servern beendet 🙄 . Am neuen Server muss nicht nur die SQL-Datenbanken (vier Dateien) übertragen werden, sondern unter Anmeldung sollte ebenso der genutzte Benutzer für den ADFS-Dienst angelegt werden.

Konfiguration aller ADFS auf neuen SQL Server

Auf jeden Server muss der neue Pfad zur Konfigurationsdatenbank geändert werden.

$adfs = Get-WmiObject -namespace root/ADFS -class SecurityTokenService

$adfs.ConfigurationDatabaseConnectionString="Data Source=*neuer SQL-Server\Instanz*;Initial Catalog=AdfsConfigurat
ionV3;Integrated Security=True"

$adfs.put()

Umzug des ADFSArtifactStore

Der folgende Schritt wird nur einmalig pro ADFS Farm benötigt. Zudem muss der ADFS-Dienst auf diesen Server gestartet sein.

Start-Service -Name adfssrv

Set-AdfsProperties -ArtifactDbConnection "Data Source=*neuer SQL-Server\Instanz*;Initial Catalog=AdfsArtifactStore;Integrated Security=True"

Auf diesem Server kann direkt der Neustart des ADFS-Dienstes veranlasst werden.

Restart-Service -Name adfssrv

Finaler Test

Der Umzug bzw. Migration ist abgeschlossen. Ab nun können alle ADFS-Dienste gestartet werden – sofern eine ADFS-Farm zum Einsatz kommt. In meinem Beispiel aus dem Screenshot war es nur ein Server. Varianten habe ich schon unterschiedliche gehabt. Verlief eigentlich immer recht harmlos und zügig. Ein kurzer Test ein paar externer Webdienste (mit Authentifizierung, sonst wird der ADFS nicht genutzt 😉 ) würde ich trotzdem vorschlagen. Allein schon beim Start des ADFS-Dienstes sollte im SQL Server Management Studio der Zugriff auf die Datenbank am neuen Server sichtbar sein.