Monthly Archive


Monthly Archives: April 2009

PowerShell for DBAs

Chad has a very interesting post on “The Value Proposition of PowerShell to DBAs” -!EA42395138308430!347.entry where he discusses the results of a poll of DBAs regarding PowerShell.

On initial reading it is a bit depressing for the PowerShell community as only 20% of respondents were using PowerShell. However, it gets a bit more cheerful if you consider that another 40% were planning to – I wonder how that will change as SQL Server 2008, with PowerShell built in, becomes more widespread.

Chad gives a number of benefits of learning PowerShell. I think that one of the most compelling reasons si that it will be a part of all future Microsoft products – look what is happening with Windows 2008 R2 – an provides a common automation platform across your Microsoft estate. PowerShell gives us the possibility of integrated, automated administration across you servers and applications.

Gives us more time for PowerShel space invaders

Technorati Tags: PowerShell

Windows 2008 R2 PowerShell for AD

Back in this post!43CFA46A74CF3E96!2214 we looked at creating OUs using the AD cmdlets in Windows 2008 R2. 

We may want to look at the OUs we have in our domain

Get-ADOrganizationalUnit -Filter {Name -like "*"} | Format-Table name, distinguishedname -AutoSize

or we may want to search for a user

Get-ADUser -Identity Richard

As regular readers will be aware I am a big fan of the Quest AD cmdlets – so I wanted to see how the Win08R2 cmdlets compared.

Creating a new user is relatively straight forward

New-ADUser -SamAccountName "fdrake" -Name "DRAKE Francis" -AccountPassword (ConvertTo-SecureString -AsPlainText "Passw0rd!" -Force) -Enabled $true -ChangePasswordAtLogon $true -GivenName "Francis" -Surname "Drake" -Path "OU=England,OU=AllUsers,DC=grayson,DC=test"

I like the ability to enable the account at the same time as we create it.  I don’t like the convolutions with the password I would probably look to move that part to a separate statement and use a variable as the value for the cmdlet if I was bulk creating users.   For creating users the two sets of cmdlets are comparable. The differences are more or less balanced.  I would be happy using either.

Searching for users is another matter.  These variants work

Get-ADUser -Filter {Name -like "*drake*"}
Get-ADUser fdrake

Some other options such as using the name don’t.  My feeling is that the Quest tool is better at this aspect of working with AD.

The AD provider I find very clumsy at first impression.  Using the distinguished name involves a lot more work than seems necessary. I’ve used the PowerShell Community Extensions provider in the past and the navigation in that does seem neater.  However, the advantage of the R2 provider is that I get access to the configuration and schema partitions as well so maybe it isn’t all bad. Need to do some more work with this one.

One feature that I am excited about in R2 is the recycle bin for AD.  The forest & domain level need raising to Windows 2008 R2 and then we can run

Enable-ADOptionalFeature 'Recycle Bin Feature' -Scope Forest -Target 'grayson'

where the target is the name of the forest.

Next job is to look at using the recycle bin.

PowerShell Modules and Exchange 2010 prerequisites

PowerShell v2 introduces the concept of modules – these can be scripts or dlls (think snapin from V1).  The modules that are loaded into PowerShell can be viewed by using get-modules.  When you install roles\functions onto Windows 2008 R2 the PowerShell functionality is delivered as modules.  Use

Get-Module -ListAvailable | Select Name

To see the available modules.  Most modules appear to be 32bit only – at least in the beta

Exchange 2010 delivers functionality as snapins

PS C:\Scripts> Get-PSSnapin -Registered

Name        : Microsoft.Exchange.Management.PowerShell.E2010
PSVersion   : 1.0
Description : Admin Tasks for the Exchange Server

Name        : Microsoft.Exchange.Management.PowerShell.Setup
PSVersion   : 1.0
Description : Setup Tasks for the Exchange Server

Name        : Microsoft.Exchange.Management.Powershell.Support
PSVersion   : 1.0
Description : Support Tasks for the Exchange Server

One of the modules is for Server Manager

Import-Module ServerManager

Expect to see error messages about loading extended type data if you have other modules already loaded.  As long as the message ends with  File skipped because it was already present from "Microsoft.PowerShell".    then we are good to go.

Server Manager gives us three cmdlets

Get-Command -Module ServerManager


Get-Windowsfeature will display all of the features with an indication of which are installed. The display name and the name by which we access the feature are displayed

Display Name                                            Name
------------                                            ----
[ ] Active Directory Certificate Services               AD-Certificate
    [ ] Certification Authority                         ADCS-Cert-Authority
    [ ] Certification Authority Web Enrollment          ADCS-Web-Enrollment
    [ ] Online Responder                                ADCS-Online-Cert
    [ ] Network Device Enrollment Service               ADCS-Device-Enrollment
    [ ] Certificate Enrollment Web Service              ADCS-Enroll-Web-Svc
    [ ] Certificate Enrollment Policy Web Service       ADCS-Enroll-Web-Pol
[X] Active Directory Domain Services                    AD-Domain-Services
    [X] Active Directory Domain Controller              ADDS-Domain-Controller
    [ ] Identity Management for UNIX                    ADDS-Identity-Mgmt
        [ ] Server for Network Information Services     ADDS-NIS


