Search results for 'app:weblogs' matching tags 'Windows PowerShell', 'operating system', 'Brian Wilhite', and 'Scripting Guy!'

Use PowerShell to Find Last Logon Times for Virtual Workstations

Anonymous — Sun, 19 Feb 2012 06:00:00 GMT

Summary: Learn how to Use Windows PowerShell to find the last logon times for virtual workstations.

Microsoft Scripting Guy, Ed Wilson, is here. Welcome back guest blogger, Brian Wilhite. Brian was our guest blogger yesterday when he wrote about detecting servers that will have a problem with an upcoming time change due to daylight savings time. Here is a little bit about Brian.

Brian Wilhite works as a Windows System Administrator for a large health-care provider in North Carolina. He has over 15 years of experience in IT. In his current capacity as a Windows SysAdmin, he leads a team of individuals that have responsibilities for Microsoft Exchange Server, Windows Server builds, and management and system performance. Brian also supports and participates in the Charlotte PowerShell Users Group.
Twitter: Brian Wilhite

Take it away, Brian…

Several weeks ago our virtual guy asked me if there was a way to determine which virtual workstations have been recently used. I started thinking, and of course, the first place I turned was to Windows PowerShell. I did some research and found the Win32_UserProfile WMI class. However, the “minimum supported client” is Windows Vista with SP1, and the majority of our virtual workstations are running Windows XP. So the dilemma was to create a function that would provide the same type of information for computers running Windows XP and later. I evaluated the information that was returned from the Win32_UserProfile class. As you see in the following image, I indexed into the third object of the Win32_UserProfile array for brevity, and this is the information that’s available.

I wanted to provide the following information:

The computer from which the function was run against
The user account that was logged on last (security identifier or SID)
The last use time (LastUseTime)
Is the user currently logged on? (Loaded)

I’m going to use two methods to gather these four pieces of information. First, I’m going to use WMI to collect the information on computers running Windows Vista with SP1 and later. For computers running Windows Vista and earlier, I’m going to use user profile file properties and registry information to collect the needed data. We will discuss the WMI method first.

I am using the Win32_OperatingSystem WMI class to collect the build number to determine which method to use.

$Win32OS = Get-WmiObject -Class Win32_OperatingSystem -ComputerName $Computer

$Build = $Win32OS.BuildNumber

The “If ($Build -ge 6001)” is the first decision point. If the build number is 6001 and above, the script block will run.

If ($Build -ge 6001)

