Exchange 2003, WMI, AD and Powershell - Part 5 (Querying AD for Exchange 2003 Information)

In previous posts in this series we have looked in particular at some of the Exchange 2003 WMI classes. So far this has required manual specification of which Exchange server you want to retrieve info from; wouldn't it be nice if you could use Powershell to find all the Exchange 2003 servers in your environment then run the WMI query against the results? Fortunately for us Exchange 2003 stores a lot of configuration information in Active Directory so we can query AD to retrieve what we need. There is a great article here which details how you can do this. We do the following:

Create a new directory object using .Net for the current AD domain.

$root= New-Object System.DirectoryServices.DirectoryEntry("LDAP://RootDSE")

Use ADSI to get the configuration partition of AD.

$cfgNC = [adsi]("LDAP://" + $root.Get("configurationNamingContext"))

Create a directory search object

$search = New-Object System.DirectoryServices.DirectorySearcher($cfgNC)

Filter on the Exchange Server object class - the below image should help illustrate what we are doing here. (other classes you can search on can be found here)

$search.filter = '(objectclass=msExchExchangeServer)'






Use the FindAll method to execute the search.

$ExchServer = $search.FindAll()

Finally, return the names of all the results.

$ExchServer | foreach {$_.properties.name}

Which in the example from the screenshot would produce a result:

EXCH

You can now combine this with any of the previous WMI scripts to run them against all the Exchange servers in your environment, e.g. for Top 10 largest mailboxes on each server:

$root= New-Object System.DirectoryServices.DirectoryEntry("LDAP://RootDSE")
$cfgNC = [adsi]("LDAP://" + $root.Get("configurationNamingContext"))
$search = New-Object System.DirectoryServices.DirectorySearcher($cfgNC)
$search.filter = '(objectclass=msExchExchangeServer)'
$ExchServer = $search.FindAll()

foreach ($server in $ExchServer)
{
$ExchangeServers = $ExchangeServers + $ExchServer | foreach {$_.properties.name}
}
foreach ($computer in $ExchangeServers) {
Get-Wmiobject -namespace root\MicrosoftExchangeV2 -class Exchange_Mailbox -computer $computer | sort-object Size -Descending | select-object -First 10 MailboxDisplayName,Servername,StorageGroupName,StoreName,Size}

Checking AD replication latency with Powershell

Having suffered from some AD replication issues in the past (the dreaded lingering objects), its been at the back of my mind on how to keep an eye on replication between all the DC's.

Also a frequent question from the helpdesk goes along the lines of they've made a change to somebody's AD account and how long is it going to be before that change will make it around to all of the DC's? In the past I've kind of stuck my finger in the air and given an approximate time based on replication intervals in the site links.

So how about some Powershell which checks AD replication latency for you (and at the same time confirms all DC's are replicating) so you can give a more precise figure on how long it takes for a change to replicate the whole way around?

Brandon at the BSonPosh blog has a frankly brilliant post with a script you can run which creates a temporary contact in AD, then polls each DC until it appears, records the time taken and finally removes the test contact.

For me this was a Snover moment (i.e. the top of my head exploded!), this is so useful for me its unreal, and possibly the best bit: my finger in the air estimate was pretty darn close. :-)

HP Lights-Out Authentication With Active Directory

OK, so its not exactly scripting, but I just spent a bunch of time getting this working in our lab environment before a production rollout. Hit a number of not very obvious gotchas so thought I would put the information out there to assist anyone else trying to get the same thing working.

If you're not familiar with it then the HP Lights-Out management processor is typically a built-in (it used to be a seperate PCI card) component in Proliant servers which enables remote management of the physical machine independent of the OS. For instance, you can effectively access the power button or the console of the machine on a server in a remote office which has become unresponsive. Full details here. The feature which usually impresses people the most is the ability to view the console as the machine is booting up - remember those times when you rebooted a remote server and it didn't come back up because it was waiting for an F1 key press which you couldn't press!

