Skip to main content

Morgan's Blog

Go Search
Home
Morgan's Blog
Minas Hjemmeside
Julies Hjemmeside
  

Morgan Simonsen's Homepage > Morgan's Blog
Exchange Move Mailbox logon info

Whenever you move a mailbox in Exchange Server the LastLoggedOnUserAccount attribute of the mailbox is changed to the user running the mailbox move. This is confusing since that user does not need permission to log on to the mailbox to perform the move.

It can also present a problem if you are trying to figure out which users have yet to log on to their mailboxes after moving them between servers. Let’s say you run this command:

Get-MailboxStatistics | where { $_.LastLogonTime -eq $null }

This would show you which users have never logged on to their mailboxes. Whichever servers they originally were located on cannot be removed before they have logged on at least once and been redirected to their new mailbox servers. Unfortunately, since the user performing the mailbox move is added to the LastLoggedOnUserAccount this command will probably return no users.

SCVMM P2V and ISA Server 2006

I recently upgraded my home network to Forefront Threat Management Gateway (TMG), retiring my old ISA Server 2006 server. I exported my ISA configuration and imported it into TMG, but to be on the safe side I decided to keep a copy of the server as a virtual machine. I used the P2V wizard in System Center Virtual Machine Manager (SCVMM) R2, but after I hit the Scan System button this error appeared:

VMM is unable to complete the request. The connection to the agent <ISA Server FQDN> was lost.

Ensure that the computer <ISA Server FQDN> exists on the network, WMI service and the agent are installed and running and that a firewall is not blocking HTTP and WMI traffic.

ID: 3157
Details: The RPC server is unavailable (0x800706BA)

Preparing to run the P2V wizard I had already created a new access rule allowing all traffic between the SCVMM and ISA Server computers, and disabled the Strict RPC compliance on the rule:

image

Apparently something was interfering with the RPC communication. Since my P2V rule was at the top of the Firewall Policy whatever was causing the problem had to be in the System Policy. I displayed the System Policy in the Firewall Editor and looked through each rule that specified RPC communication to the ISA Server. Turns out there was only one; the Microsoft Management Console (MMC) rule. To successfully perform a P2V of an ISA Server you need to disable the Strict RPC compliance setting. There was no way to do that in the MMC rule in the System Policy. Since all System Policy rules are processed before the Firewall Rules the MMC rule matched the RPC traffic and blocked parts of it necessary for P2V. I disabled the MMC rule, leaving only my P2V rule. Now the wizard worked correctly.

Windows Deployment Service Pre-Staging and GUIDs

Windows Deployment Services (WDS) has the ability to search Active Directory for pre-staged computer accounts to use when deploying images. There are several benefits to this, e.g. you can choose to service only known clients that you have created and ignore others, and you don’t have to provide or generate computer names since the image is deployed with the name of the pre-staged account. The information used to match a pre-staged computer account with a PXE-booting client is one of three things; the MAC address of the NIC executing the PXE boot, the GUID of the system or the GUID of the NIC executing the PXE boot. The latter is most widely used and recommended by Microsoft, since it virtually guaranteed to be unique. The WDS server performs an LDAP query to find the account that matches the booting computer:

(&(objectCategory=<DN of Computer Schema object>)(|(netbootGUID=<GUID>)(netbootGUID=MAC)))

This filter ensures that a device will be found if it is pre-staged using either a computer GUID or a MAC address. The netbootGUID attribute on a pre-staged client is used to store the value of the physical computer’s GUID or the MAC address.

You enter the GUID in two ways; using the GUI and Active Directory Users and Computers (ADUC) or using the CLI and WDSUTIL.EXE. Regardless you need to pay attention to how you format the GUID, because GUIDs can be byte-swapped according to the endianism of the system that handles them. The GUI in ADUC hints at this if you enter an invalid value:

---------------------------
GUID Not Valid
---------------------------
The globally unique identifier (GUID) query you entered is not valid. Use one of the following formats to enter a GUID:

    0123456789ABCDEFABCDEFABCDEFABCD or

    {67452301-AB89-EFCD-ABCD-EFABCDEFABCD}    (Note byte reordering)
---------------------------
OK  
---------------------------

In this message the first GUID is presented in what is known as binary octet string, the second representation is called just GUID string.

image

From the message you can work out how to convert between the two.