{

$Win32User = Get-WmiObject -Class Win32_UserProfile -ComputerName $Computer

I am using RegEx to filter the LocalService, NetworkService, and System profiles because they aren’t needed, and I am sorting by LastUseTime to pick the one most recently used.

$Win32User = $Win32User | Where-Object {($_.SID -notmatch "^S-1-5-\d[18|19|20]$")}

$Win32User = $Win32User | Sort-Object -Property LastUseTime -Descending

$LastUser = $Win32User | Select-Object -First 1

The Win32_UserProfile Loaded property determines if the user was logged on at the time the query was run. I’m casting that value into a new variable ($Loaded). I will create a New-Object with that property and value later.

$Loaded = $LastUser.Loaded

So now we’re looking at the LastUseTime property—the value is a “System.String” (20120209035107.508000+000), but I need to convert it to a “System.DateTime” object, so it’s readable, I will use the WMI ConvertToDateTime method to accomplish this.

$Time = ([WMI] '').ConvertToDateTime($LastUser.LastUseTime)

One of the things I need to do is take the SID that is collected via Win32_UserProfile and convert it to Domain\samAccountName format.

So I created a New-Object with the .NET Security Identifier Class Provider, and I specified the $LastUser.SID variable.

$UserSID = New-Object System.Security.Principal.SecurityIdentifier($LastUser.SID)

When New-Object is created with the SID value, there is a translate method that can be used to convert the SID to the Domain\samAccountName.

$User = $UserSID.Translate([System.Security.Principal.NTAccount])

Instead of using Write-Host or some string-type output, I prefer to use object-based output. The following code snippet shows the four pieces of information that I wanted to gather and return.

$UserProf = New-Object PSObject -Property @{

Computer=$Computer

User=$User

Time=$Time

CurrentlyLoggedOn=$Loaded

}

If you’ve ever created custom objects in Windows PowerShell, you know that without any special XML formatting, when you return the object, it will place the properties in an order that you may not like. To quickly remedy this, what I usually do is pipe my variable that contains the custom object to Select-Object and type the names of the properties in the order in which I want them returned.

$UserProf = $UserProf | Select-Object Computer, User, Time, CurrentlyLoggedOn

$UserProf

Now when $UserProf is returned, the following is displayed:

Now that we’ve taken care of any computer that has the Win32_UserProfile WMI class, beginning with Windows Vista with SP1, let’s take a look at those computers that do not have that WMI class. I started thinking about how to figure out the last person to log on, what time they logged on, and if they were currently logged on. I observed my profile as I logged on, and I noticed that the NTUSER.DAT.LOG file was immediately modified. This file is intermittently updated throughout the user’s session. The NTUSER.DAT.LOG is used for fault tolerance purposes if Windows can’t update the NTUSER.DAT file. Obviously, as soon as the user logs off, the file is no longer updated.

The If statement checks for the build number 6000 and below, meaning Windows Vista without SP1 and earlier.

If ($Build -le 6000)

{

To scan the user profile directories for the NTUSER.DAT.LOG, I am making the assumption that the Documents and Settings folder is residing on the system drive. I’m querying the system drive information from the Win32_OperatingSystem WMI class and isolating only the drive letter by using the Replace method. When we have that information, we can put the $Computer and system drive letter together and make a UNC path for scanning “Documents and Settings”.

$SysDrv = $Win32OS.SystemDrive

$SysDrv = $SysDrv.Replace(":","$")

$ProfDrv = "\\" + $Computer + "\" + $SysDrv

$ProfLoc = Join-Path -Path $ProfDrv -ChildPath "Documents and Settings"

$Profiles = Get-ChildItem -Path $ProfLoc

When we have all of the user profiles, we want to search for the NTUSER.DAT.LOG files. After we capture all the NTUSER.DAT.LOG in the $LastProf variable, we need to sort by the LastWriteTime property in descending order, and select the first one.

$LastProf = $Profiles | ForEach-Object -Process {$_.GetFiles("ntuser.dat.LOG")}

$LastProf = $LastProf | Sort-Object -Property LastWriteTime -Descending | Select-Object -First 1

We’ve isolated the most recent NTUSER.DAT.LOG, so I’m now making another assumption that the profile folder name will equal the UserName. By using the Replace method, I’m going to strip the “\\$Computer\<System Drive>$\Documents and Settings” off of the DirectoryName, which represents the full path of the user’s profile. I’m also going to grab the LastAccessTime and cast it to the $Time variable.

$UserName = $LastProf.DirectoryName.Replace("$ProfLoc","").Trim("\").ToUpper()

$Time = $LastProf.LastAccessTime

We are going to use the following code to extract the user’s SID from the access control entry of the NTUSER.DAT.LOG file.

$Sddl = $LastProf.GetAccessControl().Sddl

$Sddl = $Sddl.split("(") | Select-String -Pattern "[0-9]\)$" | Select-Object -First 1

Here we are formatting the SID, and assuming the sixth entry will be the user’s SID.

$Sddl = $Sddl.ToString().Split(";")[5].Trim(")")

The following code is used to convert the $UserName variable to the SID to detect if the profile is loaded via the remote registry and to compare the SID queried from the NTUSER.DAT.LOG file.

$TranSID = New-Object System.Security.Principal.NTAccount($UserName)

$UserSID = $TranSID.Translate([System.Security.Principal.SecurityIdentifier])

I felt it was necessary to compare the SID queried from the NTUSER.DAT.LOG file and the UserName extracted from the profile path, to ensure that the correct information is being returned.

If ($Sddl -eq $UserSID)

{

If the SIDs are equal, I’m going to open the HK_USERS hive and set the $Loaded variable to True if SubKeys contains the SID and to False if it isn’t present. If the user’s SID is present in the HK_USERS hive, the user is currently logged on.

$Reg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey([Microsoft.Win32.RegistryHive]"Users",$Computer)

$Loaded = $Reg.GetSubKeyNames() -contains $UserSID.Value

Because I have the UserName and no DomainName, I’m going to convert the SID to Account so that it will return in the DOMAIN\USER format.

$UserSID = New-Object System.Security.Principal.SecurityIdentifier($UserSID)

$User = $UserSID.Translate([System.Security.Principal.NTAccount])

}#End If ($Sddl -eq $UserSID)

If the SIDs are not equal, I will set $User to the profile folder name and set $Loaded to “Unknown” because I could not determine if the SID was 100% accurate.

Else

{

$User = $UserName

$Loaded = "Unknown"

}#End Else

Here I am creating and formatting the custom object, like we discussed earlier for the Windows Vista with SP1 and later script block.

#Creating the PSObject UserProf

$UserProf = New-Object PSObject -Property @{

Computer=$Computer

User=$User

Time=$Time

CurrentlyLoggedOn=$Loaded

}

$UserProf = $UserProf | Select-Object Computer, User, Time, CurrentlyLoggedOn

$UserProf

I setup this function to accept piped input for the ComputerName parameter. It will also accept an array of ComputerNames. So when we run Get-Lastlogon, we’ll be able to determine what workstations haven’t been used in a while, as shown in the following image.

~Brian

Thank you Brian, this is a most useful and interesting script. The complete script can be found at the Script Center Repository.

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

Use PowerShell to Save Time with Win32_TimeZone and DST Time Changes

Anonymous — Sat, 18 Feb 2012 06:00:00 GMT

Summary: Write a Windows PowerShell function to determine the status of time changes to daylight savings time.

Microsoft Scripting Guy, Ed Wilson, is here. At the Windows PowerShell User Group meeting in Charlotte, North Carolina, Brian Wilhite talked about a few of his scripts during the script club. I said, “Dude, that is cool, and I immediately challenged Brian to share his scripts with us. The result is two excellent guest postings. Here is the first one.

Here’s Brian…

Just prior to the latest time change in the fall, I was asked to run a time verification script on all of our computers running Windows Server. Typically, this was done after the time change, between 1:00 AM and 2:00 AM. Being an IT Guy, I’m used to long days and/or long, late nights, but I thought to myself, “I wonder if I can be proactive in knowing which servers may have problems making the change this year.” So I researched, and found the Win32_TimeZone WMI Class and all the goodness therein. Here is some of what I found:

Get-WMIObject –Class Win32_TimeZone

DaylightDay : 2

DaylightDayOfWeek : 0

DaylightMonth : 3

DaylightName : Eastern Daylight Time

Description : (UTC-05:00) Eastern Time (US & Canada)

StandardDay : 1

StandardDayOfWeek : 0

StandardMonth : 11

StandardName : Eastern Standard Time

So…

Like I always do when I evaluate WMI classes, I performed a BING search on MSDN Win32_TimeZone.

After I reviewed all of the information there, specifically DaylightDay, DaylightDayOfWeek, etc., I determined that I could, in fact, proactively identify servers that could have time change issues on the day of the time change.

This excerpt from the MSDN website sums it all up:

If the transition day (DaylightDayOfWeek) occurs on a Sunday, then the value "1" indicates the first Sunday of the DaylightMonth, "2" indicates the second Sunday, and so on. The value "5" indicates the last DaylightDayOfWeek in the month.

I took this information and started thinking, “I can write a function that will gather this information and report what it finds.” So here’s what I did…

First, I created the framework for an advanced function. It contains the usual items, such as: CmdletBinding, defining parameters, setting up the Begin, Process, Try, Catch, and End Script blocks. This is shown in the following image.

Next, I started thinking of all the data that I wanted to capture. I know I will need the Win32_TimeZone WMI class. Because in the past, we always checked for current time, I will also query the Win32_LocalTime. Therefore, here is the start of the processing part of the Get-DSTInfo function:

As you see in the previous image, I casted the $LocalTime variable as a DateTime object by passing it a string that is comprised of variables made up from the Win32_LocalTime WMI class. I will use this later to create a custom PSObject, which will allow you to treat this property as a DateTime object, if needed.

I also captured the WMI class that’s going to gather all the data to make the magic happen, the Win32_TimeZone class. You may have noticed the switch statement for the $TimeZone.DaylightDay property. Because the value is numeric and not “display friendly,” I set up several switch statements. They are shortened for brevity, but you get the idea:

Switch ($TimeZone.DaylightDay)

{

1 {$DSTDay = "First"}

2 {$DSTDay = "Second"}

#From 1 to 5 signifying the First through Last week in the month.

}

Switch ($TimeZone.DaylightDayOfWeek)

{

0 {$DSTWeek = "Sunday"}

1 {$DSTWeek = "Monday"}

#From 0 to 6 to signify the days of the week.

}

Switch ($TimeZone.DaylightMonth)

{

1 {$DSTMonth = "January"}

2 {$DSTMonth = "February"}

3 {$DSTMonth = "March"}

#From 1 to 12 to signify months of the year.

}

OK. So consider the following properties of the $TimeZone object, which is an instance of Win32_TimeZone.

$TimeZone.DaylightDay = 2

$TimeZone.DaylightDayOfWeek = 0

$TimeZone.DaylightMonth = 3

These property values will mean the “spring ahead.” The time change will occur on the “Second (2) Sunday (0) of March (3)”. The same thing holds true with the $TimeZone.StandardDay, $TimeZone.StandardDayOfWeek, and $TimeZone.StandardMonth—but obviously, they will have different values.

When all of my switch statements were setup (six in total), I created several objects depending on what parameters were passed when running the function. The two parameters that I defined were -Standard and -Daylight. Neither parameter is mandatory because running the function without parameters will return both Standard and Daylight time change information in the form of a PSObject for the local host that is stated. Here is the If statement that I used to accomplish neither parameter being passed:

If ((-not $Standard) -and (-not $Daylight))

{

$STND_DL = New-Object PSObject -Property @{

Computer=$Computer

StandardName=$STDTime

StandardDay=$STDDay

StandardDayOfWeek=$STDWeek

StandardMonth=$STDMonth

DaylightName=$DayTime

DaylightDay=$DSTDay

DaylightDayOfWeek=$DSTWeek

DaylightMonth=$DSTMonth

CurrentTime=$LocalTime

}#End $DL New-Object

$STND_DL = $STND_DL | Select-Object -Property Computer, StandardName, StandardDay, StandardDayOfWeek, StandardMonth, DaylightName, DaylightDay, DaylightDayOfWeek, DaylightMonth, CurrentTime

$STND_DL

As you may have noticed, I did something pretty cool. If you have played with custom objects in Windows PowerShell, you know that they don’t always display the properties the way you would like them to. So, I piped my custom PSObject ($STND_DL) to the Select-Object cmdlet to display the object properties in logical order as you read it—something that makes logical sense to a variable.

This is what you get when you run the function; the output is an object that you can have your way with:

Yes, you read that right, 3:49AM. Like I said, I’m not a stranger to long late nights—after all, I am an IT Guy.

Getting back to the topic…

You could also pipe computer names to Get-DSTInfo, something like the following:

Get-ADComputer –Filter * | Select –Expandproperty Name | Get-DSTInfo | Export-Csv –Path C:\TimeZoneInfo.csv

This would gather all the computers in your domain and run the Get-DSTInfo function against them, then export the findings to a .csv file. The way you would read the object output is that the time change would occur the First Sunday of November and Second Sunday of March.

This function allowed me to proactively review the time change information of all 1500+ servers in our domain. The great thing is that I did find a few that did not have the correct time change patch installed, and I was able to remediate that before it became an issue when the clocks turned back last fall.

Thanks for listening to me ramble on about my simple but useful function. Happy PowerShelling!

~Brian

Thank you, Brian. The full script can be found on the Script Center Repository.

Ed Wilson, Microsoft Scripting Guy