Use PowerShell to Easily Compare the Time Between Two Computers
Summary: Microsoft Scripting Guy, Ed Wilson, shows how to use Windows PowerShell to easily compare the time between two computers. Microsoft Scripting Guy, Ed Wilson, is here. In two days, I will be speaking to the AZPOSH Windows PowerShell user group in Phoenix, Arizona. No, I am not flying out there—I have enough travel coming up. Instead, I am speaking via Lync. Lync does an excellent job, and it is just about like being there in person (except for missing all the great restaurants they have out there). I will be speaking about using the Windows PowerShell 3.0 remoting capabilities for management purposes. It will be a lot of fun. If you cannot be there in person (such as myself), you may want to dial in to the Lync meeting.
Checking local and remote time
One of the people who was at the Windows PowerShell user group in Charlotte the other day was asking me about checking the time on remote computers. This got me to playing around.
Note For more information about time synchronization issues, see the following Hey, Scripting Guy! Blog posts: Configuring w32Time Service Logging and Configuring an Authoritative Time Server in Windows Server. Of course, it is possible to use WMI to query for time information from a remote machine. To do this, use the Win32_LocalTime WMI class. The problem with this is that each property is a piece of the time and, therefore, must be assembled from at least three different properties (unless you also want the date—that is another three properties).
Finding the PDC emulator
By default, the domain’s authoritative time server is the server holding the PDC Emulator FSMO role. The easiest way to find the name of this server is to use the Get-ADDomain cmdlet from the Active Directory module. On Windows PowerShell 3.0, it is not necessary to load the Active Directory module prior to running the command. Therefore, the following command returns the PDC Emulator for my domain.
PS C:> (Get-ADDomain).pdcemulator
dc1.iammred.net
Check the date / time on a remote computer
The easiest way to obtain the date and time on a remote computer is to simply use the Get-Date cmdlet. By using Windows PowerShell remoting, it is trivial to obtain the remote time information. An example is shown here.
PS C:> invoke-command -ComputerName dc1 -ScriptBlock {get-date}
Wednesday, October 31, 2012 1:23:42 PM I can shorten the command considerably by taking advantage of the ICM alias for the Invoke-Command cmdlet and by using positional parameters, as shown here.
PS C:> icm dc1 {get-date}
Wednesday, October 31, 2012 1:24:24 PM If I would like to see all of the date / time information, I can pipe the results to the Format-List cmdlet. This is shown here.
PS C:> icm dc1 {get-date} | fl *
DisplayHint : DateTime
PSComputerName : dc1
RunspaceId : 7cf0452c-688a-4e16-83f5-d9b0ec6ded6e
PSShowComputerName : True
DateTime : Wednesday, October 31, 2012 2:33:35 PM
Date : 10/31/2012 12:00:00 AM
Day : 31
DayOfWeek : Wednesday
DayOfYear : 305
Hour : 14
Kind : Local
Millisecond : 879
Minute : 33
Month : 10
Second : 35
Ticks : 634872908158794870
TimeOfDay : 14:33:35.8794870
Year : 2012 On the other hand, it is also possible that what I need to do is to see if there is a time offset between my computer and the server. To do this, I can use the new-TimeSpan cmdlet to measure the difference between the two Get-Date commands. Keep in mind that part of the time offset could be attributable to the time it takes to make the remote connection and to run the command and to return the information. How this affects the time, however, depends on whether my local system time is fast or slow when compared with the remote server. The command itself is rather simple. I use the Get-Date cmdlet from my local computer as the start of the timespan. I then use the time from the remote server as the end time. The command and associated results are shown here.
PS C:> new-timespan -Start (get-date) -end (icm dc1 {get-date})
Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : -311
Ticks : -3116406
TotalDays : -3.60695138888889E-06
TotalHours : -8.65668333333333E-05
TotalMinutes : -0.00519401
TotalSeconds : -0.3116406
TotalMilliseconds : -311.6406
Sync with an external time source
The time skew between my computer and the server is less than half of a second—certainly well within tolerance. But what if I had a greater time skew? Well, I would first resync my server with the external time source. To do this, I would use the W32tm command.
Note For more information about the topic of resyncing time sources, see this article at the TechNet Library. The following command runs W32tm and tells the remote server DC1 to resync with Time.Windows.Com. The output states that the results are successful.
PS C:> icm dc1 {w32tm /config /syncfromflags:manual /manualpeerlist:time.windows.com} The command completed successfully.
Note By using the command to resync with the time source requires Admin rights. Once I have caused the server to resync with the external time source, I will resync my local computer with the server. This command is shown here.
PS C:> w32tm /resync
Sending resync command to local computer The command completed successfully. Once I have resynced both the time server and the workstation, I use the New-TimeSpan command to monitor for any difference.
PS C:> new-timespan -Start (get-date) -end (icm dc1 {get-date})
Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : -270
Ticks : -2707415
TotalDays : -3.13358217592593E-06
TotalHours : -7.52059722222222E-05
TotalMinutes : -0.00451235833333333
TotalSeconds : -0.2707415
TotalMilliseconds : -270.7415 If I need to double-check the time source settings on the remote time server, I use the W32tm command to query the configuration. The command is shown here.
icm dc1 {w32tm /query /configuration} Join me tomorrow when I will talk about more cool Windows PowerShell stuff. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace. Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments