Modifying AD accounts with Powershell after an Exchange 2003 dial-tone restore

Recently I've been testing out some different disaster recovery scenarios for Exchange 2003, one of which involved a dial-tone method - i.e. create some new mailbox servers with blank databases to get users up and running quickly and then merge the restored data back in later. One of the types of dial tone method we used was to create new server names rather than re-use existing Exchange server names.

So for example to re-create a four node (3 active, 1 passive) cluster with new names, instead of

ExchangeServer1
ExchangeServer2
ExchangeServer3

you would now use something like

ExchangeServer1New
ExchangeServer2New
ExchangeServer3New

Then you would need to amend the AD user accounts for users on those Exchange Servers to point to the new locations - the following properties need to be changed.

homemdb
msexchhomeservername
homemta

None of these properties can be changed through ADUC, you would need to use ADSIEdit if you wanted to use a GUI. Of course those smart people among you would choose to user Powershell anyway.

So naturally I turned to my trusty friend the Quest AD cmdlets to help me out.

First of all we get all the users who have a mailbox based on one of the original servers; depending on your naming convention you may need to adjust this filter to make sure you are matching the correct people. The three properties mentioned are not returned by default from Get-QADUser so we have to specify them.

We then loop through each user and using the Switch statement if we match ExchangeServer1, 2 or 3 we amend the text of each variable to be the new Exchange servername (note: homemta will be the same for all of these users) and then user the Set-QADUser cmdlet to change these properties on the account.

$users = Get-QADUser -ldapFilter '(msExchHomeServerName=*ExchangeServer*)' -IncludedProperties homemdb,msexchhomeservername,homemta -sizelimit 0

foreach($user in $users){

$homemdb = $user.homemdb
$msexchhomeservername = $user.msexchhomeservername
$newhomemta = 'CN=Microsoft MTA,CN=ExchangeServer1New,CN=Servers,CN=Exchange,CN=Administrative Groups,CN=Springfield,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=springfield,DC=local'

switch -wildcard ($homemdb)

{
"*ExchangeServer1*" {$newhomemdblocation = $homemdb.replace("ExchangeServer1","ExchangeServer1New"); $newmsexchhomeservername = $msexchhomeservername.replace("ExchangeServer1","ExchangeServer1New");  Set-QADUser $user -objectAttributes @{homemdb=$newhomemdblocation;msexchhomeservername=$newmsexchhomeservername;homemta=$newhomemta}; break}
"*ExchangeServer2*" {$newhomemdblocation = $homemdb.replace("ExchangeServer2","ExchangeServer2New"); $newmsexchhomeservername = $msexchhomeservername.replace("ExchangeServer2","ExchangeServer2New");  Set-QADUser $user -objectAttributes @{homemdb=$newhomemdblocation;msexchhomeservername=$newmsexchhomeservername;homemta=$newhomemta}; break}
"*ExchangeServer3*" {$newhomemdblocation = $homemdb.replace("ExchangeServer3","ExchangeServer3New"); $newmsexchhomeservername = $msexchhomeservername.replace("ExchangeServer3","ExchangeServer3New");  Set-QADUser $user -objectAttributes @{homemdb=$newhomemdblocation;msexchhomeservername=$newmsexchhomeservername;homemta=$newhomemta}; break}
default {"Nothing for this user"}
}


}

I was also interested to see the resulting performance of this script and was pleasantly surprised to see it change 6000+ accounts in only 10 mins.

A sidenote to this method is that you won't actually see the mailboxes appear in Exchange System Manager until either they receive an email or a user logs on to them. To prove that this method had worked I created a quick Distribution Group, used the below one-liner to populate it with all of the above users and then sent an email to this group.

Get-QADUser -ldapFilter '(msExchHomeServerName=*ExchangeServer*)' -sizelimit 0 | Add-QADGroupMember TestGroup

There are of course many different ways to carry out Exchange DR, but this proved a useful exercise.

Powershell Active Directory One-Liners

Recently I blogged about some scripts I left behind in my previous employment for managing AD - really a lot of them were just quick one liners. Not that that is necessarily a bad thing, one of the best things for me about Powershell is the way you can get great information with very little effort. Of course I am using my good friend the Quest AD cmdlets.

I thought I'd share a few of them:

Find Expired Users:

On the theme of cleaning out AD, find user accounts which have expired.

Get-QADUser -searchroot 'domain.local/resources/users' -SizeLimit 0 -ldapFilter '(pwdlastset=0)' | ft name,passwordlastset


Find Users Not Logged in Since X Days:

On the same theme, supply X 'how many days to go back' and find users who haven't logged in during that time. (OK I cheated on the one line a bit on this one)

$now=get-date; $daysSinceLastLogon = X; Get-QADUser -sizeLimit 0 -SearchRoot 'domain.local/resources/users' | where {$_.lastlogontimestamp.value -and (($now-$_.lastlogontimestamp.value).days -gt $daysSinceLastLogon)} | ft name,lastlogontimestamp

Note: X needs to be more than 14 days to allow for the lastlogontimestamp attribute to have replicated.


Find Users Whose Password is set to Not Expire:

Keep tabs on those naughty administrators who think they can exempt themselves from the corporate password policy - you know who you are!

Get-QADUser -Sizelimit 0 -SearchRoot 'domain.local/resources/users' -PasswordNeverExpires $True | ft name


How Many Users in Active Directory?

Need to keep track on an expanding user population? Need to figure out how many CAL's you need? Easy.

Get-QADUser -DontUseDefaultIncludedProperties -SearchRoot 'domain.local/resources/users' -SizeLimit 0 | Measure-Object


Enjoy!

PowerGUI webcast - Exchange 2003 Powerpack demo

