Enterprise Admins.org

This is a very simple post, but it shows how to make the Powershell title bar contain useful information. By default the Powershell title contains the path to the powershell.exe file — here is an example:

To make this more useful, I’ve added a line to my powershell profile that looks like this:

$host.ui.rawui.WindowTitle="PowerShell $($psversiontable.psversion) as $($env:username)"

*Note: all this text should appear on the same line in your profile.

This change adds the Powershell version number and running user name to the title bar. This is useful in my environment because I often have the need to run Powershell as a different user. Here is an example of the update:

I placed this in the all users profile located here:

%windir%\system32\WindowsPowerShell\v1.0\profile.ps1 

This profile is machine specific and executes anytime you open a powershell console for any user. While you have the profile open, I have one more time saving suggestion. If you use the Send-MailMessage cmdlet often, add this line:

$PSEmailServer = "smtp-relay.mydomain.local"

With this variable specified, you no longer need the “-SmtpServer” attribute to send a message — this global variable will automatically be used.

Hope this helps!

In most of my Powershell scripts I make use of the PSCustomObject to store results. The example I first learned (and use all the time) looks just like this:

$item = "" | Select Name, RAM, CPU
$item.Name = "blah"
$item.Ram = 4096
$item.Cpu = 1
$item

In the above example, you create a blank PSCustomObject on line 1 which has Name, RAM and CPU placehoders. Then on lines 2 through 4 you assign values to each attribute. Finally on line 5 you do something with the variable $item. In the above example, the contents of the $item variable are displayed onscreen. Normally you’d see something like $myreport += $item which stores the new item in a collection called $myreport.

The problem is adding an additional attribute to your object requires two steps — first, you must declare the attribute on line 1 and then assign something to the attribute after it is declared. For example, if I wanted to add PowerState to my report, I would have to add “, PowerState” on the first line. If you forget, which happens to me all the time, you get this error:

$item.PowerState = "PoweredOff"
Property 'PowerState' cannot be found on this object; make sure it exists and is settable.
At line:1 char:7
+ $item. <<<< PowerState = "PoweredOff"
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : PropertyAssignmentException

I recently found a new example that I like a lot better. Here is an example:

$item2 = new-object -type PSObject -Property @{
	Name = "blah"
	RAM = 4096
	CPU = 1
}
$item2

In the above example, attributes are created as needed, removing the need to pre-define them on the first line of the script. This method removes the need to specify "$item." for each attribute, making the code easier to read/maintain/support.

This is a very simple example, but I hope others find it useful.

I have been working on various scripts that populate information into a SQL table. The other day I was attempting to see how long some of these tables took to populate. I could have updated the PowerShell script to include some Measure-Command information, but then I’d have to re-execute my tasks and see how long they took to run. Since I already had all of the information populated into a table, and each row had a time stamp of when the data was entered, I could just use a T-SQL select statement to get the run time data I wanted.

SELECT CAST( (MAX(dataCollected) - MIN(dataCollected)) as time) as TotalRunTime, COUNT(*) as RecCount FROM tblTestInserts WHERE collectionID = MAX(collectionID)

The above example looks at two columns in my table. The first column (dataCollected) is of the datetime type and has a default binding of GetDate() — so it is automatically populated with the SQL Servers date and time every time a record is inserted. The second column (collectionID) is an integer that is calculated each time I execute the script — inside of powershell I select the maximum value of this column and then add 1. This provides a way know how many times the task has been executed and which data is the most current.

This gave me exactly the information I was looking for without needing to modify my PowerShell script and re-run the collection. It also allows me to compare current runs to previous runs (by changing the value of the collectionID in the WHERE clause). I can also be more specific…I can add an ‘AND’ to the where clause and see how long a specific part of the collection took to run.

In a future post I plan to share how I was able to take a vbscript that took 8 hours to complete condense it into a 28 minute execution time powershell script. (Here is a preview of the magic sauce — Group-Object -Property DN -AsHashTable -AsString)