Exchange 2010 has a number of prerequisite features that need installing.  Unfortunately the documentation gives them using ServerManagerCmd.  This will never do.  Ok the PowerShell equivalent is

Add-WindowsFeature -Name RSAT-ADDS-Tools, RPC-over-HTTP-proxy, NET-HTTP-Activation, Web-Dyn-Compression, Web-Windows-Auth, Web-Digest-Auth, Web-Basic-Auth, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-ISAPI-Ext, Web-Server -Concurrent

If required the features can be installed individually. The PowerShell remoting features enable us to perform these actions on remote servers as well as the local server. 

The module system in PowerShell v2 makes dynamic configuration of your PowerShell environment much simpler and more flexible

Exchange 2010

Exchange 2007 has been a poster child for PowerShell.  The GUI is layered over PowerShell cmdlets and everything can be performed at the PowerShell prompt.  There are some activities that can only be performed at using PowerShell.

The Exchange 2010 beta became available this week.  It has lots of good stuff for Exchange people but the important news is that the use of PowerShell remains – in fact it gets better.

Exchange 2010 beta requires PowerShell v2 CTP3.  This gives us access to the remoting and asynchronous processing capabilities – think mailbox provisioning as a background task. 

Put Exchange PowerShell together with the PowerShell functionality in Windows 2008 R2 and we really will be into a PowerShell world.

I will be posting some examples of the two together as soon as my virtual machine finishes building – its a sloooooooow process.

Technorati Tags: PowerShell,v2,Exchange 2010

PowerShell goes to work

I was working this past weekend. PowerShell saved me lots of time and effort for instance:

  • use the Quest cmdlets to move subnets between sites.  One by hand isn’t too bad but by the time you have tens of the things it gets tedious.
  • moving DCs between sites
  • checking replication is working properly & forcing a replication so I can test (both those scripts are in my book)
  • checking the contents of GPOs
  • adding accounts to AD & local groups
  • etc

The more you use it the more you find to do with it – I haven’t quite got to the point of 2+2 in PowerShell but its only a matter of time  😉

Technorati Tags: PowerShell

Interesting Posts

A couple of interesting posts I came across.

First up is a way to work with System Center Configuration Manager using PowerShell.

Some of the System Center family have PowerShell support but not Config Manager.  Hopefully this will be corrected in the next release.

The second post was from Jonathan – a UK User Group member – on working with the registry and using the functions supplied by PowerShell MVP Shay Levy -



One task I had to do a a few times recently is track down which GPOs had a particular setting enabled.  If you are working in an environment with a signifcant number of GPOs this can be a tedious task.
The easier way - use the SDMSoftware GPMC cmdlets to create an XML file for each GPO. You can then use select-string to search through the GPOs for the setting you need.  The real advantage that searching is so quick that you can have multiple attempts to refine your search and still do it much quicker than checking manually in GPMC.

Modules in Windows 2008 R2

One thing I have noticed with my quick dip into Windows 2008 R2 is that the extra functionality is all loaded as modules.  This is a new area in PowerShell v2 that enables you to load\unload functionality from your PowerShell sessions.  Modules can be "libraries" of functions as I showed in a recent set of posts or they can be compiled dlls with cmdlets.  The good thing about compiled modules is that you don't have to register them in the same way you do snapins.  Much easier to work with. I would expect snapins to disappear in (much) future version of PowerShell (!!!! My opinion only !!!!) as modules do the same role role and more.
There are a number of default modules that are available when you first install R2 including:
  •  File Transfer
  • PSdiagnostics
  • TroubleShootingPack
  • AD Rights Management

As you add functionality - such as running dcpromo other modules are installed.  You only get the PowerShell modules for the functionality you install.  It appears, at least in the beta, that even though Windows 2008 R2 is 64 bit - most of the PowerShell functionality is 32bit.  Compare the modules folder in the two PowerShell install directories.


Windows 2008 R2 – OU

One of the big benefits of Windows 2008 R2 is the fact that PowerShell v2 is installed by default and that AD can be administered by PowerShell.  There are 76 AD cmdlets and an AD provider.  We’ll start by looking at the cmdlets.

Organizational Units are the subdivisions with a domain.  We can easily create a new OU.

New-ADOrganizationalUnit -Name "AllUsers" -ProtectedFromAccidentalDeletion $true

The default location is to create OUs in the root of the domain.  I really like the ability to set Protection from Accidental Deletion on when I create the OU.

If I want to create a child OU I just need to add the path to the OU in which I want to create the OU.

New-ADOrganizationalUnit -Name "RemoteUsers" -Path "OU=AllUsers,dc=grayson,dc=test" -ProtectedFromAccidentalDeletion $true

We also have Get-, Set- and Remove-OrganizationalUnit cmdlets.

The Get returns a Microsoft.ActiveDirectory.Management.ADOrganizationalUnit object – NOT a directory entry object.  We need to use the other cmdlets to work with the OU.

PowerShell in Practice- Chapter 11

Chapter 11 on AD topology has been posted on Mannings early access site -