I was recently invited to record a webcast by the Product Manager at Quest for PowerGUI, Darin Pendergraft, demoing the Exchange 2003 Powerpack I made for PowerGUI.

They came up with the idea to make some videos / webcasts giving some community members the opportunity to show what PowerGUI can do. A lot of people primarily use it only as a script editor, but the management console side of things is brilliant once you get into it - hopefully these examples will help inspire more people to make some powerpacks.

I had a lot of fun recording the interview, it was funny to be on the other end of the questions for once, normally I'm asking them for the Get-Scripting podcast.

It runs for about 15 - 20 mins, I hope you enjoy it.

Get-Scripting Podcast Episode 6

So we got Episode 6 of the Get-Scripting Podcast out last week. You can get it from here:

Download it here, subscribe in iTunes or via a different feed reader

Normally Alan, Matt and I all arrange to be in the same place to record the show. Given we live in completely different places in the UK this is not easy and is probably the main reason we keep it to one show per month. We could do a Skype type thing, but we prefer to keep it a face-to-face recording. Now though that I work in the same office as Alan this time we took the opportunity to record the show during a lunchtime and I got Matt to post-edit the result when meeting for family time over Christmas.

End result: I think the show was a bit more relaxed because we just let the tape roll and edited afterwards rather than stopping and starting when normally we sometimes re-record bits; logistically much easier; still took about the same time to edit.

The interview with Ben Pearce which I had recorded a few weeks earlier was an absolute blast. Ben is such a fun guy to be around and made for a real easy interview because he doesn't stop talking; I think we got some great tips from him for Powershell beginners too.

Powershellers on Twitter

So I was pretty sceptical for a long while about things like Twitter and Facebook, but I finally gave in mostly thanks to my buddy Alan Renouf and to be honest its been brilliant. Its such a useful way to quickly find information and keep up to date with a particular topic, obviously in my case Powershell.

Whilst at Teched it was a great tool to keep up with things which were going on in sessions or what people where up to. I also used it during a Powershell Q&A with Jeffrey Snover to invite fellow Twitterers to give me some questions for him.

At the Get-Scripting podcast its a really useful tool for us to be able to put out info about the show, particularly when we release a new epsiode and conversley really handy to keep up to date with shows like the Powerscripting Podcast and Mind of Root.

Steven Murawski from the Mind of Root podcast has helpfully posted a list of Powershell people on Twitter who you can follow.

Best news of all Jeffrey Snover has just started posting on Twitter! Now that is definitely a good person to follow for Powershell info. ;-) There was lots of chat during the Powerscripting UStream the other night when Jeffrey and Bruce were on the show about how the chat that night was pretty similar to what goes on on Twitter, so I guess that's maybe we he signed up too.

PowerScripting Live CTP3 Special - Thursday 18th Dec

This is a must watch PowerScripting Podcast special - the hint is in the title.

Jeffrey Snover and Bruce Payette are the two guests, it should be an awesome show.

Thursday 18th Dec 9pm EST, which translates to 2am UK time. I think I'm going to have to stay up for it!

Take your own advice Jonathan!

During this last year I've done quite a few presentations about Powershell and quite often as part of the demo I have included PowerGUI since I find it a great way to reel people in who aren't quite yet ready to make a jump the whole way to command line scripting.

One of the topics I usually talk about around this is how I (like most people seem to) initially used the PowerGUI script editor for writing my scripts, but didn't really get what the PowerGUI console was all about. I couldn't quite get my head around why you would want a

GUI console for a command shell to manage a GUI OS or product,

it didn't seem to make much sense to me.

Luckily, we were very fortunate back in May to head over to Quest in the UK with the Powershell User Group for an evening's event. I decided I'd better figure out what the PowerGUI console was for before attending so watched some of the videos on the PowerGUI site to give myself a better idea.

Doing that and seeing Dmitry's presentation in the night made things finally click. You could use it to make custom management consoles for your own use or even better to give to a colleague or share with the community. That's where the idea for the Exchange 2003 PowerPack was born and the Get-Scripting podcast was born almost by accident that night too, but those are stories for another day. :-)

Anyway, back to the presenting. I often show PowerGUI and explain how you can use it to make custom management consoles to give to colleagues.

Recently I have been working out my notice period before heading to a new job and one of the things I have done during that time is create a bunch of scripts for the regular admin tasks I or others carry out (particularly with AD) which I never got round to writing for myself or them and to save whoever took on my role or parts of it a load of hassle.

For instance I finally got around to creating a script for de-provisioning users which should really help to improve the previous process which was in place. It was based on my good friend Jonathan Noble's blog post about setting logon hours for an account rather than disabling it so that the email doesn't bounce. Thanks Jon!

Of course some of these scripts were to be handed over to the helpdesk. Now without being patronising (because we have some very smart people on our helpdesk) it can be quite a jump for a helpdesk person to read through all the documentation I wrote for each script and start running those scripts from the command shell and seeing their results in a blue on black window.

So the cogs started whirring away in the old brain whilst I tried to think of a better way I could deliver these scripts for the helpdesk so they could get up and running with them much quicker and easier without having to read through all the boring documentation first and have a better experience when running them, i.e. don't put them off using the scripts once I'm not there anymore to help them.

Finally it clicked. Why didn't I take my own advice I'd been giving out all year about making management consoles for your colleagues and go and do it myself! So the AD Admin Powerpack was born, I packaged up my scripts into this PowerPack, installed PowerGUI for them and instantly the scripts were far more useable.

No need to read all of my boring documentation beforehand since its pretty obvious what clicking on script nodes such as 'Find Expired AD users' or 'How many users in Active Directory?' will do.

Effective, very simple solutions which save people time, make them more efficient and its makes me feel good to leave something useful like that behind for them to use. Thank you PowerGUI!

Of course the girls on the helpdesk love the train icon so it was an even easier win with them.