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

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_NTDomainLook for the DomainControllerName property.

Test to see what that data type of a value is in PowerShell

PowerShell has a comparison operator called –is.  The –is operator simply response True or False when you use it to verify the data type of a value.  The valid data types in PowerShell are:
[string]    Fixed-length string of Unicode characters
[char]      A Unicode 16-bit character
[byte]      An 8-bit unsigned character
[int]       32-bit signed integer
[long]      64-bit signed integer
[bool]      Boolean True/False value
[decimal]   A 128-bit decimal value
[single]    Single-precision 32-bit floating point number
[double]    Double-precision 64-bit floating point number
[DateTime]  Date and Time
[xml]       Xml object
[array]     An array of values
[hashtable] Hashtable object

Below is a script that will use –is to test some values.
$String="Hello"$Boolean=$True$Int=15Write-Host"Test for string"$String-is [String] $Boolean-is [String] $Int-is [String] Write-Host" "Write-Host"Test for Boolean"…

Where did a User’s Account Get Locked Out?

Updated: May 15, 2015
When this article was originally published, two extra carriage returns were add causing the code to malfunction.  The code below is correct.  

My client for this week’s PowerShell class had a really interesting question. They needed to know where an account is being locked out at. OK, interesting. Apparently users hop around clients and forget to log off, leading to eventual lock out of their accounts. The accounts can be unlocked, but are then relocked after Active Directory replication.
This problem is solved in two parts. The first one is to modify the event auditing on the network. The second part is resolved with PowerShell.
The first part involves creating a group policy that will encompass your Domain Controllers. In this GPO, make these changes.
Expand Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Advanced Audit Policy Configuration \ Audit Policies \ Account ManagementDouble click User Account ManagementCheck Configure the f…