We are looking at deploying this to all of our AD DC's, which are typically the only server at branch offices and can involve long and costly trips for engineers should the server need maintenance. One requirement we have for the project is auditing and accountability, i.e. if an engineer has used the tool to power off a DC we may need to know who did it. Consequently we examined in the lab how to use the authentication that HP Lights-Out provides against Active Directory.

First of all here are the requirements for what you will need:

• HP servers with iLo enabled management processors. For advanced features like Remote Control you need an advanced license which typically can be purchased for around £80 per machine.
• LDAP directory, we're using Active Directory. You will need admin accounts which belong to a group which iLo can use.
• ilo wants to authenticate over SSL so you will need to enable your Active Directory to respond to LDAP requests on SSL which it does not do by default. (detailed info to follow)
• HP Directories Support management software - download from the Proilant driver page.
  
• A brick wall to bash you head against when you try to figure out the (undocumented) format to specify the login name as.

iLo
-------

Get the latest Proliant support pack (currently 8.0) onto your server, there are some OS iLo updates in there. Update iLo itself to the latest firmware release. Patch the iLo card into your network, give it a DNS name and network settings - Tip: make sure the DNS server settings are correct (obvious, but I had it incorrect which led to some headscratching later on)

Active Directory
-------

Download and ingest the Integrating HP Proliant Lights-Out processors with Microsoft Active Directory guide. Note there is an option to extend your AD schema to get some extra features, this blog post is around the schema-free integration.

You will need to enable SSL over LDAP on your DC's. There's a KB which makes it look very simple and in the main it is. Two tips from the field:

1. You may need to reboot a DC before it will pick up the certificate.
2. Add the Domain Controllers group to the CERTSVC_DCOM_ACCESS group as detailed in this KB article.

HP Lights-Out Directories Migration Utility
--------

Run this tool as per the ilo AD guide - note: maybe it's just me, but it is not intuitve at all, you should be able to figure it out though. Essentially it will configure most of the settings you need, its just not obvious what to put in there sometimes.

A key gotcha later on is the naming context so make sure you populate the Directory User Context with the path to where you admin accounts and the 'ilo-admins' group which contains them lie.


Directory testing
-------

Login to iLo via the webpage at its configured IP address and the local iLo Administrator account (you may want to keep this as an emergency account if directory login is not working). Navigate to Administration, Security, Directory and you should see settings you specified during the migration utility. Check these settings are what you expect and then use the very useful Test Directory Settings link at the bottom.

Obviously, this will test all the settings you have input and tell you anything which is incorrect. The key point here is that you have to input a username and password to use for the testing, what it does not tell you is that it is expecting the username in the format of the DN, e.g. CN=test admin,OU=admin accounts,dc=testdomain,dc=com (of course this is not in the iLo AD guide!)

Once you have successfully passed all of the tests you can then logout and log back in with an AD admin account. If you have correctly populated your directory search context you can use either:

• test admin (note the space) or
• CN=test admin

otherwise you will have to specify the full path, i.e. CN=test admin,OU=admin accounts,dc=testdomain,dc=com .

Final note:

If you specify a search context of @testdomain.com some newgroup posts alledge that you can then login as test.admin, i.e. the accountname , but I couldn't get this to work.

More on Password Policies

As touched on in the previous post, doing a lot of work with password policies at the minute.

Say you need to find the date all the members of a group last changed their password, below is all you need to do:

Get-QADGroupMember 'domainname\groupname' | Get-QADUser -IncludeAllProperties | ft displayname,pwdlastset

The pwdlastset parameter will (obviously) give you the time and date the password was last checked. It's pretty straightforward moving on from there to start doing things like finding which of these users' passwords will expire shortly.

Password Policy Details / Updated Quest AD Cmdlets

Quest have released an updated version (1.1.0) of their AD cmdlets.

Published as part of the update is the ability to find details of the default domain password policy, previously a little tricky to get hold of.

A simple:

Get-QADObject domainname/ | format-list *

exposes the information you can obtain.

We've been doing a lot of work recently with password policies and

(Get-QADObject domainname/).MaximumPasswordAge

makes some of this work now a snap!

--------------------------------------------------------------------------

Update:

Or even easier

(Get-QADRootDSE).Domain | Format-List Name, *Password*, *Lockout*

Name : springfield
MinimumPasswordAge : 7 days
MaximumPasswordAge : 90 days
PasswordHistoryLength : 10 passwords remembered
MinimumPasswordLength : 6 characters
LockoutDuration : 30 minutes
LockoutTreshold : 5 invalid logon attempts
ResetLockoutCounterAfter : 30 minutes

Thanks Mr Sotnikov!

Disabling Outlook Web Access on AD accounts

A request came up asking, "If we need to could we disable Outlook Web Access for a particuar list of users?"

After some digging around and some great help from Shay Levy on the Powergui message board I was able to come up with the following:

Set-QADUser 'springfield\homer.simpson' -ObjectAttributes @{ProtocolSettings='HTTP§0§1§§§§§§'}

If you need to disable more than one of the options it would be

Set-QADUser 'springfield\homer.simpson' -ObjectAttributes @{ProtocolSettings='HTTP§0§1§§§§§§,IMAP40§1§§§§§'}

The options detailed on the 'Exchange Features' tab of an AD account are stored in the ProtocolSettings field. If you look at that field in Adsiedit, you will see which options have been disabled, if any. From there you can grab the HTTP,IMAP etc string that you need.

More info here:
Making bulk protocolSettings changes

Add Users to an AD group from a CSV file

So I had a text file containing data in the following format:

username1.xxx.xxx.xxx.companyname

username2.xxx.xxx.xxx.companyname

username3.xxx.xxx.xxx.companyname

basically Novell usernames.

These accounts have equivalent usernames in Active Directory in the format

username1

username2

username3

ie. everything after the first dot is removed.

The task is to open up the text file, convert the Novell usernames to the AD format and then add each user to a group. With a bit of help from a post of Richard Siddaway's (http://richardsiddaway.spaces.live.com/blog/cns!43CFA46A74CF3E96!822.entry) the below script does the job.

(As usual the Quest AD cmdlets are required)

# Open the text file, split out each username at the first '.' and keep the first part of each split.
$users = Get-Content C:\Scripts\UserList.csv | %{$_.split(".")[0]}

# For each username get the user's AD DN and add the user to the specified group.
foreach ($a in $users)
{
Get-QADUser -Identity $a | Add-QADGroupMember -Identity 'domainname\groupname'
}

Bye bye my vbscripts?

OK, so I've moved onto Powershell these days, but I thought I'd start my blog posting with one of my favourites. Its adapted from a great idea at http://www.microsoft.com/technet/scriptcenter/resources/qanda/apr05/hey0429.mspx and essentially makes the description field of your computer accounts dynamically populated.

Why might you want to do this you ask?

Well, have you ever needed to find a computer name easily without needing to get the user to find it out? This script if run at login will populate the description field of the computer account with: username, current AD site, make and model of machine, time logged in, e.g.

Joe Bloggs logged on in Paris using HP 6710b, 08:30.

Simply sort your computer accounts by the description column and hey presto easy to find the computer the user is logged into. Simple, but very effective.

I also used it to easily sort computers into separate OU's for laptops and desktops.


On Error Resume Next
Set objSysInfo = CreateObject("ADSystemInfo")

Set objUser = GetObject("LDAP://" & objSysInfo.UserName)
Set objComputer = GetObject("LDAP://" & objSysInfo.ComputerName)
objSitename = objSysInfo.SiteName

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_ComputerSystem")

For Each objItem in colItems
strManufacturer = objItem.Manufacturer
strModel = objItem.Model
Next

strMessage = objUser.CN & " logged on in " & objSitename & " using " & strManufacturer & ", " & strModel & " " & Now & "."

objComputer.Description = strMessage
objComputer.SetInfo


(By the way you'll need to add the 'Write description' property on the OU(s) where your computer accounts reside to something like Authenticated Users.)