Microsoft has announced that Windows 2012 R2, System Center 2012 R2 and Windows 8.1 will be on general availability on October 18. The important point being that Windows 2012 R2 & Windows 8.1 bring PowerShell v4
If the pattern of previous releases is followed they will be available earlier through MSDN.
Pity it couldn’t have been 8 days earlier – would have made a nice birthday present
The second part of the PowerShell jump start – Tools and Scripting – was broadcast on 1 August
The recordings are now available from
The first set of recordings are still available at
I even get a mention Smile
The next chapter of AD Management in a Month of Lunches has been released to MEAP
Chapter 16 deals with Sites and Subnets
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.
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:
It builds on the information in my post including information on how the prompt changes when you enter a remote session
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.
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 )
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
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.
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
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