PowerShell for Windows Admins


July 5, 2013  12:56 PM

Excel–named range

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

To create a named range in an Excel spreadsheet

$xl = New-Object -ComObject ‘Excel.Application’
$wkbk = $xl.Workbooks.Add()
$sheet = $wkbk.WorkSheets.Item(1)
$range = $xl.Range(“A1″, “D4″)
$range.Name = “Test”

Just to show how to work with named ranges

$range2 = $xl.Range(“Test”)
$range2.Borders.Color=0
$range2.Borders.ColorIndex=26
$range2.Borders.Weight=2
$xl.visible = $true

July 4, 2013  12:14 PM

PowerShell help RSS feed

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

The updatable help in PowerShell 3.0 caused a lot of confusion when that version first shipped. The help files have been updated periodically since 3.o shipped but its always been difficult finding out when they’ve been updated.

That’s changed

There is now an RSS feed that provides information on updates to the help files. Written by the team that creates the PowerShell help files you can now keep up to date with changes.

Subscribe at http://sxp.microsoft.com/feeds/msdntn/PowerShellHelpVersions.


July 3, 2013  2:12 PM

Office365 ate my RSS feeds

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

Just been puzzling out why I haven’t been getting any RSS feeds for a few days. Looks like when I hooked up my Office365 account to Outlook it took out all the RSS feeds. Fun time to come putting them back


July 2, 2013  12:58 PM

New-mailbox oddity

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

I’ve been doing a lot with Exchange recently and found an interesting quirk.

If you use the New-mailbox cmdlet with the –PrimarySMTPaddress parameter the mailbox doesn’t get email address policies applied.

You need to use set-mailbox to turn policy application on – after the mailbox has finished creating


June 30, 2013  3:57 PM

Need for speed?

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

How fast does an admin script have to be?

My opinion has always been that if its significantly faster than me doing the same task by hand then that’s more than fast enough.

Is my time better spent developing new functionality compared to shaving a few % off the execution time of my scripts? If the script is long running its either because I’m hitting a lot of data or I’m hitting a lot of machines. In both cases the script itself probably isn’t the bottle neck and if its that long an operation I can always run it over night. A mass mailbox migration may run over a long weekend!

Speed is relative and as long the script delivers its results in an acceptable time frame the absolute time doesn’t really matter.


June 30, 2013  1:52 PM

Using localhost

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

When creating functions that accept a computer name as a parameter you will often see this syntax

param (
[string]$computername = ‘localhost’
)

This is designed to give a default value in the event of a value not being passed. That’s a good idea if there is a sensible, safe, value you can use and you aren’t making the parameter mandatory.

The only objection I have is to using ‘localhost’

I have seen this break down – for instance if you try to use the System.DirectoryServices.AccountManagement classes against accounts on the local machine. On the other hand you have to use it when dealing with the WSMAN provider.

Just be aware that ‘localhost’ can cause issues


June 28, 2013  11:39 AM

Refreshing values

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

The CIM cmdlets in PowerShell v3 enable you to refresh the data in the object. Try this:

$p = Get-CimInstance -ClassName Win32_PerfFormattedData_PerfOS_Processor
$p | Get-CimInstance | select percentprocessortime

$p will remain unchanged. Another use for this is monitoring processes – you could check on CPU utilisation


June 27, 2013  3:50 PM

PowerShell presentations

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

Jeffrey Snover and Jason Helmick will be presenting by webcast 18 July 9am – 5pm (PDT) on “Getting started with PowerShell”

Details from http://powershell.org/wp/2013/06/27/a-special-presentation-on-getting-started-with-powershell/

A follow up day of presentations will occur in August delving further into scripting, automation and building tools


June 27, 2013  3:44 PM

Writable properties for a WMI class

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

Do you know how to discover which properties on a WMI class, and therefore a WMI instance, can be modified?

Get-CimClass from the PowerShell 3.0 CIM cmdlets is the answer:

$class = Get-CimClass -ClassName win32_volume
$class.CimClassProperties

The last command returns all of the properties in this format

Name : Description
Value :
CimType : String
Flags : Property, ReadOnly, NullValue
Qualifiers : {read}
ReferenceClassName :

Name : DriveLetter
Value :
CimType : String
Flags : Property, NullValue
Qualifiers : {read, write}
ReferenceClassName :

Notice the first one has a Flag of ReadOnly and the second one has a Qualifier of write. So the question becomes how can you filter on those two items?

If you run something like this:

$class = Get-CimClass -ClassName Win32_Volume
$class.CimClassProperties |
foreach {
if ($psitem | select -ExpandProperty Qualifiers | where Name -eq ‘write’){$psitem}
if (($psitem.Flags -split ‘, ‘) -notcontains ‘Readonly’) {$psitem}
}

You will see that some properties may not be Readonly but also aren’t writable such as:

Name : NumberOfBlocks
Value :
CimType : UInt64
Flags : Property, NullValue
Qualifiers : {MappingStrings}
ReferenceClassName :

In that case we need just the writable properties

Get-CimClass -ClassName Win32_Volume |
select -ExpandProperty CimClassProperties |
foreach {
if ($psitem | select -ExpandProperty Qualifiers | where Name -eq ‘write’){$psitem}
}

This brings the results down to three properties DriveLetter, IndexingEnabled, Label

The first and last I expected – IndexEnabled was new to me


June 27, 2013  1:58 PM

Automation tools?

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

In this post http://richardspowershellblog.wordpress.com/2013/06/23/opinionautomate-or-suffer/ I talked about the need for admins to learn to automate. A couple of comments brought up the need for tools to create our automation scripts.

I remember the 4th generation languages of the late 1980s & 1990s. The promised that you wouldn’t have to code – just drag & drop onto the designer, answer a few questions and your application was created.

The worked great – as long as you wanted a cookie cutter application that only had limited functionality and was dog slow.

Automating code generation, in my experience, is a hard task. Compare the PowerShell snippets that come out of AD Admin center or the Exchange Management Console with what you actually write. They are usually very verbose and include lots of stuff you don’t need.

If someone can create a tool that creates my code for me, with minimal input on my side then I’ll sign up for it. I suspect it’ll be a long time coming. Until then happy coding.


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: