Open a Socket!

If you’re creating contact objects in Active Directory the Exchange cmdlets New-MailContact, Set-MailContact and Set-Contact are usually sufficient.  On the other hand I haven’t found a way using these cmdlets to set all the attributes that I might need.  For example, the “description” attribute doesn’t appear to feature anywhere.

Things have obviously changed with the AD Powershell Provider and associated cmdlets in Windows Server 2008 R2, but here’s a script to bulk create contacts  from CSV file if you’re still using Powershell 1.0.

The format of the requried CSV file looks like this:

givenName,sn,displayName,mail,description
Bob,Smith,”Bob Smith”,bob.smith@gmail.com,”External Supplier”
Sue,Jones,”Sue Jones”,sue.jones@hotmail.com,”Hadware Sales”
Graeme,Turner,”Graeme Turner”,graeme.turner@yahoo.com,partner

#########################################################
#
# Name: BulkCreateContacts.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 13/12/2009
# Comment: PowerShell 1.0 script to
# bulk create AD Contact objects from csv file
#
#########################################################

# Set the target OU where the contacts will be created
$ContactOU=[ADSI]“LDAP://ou=Contacts,dc=mycompany,dc=com“

# Find our current working directory
$working = $(Get-Location)

# Specify the folder and CSV file to use
$folder = “C:\util\Powershell\CSV”
Set-Location $folder
$csv = Import-Csv “contacts.csv”

# Parse the CSV file line by line
foreach($line in $csv) {

# Assign variables to each attribute
$givenName = $line.givenName
$sn = $line.sn
$displayName = $line.displayName
$mail = $line.mail
$description = $line.description
$targetAddress = $line.mail

# Go ahead and create the contact object
$Contact = $ContactOU.create(“Contact”,”cn=$displayName”)
# Set the attributes on the contact object
$Contact.Put(“givenName”,$givenName)
$Contact.put(“sn”,$sn)
$Contact.put(“displayName”,$displayName)
$Contact.put(“mail”,$mail)
$Contact.put(“description”,$description)
$Contact.put(”targetAddress”,$targetAddress)
# Commit the changes
$Contact.setinfo()
# Mail-enable the contact (if you need to)
Enable-MailContact -Identity $displayName -ExternalEmailAddress $targetAddress
}
# Go back to the original working directory
Set-Location $working

The other day I applied Update Rollup 1 for Exchange Server 2007 Service Pack 2 in my test lab and wanted to check that the update was successfully applied.  Being something of a Powershell fan I first tried the command shown below:

(get-exchangeserver MyE2K7Server).admindisplayversion

The output showed Version 8.2 (Build 176.2), which is the same as Exchange Server 2007 SP2 without the Update Rollup.  Next I look at the value using the Exchange Management Console (EMC), which showed me the same information.

I even checked the registry under HKLM\SOFTWARE\Microsoft\Exchange\v8.0\<role> and the ConfiguredVersion value shows the same (8.2.176.2).

The only place I noticed the build number had been incremented was in the EMC under Help->About.

After some Googling I found the statement below from Microsoft’s Ananth Ramanathan

Successful installation of an update rollup should not be ascertained by the version number shown in the admin tools. The version number displayed by Exchange Management Console or other administrative mechanisms is obtained from the Exchange Server Object in Active Directory. If we update the Exchange Server Object in Active Directory to show a new version number for every rollup, it would require additional privileges for the account being used to install the rollup. Since many large customers have split level administrative model where the Exchange administrators do not have permissions to the Active Directory we do not update the Active Directory with an updated version number when the rollup is installed.

Another factor is that the rollup is no different than a Hotfix/Update for other products from Microsoft. So as an administrator you should do what you usually do for validating that the Hotfix is correctly installed/ In Windows Server 2003, you will need to go to Add//Remove programs in control panel and make sure the “Show Updates” checkbox is selected at the top. In Windows Server 2008, you will need to go to “View Installed Updates” in the Control Panel.

Ananth’s method is fine you want to look at one Exchange Server, but what if you want to list the build levels for all Exchange servers in your organisation?  Powershell to the rescue!  Here’s a script I put together to show the names, editions and build numbers for each Exchange server in the organisation.

#########################################################
#
# Name: GetExchangeBuild.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 24/11/2009
# Comment: PowerShell script to list build info
# for each Exchange Server in the organisation
#
#########################################################

#Uncomment the line below if running from Powershell outside the EMS
#add-pssnapin Microsoft.Exchange.Management.Powershell.Admin

$exsrvs = (get-exchangeserver)
foreach ($exsrv in $exsrvs)
{
$version = (get-exchangeserver -identity $exsrv).admindisplayversion
$edition = (get-exchangeserver -identity $exsrv).edition
write-host “=====================================================”
write-host “Exchange Server: $exsrv”
write-host $version
write-host “Edition: $edition”
write-host “Installed Update Rollups:”
$baseKey = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey(’LocalMachine’, $exsrv)
$regKey = “SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\461C2B4266EDEF444B864AD6D9E5B613\Patches\”
$baseKey = $baseKey.OpenSubKey($regKey)
$Updates = $baseKey.GetSubKeyNames()
ForEach($Update in $Updates)
{
$fullPath= $regKey + $Update
$UpdateKey = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey(’LocalMachine’, $exsrv)
$UpdateKey = $UpdateKey.OpenSubKey($fullPath)
$values = $UpdateKey.GetValueNames()
ForEach($value in $values)
{
if ($value -eq “DisplayName”)
{Write-host $UpdateKey.GetValue($value)}
}
}
write-host “=====================================================”
}

Let me know if you have any problems with the script, or if you can think of ways to improve it.

Tony

Windows Server 2008 R2 introduces the ability to revert to an earlier forest or domain functional level.  Previous versions of Active Directory did not have this ability and raising the forest or domain function level was, effectively, a one-way operation.  I say “effectively” because it is possible to revert, but only through highly disruptive recovery operations (full forest recovery in the case of a forest functional level upgrade).

I’ve actually not experienced or even heard of anyone having serious problems following a functional level upgrade, but that’s not really the point.  Have you ever tried to get approval from a Change Manager when your proposed backout plan involves a full forest outage of 12 hours or more?  In providing a mechanism for reversing a functional level upgrade, Microsoft has responded to customer demand for peace of mind, rather than a fix for a known problem.

This article shows how to raise the forest functional level and then revert it using Powershell commands.  The screenshots shown below are from running the commands in Powershell ISE.

On a Domain Controller, open a Powershell prompt and (assuming you don’t already have it) import the Active Directory Powershell module.

Import-module ActiveDirectory

Show the current Domain Functional Level

get-addomain | format-list domainmode

Show the current Forest Functional Level

get-adforest | format-list forestmode

Set the Forest Functional Level to Windows 2008 R2 (Forest Functional Level 4)

set-adforestmode -identity ad.contoso.com -forestmode windows2008R2forest

Show the current Forest Functional Level

get-adforest | format-list forestmode

Revert the Forest Functional Level to Windows 2008 (Forest Functional Level 3)

set-adforestmode -identity ad.contoso.com -forestmode windows2008forest

Show the current Forest Functional Level

get-adforest | format-list forestmode

You should see that the functional level has reverted successfully.

Note that after raising the functional level certain subsequent operations prevent you from reverting.  One of these operations is enabling the AD Recycle Bin, as shown below.

Enable-ADOptionalFeature 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target ad.contoso.com

After enabling the AD Recycle Bin you will receive the error below if you try to revert the functional level.

Another limitation is that you can currently only revert from Windows Server 2008 R2 functional level to Windows Server 2008 functional level.  In other words, the feature has not be retro-fitted to support earlier functional levels.

As you can see, raising and reverting the functional level is fairly straightforward operation once you have the appropriate Powershell commands.  It should give you (and your Change Manager)  a degree of comfort when planning your upgrade.

Earlier this week Nathan Mercer (Technology Advisor for Microsoft) gave me a brief look at the new Powershell Integrated Scripting Environment available with Windows Server 2008 R2.  ISE allows you to run commands and write, test, and debug scripts in a Windows GUI.  It also has multi-line editing, tab completion, syntax coloring, selective execution and context-sensitive help.  The best thing about it from my perspective is that it is great for demos of R2 Active Directory Powershell cmdlets.  Basically, it provides a much nicer view than the powershell command line and the selective execution allows you to pre-load all the commands you need (and save them in a Powershell data file), so that you don’t have to type them in front of a whole bunch of people! 

ISE is installed as a feature.  You can use server manager to install ISE, but if you want to go the Powershell route, try the following commands:

> Import-module ServerManager

> Add-WindowsFeature Powershell-ise

To use the feature and launch the GUI simply type the following at the Powershell command prompt:

> ise

Enjoy!

I have recently spent some time working with Xpath queries as part of Event Log filtering in Windows Server 2008.  It’s a great feature, but one limitation I found was that it doesn’t appear possible to use the starts-with() function when querying Event Logs with either the UI or Wevtutil.exe.  Here’s an example.

Let’s say I enabled LDAP logging on a DC and want to filter the Directory Service event log to find all LDAP queries coming from a particular IP address.  The IP address is buried in one of the Data nodes of the Event XML, as shown in red below.

<Event xmlns=”http://schemas.microsoft.com/win/2004/08/events/event”>

  <System>

    <Provider Name=”Microsoft-Windows-ActiveDirectory_DomainService” Guid=”{0e8478c5-3605-4e8c-8497-1e730c959516}” EventSourceName=”NTDS General” />

    <EventID Qualifiers=”16384″>1644</EventID>

    <Version>0</Version>

    <Level>4</Level>

    <Task>15</Task>

    <Opcode>0</Opcode>

    <Keywords>0×8080000000000000</Keywords>

    <TimeCreated SystemTime=”2009-04-29T20:39:00.886Z” />

    <EventRecordID>339453</EventRecordID>

    <Correlation />

    <Execution ProcessID=”648″ ThreadID=”792″ />

    <Channel>Directory Service</Channel>

    <Computer>DC1.Myco.Com</Computer>

    <Security UserID=”S-1-5-21-854245398-152049171-725345543-4606″ />

  </System>

  <EventData>

    <Data>CN=MyCo Enterprise Issuing CA 1, CN=Public Key Services,CN=Services,CN=Configuration,DC=MyCo,DC=Com</Data>

    <Data> (objectClass=cRLDistributionPoint) </Data>

    <Data>1</Data>

    <Data>1</Data>

    <Data>192.168.40.10:4048</Data>

    <Data>base</Data>

    <Data>deltaRevocationList</Data>

    <Data>

    </Data>

  </EventData>

</Event>

So if I wanted to use Xpath to filter all events in the Directory Service Event Log from that IP address my query would look something like this:

<QueryList>

  <Query Id=”0″ Path=”Directory Service”>

    <Select Path=”Directory Service”>*[System[(Level=4 or Level=0) and (EventID=1644)]] and *[EventData[Data[5]=’192.168.40.10:4048′]]</Select>

  </Query>

</QueryList>

The query works well, but the problem is that the Data node within the XML contains the port number (4048) in addition to the IP address.  I want to find all queries issued from that client, regardless of the port used.  Here’s my attempt to use the starts-with() function to filter the event.

<QueryList>

  <Query Id=”0″ Path=”Directory Service”>

    <Select Path=”Directory Service”>*[System[(Level=4 or Level=0) and (EventID=1644)]] and *[EventData[starts-with(Data[5],’192.168.40.10′)]]</Select>

  </Query>

</QueryList>

This fails with the error “The specified query is invalid“.  Back to the drawing board.  I posted a question to Technet Forums and got some good help from Ivan Ting at Microsoft.  He provided some Javascript that used starts-with() and this worked (after some fun messing around with default namespace issues).  Being something of a Javascript muppet (the antithesis of a Javascript guru), I decided to try my hand at a Powershell version.  Here’s what I came up with.

#####
# Author: Tony Murray
# File name: LDAPEvents.ps1
# Date: 28th April 2009
# Purpose: Extracts LDAP Search information from Directory Service Event
# Log. Requires LDAP logging to be switched on.
#####

# Function to create an object for XML document navigation
# Source: Technet Scriptcenter
function get-xpn ($text)
{
$rdr = [System.IO.StreamReader] $text
$trdr = [system.io.textreader]$rdr
$xpdoc = [System.XML.XPath.XPathDocument] $trdr
$xpdoc.CreateNavigator()
}

# Run Wevtutil.exe to export the Event log to file
# Could use Powershell to do this but it creates odd-looking xml!

$file = “c:\util\dumplog.xml”
& $env:windir\System32\wevtutil qe `”Directory Service` /e:Events | Out-File $file

# Remove the namespace from the xml file. It won’t work if it stays

$findStr = ” xmlns=`’http://schemas.microsoft.com/win/2004/08/events/event`’”
$ReplStr = “”
$newcontent = (Get-Content $file) -replace ($findStr,$ReplStr)
Set-Content $file $newcontent

# Invoke the navigator
$xb = get-xpn $file

# Define the Xpath query we want to use
$query = “//*[ System[(Level=4 or Level=0) and (EventID=1644)] `
and EventData[starts-with(Data[5],’192.168.40.10′)]]”

# Create a CSV file with the output. Each line represents the details
# we want from a single Event.

Write-Output $xb.Select($query) | %{[xml] $_.OuterXml} | Select-Object `
@{name = “Date&Time”;Expression = {$_.Event.System.TimeCreated.SystemTime}}, `
@{name = “SearchBase”;Expression = {$_.Event.EventData.Data[0]}}, `
@{name = “Filter”;Expression = {$_.Event.EventData.Data[1]}}, `
@{name = “Visited”;Expression = {$_.Event.EventData.Data[2]}}, `
@{name = “Returned”;Expression = {$_.Event.EventData.Data[3]}}, `
#@{name = “SourceIP”;Expression = {$_.Event.EventData.Data[4]}}, `
@{name = “SearchScope”;Expression = {$_.Event.EventData.Data[5]}} `
| export-csv ds.csv -notype
# Replace the previous line with the following line to change the output format
#ConvertTo-HTML | Out-File “LDAPEvent.html”

Having to write a script is more effort than simply issuing the query from within Eventvwr, but it does have the advantage of allowing you to return only the information you are interested in - and in the format that you want.  Hopefully, my experience will save you a bit of time and effort if you are trying to achieve something similar.

In my last post, I provided a small batch file to support scheduled IFM dumps of an AD LDS instance.  Afterwards, I realised that batch files are sooo last century and decided to have a crack at the Powershell version.  I’m no Bwandon, but the script below seems to do the trick.

#
# Name: Create_IFM_Dump.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 20/04/2009
# Comment: PowerShell script to create AD LDS IFM
# backup.  To be run nightly as a scheduled task.
#
#########################################################

# Declare variables$IFMDir = “c:\backup\adlds\Instance1″
$IFMName = “adamntds.dit”
$cmd = $env:SystemRoot + “\system32\dsdbutil.exe”
$flags = “`”ac i Instance1`” ifm `”create full c:\backup\adlds\Instance1`” q q”
$date = get-Date -f “yyyymmdd”
$backupfile = $date + “_adamntds.bak”$DumpIFM = “{0} {1}” -f $cmd,$Flags

# Main

# Create the folder if it doesn’t exist if(test-path -path $IFMDir)
{write-host “The folder” $IFMDir “already exists”}
else
{New-Item $IFMDir -type directory}# Clear the IFM folder (Dsdbutil needs folder to be empty before writing to it) Remove-Item $IFMDir\*

# Run Dsdbutil.exe to create the IFM dump file Invoke-expression $DumpIFM# Rename the dump file to give the backup a unique name

rename-item $IFMDir”\”$IFMName -newname $backupfile

# End Main

 Tony

The other day I had a need to configure scheduled backups of GPOs to file on a Windows Server 2008 Domain Controller.  Aha (I thought), I’ve done this before using the BackupAllGPOs.wsf script that is included along with a whole bunch of other handy scripts when you install the Group Policy Management Console (GPMC).  After a few minutes of fruitless searching on my Windows Server 2008 DC I realised that although the GPMC was installed (as a feature) the scripts were nowhere to be found.  After some Googling I found out that I hadn’t been singled out for victimisation - unlike Windows Server 2003, the scripts just aren’t installed by default in Windows Server 2008 when you enable the GPMC feature.  I discovered that you could download the Vista and Windows Server 2008 versions of the scripts here:

Group Policy Management Console Sample Scripts

It puzzled me that the scripts weren’t included by default.  I suspect the Vista and WS2008 versions of the scripts were developed after the products had shipped.  Anyway, it made me think that Microsoft maybe wanted me to work with PowerShell and not VBScript.  Aha (I thought again), I’ll see if I can find the PowerShell equivalent of the GPMC scripts.  After a fair bit of searching I found two options.

Option 1.

SDM GPMC PowerShell Cmdlets from Darren Mar-Elia

Option 2.

Sample functions provided by Thorbjörn Sjövold in his Technet Magazine article, Simplify Group Policy Administration with Windows PowerShell

The first option requires installing the Cmdlets from an .msi install package, something I didn’t really want to have to do in the environment I was working with.

The second option proved a winner and provided the functions I needed to get my PowerShell script up and running within a few minutes.  Here’s my script to backup all the GPOs in a given domain. 

## FileName: BackupGPOs.ps1
## Date: 13.12.2008
## Purpose:  Backs up all GPOs within domain to file

## Variables

$backupDirectory = “c:\backup\GPO”
$domainName = [System.DirectoryServices.ActiveDirectory.Domain]::GetComputerDomain().Name

## Functions

# Source: http://technet.microsoft.com/en-us/magazine/cc162355.aspx

###########################################################################
# Function   : BackupAllGpos
# Description: Backs up all GPOs in a Domain
# Parameters : $backupDirectory - The directory where the backups will be stored
#            : $domainName - The dns name, e.g. microsoft.com, of the domain to operate on
#            : $backupComment - An optional comment for the backups, if nothing is passed the current date will be
used.
# Returns    : N/A
###########################################################################
function BackupAllGpos(
  [string] $backupDirectory=$(throw ‘$backupDirectory is required’),
  [string] $domainName=$(throw ‘$domainName is required’),
  [string] $backupComment=$(get-date))
{
  $gpmAllGposInDomain = GetAllGposInDomain $domainName

  foreach ($gpmGpo in $gpmAllGposInDomain) # Iterate through all the GPOs
  {
    “Back up GPO : ” + $gpmGpo.DisplayName
    $gpmResult = $gpmGpo.Backup($backupDirectory, $backupComment) # Backup the GPO
    [void] $gpmResult.OverallStatus
    $gpoBackup = $gpmResult.Result
  }
}

###########################################################################
# Function   : GetAllGposInDomain
# Description: Returns all GPOs in a domain
# Parameters : $domainName - The dns name, e.g. microsoft.com, of the domain to operate on
# Returns    : All Group Policy Objects in the supplied domain
###########################################################################
function GetAllGposInDomain(
  [string] $domainName=$(throw ‘$domainName is required’))
{
  $gpm = New-Object -ComObject GPMgmt.GPM # Create the GPMC Main object
  $gpmConstants = $gpm.GetConstants() # Load the GPMC constants
  $gpmDomain = $gpm.GetDomain($domainName, “”, $gpmConstants.UseAnyDC) # Connect to the domain passed using any DC
  $gpmSearchCriteria = $gpm.CreateSearchCriteria() # Create a search criteria without any restrictions
  $gpmDomain.SearchGPOs($gpmSearchCriteria) # Search and find all GPOs in the domain, this will return the array
}

## Main

backupAllGpos $backupDirectory $domainName

## End

Note that I’ve set the $domainName variable to match the domain of the computer from which the script is run.  To set the variable to match the domain of the user account under which the script runs change it to (may wrap):

[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name

The sample functions provided by Thorbjörn are comprehensive and cover nearly all of the features included in the original GPMC VBScripts.  I encourage you to take a look.

Or at least it nearly did.

I was working a script and because of a small typo very nearly lost most of the data on my C: drive.   It’s very easy to get wrong, so treat this as a cautionary tale.   The example below shows the error I made and the potential impact.  I’ve used the command line instead of my script in the example, but the effect is the same.

 First of all I set a variable to point to a folder off the root of the C: drive.  Then I cleared the contents of the folder using the variable together with the Remove-Item command.

 The screenshot below shows how to do this correctly.

 Now look what happens when you mistype the name of the variable.  PowerShell basically ignores the variable and assumes you want to remove everything from the root of the drive. 

In my case only the fact that I didn’t use the  -recurse parameter saved me.  If I had used the -recurse parameter I would have lost everything except for items protected by the system.

Nasty.

It’s been a little while since I’ve blogged, so here’s a more or less random collection of snippets for you to enjoy/delete at leisure.

Quest acquires Netpro

Wow, this one took me by surprise, especially as I have been contracting to Quest on and off for the past 10 months.  Two of the biggest names in the Active Directory management space are now one.  It’s going to take quite a while for competitors to breach the gap.

Microsoft acquires Deano

I just learned from Joe Richard’s blog that Dean Wells has taken a position at Microsoft within the Directory Services product team in Redmond.  I’ve known Dean for the past six years or so and he is one of the most knowledgeable AD people around.  He’s forgotten more about AD than most of us know.  I’m sure he’ll be a huge asset to the DS team.  Good luck Deano!

Handy CSV import script

I came across a good vbscript for modifying AD attribute values using a CSV input file.  There are a number of methods and scripts around that can work with CSV input files, but the cool thing about this script is that can easily be modified to accommodate different attributes.  Check it out here.  I’m thinking of putting together a Powershell version of the same thing.

Good anecdote from Don Hacherl

A while back I blogged about one of the new features of AD in Windows Server 2008: protection from accidental deletion.  If you were looking for a good supporting anecdote to hasten the deployment of this feature in your environment, look no further than this nugget from one of the Godfathers of AD, Don Hacherl, posted on the mailing list at ActiveDir.org:

From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Don Hacherl
Sent: Sunday, 7 September 2008 4:52 p.m.
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Delegating Start/Stop Service on DCs

Years ago I worked with a “domain admin qualified” person at Microsoft who fat fingered the admin UI and deleted a container instead of the object he was intending.  The container was named “North America”, and that was the night we wrote our first authoritative restore tool.  (Later he said “I wondered why it was taking so long to finish.”)

A tightly constrained proxy program can be more reliable and less dangerous than a distracted human administrator.

Don

Tech-Ed

My sessions at Auckland and Sydney completed without mishap and my demos (bizarrely) worked without one single blue-screen :-)  The feedback was positive and I was happy with the eval scores.  Looking at the video of my session, I realise that I need to slow down a little, engage the audience more and stop saying “um” so much.  Talking in front of a large audience is nerve-wracking and I wasn’t even aware I was doing it.

Tech-Ed in Sydney was also a good opportunity to catch up with fellow DS MVP Gil Kirkpatrick and my ex-colleagues from Gen-i, Craig Pringle and James Brombergs.

I sometimes have to work in environments where I have to use the customer’s PC instead of my laptop.  This can be quite frustrating as my laptop is quite heavily customised and has all the tools that I need.  One thing I find problematic is having to work with scripts (especially VBScript) without a decent script editor.  Notepad doesn’t really cut the mustard.

If the PC I am assigned to has Office installed I usually fire up the Microsoft Script Editor (MSE7.EXE) when working with scripts.  This underutilised editor has a sufficiently rich set of features to make working with VBScript a comfortable experience.

The Microsoft Script Editor is normally installed by default with Office 2007, but is not reachable directly from the Start -> All Programs -> Microsoft Office menu.  Instead, you can usually find it by searching for MSE7.EXE on the local drives.  On the machine I am working on now, it is installed in the following location:

%programfiles%\Common Files\Microsoft Shared\OFFICE12\MSE7.EXE