PowerShell for Windows Admins

August 13, 2013  2:30 PM

Finding the typo

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

A project I’m working on involves 1000s of lines of code, across numerous modules and folders. When I make changes, like everyone else, I sometimes mistype a command. When your system throws an error and its in nested several levels deep in your code and you’re not sure where it is – who you going to call?

Unfortunately, Ghostbusters can’t help you. But PowerShell can help. I’d type [swtch] instead of [switch]. Nice easy way to find the spelling mistake. Open a PowerShell prompt in the top folder and

Get-ChildItem -Recurse -File | Select-String -Pattern “[swtch]” –SimpleMatch

You will get the file and line number containing the typo. Simple.

August 12, 2013  3:38 PM

More prompts

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

In this post http://msmvps.com/blogs/richardsiddaway/archive/2013/07/21/fun-with-prompts.aspx I showed some of the things you can do to change the prompt in PowerShell. I now use £> as my prompt.

What I hadn’t realised is that there is a PowerShell help file:

get-help about_Prompts

It builds on the information in my post including information on how the prompt changes when you enter a remote session

August 12, 2013  1:48 PM

Active Directory Cookbook 4th Ed

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

The Active Directory Cookbook (O’Reilly ISBN: 978-1-449-36142-6) has been a constant resource for me since the first edition covering Windows 2003. I plundered the book for a lot of my early forays in scripting AD. The cookbook supplied answers using as many as possible of the GUI tools, command line tools and scripts.

In those days VBscript was the language we had to use though a couple of scripts in other languages crept into the book. The third edition, covering Windows 2008, finally brought PowerShell into the book. VBScript was still the predominant scripting language. The GUI and command line tools are still present. The PowerShell scripts were written using either the Quest AD cmdlets or by scripting using the .NET classes and the [adsi] & [adsisearcher] accelerators.

The fourth edition covers Windows 2012. PowerShell is now the standard scripting language – using the Microsoft cmdlets where possible and the approperiate .NET classes to fill in the gaps. VBscript is more or less removed. The command line tools and the GUI options still remain.

The book runs to 830 pages and which is a decrease from the third edition but it appears that is mainly due to the removal of the wordy VBSript examples.

The book covers the whole range of AD activity – users, groups, OUs, domain & forests, trusts, domain controllers, computers, GPO, schema, sites, replication, dns (the new DNS cmdlets in Windows 2012 are show cased), security, logging, backup, ADLS, ADFS, Exchange 2013 and FIM.

With over 465 recipes in the cookbook it covers most of the situations you are likely to meet.

A few minor cautions are needed. Firstly, the individual recipes are just that individual. If you want to create a user – you get an example. If you want to add a user to a group – you get an example. If you want to create a user and add to a group you need to work out how to combine the two scripts.

Secondly, the PowerShell examples aren’t always as good as they could be. They work and will get the job done but don’t always conform to best practice.

Thirdly, you need to learn PowerShell somewhere else. This book won’t teach you and to be fair it doesn’t and shouldn’t try. The cookbook is a domain specific resource.

For the next edition I would recommend dropping the command line tools where there is a PowerShell option. Those tools will eventually disappear. Use PowerShell so you can integrate all of your Windows automation work.

This is a book that I still refer to – even if its just to check some odd AD related fact – and expect to continue to refer to as long as I’m automating AD administration tasks. I can’t recommend this book enough. Get yourself a copy – you won’t regret it.

August 11, 2013  3:33 PM

Time Spans

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

I’ve been using Search-ADaccount a lot recently. One of the options is to input a timespan to determine for far back in time to search e.g. for accounts that have been inactive for 90 days

The cmdlet takes a string that can be turned into a timespan. if you look at the documentation the data type is a Timespan.

To search for accounts that have been inactive for 90 days

Search-ADaccount –AccountInactive –TimeSpan “90:00:00:00”

Alternatively, if you can’t remember the timespan structure

Search-ADaccount –AccountInactive –TimeSpan (New-TimeSpan -Days 90 )

August 11, 2013  1:56 PM

WMI and Trusts

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

When you install AD on a machine you get the MicrosoftActiveDirectory WMI namespace as well. This namespace was deprecated in Windows 2012 but while it is still available there are few useful things we can do with it. Even with my fondness of WMI I’m not suggesting moving to using WMI wholesale for AD admin but one of the more useful things is testing a trust’s status.

PS> Get-CimInstance -ClassName Microsoft_DomainTrustStatus -Namespace root\MicrosoftActiveDirectory |
select Flatname, Trust*

Flatname : SPHINX
TrustAttributes : 8
TrustDirection : 3
TrustedDCName :
TrustedDomain : sphinx.org
TrustIsOk : False
TrustStatus : 1355
TrustStatusString : The specified domain either does not exist or could not be contacted.
TrustType : 2

The error messages are because the VM hosting the remote domain is switched off. If you want a quick test of your trust status this is a good way.

August 7, 2013  1:59 AM

Time oddity

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

I was looking for a test of time synchronisation on domain controllers and knew that the .NET domain controller object held a system property. So, I cam up with this

$dom = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
$dom.DomainControllers | Format-Table Name, CurrentTime

What I didn’t realise was that the CurrentTime given by this object reads GMT not your local time. OK, technically its UTC but as I live in the UK its GMT 🙂

When you are testing for time synchronisation all you want is differences so the absolute time doesn’t matter so much. If you need the system time as local time

Get-CimInstance -ClassName Win32_OperatingSystem | select LocalDateTime

will find it for you

July 31, 2013  3:04 PM

Pure PowerShell–the great debate

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

One of the outcomes of the Scripting Games is a series of debates on powershell.org regarding things that were noticed during the games. The latest is on using “pure” powershell as opposed to adding .NET, COM, utilities and whatever comes to hand


July 31, 2013  1:33 PM

PowerShell Jump Start recordings

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

The records of the PowerShell Jump Start from two weeks ago are now available.

9 sessions on PowerShell 3.0 delivered by Jason Helmick and Jeffrey Snover.


It doesn’t get any better than this.

July 30, 2013  3:28 PM

drive letter functions

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

Have you ever looked at the functions available to you in PowerShell?

Get-ChildItem function:

shows the list of functions currently available in your PowerShell session.

function: is a PowerShell drive. Other drives are available:

£ Get-PSDrive

Name Used (GB) Free (GB) Provider Root
—- ——— ——— ——– —-
Alias Alias
C 103.58 129.21 FileSystem C:\
Cert Certificate \
D .03 .06 FileSystem D:\
E FileSystem E:\
Env Environment
F FileSystem F:\
Function Function
Variable Variable

These drives are created by PowerShell providers – functionality that exposes data stores as if they were file systems. Other providers include AD, SQL Server and IIS if you have those installed.

The function drive enables you to work directly with functions. You can view their details:

£ get-command c: | fl *

PSPath : Microsoft.PowerShell.Core\Function::C:
PSDrive : Function
PSProvider : Microsoft.PowerShell.Core\Function
PSIsContainer : False
HelpUri :
ScriptBlock : Set-Location C:
CmdletBinding : False
DefaultParameterSet :
Definition : Set-Location C:
Options : None
Description :
Verb :
Noun :
HelpFile : System.Management.Automation.dll-Help.xml
OutputType : {}
Name : C:
CommandType : Function
Visibility : Public
ModuleName :
Module :
RemotingCapability : PowerShell
Parameters : {}
ParameterSets : {}

In this case the information is minimal because all the function does is set your location to the c: drive.

The important part is that you can investigate functions as you will see later

July 30, 2013  2:04 PM

Is PowerShell too big?

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

I was thinking the other day about the differences between PowerShell v1 and the new v4 we’ll be getting soon. There is so much in PowerShell that its very difficult to be an expert in aspects.

Think about these topics for a moment:

PowerShell pipeline
Error handling and debugging
Extensible type System
PowerShell remoting
PowerShell jobs
Advanced functions
CIM sessions
Scheduled jobs
Desired State Configuration
And all of that is before you start adding in the cmdlets for administering specific parts of your environment – AD, Exchange, SQL Server, SharePoint, DNS, DHCP, networks, backup etc etc etc.

PowerShell has got to the point where you can’t expect to be an expert in every facet. Have a working knowledge of as much as possible but specialise where it will help you do your job.

That’s why it took three of us to write PowerShell in Depth!

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: