Skip to main content

New way to convert WMI time properties

I picked up new way to convert time that is retrieved from Get-WMIObject.  One of my past students, Zak Shupp from HP, sent me a function that we was working and it had a .NET object that I never seen before.  For those of you in a PowerShell V2 environment, you do not get to benefit from the Get-CIMInstance cmdlet.  Here is an example of the output of the same class with a focus on a DATETIME property:

PS C:\> Get-WmiObject Win32_Operatingsystem |

Select-Object -ExpandProperty InstallDate



PS C:\> Get-CIMInstance Win32_Operatingsystem |

Select-Object -ExpandProperty InstallDate


Wednesday, November 13, 2013 10:25:19 AM


The first command pulls a string of characters to represent the date and time of the operating system installation.  This is not exactly intuitive.  The last 3 digits are for the time zone.  Try explaining that one.  The second command pulls this data as a DATETIME object, which is what PowerShell cmdlets like.  To correct this with Get-WMIObject, a scriptmethod called ConvertToDateTime is provided by the Get-WMIObject cmdlet to all objects that it recovers for you.  Here is how it is used.

PS C:\> (Get-WMIObject Win32_Operatingsystem).ConvertToDateTime((Get-WmiObject Win32_Operatingsystem).InstallDate)




Wednesday, November 13, 2013 10:25:19 AM


Not cool.  Now, we will do it Zak’s way using the System.Management.ManagementTimeConverter object.

PS C:\> $OS = Get-WmiObject Win32_OperatingSystem

PS C:\> [System.Management.ManagementDateTimeconverter]::ToDateTime($OS.InstallDate)



Wednesday, November 13, 2013 10:25:19 AM


Much better! Ok, not as good as the CIM cmdlets, but Zak has simplified the process for those who need to use Get-WMIObject in their environments.  Remember, once all of your systems are at PowerShell V3 or better, start coding with Get-CIMInstance and begin to phase out Get-WMIObject.


Popular posts from this blog

How to force a DNS zone to replicate

For many implementations of DNS in a Windows environment, DNS is configured as being Active Directory integrated.  In other words, the DNS zone information is actually stored as a partition in the active directory database.  When Active Directory replicates, the zone data transfers.  For standard DNS deployments, the data is stored in a file.  You have to configure zone transfers manually in the DNS console.   The question in class was how to initiate replication manually.  Once you have properly configured a Primary and secondary DNS server and configured the Primary server to allow zone transfers, you can manually initiate a zone transfer.   Below you can see our test environment.  The image is of to RDP sessions to two different servers.  The DNS console on the left is the primary.  You can see and entry for Test2 that is not in the secondary database.  The servers are named NYC-DC2 (Primary DNS) and NYC-DC1 (Secondary DNS).  The DNS zone is named . On the se

Export Your Performance Monitor Data to Excel

Updated: 2016MAY04 To clarify when this functionality is available, you can only save the view when you are viewing a Data Collection Set.  The "live" data cannot be saved in this way. Performance Monitor in Windows Server give us the ability to see when our servers are having some issues.  Analyzing that data into something meaningful can be a problem.  You can export your data to Excel so you can better see what your performance data represents.  First collect your data. Right click the graph and select Save Data As . Change the Save as type to Text file (comma delimited)(*.csv) . Give the file a name and save it where you want to store it. Now open that file on a client with Excel installed on it.  By using excel, you will be able to present the data in a more meaningful format.

Determine which Domain Controller a client is connected to with PowerShell

When a Windows client comes online, it must find a domain controller to bind to.  Either through a static configuration or DHCP, the client will request a list of all Domain Controllers in the domain from a DNS server.  Once the list is received, the client will randomly go through the list to find a DC that will respond.  Once the client has authenticated itself with the DC, the DC will transmit the site information to the client.  The site information will contain the site name, the subnet(s) associated with that site, and any domain controllers in that site.  The client will then take a look at it’s own IP address to determine which site it is in.  From the list of DCs in the same site, it will attempt to bind to one of those DCs to receive it’s Group Policies.   You can use PowerShell and WMI to locate the domain controller that a client is connected to.   Get-WMIObject Win32_NTDomain   Look for the DomainControllerName property.