From Binary Octet string to GUID string (using the octet string in the message above):

  1. Each pair or characters is called an octet. Work with the GUID from left to right.
  2. Take the first 4 octets and reverse their order: 01234567 –> 67452301.
  3. Take the next 2 octets and reverse their order: 89AB –> AB89.
  4. Repeat for the next 2 octets: CDEF –> EFCD
  5. The rest of the octet string is identical for both formats so just add a hyphen: ABCDEFABCDEFABCD –> ABCD-EFABCDEFABCD

Reverse the process to convert from GUID string to binary octet string.

So how do you know which type you have? Sometimes the system will tell you; like ADUC’s Attribute Editor does:

image

Now, to confuse you completely, take a look at this from the ADUC Attribute Editor:

image

You have a value that is stored as an Octet String, but displayed in the list as GUID string! You have to double-click the value to see the REAL Octet String! Nice going!

Anyway, back to figuring out which way your GUID is displayed. If the system does not explicitly tell you which type its using I can give you this rule of thumb: GUID strings are usually displayed in braces (squiggly/sexy brackets) and with hyphens, or just with hyphens, while Binary octet string GUIDs are not. Keep in mind though; this might not always be the case. A perfect example of this is PXE boots, where the GUID that is displayed has hyphens, but is still an octet string GUID. All physical machines that I have observed have had octet string GUIDs in their PXE boot screens (see exception below for Hyper-V VMs).

image

If you want to pre-stage a computer account in Active Directory using this GUID you have to enter it without braces and hyphens:

image

This will cause ADUC to convert it to a GUID string, which is what the GUI always displays:

image

A very interesting exception to this is for Hyper-V VM PXE boots. For some strange reason, Microsoft decided that the GUID displayed during PXE boots in a Hyper-V VM is in GUID string format!

image

If you want to pre-stage a Hyper-V VM in Active Directory using this GUID you have to enter it with braces and with hyphens. This prevents ADUC from converting it, which it would do with a normal (octet string) GUID. So the braces probably mean ‘literal’ string or something.

image

Way to go Microsoft! :-(

So to summarize:

  • PXE boot screens always display octet string GUIDs (except Hyper-V VMs)
  • Active Directory Users and Computers always displays the GUID in GUID string format.
  • Active Directory Users and Computers accepts both octet string GUIDs and GUID string GUIDs, but will always convert to GUID string when displaying.

More info:

Microsoft Security Essentials, Sysprep and Group Policy

In smaller deployments Microsoft Security Essentials (MSE) is a good, free alternative for anti-malware. If you decide to use MSE in your images, you will discover that sysprep resets the Out Of Box Experience (OOBE) settings for MSE. In other words; every user that logs on to a machine deployed from your image will see the MSE OOBE Wizard (Figure 1-2), until someone with Administrator privileges completes the wizard. Sometimes you might not want to expose your users to that. Fortunately for us, we can use Group Policy Preferences to bypass the OOBE wizard.

Figure 1

Figure 2 

Steps to disable MSE OOBE with Group Policy Preferences:

  1. Create a new Group Policy Object (GPO) or use an existing one.
  2. Create a new Registry preference for computers (Figure 3).
  3. Update the key HKLM\SOFTWARE\Microsoft\Microsoft Security Essentials\OOBE DWORD to 0.
  4. Update policy on the client.

Figure 3

The OOBE value has two (known) values:

  • 1: Yes, run OOBE please
  • 0: No thanks, OOBE has already run for this computer
A list of System Center Virtual Machine Manager 2008 R2 warnings and errors, and their (possible) explanations/resolutions

Warning/Error number

VMM Description

VMM Recommended action

Possible cause/Resolution

10696 The host network adapter does not support the specified virtual network adapter configuration. Select a host network adapter that supports this configuration. Remove the check mark for Enable virtual network optimizations on the virtual network adapter in the Hardware Configuration tab of the virtual machine.
Windows and Extension mechanisms for DNS (EDNS)

Introduction

RFC 2671 defines the Extension mechanisms for DNS (EDNS), or EDNS0 as it is also known. EDNS is a specification for expanding the size of several parameters of the Domain Name System (DNS) protocol. More info about EDNS here. As of Windows Server 2008 R2, the Windows DNS service will use EDNS in its queries to other DNS servers. Because of the way EDNS works, this should not present a problem. EDNS only adds data to the end of a DNS packet. Any server not supporting EDNS will just ignore those extra bytes and process the first 512 bytes as a regular DNS packet. Unfortunately this is not always so. In some cases, I cannot explain why, DNS servers reject or return an error when they receive an EDNS packet. This could possibly be because the receiving DNS server has some intrusion/hacking functionality in place which causes it to reject a packet longer than 512 bytes, or that it supports the EDNS specification partially. Whichever it is, this presents a problem. The best way to fix it is to update the offending DNS server. This should be easy to do and solve the problem for everybody. If that is not possible we have to disable the EDNS functionality on the Windows DNS servers. To do this you use dnscmd.exe.

To see if EDNS is active on your DNS server:

dnscmd.exe /info /EnableEdnsProbes

If this returns 1 EDNS is active.

To disable EDNS on your DNS server:

dnscmd.exe <servername> /Config /EnableEDNSProbes 0

More information

  • The answer received from a non-compliant DNS server when queried using EDNS could generate event 5504 in the DNS log of the Windows DNS server that sent the query. This is an example:
    Message : The DNS server encountered an invalid domain name in a packet from <IP address of DNS server>. The packet will be rejected. The event data contains the DNS packet.

  • It seems that any Windows DNS server upgraded to Windows Server 2008 R2 retain its original settings and does not use EDNS unless specifically configured to do so.

  • A network trace can reveal if a DNS query uses EDNS. This example is from Wireshark:

    image 

    Notice the Type: OPT (EDNS0 option). This means the DNS packet uses EDNS. A packet that does not use EDNS will not have any Addition records.

  • Firewall may sometimes interfere with EDNS packets. The original DNS specification sets a limit of 512 bytes on DNS packet. If a firewall encounters a packet that is longer than 512 bytes (this would be an EDNS packet) it may block it, causing DNS resolution to fail.

In conclusion

The EDNS draft was first published in 1999, and for good reason. DNS is one of the corner stones of the Internet and we really need the functionality provided by EDNS (DNSSEC, for instance, requires EDNS to work). In my mind there is no reason why anyone should not support it, be it DNS servers or firewalls. Microsoft should not be blamed for turning on functionality that we have had almost 10 years to implement.

Links

Hyper-V Backup tip

KB article 958662 explains how to user Windows Server Backup, the new backup software included with Windows Server 2008 and Windows Server 2008 R2, to backup up Hyper-V virtual machines. The article walks you through creating a new Registry value to enable support for the Volume Shadow Copy Service (VSS) provider for Hyper-V. I have put together a command line that does it for you, just copy, paste and run it on your server.

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WindowsServerBackup\Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v "Application Identifier" /d Hyper-V /t REG_SZ

To verify that the key was created successfully you can use vssadmin.exe:

vssadmin.exe list writers

If everything is in order the result will include an entry for the Microsoft Hyper-V VSS Writer:

Writer name: 'Microsoft Hyper-V VSS Writer'
   Writer Id: {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
   Writer Instance Id: {f3358397-0e40-4c97-b845-d9ec930740e6}
   State: [1] Stable
   Last error: No error

Notice the Writer Id for the provider, which is identical to the one created in the Registry.

More info:

  • KB958662: How to back up Hyper-V virtual machines from the parent partition on a Windows Server 2008-based computer by using Windows Server Backup
  • Vssadmin
Error 0x8024D007 when running Windows Update

A server I was working on refused to let me update it through Windows/Microsoft Update. It would tell me that the computer needed an update before I could update it (!). First it would download some files from the Microsoft Update site, copy them and, finally, try to register them. This last step reached 100 %, but always terminated with the error 0x8024D007.

Process Monitor revealed that regsvr32.exe was called several times and the it failed with an Access Denied error on the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost. Looking at the permissions on that key I saw that the local Administrators group only had Read access. I changed it to Full Control and was able to restore Windows Update functionality.

In my search for a solution this particular scenario never showed up, so maybe this will help someone.

Some notes on the Windows Server 2008 R2 Active Directory Recycle Bin Feature
  • The Enable-ADOptionalFeature cmdlet must be run on the Schema Master DC (if not you will get A referral was returned from the server)
  • The only valid value for the Scope parameter is ForestOrConfigurationSet, Domain is not vaild (If you try you will get The specified method is not supported)
  • The Forest Functional Level must be Windows Server 2008 R2 mode
  • You must be an Enterprise Admin
  • The process is irreversible; you cannot turn off the Recycle Bin Feature once it is enabled

More info here:

Configuring a Windows Domain Controller to synchronize its clock with an external time source

Kerberos authentication requires correct time on all clients participating in authentication. If the clocks on two machines trying to authenticate to each other are too far apart, Kerberos authentication will fail. Since Kerberos is used extensively in Windows a mechanism to ensure correct clocks throughout the forest was also implemented. This is the Windows Time Service (w32time), a service which runs on all Windows machines since Windows 2000. The protocol used for synchronizing clocks is the Network Time Protocol (NTP). Every member computer, be it server or workstation, synchronize their clocks with the Domain Controller holding the PDC emulator FSMO role for its domain. The PDC emulator for a domain, in turn, synchronizes with the PDC emulator DC in the forest root domain. The PDC emulator in the root domain, therefore, is authoritative for the time throughout the forest, since all machines will inherit its clock. For this reason the PDC emulator DC in the forest root domain should be configured to obtain exact time from a dependable time server on the Internet. Microsoft has published information about doing this in KB816042. I have created a VBScript which implements the registry changes specified in that article:

   1: ' Configures the PDC Emulator in the root of a forest to be an authoritative time server
   2: ' and sync time from several NTP time servers on the Internet
   3: ' Info gathered from KB816042 How to configure an authoritative time server in
   4: ' Windows Server 2003 (http://support.microsoft.com/kb/816042)
   5: '
   6: ' On a PDC Emulator the settings changed from the default settings are:
   7: ' Type (From NT5DS to NTP)
   8: ' AnnounceFlags (From 10 to 5)
   9: ' NTPServer (From time.windows.com,0x1 to contents of strTimeServers)
  10: ' SpecialPollInterval (From 3600 to 900)
  11: ' MaxPosPhaseCorrection (From 4294967295 to 1800)
  12: ' MaxNegPhaseCorrection (From 4294967295 to 1800)
  13: '
  14: ' A useful command line command is:
  15: ' w32tm /config /manualpeerlist:"time-a.nist.gov time-b.nist.gov time.nist.gov time-nw.nist.gov" /syncfromflags:manual /reliable:yes /update
  16: ' This command sets AnnounceFlags to 5, NTPServer to the server list and Type to NTP
  17: ' Command found here:
  18: ' http://technet2.microsoft.com/windowsserver/en/library/ce8890cf-ef46-4931-8e4a-2fc5b4ddb0471033.mspx?mfr=true
  19: '
  20: ' A list of the NIST time server can be found here:
  21: ' http://tf.nist.gov/service/time-servers.html
  22: '
  23: ' Microsoft's list of (S)NTP servers is here:
  24: ' http://support.microsoft.com/kb/262680/en-us 
  25:  
  26: const HKEY_CURRENT_USER = &H80000001
  27: const HKEY_LOCAL_MACHINE = &H80000002
  28: strKeyPath = "SYSTEM\CurrentControlSet\Services\W32Time" 
  29:  
  30: strTimeServers = "time-a.nist.gov,0x1 time-b.nist.gov,0x1 time-a.timefreq.bldrdoc.gov,0x1 time-b.timefreq.bldrdoc.gov,0x1 time-c.timefreq.bldrdoc.gov,0x1 utcnist.colorado.edu,0x1 time.nist.gov,0x1 time-nw.nist.gov,0x1 nist1.dc.certifiedtime.com,0x1 nist1.datum.com,0x1 nist1.nyc.certifiedtime.com,0x1 nist1.sjc.certifiedtime.com,0x1"
  31: strComputer = "."
  32: Set objReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv") 
  33:  
  34: 'Change the server type to NTP (KB Step 1)
  35: objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath & "\Parameters","Type","NTP"
  36: 'Set AnnounceFlags to 5 (KB Step 2)
  37: objReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath & "\Config","AnnounceFlags",5
  38: 'Enable NTPServer (KB Step 3)
  39: objReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath & "\TimeProviders\NtpServer","Enabled",1
  40: 'Specify the time sources (KB Step 4)
  41: objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath & "\Parameters","NtpServer",strTimeServers
  42: 'Select the poll interval (KB Step 5)
  43: objReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath & "\TimeProviders\NtpClient","SpecialPollInterval",900
  44: 'Configure the time correction settings (KB Step 6)
  45: objReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath & "\Config","MaxPosPhaseCorrection",1800
  46: objReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath & "\Config","MaxNegPhaseCorrection",1800 
  47:  
  48: Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
  49: Set colListOfServices = objWMIService.ExecQuery ("Select * from Win32_Service Where Name ='W32Time'")
  50: For Each objService in colListOfServices
  51:     retVal = objService.StopService()
  52:     If retVal = 0 Then
  53:         'WScript.Echo "Service stopped"
  54:     Else
  55:         WScript.Echo "Service stop failed (" & retVal & ")"
  56:     End If
  57:     WScript.Sleep 5000
  58:     retVal = objService.StartService()
  59:     If retVal = 0 Then
  60:         'WScript.Echo "Service started"
  61:     Else
  62:         WScript.Echo "Service start failed (" & retVal & ")"
  63:     End If
  64: Next 
  65:  
  66: WScript.Echo "Done!" 

Below is a comparison of the changes in the registry before and after the changes:

Before

   1: PS C:\Users\administrator> w32tm /query /configuration
   2: [Configuration]
   3:  
   4: EventLogFlags: 2 (Local)
   5: AnnounceFlags: 10 (Local)
   6: TimeJumpAuditOffset: 28800 (Local)
   7: MinPollInterval: 6 (Local)
   8: MaxPollInterval: 10 (Local)
   9: MaxNegPhaseCorrection: 172800 (Local)
  10: MaxPosPhaseCorrection: 172800 (Local)
  11: MaxAllowedPhaseOffset: 300 (Local)
  12:  
  13: FrequencyCorrectRate: 4 (Local)
  14: PollAdjustFactor: 5 (Local)
  15: LargePhaseOffset: 50000000 (Local)
  16: SpikeWatchPeriod: 900 (Local)
  17: LocalClockDispersion: 10 (Local)
  18: HoldPeriod: 5 (Local)
  19: PhaseCorrectRate: 7 (Local)
  20: UpdateInterval: 100 (Local)
  21:  
  22:  
  23: [TimeProviders]
  24:  
  25: NtpClient (Local)
  26: DllName: C:\Windows\system32\w32time.dll (Local)
  27: Enabled: 1 (Local)
  28: InputProvider: 1 (Local)
  29: CrossSiteSyncFlags: 2 (Local)
  30: AllowNonstandardModeCombinations: 1 (Local)
  31: ResolvePeerBackoffMinutes: 15 (Local)
  32: ResolvePeerBackoffMaxTimes: 7 (Local)
  33: CompatibilityFlags: 2147483648 (Local)
  34: EventLogFlags: 1 (Local)
  35: LargeSampleSkew: 3 (Local)
  36: SpecialPollInterval: 3600 (Local)
  37:  
  38:  
  39:  
  40:  
  41: Type: NT5DS (Local)
  42:  
  43: NtpServer (Local)
  44: DllName: C:\Windows\system32\w32time.dll (Local)
  45: Enabled: 1 (Local)
  46: InputProvider: 0 (Local)
  47: AllowNonstandardModeCombinations: 1 (Local)
  48:  
  49: VMICTimeProvider (Local)
  50: DllName: C:\Windows\System32\vmictimeprovider.dll (Local)
  51: Enabled: 1 (Local)
  52: InputProvider: 1 (Local)
  53:  

After

   1: PS C:\Users\administrator> w32tm /query /configuration
   2: [Configuration]
   3:  
   4: EventLogFlags: 2 (Local)
   5: AnnounceFlags: 5 (Local)
   6: TimeJumpAuditOffset: 28800 (Local)
   7: MinPollInterval: 6 (Local)
   8: MaxPollInterval: 10 (Local)
   9: MaxNegPhaseCorrection: 1800 (Local)
  10: MaxPosPhaseCorrection: 1800 (Local)
  11: MaxAllowedPhaseOffset: 300 (Local)
  12:  
  13: FrequencyCorrectRate: 4 (Local)
  14: PollAdjustFactor: 5 (Local)
  15: LargePhaseOffset: 50000000 (Local)
  16: SpikeWatchPeriod: 900 (Local)
  17: LocalClockDispersion: 10 (Local)
  18: HoldPeriod: 5 (Local)
  19: PhaseCorrectRate: 7 (Local)
  20: UpdateInterval: 100 (Local)
  21:  
  22:  
  23: [TimeProviders]
  24:  
  25: NtpClient (Local)
  26: DllName: C:\Windows\system32\w32time.dll (Local)
  27: Enabled: 1 (Local)
  28: InputProvider: 1 (Local)
  29:  
  30: AllowNonstandardModeCombinations: 1 (Local)
  31: ResolvePeerBackoffMinutes: 15 (Local)
  32: ResolvePeerBackoffMaxTimes: 7 (Local)
  33: CompatibilityFlags: 2147483648 (Local)
  34: EventLogFlags: 1 (Local)
  35: LargeSampleSkew: 3 (Local)
  36: SpecialPollInterval: 900 (Local)
  37: Type: NTP (Local)
  38: NtpServer: time-a.nist.gov,0x1 time-b.nist.gov,0x1 time-a.timefreq.bldrdoc.gov,0x1 time-b.timefreq.bldrdoc.gov,0x1 time-
  39: c.timefreq.bldrdoc.gov,0x1 utcnist.colorado.edu,0x1 time.nist.gov,0x1 time-nw.nist.gov,0x1 nist1.dc.certifiedtime.com,0x
  40: 1 nist1.datum.com,0x1 nist1.nyc.certifiedtime.com,0x1 nist1.sjc.certifiedtime.com,0x1 (Local)
  41:  
  42:  
  43: NtpServer (Local)
  44: DllName: C:\Windows\system32\w32time.dll (Local)
  45: Enabled: 1 (Local)
  46: InputProvider: 0 (Local)
  47: AllowNonstandardModeCombinations: 1 (Local)
  48:  
  49: VMICTimeProvider (Local)
  50: DllName: C:\Windows\System32\vmictimeprovider.dll (Local)
  51: Enabled: 1 (Local)
  52: InputProvider: 1 (Local)

The most notable change is the Type value for the NTP client, which changes from NT5DS to NTP. The Type value is documented here.

Using w32tm.exe

The Windows Time Service can be configured using a complimentary utility called w32tm.exe. The following sets AnnounceFlags to 5, NTPServer to the server list and Type to NTP:

w32tm.exe /config /manualpeerlist:"time-a.nist.gov time-b.nist.gov time.nist.gov time-nw.nist.gov" /syncfromflags:manual /reliable:yes /update

Note that the settings for poll interval (SpecialPollInterval) and time correction (MaxPosPhaseCorrection/MaxNegPhaseCorrection) must be set in the registry.

Although the script uses the NIST time servers, I would recommend looking at the NTP Pool Project as well.

Also, to clear up a common misunderstanding, Windows does not need any third party software to synchronize its clock with an external time source, as long as the protocol used is NTP. This, of course, does not apply if you are using a special piece of hardware, such as a hardware clock, to keep correct time on your forest root PDC emulator DC. Furthermore, it is absolutely not necessary to include net time /sync or the like in logon scripts for clients to ensure they have the correct time, the Windows Time Service handles this.

If the DC holding the PDC Emulator FSMO role in the forest root domain is not set to sync its time from a reliable or external time source, the Windows Time service will log a warning in the System log with event ID 12:

Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the AD PDC emulator for the domain at the root of the forest, so there is no machine above it in the domain hierarchy to use as a time source. It is recommended that you either configure a reliable time service in the root domain, or manually configure the AD PDC to synchronize with an external time source. Otherwise, this machine will function as the authoritative time source in the domain hierarchy. If an external time source is not configured or used for this computer, you may choose to disable the NtpClient.

Resetting configuration

In some cases you need to reset the configuration of the Windows Time Service. The easiest way I have found is to unregister and the register the service. Do this:

  1. Stop the Windows Time Service
    net stop w32time
  2. Unregister the service:
    w32tm /unregister
  3. Register the service:
    w32tm /register
  4. Start the Windows Time Service
    net start w32time

These steps will reset the service back to the defaults, usually to sync from the Domain Hierachy for a domain joined machine.

1 - 10 Next

 ‭(Hidden)‬ Admin Links