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.
