Der Geräte-Manager zeigt nur Plug&Play-Geräte, -Treiber und -Drucker an, wenn Sie im Menü Ansicht auf Ausgeblendete Geräte anzeigen klicken. Nicht an den Computer angeschlossene Geräte, die Sie installieren (z. B. USB-Geräte oder „verwaiste“ Geräte), werden im Geräte-Manager nicht angezeigt, auch dann nicht, wenn Sie auf Ausgeblendete Geräte anzeigen klicken.
Abhilfe
Gehen Sie folgendermaßen vor, um dieses Verhalten zu umgehen und Geräte mit der Option Ausgeblendete Geräte anzeigen anzuzeigen:
Klicken Sie auf Start, zeigen Sie auf Alle Programme, zeigen Sie auf Zubehör, und klicken Sie anschließend auf Eingabeaufforderung.
Geben Sie an der Eingabeaufforderung den folgenden Befehl ein, und drücken Sie anschließend die EINGABETASTE:set devmgr_show_nonpresent_devices=1
Geben Sie an der Eingabeauforderung den folgenden Befehl ein, und drücken Sie dann die EINGABETASTE:start devmgmt.msc
Führen Sie eine Problembehandlung für die Geräte und Treiber im Geräte-Manager durch.
HINWEIS: Klicken Sie im Menü Ansicht im Geräte-Manager auf Ausgeblendete Geräte anzeigen, um Geräte sehen zu können, die nicht an den Computer angeschlossen sind.
Wenn Sie die Problembehandlung abgeschlossen haben, schließen Sie den Geräte-Manager.
Geben Sie an der Eingabeaufforderung exit ein.
Wenn Sie das Eingabeaufforderungsfenster schließen, deaktiviert Windows die Variable devmgr_show_nonpresent_devices=1 zurück, die Sie in Schritt 2 erstellt haben, und verhindert, dass verwaiste Geräte bei Anklicken von Ausgeblendete Geräte anzeigen angezeigt werden.
Do you have a computer with High-DPI screen? A very high resolution display? And is everything too small to see within your Remote Desktop Connection, try this solution…
This issue is caused by lack of not being DPI scaling aware of the Remote Desktop Client. If you open a Remote Desktop connection to a server or other computer the native resolution of the computer is used instead of the scaling to 1920×1080, so you’ll get very small icons etc.
Some other blogs mention to fix the issue with using Remote Desktop Connection Manager 2.7 or using RD Tabs.
Another solution where you don’t need extra tools or programs is to make a manifest file, see the steps below.
First tell Windows to look for a manifest file for an application by default. This can be done by setting a registry entry.
Open regedit and navigate to the registry key: HKLMSOFTWAREMicrosoftWindowsCurrentVersionSideBySide Right-click, select NEW -> DWORD (32 bit) Value
Type PreferExternalManifest and then press ENTER.
Right-click PreferExternalManifest, and then click Modify.
Enter Value Data 1 and select Decimal.
Click OK. Exit Registry Editor.
Next step is to make the manifest file, mstsc.exe.manifest. Copy the contents below and put it in Notepad or similar tool and save it to a file as %SystemRoot%System32mstsc.exe.manifest. Download of the file is also available, here. Important is that you save the file in the same directory as the Remote Desktop Client executable (mstsc.exe).
<?xml version=“1.0″ encoding=“UTF-8″ standalone=“yes“?> <assembly xmlns=“urn:schemas-microsoft-com:asm.v1″ manifestVersion=“1.0″ xmlns:asmv3=“urn:schemas-microsoft-com:asm.v3″> <dependency> <dependentAssembly> <assemblyIdentity type=“win32″ name=“Microsoft.Windows.Common-Controls“ version=“6.0.0.0″ processorArchitecture=“*“ publicKeyToken=“6595b64144ccf1df“ language=“*“> </assemblyIdentity> </dependentAssembly> </dependency> <dependency> <dependentAssembly> <assemblyIdentity type=“win32″ name=“Microsoft.VC90.CRT“ version=“9.0.21022.8″ processorArchitecture=“amd64″ publicKeyToken=“1fc8b3b9a1e18e3b“> </assemblyIdentity> </dependentAssembly> </dependency> <trustInfo xmlns=“urn:schemas-microsoft-com:asm.v3″> <security> <requestedPrivileges> <requestedExecutionLevel level=“asInvoker“ uiAccess=“false“/> </requestedPrivileges> </security> </trustInfo> <asmv3:application> <asmv3:windowsSettings xmlns=“http://schemas.microsoft.com/SMI/2005/WindowsSettings“> <ms_windowsSettings:dpiAware xmlns:ms_windowsSettings=“http://schemas.microsoft.com/SMI/2005/WindowsSettings“>false</ms_windowsSettings:dpiAware> </asmv3:windowsSettings> </asmv3:application> </assembly>
Note that you can use the manifest for other applications also that aren’t scaling aware.
Siehe auch https://www.brankovucinec.com/fix-remote-desktop-dpi-scaling-issues/
oder https://www.windowspro.de/wolfgang-sommergut/anzeige-rdp-sitzungen-fuer-hochaufloesende-monitore-anpassen
Windows Server 2008 R2 wird von Microsoft nur noch bis zum 14.01.2020 mit Sicherheitsupdates versorgt. So gelingt mit Inplace Upgrade eine Aktualisierung auf Windows Server 2012 R2.
Inhaltsverzeichnis
Was ist ein Inplace Upgrade?
Inplace Upgrade oder Neuinstallation?
Lifecycle beachten
Migrationspfad prüfen
Kompatibilität prüfen
Wichtige Vorarbeiten
Upgrade durchführen
Finale: System bereinigen
Was ist ein Inplace Upgrade?
Bei einem Inplace Upgrade wird das aktuell installierte Betriebssystem auf eine neuere Betriebssystemversion aktualisiert. Daten, Einstellungen und Programme bleiben dabei erhalten.
Inplace Upgrade oder Neuinstallation?
Im Normalfall sollte eine Neuinstallation gegenüber einem Inplace Upgrade bevorzugt werden. Eine Neuinstallation erzeugt ein sauberes, frisches und stabiles System. Bei einem Inplace Upgrade wird meist ein altes, vielleicht etwas betagtes System hochgerüstet und möglicherweise schlummernde Probleme mitportiert.
Domänencontroller können mit Inplace Upgrade aktualisiert werden. Ich würde aber eine Neuinstallation empfehlen.
Quelle: Microsoft.com
Datenbankserver mit Microsoft SQL Server können theoretisch per Upgrade aktualisiert werden. Aber auch hier ist eine Neuinstallation meist ratsam.
Quelle: Microsoft.com
Bei einem Exchange Server muss definitiv eine Neuinstallation durchgeführt werden.
Quelle: msxfaq.de
Lifecycle beachten
Neue Sicherheitsupdates werden nur bis zum Ende des sogenannten Extended Lifecycles (erweiterter Support) veröffentlicht. Danach bleiben neue entdeckte Sicherheitslücken ungepatcht und stellen eine Gefahr für das System und meist auch das restliche Netzwerk dar.
Betriebssystemversion
Ende Extended Lifecycle
Windows Server 2016 Standard/Datacenter
12.01.2027
Windows Server 2012 (R2) Standard/Datacenter
10.10.2023
Windows Server 2008 R2 Standard/Datacenter mit SP1
14.01.2020
Windows Server 2008 Standard/Enterprise mit SP2
09.04.2011
Windows Server 2008 Datacenter
12.07.2011
Quelle: Microsoft.com
Migrationspfad prüfen
Folgende Inplace Upgrades sind möglich:
Aktuelles System
Zielsystem(e)
Windows Server 2016 Standard
→
Windows Server 2019 Standard/Datacenter
Windows Server 2016 Datacenter
→
Windows Server 2019 Datacenter
Windows Server 2012 (R2) Standard
→
Windows Server 2016 Standard/Datacenter
Windows Server 2012 (R2) Datacenter
→
Windows Server 2016 Datacenter
Windows Server 2008 R2 Standard mit SP1
→
Windows Server 2012 R2 Standard/Datacenter
Windows Server 2008 R2 Datacenter mit SP1
→
Windows Server 2012 R2 Datacenter
Windows Server 2008 Standard/Enterprise mit SP2
→
Windows Server 2012 Standard/Datacenter
Windows Server 2008 Datacenter mit SP2
→
Windows Server 2012 Datacenter
Achtung:
Core-Server können nicht auf Server mit Desktopdarstellung migriert werden!
Sprache muss gleich sein
nur mehr bei Windows Server 2008 relevant: keine Migration von 32- auf 64-Bit möglich!
Quelle: docs.microsoft.com, Microsoft Upgrade Center
Kompatibilität prüfen
Hardware wird von zukünftigem Betriebssystem unterstützt bzw. verfügt über ausreichend Ressourcen?
Installierte Software wird von zukünftigem Betriebssystem unterstützt?
Wichtige Vorarbeiten
Freien Speicherplatz prüfen (mehr als 50 % frei)
Backup- und Recovery-Plan prüfen
Aktuelles Backup erstellen und prüfen (Wiederherstellungstest durchführen)
Bei einem physischem Server: BIOS & Firmware aktualisieren
Alle aktuell verfügbaren Windows-Updates für das aktuelle Betriebssystem installieren
evtl. manuell ein weiteres Backup erstellen (oder auf automatisches Backup warten)
Finale: System bereinigen
Beim Upgradevorgang wird C:Windows.old erstellt und dort das alte System für eine eventuelle Wiederherstellung gesichert. Dieser Ordner kann nach einem erfolgreichen Upgrade (inkl. entsprechender Wartezeit) gelöscht werden. In meinem Fall mussten zuvor aber Besitzer- und NTFS-Rechte des Ordners inkl. allen darunterliegenden Objekten angepasst werden.
Da der Server nach dem Upgrade wahrscheinlich auch eine große Menge Windows Updates erhält, kann im Anschluss der Windows Komponentenspeicher „WinSXS“ bereinigt werden:
Hier eine Auflistung der gängigsten Active Directory Ports sowie gängiger Ports für Paketfilter in Firewalls.
tcp/53 DNS tcp/88 Kerberos tcp/135 RPC tcp/445 sysvol share tcp/389 LDAP tcp/464 Kerberos password (Max/Unix clients) tcp/636 LDAP SSL (if the domain controllers have/need/use certificates) tcp/1688 KMS (if KMS is used. Not necessarily AD, but the SRV record is in AD and clients need to communicate with the KMS). tcp/3268 LDAP GC tcp/3269 LDAP GC SSL (if the domain controllers have/need/use certificates) tcp/49152 through 65535 (Windows Vista/2008 and higher) aka “high ports”
udp/53 DNS udp/88 Kerberos udp/123 time udp/135 RPC udp/389 LDAP udp/445 sysvol share
You can minimize the high-port range by configuring a static RPC port for Active Directory.
It’s usually a good idea to force Kerberos to use only tcp/ip, particularly if you have a large, complex network, or accounts are members of large number of groups/large token size.
1900, 2869 (UPnP Framwework für Netzwerkkommunikation unter Windows
WINS
TCP/UDP
1512
NetBIOS
TCP/UDP
137
NetBIOS Datagramm
UDP
138
NetBIOS Session Service
TCP
139
WINS Replikation
TCP/UDP
42
Active Directory Kommunikation
Notwendiger Datenverkehr
Netzwerkanmeldung eines Benutzers über eine Firewall
Microsoft-DS-Datenverkehr (445/TCP, 445/UDP) Kerberos-Authentifizierungsprotokoll (88/TCP,88/UDP) LDAP-Ping (389/UDP) DNS (53/TCP, 53/UDP)
Computeranmeldung an einem Domänencontroller
Microsoft-DS-Datenverkehr (445/TCP, 445/UDP) Kerberos-Authentifizierungsprotokoll (88/TCP,88/UDP) LDAP-Ping(389/UDP) DNS (53/TCP, 53/UDP)
Herstellen einer Vertrauensstellung zwischen Domänencontrollern in verschiedenen Domänen
Microsoft-DS-Datenverkehr (445/TCP, 445/UDP) Kerberos-Authentifizierungsprotokoll (88/TCP,88/UDP) LDAP-Ping (389/UDP) DNS (53/TCP, 53/UDP) LDAP (389/TCP; 686/TCP bei Verwendung von SSL)
Verifizierung einer Vertrauensstellung zwischen zwei Domänencontrollern
Microsoft-DS-Datenverkehr (445/TCP, 445/UDP) Kerberos-Authentifizierungsprotokoll (88/TCP,88/UDP) LDAP-Ping (389/UDP) DNS (53/TCP, 53/UDP) LDAP (389/TCP; 686/TCP bei Verwendung von SSL) Netlogon
Microsoft SQL Server Ports
Dienstebeschreibung
TCP/UDP
Portnummern, Beschreibung
SQL Abfragen
TCP
1433
SQL Monitor
TCP
1434
Microsoft Exchange Server Ports
Netzwerkkommunikation
Notwendiger Datenverkehr
Kommunikation mit Domänen- controllern
LDAP-Standardprotokoll (389/TCP; 636/TCP bei Verwendung von SSL) LDAP-Kommunikation für Standortreplikationsdienst (379/TCP) LDAP-Kommunikation für globalen Katalog (3368/TCP; 3269/TCP bei Verwendung von SSL)
Ausgehende DNS-Anforder-ungen an einen DNS Server
DNS (53/TCP und 53/UDP)
Nachrichtenaustausch zwischen Servern
SMTP Datenverkehr (25/TCP; 465/TCP bei Verwendung von TLS) SMTP Verbindungsalgorithmus (691/TCP)
Clients, die E-Mail über POP3 herunterladen
POP3 (110/TCP; 995/TCP bei Verwendung von SSL)
Clients, die E-Mail über IMAP4 herunterladen
IMAP4 (143/TCP; 993/TCP bei Verwendung von SSL)
Client, der Newsreader einsetzt
NNTP (119/TCP; 563/TCP bei verwendung von SSL)
Webbrowser, der E-Mail von OWA herunterlädt
HTTP-Protokoll (80/TCP; 443/TCP bei Verwendung von SSL)
Clients, die Sofortnachrichten verwenden
RVP (80/TCP sowie Anschlüsse über 1024/TCP)
Clients, die ein Chatprotokoll verwenden
IRC/IRCX (6667/TCP; 994/TCP bei Verwendung von SSL
Internetauthentifizierungsdienst (RADIUS)
Dienstebeschreibung
TCP/UDP
Portnummern, Beschreibung
Authentifizierungsdaten-verkehr
UDP
1645, 1812
Kontoführungsdatenverkehr
UDP
1813, 1646
Benachrichtigungs- und Über-wachungsdatenverkehr der Quarantänesteuerung
UDP
7250
Diverse gängige Netzwerkports
Dienstebeschreibung
TCP/UDP
Portnummern, Beschreibung
PPTP VPN
TCP
1723 (GRE, IP/47)
L2TP VPN
TCP
1701, sowie IKE Port 500/UDP
SSH
TCP
22
HTTP
TCP
80
HTTPS
TCP
443
RDP
TCP
3389, Microsoft Remote Desktop Protocol
iSCSI
TCP
3260, 860
RPC Locator
TCP/UDP
135, Remote Procedure Call
Microsoft Operations Manager
TCP/UDP
1270
WINS
TCP/UDP
1512
Microsoft Message Queue
TCP/UDP
1801
Microosft Desktop Air Sync Protocoll
TCP/UDP
2175
Microsoft Active Sync Remote API
TCP/UDP
2176
Microsoft OLAP3
TCP/UDP
2382
Microsoft OLAP4
TCP/UDP
2383
Microsoft .NETster
TCP/UDP
3126
Microsoft Business Rule Engine Update Service
TCP/UDP
3132
Microsoft Globaler Katalog
TCP/UDP
3268
Microsoft Globaler Katalog mit LDAP/SSL
TCP/UDP
3269
Microsoft Windows File System (WINFS)
TCP/UDP
5009
Microsoft Small Business
TCP/UDP
5356
Microsoft DFS Replikation
TCP/UDP
5722
Microsoft max
TCP/UDP
6074
NTP
TCP/UDP
123, Network Time Protocol
NetBIOS
TCP/UDP
137
NetBIOS Datagramm
UDP
138
NetBIOS Session Service
TCP
139
RPC Dynamic Assignment
TCP
1024-65535
Server Message Block, SMB over IP (Microsoft-DS)
TCP/UDP
445
GRE, generic routing encapsulation (if using PPTP)
IP
47
IPSec ESP
IP
50, Encapsulated Security Payload
IPSec AH
IP
51, Authenticated Header
Emule
TCP
4661, Ausgehend
Emule
TCP
4662, Eingehend
Emule
UDP
4665, Ausgehend
Emule
UDP
4672, Eingehend
MSN Messenger
Ältere Messenger Versionen: IN TCP 6891 – 6900 IN TCP 1863 IN UDP 1863 IN UDP 5190 IN UDP 6901 IN TCP 6901 Neue Messenger Versionen: UDP Ports: 135, 137, 138 TCP Ports: 135, 139, 445
Ältere MSN Messenger: (Achtung!! Alte Messenger benötigen einen großen Portbereich!!)
Ports 6891-6900 erlauben Datei Sendungen Port 6901 ist für Audio Kommunikation Allows Voice, PC to Phone, Messages, and Full File transfer capabilities. Thnx to Brad King & Bill Finch Jr. Neue MSN Messenger: UDP Ports: 135, 137, 138, TCP Ports: 135, 139, 445
The MaxShadowCopies registry value specifies the maximum number of client-accessible shadow copies that can be stored on each volume of the computer. A client-accessible shadow copy is a shadow copy that is created using the VSS_CTX_CLIENT_ACCESSIBLE value of the _VSS_SNAPSHOT_CONTEXT enumeration. Client-accessible shadow copies are used by Shadow Copies for Shared Folders. For more information about shadow copies, see the VSS documentation.
If the MaxShadowCopies registry value does not exist, the backup application can create it under the following registry key:
Create a value with the name MaxShadowCopies and type DWORD. The default data for this value is 64. The minimum is 1. The maximum is 512.
Note
For other types of shadow copies, there is no registry value that corresponds to MaxShadowCopies. The maximum number of shadow copies is 512 per volume.
Note The MaxShadowCopies setting is supported on Windows Server 2003 or later.
Windows Server 2003: On cluster servers, MaxShadowCopies registry value’s data may need to be set to a lower number. For more information, see „When you use the Volume Shadow Copy Service on Windows Server 2003-based computers that run many I/O operations, disk volumes take longer to go online“ in the Help and Support Knowledge Base at https://support.microsoft.com/kb/945058.
In einer Windows-Domäne sollte die Systemzeit aller Rechner übereinstimmen, damit das Active Directory störungsfrei funktionieren kann. Während die Synchronisierung der Uhrzeit bei normalen Mitgliedern einer Domäne automatisch gewährleistet sein sollte, empfiehlt sich beim DC mit der PDC-Emulator-Rolle die Konfiguration eines externen NTP-Servers.
Eine synchrone Systemzeit benötigt das Active Directory vor allen aus zwei Gründen:
Bei der Replikation der AD-Datenbank werden Zeitstempel verwendet, um Replikationskonflikte aufzulösen. Sie entstehen, wenn Objekte parallel auf zwei oder mehreren Domain-Controllern verändert werden.
Kerberos V5 verweigert die Authentifizierung von Computern, wenn deren Zeit mehr als 5 Minuten abweicht (dieser Wert ist die Voreinstellung, sie kann über GPOs mit der Einstellung Max. Toleranz für die Synchronisierung des Computertakts unter Computerkonfiguration => Windows-Einstellungen => Sicherheitseinstellungen => Kontorichtlinien => Kerberos-Richtlinie geändert werden).
Synchronisierung per Voreinstellung
Innerhalb einer Windows-Domäne sorgt der Windows Time Service (W32Time) automatisch für den Abgleich der Systemzeit. Normale Mitglieder, seien es Clients oder Server, synchronisieren ihre Zeit mit einem der Domain Controller.
Die Zeitsynchronisierung folgt in der AD-Hierarchie nach unten.
Die DCs wiederum beziehen ihre Zeit vom Inhaber der Rolle PDC-Emulator. Dieser wiederum sollte seine Einstellungen von einem DC der übergeordneten Domäne erhalten, und die DCs dort synchronisieren sich mit dem dortigen PDC-Emulator, usw. (siehe Grafik). Der PDC-Emulator der Root-Domäne ist schließlich derjenige, der seine Systemzeit von einer externen Quelle abrufen sollte, etwa von einem dafür vorgesehenen Gerät oder einem Internet-Zeit-Server.
Einstellungen überprüfen mit w32tm
Möchte man herausfinden, von welcher Quelle ein Rechner seine Systemzeit ermittelt, dann kann man dies mit Hilfe des Befehls
w32tm /query /source /computer:<RemotePC>
herausfinden. Bei normalen Mitgliedern der Domäne sollte das Ergebnis ein DC sein, bei DCs der Inhaber der Rolle PDC-Emulator. Läuft Windows jedoch in einer virtuellen Maschine, dann lautet unter Hyper-V die Quelle auf VM IC Time Synchronization Provider, wenn die Synchronisierung über die Integrationsdienste aktiviert ist. Das Pendant unter VMware heißt VMICTimeProvider.
Synchronisierung in VMs unter Hyper-V
Gastbetriebssysteme in VMs greifen nicht auf die CMOS-Uhr zurück, um beim Booten die Systemzeit einzustellen. Stattdessen erhalten sie diese Information von Hyper-V, und zwar noch bevor die Integrationsdienste starten. Ab diesem Zeitpunkt berechnet Windows die aktuelle Zeit anhand eines eigenen Algorithmus. Da dieser innerhalb von VMs durch die ungleichmäßige Zuteilung von Hardware-Ressourcen meist außer Tritt gelangt und die Uhr damit zu langsam geht, gleicht die Synchronisierungsfunktion der Integrationsdienste diesen Rückstand immer wieder aus.
Die Synchronisierung der Zeiteinstellung durch die Integrationsdienste ist per Voreinstellung aktiviert.
Aufgrund der ohnehin herrschenden Zeitsynchronisierung innerhalb einer Domäne erscheint es nicht notwendig, dass Windows-VMs ihre Systemuhren zusätzlich mit dem Virtualisierungs-Host abgleichen. Ben Armstrong, Program Manager für Hyper-V bei Microsoft, empfiehlt aber in einem Blog-Beitrag, die Synchronisierung mit Hyper-V eingeschaltet zu lassen. Diese komme damit klar, wenn Gäste ihre Einstellungen zusätzlich über eine andere Quelle bezögen. Außerdem sei sie in der Lage, die Uhren auch dann abzugleichen, wenn Host und Gast verschiedenen Zeitzonen angehören.
Diverse Ratgeber im Web empfehlen, die Zeitsynchronisierung mit Hyper-V in jedem Fall abzuschalten, wenn in der VM ein virtueller DC mit der PDC-Emulator-Rolle läuft. Hier drohe Chaos, wenn er zusätzlich seine Einstellungen von einer externen Quelle abrufe. Im oben genannten Beitrag rät Ben Armstrong jedoch dazu, auch in diesem Fall die Synchronisierung über Hyper-V nicht auszuschalten.
Externen Zeitgeber konfigurieren
In den meisten Umgebungen wird man nur den PDC-Betriebsmaster mit einer externen Quelle synchronisieren, alle anderen Rechner innerhalb der Domäne sollten automatisch mit ihm abgeglichen werden.
Auch die Konfiguration eines externen NTP-Servers erfolgt über den Befehl w32tm. Mit dem Parameter manualpeerlist teilt man ihm den DNS-Namen oder die IP-Adresse von einem Zeitgeber mit. Gibt man mehr als eine Quelle an, dann muss die Liste in Anführungszeichen stehen und die einzelnen Elemente müssen durch Leerzeichen getrennt sein. So konfiguriert man etwa die öffentlich zugänglichen NTP-Server von ntp.org auf folgende Weise:
Alternativ zu w32tm.exe kann man Gruppenrichtlinien verwendet, um eine externe Zeitquelle zu definieren. Dazu erstellt man ein GPO und verknüpft es mit der OU Domain Controllers. Damit es nur auf den DC mit der Rolle PDC-Emulator angewendet wird, benötigt man diesen WMI-Filter:
Select * from Win32_ComputerSystem where DomainRole = 5
Die dafür zuständigen Einstellungen sind Windows-NTP-Client aktivieren und Windows-NTP-Client konfigurieren, sie finden sich unter Computerkonfiguration => Richtlinien => Administrative Vorlagen => System => Windows-Zeitdienst => Zeitanbieter.
Für die Konfiguration eines externen Zeitanbieters über ein GPO benötigt man 2 Einstellungen.
Bei der Konfiguration des NTP-Clients muss man unter Type auf NTP umstellen, wenn man eine externe Quelle über dieses Protokoll einbinden möchte. Bei virtualisierten DCs kann es zudem hilfreich sein, das Poll-Intervall von den vorgegebenen 3600 auf 900 Sekunden zu verkürzen.
Schließlich muss man noch unter Computerkonfiguration => Richtlinien => Administrative Vorlagen => System => Windows-Zeitdienst die Globalen Konfigurationseinstellungen aktivieren und die vorgegebenen Werte dort bei Bedarf anpassen.
Seit dem Funktionsupdate 20H1 ist die oben beschriebene Schaltfläche „Benutzer müssen Benutzernamen und Kennwort eingeben“ nicht mehr vorhanden. Du kannst diese aber mit einem neuen Registryeintrag wieder aktivieren. Ändere hierfür den Wert für „DevicePasswordLessBuildVersion“ unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Passwordless\Device auf den Wert „0“. Sollte der Schlüssel bei Dir nicht vorhanden sein, so musst Du diesen als Typ „REG_DWORD“ anlegen.
Windows 10 Autologin per Registry konfigurieren
Das was der oben beschriebene Weg im Hintergrund ausführt, kann man auch manuell per Registry tun. Der folgende Weg hat nur einen „kleinen“ Nachteil: Das Benutzerkennwort wird im Klartext in der Registrierungsdatenbank von Windows hinterlegt, ist also theoretisch für jeden einsehbar. Wenn das kein Problem darstellt, dann brauchst Du lediglich die folgenden Werte in der Registry ändern, bzw. erstellen, sofern diese noch nicht vorhanden sind.
Sometimes we just need a computer with the so-called auto-logon feature. This feature is without a doubt a security risk but on the other hand it is a good way to make computers as simple as possible for all users. Auto-Logon configruation is suitable for Kiosk mode or presentation computers where it should be as simple as possible. In this blog post I will provide a script to configure auto login without having to search the registry for the right keys. Let’s get started.
The Objective
In this part I will show you what happens if you run my script.
That’s it. Cool stuff. Which brings me to the code.
The Code
Before you run the code, check your PowerShell ExecutionPolicy settings. On Windows 10 computers the default setting is Restriced. In order to run the script, you have to change the policy to at least RemoteSigned.
Copy the code below into PowerShell ISE or an editor of your choosing. Run the code and enter username and password. Then restart the computer and check if it works as expected.
12345678910111213141516171819202122232425
### The code below configures Auto-Login on Windows computers ###<#Author: Patrick Gruenauer | Microsoft MVP on PowerShellWeb: https://sid-500.com#>$Username= Read-Host'Enter username for auto-logon (f.e. contoso\user1)'$Pass= Read-Host"Enter password for $Username"$RegistryPath= 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon'Set-ItemProperty$RegistryPath'AutoAdminLogon'-Value"1"-TypeString Set-ItemProperty$RegistryPath'DefaultUsername'-Value"$Username"-typeString Set-ItemProperty$RegistryPath'DefaultPassword'-Value"$Pass"-typeStringWrite-Warning"Auto-Login for $username configured. Please restart computer."$restart= Read-Host'Do you want to restart your computer now for testing auto-logon? (Y/N)'If($restart-eq'Y') {Restart-Computer-Force}
Fine, that’s it for today. See you next time with PowerShell.
Caution: To test this script in Hyper-V, you must disable Enhanced Session mode for the Hyper-V guest.