By default, the Active Directory Schema MMC snap-in is not registered on domain controllers or machines with the Remote Server Administration Tools (RSAT) installed. To use the snap-in for the first time on a new machine, you’ll need to register the DLL. To do this, follow the steps below:
Open an elevated command prompt
Run the following command: regsvr32 schmmgmt.dll
You should receive a success message:
Once you have registered the snap-in, you can add it to an MMC by following these steps:
Open a new MMC Console (Start>Run>mmc)
In the MMC Console, go to File>Add/Remove Snap-in
Add the Active Directory Schema snap-in as shown below:
Once you click OK, you’ll be able to access the snap-in through the MMC Console
ι Greek letter Ι Greek letter, capital version of above character, not an „I“) α alpha U+03B1 Alt 224 Γ gamma U+0393 Alt 226 δ delta U+03B4 Alt 235 ε epsilon U+03B5 Alt 238 Θ theta U+0398 Alt 233 π pi U+03C0 Alt 227 Σ sigma upper U+03A3 Alt 228 σ sigma lower U+03C3 Alt 229 τ tau U+03C4 Alt 231 Φ phi upper U+03A6 Alt 232 φ phi lower U+03C6 Alt 237 Ω omega U+03A9 Alt 234 一 Japanese Character? (Thanks, Jam) 口 Japanese character? (Thanks, Jam) 末 Japanese character „End“ (Thanks, Jam) (a private use character) (Thanks, Peter O.)
Und man kann auch tatsächlich (fast) alle Sonder-Zeichen außer \ / : * ? “ < > | verwenden.
So, jetzt zum wirklich Wichtigen, die Buchstaben nach „Z“.
Zuerst habe ich das Ohm-Zeichen Ω gefunden (das griechische Omega).
Dann herausgefunden das alle griechischen Buchstaben α β γ δ ε … φ χ ψ ω nach den deutschen Buchstaben kommen und danach die kyrillischen Buchstaben Ё Ђ Ѓ Є … Ҳ Ҹ Һ Ә Ө .
Vor der Null kommen anscheinend nur Satzzeichen und Symbole, den Anfang macht das ! dann # $ % & irgendwann kommt das @ , Plus, Minus und Underline sind auch vor Null.
Ein paar schöne Symbole vor Null sind Pik, Kreuz, Herz und Karo ♠ ♣ ♥ ♦ , sowie ■ ▲ ▼ ► ◄ wobei diese komischer Weise im Explorer unterschiedlich groß dargestellt werden.
Und noch ein ganz Spezielles, weil ja * nicht erlaubt ist, kann man alternativ den arabischen Stern ٭ verwenden, der aber hier im Textfenster etwas Probleme macht, ist wohl ein Steuerzeichen für irgend was, er schaut hier im Text auch nicht so schön aus wie im Explorer.
Die Sortierreihenfolge nach unterschiedlichen Sonderzeichen, speziell Minus, bleibt wohl für ewig ein Rätsel, hier ein Beispiel:
Den Windows-Dienst W32Time unter Windows Server 2019 konfigurieren und als Zeitquelle innerhalb einer Active Directory Domäne anbieten.
Inhaltsverzeichnis
Vorabinformationen
Die richtige Uhrzeit
Domänencontroller und Zeitquellen
Domänencontroller mit PDC-Betriebsmaster finden
Virtuelle Domänencontroller und Hypervisor-Zeitsynchronisation
Netzwerkanforderungen
Uhrzeit auf einem Core Server anzeigen
Zeitquelle auf dem PDC-Betriebsmaster konfigurieren
Zeit in der Domäne verteilen
Zeit für mobile Geräte verteilen
Vorabinformationen
Die richtige Uhrzeit
Neben dem offensichtlichen praktischen Nutzen einer möglichst korrekten Uhrzeit, gibt es auch eine technische Notwendigkeit. So ist in einer Active-Directory-Domäne das zeitabhängige „Kerberos“ im Hintergrund für die Authentifizierung zuständig. Kerberos erstellt für jede Authentifizierungsanforderung (z.B. Zugriff auf Dateifreigabe) zeitlich begrenzt gültige Tickets, die den angeforderten Vorgang innerhalb weniger Minuten erlauben. Bei entsprechender Zeitdifferenz schlagen die Authentifizierungen fehl und der Zugriff wird blockiert.
Domänencontroller und Zeitquellen
Der Domänencontroller der den PDC-Betriebsmaster ausführt, dient innerhalb einer Active-Directory-Domäne als Zeitquelle für alle anderen Windows Server und Clients. Dadurch genügt es die Zeitquelle auf dem Domänencontroller zu konfigurieren.
Domänencontroller mit PDC-Betriebsmaster finden
Da typischerweise mehrere Domänencontroller in einem Netzwerk ausgeführt werden, kann der Domänencontroller mit dem PDC-Betriebsmaster wie folgt gefunden werden:
„Active Directory-Benutzer und -Computer“ öffnen
Rechtsklick auf die Domäne → Betriebsmaster
Registerblatt PDC anklicken:
Virtuelle Domänencontroller und Hypervisor-Zeitsynchronisation
Bei virtuellen Domänencontrollern besteht die Gefahr, dass von außen der jeweilige Hypervisor eine andere falsche Zeit vorgibt. Bei Hyper-V kann dies in den Einstellungen der virtuellen Maschine unter dem Menüpunkt Integrationsdienste → Zeitsynchronisierung deaktiviert werden:
Netzwerkanforderungen
Der Windows Zeitdienst folgt dem NTP-Standard und verwendet für die Synchronisation den UDP Port 123. In restriktiv konfigurierten Netzwerk-Firewalls muss dieser Port daher zumindest vom Domänencontroller ausgehend ins Internet erlaubt werden.
In vielen Fällen kann aber auch die Firewall selbst einen NTP-Zeitserver anbieten und mit einem Internet-NTP-Server abgleichen. In diesem Fall könnte dann der Domänencontroller mit PDC-Rolle die Firewall als Zeitquelle nutzen.
Uhrzeit auf einem Core Server anzeigen
Die Uhrzeit kann über den Befehl sconfig → „9) Datum und Uhrzeit“ angezeigt werden:
Datum und Uhrzeit
Zeitquelle auf dem PDC-Betriebsmaster konfigurieren
Eingabeaufforderung als Administrator öffnen und mit folgendem Befehl den öffentlichen NTP-Serverpool „at.pool.ntp.org“ als Zeitquelle festlegen:
w32tm /config /manualpeerlist:“at.pool.ntp.org,0x8″ /syncfromflags:manual /reliable:yes /update net stop w32time && net start w32time
Ein erneuter Zeitabgleich wird mit folgendem Befehl initiiert:
w32tm /resync
Der W32TM-Status kann wie folgt ermittelt werden:
w32tm /query /status
w32tm /query /status
Zeit in der Domäne verteilen
Im Normalfall verteilt sich die neue Uhrzeit relativ schnell von selbst. Wenn ein Windows Desktop oder Server die Zeit scheinbar nicht übernimmt, ist möglicherweise eine andere Zeitquelle konfiguriert. Mit diesen Befehlen wird wieder der Domänencontroller als Zeitquelle konfiguriert:
w32tm /config /syncfromflags:domhier /update net stop w32time && net start w32time
Ein erneuter Zeitabgleich wird mit folgendem Befehl initiiert:
w32tm /resync
Zeit für mobile Geräte verteilen
Wenn mobile Windows Clients auch extern einen Zeitabgleich mit öffentlichen NTP-Servern durchführen sollen, kann das wie folgt konfiguriert werden:
w32tm /config /manualpeerlist:“at.pool.ntp.org,0x8″ /syncfromflags:manual,domhier /update net stop w32time && net start w32time
Mehr auf Microsoft.com
Many times users connect to remote Windows systems, do work and close the remote session without properly logoff the account. In that case multiple applications, which are still running with that login session uses system resources. Some times it causes slow response of our servers and create pain for us. So this will be good to auto log off disconnected sessions from Windows system.
This tutorial will help you to log all the disconnected remote sessions on the Windows system. This tutorial has been tested with Windows Server 2019.
Setup Auto Log Off Disconnected Sessions
We are making changes in Local group policy of systems. So be careful with the changes.
First of all, open the ‘Group Policy Editor‘ on your server. Start run window by pressing “Win + R” and type gpedit.msc on run window.
The local group policy editor will be opened on your system. Then navigate to the following location as the below given instructions:
Local Computer Policy => Computer Configuration => Administrative Templates => Windows Components => Remote Desktop Services => Remote Desktop Session Host => Session Time Limits
You will find a list of options on the right-side. Then Double click on “Set time limit for disconnected sessions” to open it.
By default, it is configured a ‘Not configured. Change this to ‘Enabled. Now you will see an option “End a disconnected session” in the lower-left side. Set this value to the desired time. I have set this to 1 hour, so any disconnected user is logged off after 1 hour.
Conclusion
In this tutorial, you have learned to configure your Windows system to auto logout disconnected remote sessions.
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
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.