At this time every year, I have to arrange the provisioning of Active Directory user accounts and Exchange mailboxes for thousands of students. This year, I'm completing the whole of that process using Windows PowerShell. This means spreading them evenly over a set of Exchange mailbox databases.

The first step in this is finding out how many mailboxes are already in each database, which I'm doing like this:

#requires -pssnapin Microsoft.Exchange.Management.PowerShell.Admin
$mailboxcount = @{}
Get-MailboxDatabase -Server EXSRV02 | ?{$_.recovery -eq $FALSE} | `
%{$mailboxcount["$($_.storagegroup)\$($_.name)"] = 0;
Get-Mailbox -Database $_ -ResultSize Unlimited | `
%{$mailboxcount["$($_.database)"]++}}
$mailboxcount.GetEnumerator() | sort name

Breaking that down...

I'm not actually running this in the Exchange Management Shell. My profile imports the necessary Exchange snapin to the standard shell (along with a few other things), but I'm just checking that it's registered first by using the #requires statement because otherwise we wouldn't get very far (see my friend Aleksandar's post on #requires for more explanation).

Then we declare an empty hashtable, $mailboxcount, which we're going to use to hold the mailbox databases and the number of mailboxes in each.

In my example script, I'm specifying a server name to the Get-MailboxDatabase cmdlet, but you could equally leave off the -server parameter, which will get all of the mailbox stores (databases) in your Exchange 2007 environment. You could also specify a set of servers by reading them from a file, or passing an array of strings containing server names, to the get-mailboxserver cmdlet and then into get-mailboxdatabase like this:

get-content mailboxserver.txt | get-mailboxserver | get-mailboxdatabase

or

"EXSRV01","EXSRV02" | getmailboxserver | get-mailboxdatabase

That gets all of the databases on the servers that we want to look at, but it also includes Recovery Storage Groups, so we're filtering those out by piping our mailbox databases through...

?{$_.recovery -eq $FALSE}

Next, we're piping each database into a script block by using the foreach-object cmdlet (aliased to %). This script block contains two lines of PowerShell, separated with a semi-colon. The first populates the $mailboxcount hashtable with each of the database names. It does it in a slightly strange manner: $($_.storagegroup)\$($_.name) because this the same format as we'll get from the mailbox's database property and we need them to match up, and also because this produces the most useful output - SERVERNAME\STORAGEGROUP\DATABASE. We're assigning each database an initial value of 0.

That line may be optional to you, depending on how you want this to work. If you want to see any empty databases, you need it in there, but if you've added a new database you're not quite ready to use just yet, you can leave it out and the empty database will be left out of your results (and therefore the allocations in the next phase).

The next line uses the Get-Mailbox cmdlet, specifying the -database parameter to return all the mailboxes for the current database and these are passed down the pipeline to increment the value for that database in the hashtable with

mailboxcount["$($_.database)"]++

The mailbox's database property is enclosed in $() so that it is evaluated before it's treat as the key string, otherwise you'd end up with a hashtable full of MAILBOXNAME.database, with a value of 1. That part of the script takes longer the more mailboxes you have.

That done, we're displaying the contents of the hashtable, which is better viewed sorted, so we're using the GetEnumerator method and sorting by name to get something like:

Name                           Value
----                           -----
EXSRV02\SG01\MS01              199
EXSRV02\SG02\MS02              201
EXSRV02\SG03\MS03              199
EXSRV02\SG04\MS04              200
EXSRV02\SG05\MS05              189
EXSRV02\SG06\MS06              188
EXSRV02\SG07\MS07              200
EXSRV02\SG08\MS08              172
EXSRV02\SG09\MS09              195
EXSRV02\SG10\MS10              183
EXSRV02\SG11\MS11              77

Alternatively, you can sort by value to see the most used databases by using

$mailboxcount.GetEnumerator() | sort value -desc

which will show largest down to smallest, like this:

Name                           Value
----                           -----
EXSRV02\SG02\MS02              201
EXSRV02\SG07\MS07              200
EXSRV02\SG04\MS04              200
EXSRV02\SG01\MS01              199
EXSRV02\SG03\MS03              199
EXSRV02\SG09\MS09              195
EXSRV02\SG05\MS05              189
EXSRV02\SG06\MS06              188
EXSRV02\SG10\MS10              183
EXSRV02\SG08\MS08              172
EXSRV02\SG11\MS11              77

That's a useful script for seeing how many mailboxes are in each database, although you may want to discount the disconnected mailboxes, i.e. those that are waiting to be purged because their associated user object has been deleted (see my earlier post about orphaned mailboxes).

Now on to adding new mailboxes...

Now that we've got that hashtable, we don't need to query the system again for this round of provisioning. All we're going to do is, for each new mailbox we create, grab the database with the fewest mailboxes, increment the value in the hashtable, like so...

$mbdatabase = ($mailboxcount.GetEnumerator() | sort value | select -first 1).key
$mailboxcount[$mbdatabase]++

and this gives us the database to use for the new mailbox in our variable $mbdatabase, which we can give to the Database parameter of the New-Mailbox cmdlet, which will create the mailbox AND the user object for us, or the Enable-Mailbox cmdlet, which will give a mailbox to an existing user.

Update (solution):
A very helpful Microsoft support person told me that there was a problem in this area which was fixed by Exchange 2007 SP1, so the problem is more specifically that I was apparently using a pre-SP1 version of the 32-bit cmdlet, even though the rest of the Exchange 2007 infrastructure was patched to SP1. I've now applied the 32-bit version of Exchange 2007 SP1 to the 32-bit server and everything now works fine.

Note to self - if you've got client tools installed somewhere for remote managment, make sure you patch them as well as the servers you're managing!

Original Post:
Here's a bit of a gotcha that I've not seen documented elsewhere, so I wanted to get it out there for anyone else stumbling across it...

Last week I was prompted by Adam Smith's post to check how many iPhones running the new 2.0 software had begun to use Exchange ActiveSync against our systems. I looked to tweak a script that I'd pulled together previously by editing in PowerShell Plus (my PowerShell tool of choice), but I was working on 64-bit Server 2008 and PowerShell Plus won't use 64-bit plug-ins like the Exchange cmdlets. I decided that it would be easier to edit the script in my old trusty 32-bit Server 2003 machine which has the 32-bit Exchange 2007 Management Tools (from the Microsoft Download Center) installed.

I've worked with those tools in PowerShell Plus frequently in the past - it's a handy environment to develop scripts; although I now run everything in production on the 64-bit server, so I rarely actually use the 32-bit versions of the Exchange cmdlets to do anything. I'd figured that using a "getter" to grab some statistics couldn't do any harm. Guess again!

Every time I ran Get-ActiveSyncDeviceStatistics from from the 32-bit tools, the next time a device would try to use EAS, it'd receive the message "There has been a change made on your server that requires you to re-synchronise all items on your device. Please perform a manual sync." with support code 0x80883001.

When the support queries started coming in shortly after, I initially thought it must be a coincidence since I wasn't making any changes to the server, but I had a nagging feeling that my script must be triggering something in the Exchange infrastructure that was having this effect.

I started testing running the cmdlet against mine and a couple of other mailboxes and true enough it was recreating the problem totally consistently. It was almost by accident that part way through my testing I found myself using a shell on my 64-bit server and the problem stopped occurring. Going back and forth between testing the two: the 64-bit version of the cmdlet is fine; the 32-bit version always causes a problem.

I'm not sure if you'd call this a bug or a perfectly reasonably explainable feature, but it had me stumped for a little while!

My team has started a blog talking about a) the products that we work with, b) the services we provide, and c) anything else that we think would be of interest to people reading about a and b. I'd imagine that at a good percentage of my contributions are going to be looking at PowerShell, so I figured I'd pull together a few bits and pieces that I've written here and there and post an Introduction to Windows PowerShell. This is it...

PowerShell is a command shell and language focusing on Windows system administration. It can be used interactively to get immediate results, or you can write complex scripts and do batch processing. Although it is still not used as much as it should be, PowerShell isn't a brand new product; it's been around for a couple of years and version 2 is currently available in its 2nd Community Technical Preview.

Now that PowerShell is part of Microsoft's Common Engineering Criteria (meaning that product teams pretty-much have to incorporate PowerShell into their new releases), and being incorporated as a feature in Windows Server 2008, you'll see PowerShell usage sky-rocket! (It's worth also saying that Microsoft aren't the only ones adding PowerShell support to their products - VMWare, IBM, Citrix and others see the potential of managing their products this way.)

The thing that sets PowerShell apart from other shells is that it uses pipelines of objects, not of text. It is build on the .NET Framework, but you don't need to have a developer's appreciation of .NET to work with PowerShell. In fact one of the best ways of getting started with PowerShell is to just run it each time you were about to run cmd.exe - many of the things you'd want to do there work in PowerShell. If you've been a *nix admin in the past, you'll find that some of the commands you're familiar with work in PowerShell too.

For example, the PowerShell cmdlet (pronounced "command-let") to list the contents of a folder, Get-ChildItem, has aliases built in, so that you can use either dir or ls in its place. The interesting thing with PowerShell is that it has providers which let you access other repositories (referred to as PSDrives) in the same way as the file system, so you can do this:

cd HKLM:\software
dir

...and see the contents of a registry hive! (Note that if you want to do a recursive directory listing, the parameters are different to the dir in cmd.exe, so you'll want to check the help to see what you can do with the cmdlets)

Give it a go and I'm sure you'll soon find your way around. To get started, Get-Command gives you a list of the available cmdlets; Get-Help [cmdlet] tells you what they do; Get-Member lists the properties and methods of an object; Get-PSDrive lists the PSDrives that are available to you. Knowing those cmdlets is enough to get you quite a distance.

The TechNet Script Center has a load of great resources for IT Pros at and there's a fantastic community building around PowerShell, with a UK User Group (run by Richard Siddaway who is a PowerShell MVP - details on his blog), numerous PowerShell bloggers, and community sites. There are also a bunch of PowerShell books, most of which are pretty good, but if you're just looking for one I'd recommend Lee Holmes' PowerShell Cookbook.

If you don't find that there's support built in to products or PowerShell itself for what you want to do, there may be a 3rd party snap-in that could help. I'm making used of the free Active Directory cmdlets from Quest Software, the free Group Policy management cmdlets from SDM Software and the PowerShell Community Extensions - a large suite of additional cmdlets, providers, functions and more.

I'll leave you with a quick PowerShell example. This is a cut down version of something that we used yesterday to enumerate the members of all the AD groups in a particular OU and save the listing for each group in a separate file named after the group:

Get-QADGroup -SearchRoot "OU=Groups,OU=ISS,DC=campus,DC=ncl,DC=ac,DC=uk" | %{$name = $_.name; Get-QADGroupMember $name | Out-File "$name.txt"}

It has probably wrapped in your browser, but that's just with one line of PowerShell and frankly a good chunk of it is specifying the OU that we're looking in! If you want to run that, you'll just need to change the OU and have the Quest AD cmdlets installed. I won't explain how it works here - I just wanted to show how much you can do with so little PowerShell. How much effort/code would it take to achieve that task another way?!

If you write scripts on Windows systems, you should definitely already have the TechNet Script Center bookmarked as they have a huge amount of high quality resources for the full range of Windows admin scripting technologies (as well as the fun of the Scripting Games). Their PowerShell Script Center is a great hub of links and free tools, articles and tips and should be one of the first stops you make in learning PowerShell.

Two of the more comprehensive resources on Script Center have just been updated:

The Windows PowerShell Owner's Manual, which has previously had chapters on Getting Started, Customizing the Console, Shortcut Keys, Piping and the Pipeline and Running Scripts, has had two additional chapters published - The Windows PowerShell Profile and Windows PowerShell Aliases. This is great material, written with the trademark humour of the Scripting Guys and well worth a read.

The second updated resource is The VBScript-to-Windows PowerShell Conversion Guide. If you're already a fluent VBScript scripter and want to update your skills to PowerShell then this is a useful reference, although I think from the PowerShell purist's point of view it probably isn't the best way to learn PowerShell since there's a paradigm shift that translating VBScript directly doesn't take advantage of. That said, if you know how to do something in VBScript and you want to know how to do it in PowerShell, this is the place to come.

The Conversion Guide has been expanded from just VBScript Commands, with new sections covering Dictionary Object Methods and Properties, FileSystemObject Methods and Properties and Windows Script Host Methods.

There are plenty of examples on the web of how to replace text in a single file using PowerShell, but there may be times when you want to replace some text in a bunch of files; say you've moved a load of scripts to a different drive and some of them have reference to the old drive/folder path in them. It's practically as easy to work with a whole folder as it is with one file.

Firstly, make sure you're working in the folder where the files exist and then it's just a one liner...

cd d:\scripts
dir -name | %{$content = (gc $_) -replace "c:\\scripts","d:\scripts"; sc $_ $content}

Breaking that down, the dir command gets a directory listing for the current folder. (NB dir is just an alias to the Get-ChildItem cmdlet; equally, I could've used ls, which is also an alias). We don't need the whole FileInfo object that Get-ChildItem returns, just the file name, so I'm using the -name parameter.

We pipe those file names to a ForEach loop (% is an alias for the ForEach-Object cmdlet), so we're working with one file at a time. Here we grab the content of each file using the Get-Content cmdlet...

(gc $_)

...so if the current file on the pipeline is test1.ps1 this is the same as us typing Get-Content test1.ps1. This is enclosed in parentheses so that it is done before the replace operator takes effect.

-replace "c:\\scripts","d:\scripts"

...replaces any instance of "c:\scripts" with "d:\scripts", but note the double backslash in the text that's being replaced. This is because the replace operator is searching for the text using a regular expression and the backslash is the escape character, so you need to escape it.

The file's content, with the path replaced, is placed into a variable called $content, then, before we leave the script block that's dealing with each file, we use the Set-Content cmdlet to write the contents of $content into the file whose name is still held in the automatic $_ variable.

Working on a folder tree

If you want to replace the text in all the files within a whole folder structure you can add the -recurse parameter to your dir/ls/Get-ChildItem. However, this will pass the sub-folders themselves (and not just the files contained within) to the ForEach loop, so you'll get errors when you try to Get-Content and Set-Content on a folder. We need to filter the sub-folders out of the pipeline, and in order to do this we need to look at the full object, not just the name...

dir -recurse | ?{!$_.PSIsContainer} | %{$content = (gc $_) -replace "c:\\scripts","d:\scripts"; sc $_.PSPath $content}

These objects that our directory listing returns are filtered by...

?{!$_.PSIsContainer}

...which uses the (? alias to the) Where-Object cmdlet to check the PSIsContainer property and only allow the objects which are not (hence the !) containers to pass along the pipeline (so we just have the files, not the folders).

The other change that I've had to make is interesting: while Get-Content is happy to be given a FileInfo object as a parameter, Set-Content is not. To get round this, I've picked out the PSPath property of the file (the file's path, fully qualified with the provider), which Set-Content is happy to accept.

I've been called out by Richard to fill in Steven Murawski's Scripting/Sysadmin Meme, so here it is...

How old were you when you started using computers?

I'm only guessing here, but I think I was about 8. I was in junior school anyway.

What was your first machine?

The first machine I used was the BBC Micro Model B at school, then my friend got a BBC Master with a whole 128k which we put to good use playing Elite. The first machine that was actually mine was the spiritual successor to the BEEBs, the Acorn Archimedes A3000.

What was the first real script you wrote?

The first code of any kind I wrote was in BBC BASIC - it was a text adventure game and was neither long nor good. I'm not sure what my proper sysadmin script was, but I have a feeling that it could well have been one that populated our brand new Active Directory with user accounts in 1999. A bit like jumping in at the deep end!

What scripting languages have you used?

I mostly used VBScript (with a bit of JScript from time to time) for a bunch of years before PowerShell came along. Now it's all PowerShell, all the time.

What was your first professional sysadmin gig?

Well I (along with a friend) was the IT support for the school (when I was about 8) because the teachers didn't know what they were doing, but I wasn't paid so it was hardly professional, although it did get me out of assemblies, so that was some reward. Then I suppose I could count some work I did on some Apple machines in the theatre/sports centre where I worked in my teens. It's probably more reasonable to say the job that I've been in for the last 9 years, which is a proper sysadmin gig.

If you knew then what you know now, would have started in IT?

If I knew then that all the hard slog around the cluster rooms, building hundreds of NT4 workstations with Ghost boot floppies and disk images on CD, would lead on to the success and growth of our systems in the Active Directory era, and that we'd be able to expand into different areas and services with basically the same number of people running them; firstly I wouldn't have believed you, but I think I'd have been as excited about being part of the industry as I am now! This isn't a great job for someone who fears change, but if you love technology, it's a great roller coaster ride!

If there is one thing you learned along the way that you would tell new sysadmins, what would it be?

Definitely get involved in the IT community. Join user groups, go to the TechEd event in your region (or, what the heck, why not another region) and try to learn as much from people in the hallways or the dining room as you do in the formal sessions (I think a week at TechEd is better value than any training course). Communicate with peers any way you can. If you're not in a position to meet people physically, chat online with them; comment on blogs, participate in online forums. It may not pay off immediately, but it will pay off.

What’s the most fun you’ve ever had scripting?

Ever since I started to really get PowerShell, it's been almost non-stop fun. Finding out how very much you can achieve with how very little code is like a game on top of the puzzle of actually solving the original problem.

Who am I calling out?

Jonathan Walz and Chris Warwick

If you want to access the OS version of a computer you've got a few options. The easiest way in PowerShell is to use the Get-QADComputer cmdlet from the excellent free set of Quest AD cmdlets. However, you'll find that you can't tell the difference between Windows Server 2003 and Windows Server 2003 R2.

In order to find out which of your servers are running R2 (if you want to audit your licences for example), you'll have to use WMI and access the OtherTypeDescription property of the Win32_OperatingSystem class. This one-liner will do the job for you (just alter the search root to match your Active Directory structure):

get-QADComputer -searchroot "yourdomain.com/servers/sql servers" | `
%{gwmi -Class win32_OperatingSystem -Namespace "root\CIMV2" -ComputerName $_.Name `
-ea silentlycontinue} | `
sort version,othertypedescription -Descending | `
ft @{label="SERVER";expression={$_.csname}},@{label="OS";expression={$_.caption}}, `
@{label="R?";expression={$_.othertypedescription}}, `
@{label="SP";expression={$_.servicepackmajorversion}} -a

What it will give you is a handy table like this:

SERVER    OS                                                       R? SP
------    --                                                       -- --
SPURS     Microsoft(R) Windows(R) Server 2003, Standard Edition    R2  2
PISTONS   Microsoft(R) Windows(R) Server 2003, Standard Edition    R2  2
LAKERS    Microsoft(R) Windows(R) Server 2003 Standard x64 Edition R2  2
CELTICS   Microsoft(R) Windows(R) Server 2003, Standard Edition        2
CAVS      Microsoft(R) Windows(R) Server 2003, Standard Edition        2
HORNETS   Microsoft(R) Windows(R) Server 2003, Standard Edition        2

Footnote:
That's fine if all of your servers are going to allow that incoming WMI query. You may have servers which are tightly locked down and you'd prefer not to open them up. If that's the case, you can do what we do and query the WMI locally on the server and write the results out to a database as part of a startup script (we currently do this in VBScript). If you take this approach, especially if you have a lot of servers, be sure to make the date part of the record so you have an idea how good it is.

I'm writing this to help anyone wondering about PowerShell, and those just getting started and struggling with the paradigm-shift that the PowerShell pipeline represents. What does it mean to have a pipeline of objects? It's a prominent bullet-point in the PowerShell marketing, and while it may instantly make sense to developers and computer scientists, it's not a straight forward concept for everyone. I thought of an analogy which I think will help...

Say you're on your way home from work and your spouse calls to ask you to stop on the way for a new light bulb to replace a dead one in the bed-side lamp. In order to make sure that you get the right bulb, your spouse is going to have to describe it in a fair amount of detail: bulb style=candle, bulb height=short, wattage=40w, fitting type=screw, fitting size=small, glass type=pearl, glass col=white. Basically, your spouse is going to give you a load of strings of text to describe the different properties of the bulb that you need.

I'm going to assume we have a cmdlet (a PowerShell command, pronounced "command-let") called Buy-LightBulb and we'll use PowerShell syntax to describe what our spouse is saying on the phone, but this basically is the pre-PowerShell way of working:

Buy-LightBulb -bulbstyle candle -bulbheight short -wattage 40 -fittingtype screw -fittingsize small -glasstype pearl -glasscol white

Now let's imagine that we got home before our spouse got round to calling. Instead of describing all of those properties for the replacement bulb, they could give us the old one as a reference. After all, it has all of those properties.

So let us assume that we've got the old bulb in a PowerShell variable called $oldbulb. If we piped $oldbulb to Get-Member, we'd see something like this, showing that it has the properties and methods that we'd expect from a light bulb:

PS > $oldbulb | Get-Member

   TypeName: System.Illumination.LightBulb

Name        MemberType   Definition
----        ----------   ----------
bulbstyle   Property  bulbstyle=candle
glasstype   Property  glasstype=pearl
wattage     Property  wattage=40
....

We can pass (pipe) that light bulb object to the Buy-LightBulb cmdlet with the result that we'll buy a new light bulb with the same properties as the old one (except that we'd hope it will work!). If we assign that pipeline to a variable $newbulb...

$newbulb = $oldbulb | Buy-LightBulb

...then $newbulb will be a new light bulb object with the same properties as the old bulb. This is the PowerShell way of working.

Still, our spouse hasn't forgotten the time we came back from the store with the wrong sized refuse sacks, so we've got to to pass the new bulb through their Check-SpousePurchase cmdlet.

Before PowerShell, you'd expect that Buy-LighBulb would have returned some code to signify success, or the name of the light bulb, or perhaps a set of strings describing the properties of the light bulb we've bought. In order for your untrusting spouse to accept the product you've bought, you'd have to give strings describing all the properties of it to Check-SpousePurchase.

In PowerShell however, the results of Buy-LightBulb is a rich .Net object of type System.Illumination.LightBulb. The Check-SpousePurchase cmdlet can take this object from the pipeline, so the whole process can be expressed in PowerShell by passing objects along the pipeline and never having to describe properties with strings...

Your spouse hands you the bulb to replace, you purchase a replacement and hand the new bulb back to your spouse who confirms it's the right one and we avoid the problem we had with the refuse sacks were we didn't have a full understanding of the properties and bought the wrong ones:

$oldbulb | Buy-LightBulb | Check-SpousePurchase

Really, if you forget about light bulbs, the difference is between passing the physical object from one step to the next, or describing over the phone what has come out of one stage to go into the next. I hope that's helped clear things up for some of you and also shown why pipelines of objects have significant advantages over passing strings from one command to another.

The ScriptingAnswers.com University Windows PowerShell Full Set, which I blogged about a couple of weeks ago, arrived yesterday. We only got round to sorting out the purchase order on Tuesday, so that delivery has been extraordinarily fast!

Not sure if I'll get a chance to try it over the weekend, but I should be able to provide something of a review in the next week or so.

If your enterprise has a high turnover of people, then at any one time you'll likely have numerous disconnected mailboxes on your Exchange Servers. That's because Exchange, by default, will not purge the mailbox until 30 days after the user it was connected to has disappeared from Active Directory, i.e. it has become orphaned.

Keeping those mailboxes there for a month can be a handy safety net, so I'm not suggesting purging them sooner (although that may suit you), but if you're going to allocate new users to mailbox stores based on how much space is in use/available it can be handy to look at how much space disconnected mailboxes are taking up, i.e. how much white space will be freed up in your .edb file after the disconnected mailboxes are purged (and an online defrag has taken place).

Since we have to talk to Exchange 2003 and Exchange 2007 in different ways, I'm going to deal with them separately, then if you want to combine them into a single script, you can (it's just a case of not re-initialising the hashtable).

Ok, so I'm going to assume that we've got a text file Ex03Servers.txt which contains a list of the Exchange 2003 servers we want to query. We need to setup a hashtable to hold the results, but then the rest of the work is done by a one liner:

$space = @{}
get-content Ex03Servers.txt | `
%{gwmi -co $_ -namespace "root\MicrosoftExchangeV2" -query "SELECT * FROM Exchange_mailbox WHERE DateDiscoveredAbsentInDS IS NOT NULL" | `
%{$space[$_.ServerName+"\"+$_.StoreName]+=$_.Size}}

Thanks to Gaurhoth in the #powershell IRC channel on irc.freenode.net for pointing me in the right direction for finding disconnected mailboxes on Exchange 2003 with WMI.

$space now contains the amount of free space and you can just type $space to see it, although you'll get the output in a random order, so you may want use the enumerator to sort by size:

$space.GetEnumerator() | Sort value -desc

Or by server and store name alphabetically:

$space.GetEnumerator() | Sort name

So, to do the same thing for disconnected mailboxes on Exchange 2007, do this:

$space = @{}
get-content Ex07Servers.txt | `
%{get-mailboxstatistics -Server $_ | `
?{$_.DisconnectDate -ne $null} | `
%{$space[$_.Database]+=$_.TotalItemSize.Value.ToKB()}}

Most Exchange admins will have learned, to their distress or delight, that Exchange 2007 has PowerShell at the core of its management. In fact, if you're not aware of that, the GUI seems really odd - you've got to adjust your thinking somewhat and remember it's actually closer to the command line than the old Exchange System Manager. Actually, that was really the catalyst for me getting into PowerShell so much.

Anyway, Exchange 2007 and PowerShell work great together and I wish that I was in a position to take full advantage, but I guess like a lot of people, we're in the process of migrating to Exchange 2007 and will have some Exchange 2003 servers for a while yet. That means that we have our hands tied to a certain extent, but it doesn't mean that we can't do a lot with PowerShell!

The PowerShell function that I've written here is a good example of how you can use the new Exchange 2007 cmdlets to a certain extent and the limitations of that backwards compatiblity. Since we get a lot of requests for quota increases, what I've set out to do is find out the quota limits and current usage when given a username. We also have a slightly strange situation with SMTP addresses (more on that later), so I'm listing those out, as well as the mailbox location...

function get-mailboxinfo ([string]$user = $(Throw "USAGE: get-mailboxinfo username"))
{
$usermb = Get-Mailbox $user
"{0,-15}{1,-2}{2,-20}" -f "User",":",$user
"{0,-15}{1,-2}{2,-40}" -f "Name",":",$($usermb.DisplayName)
"{0,-15}{1,-2}{2,-20}" -f "Server",":",$($usermb.ServerName.ToUpper())
"{0,-15}{1,-2}{2,-40}" -f "Database",":",$($usermb.Database)
"-- SMTP Addresses --"
($usermb.EmailAddresses |?{$_.IsPrimaryAddress -and ($_.PrefixString -eq "SMTP")}|select addressstring).AddressString + " (primary)"
$usermb.EmailAddresses |?{!($_.IsPrimaryAddress)}|select addressstring | %{$_.AddressString}
"-- Quota & Usage --"
if ($usermb.UseDatabaseQuotaDefaults -eq $TRUE){
    write-Host "Using database default quotas"
    $WarningPreference = "SilentlyContinue" #get-mailboxdatabase generates warnings if .edb in a root directory
    #Need to use get-mailboxdatabase in this way to work with Exchange 2003...
    #If only using Exchange 2007, get-MailboxDatabase $usermb.Database is better...
    $mbdatabase = Get-MailboxDatabase -IncludePreExchange2007 -Server $usermb.ServerName | ?{$_.name -eq $usermb.Database}
    $iwq = $mbdatabase.IssueWarningQuota.Value.ToKB()
    $psq = $mbdatabase.ProhibitSendQuota.Value.ToKB()
    $psrq = $mbdatabase.ProhibitSendReceiveQuota.Value.ToKB()}
else{
    $iwq = $usermb.IssueWarningQuota.Value.ToKB()
    $psq = $usermb.ProhibitSendQuota.Value.ToKB()
    $psrq = $usermb.ProhibitSendReceiveQuota.Value.ToKB()}
if ($usermb.RecipientTypeDetails -eq "LegacyMailbox"){
    #Use WMI to find size of Exchange 2003 mailbox
    $filter = "MailboxGUID='{" + $usermb.ExchangeGuid + "}'"
    $wmimb = gwmi -ComputerName $usermb.Servername -Namespace "root\MicrosoftExchangeV2" -Class "Exchange_mailbox" -filter $filter
    $mbsize = $wmimb.size}
else{
    #WMI MicrosoftExchangeV2 namespace replaced by get-mailboxstatistics cmdlet in Exchange 2007
    $mbsize = (Get-MailboxStatistics $user).TotalItemSize.Value.ToKB()}
"{0,-15}{1,-2}{2,7}" -f "Using (KB)",":",$mbsize
"{0,-15}{1,-2}{2,7}{3,8}{4,8}" -f "Quotas",":",$iwq,$psq,$psrq
"{0,-15}{1,-2}{2,7:p}{3,8:p}{4,8:p}" -f "Quota %",":",$($mbsize/$iwq),$($mbsize/$psq),$($mbsize/$psrq)
}

What that will give you, is a quick report like this, irrespective of where the mailbox is:

User : fbloggs
Name : Fred Bloggs
Server : EXSERVER1
Database : Mailbox Store 6
-- SMTP Addresses --
fred.bloggs@yourdomain.com (primary)
fred.bloggs@marketing.yourdomain.com
-- Quota & Usage --
Using (KB) : 385911
Quotas : 500000 600000 1000000
Quota % : 77.18 % 64.32 % 38.59 %

You may not find the SMTP address list so helpful, but our users each have four (and an X400 address) like:
username@theexchangesystem.domain.com (initially set as the primary by the recipient update policy)
username@forestrootdomain.domain.com
emailname@shortdomain.com (external address with abbreviated domain name, so most used)
emailname@longdomainname.com (the primary external formal email address)
so you can see how it's useful in our case!

If you want to take advantage of Exchange 2007 and the extra info that you can easily get about those mailboxes, add this into the function and wish that migration would move a little faster...

if ($usermb.RecipientTypeDetails -eq "UserMailbox")       
    {get-MailboxStatistics $user | FT ItemCount,StorageLimitStatus,@{label="TotalItemSize (KB)";expression={$_.TotalItemSize.Value.ToKB()} },LastLogonTime -auto
    write-Host "Largest folders for $($user):"
    get-MailboxFolderStatistics $user | Sort foldersize,folderpath -desc | Select-Object -first 10 | FT FolderPath,ItemsInFolder,@{label="FolderSize (KB)";expression={$_.FolderSize.ToKB()}} -auto
    }

I mentioned 3rd-party Outlook add-in Xobni a while ago, and have been using the beta since then. I received an email from them today announcing the general availability of the product. The launch is accompanied by a New York Times article only a few days after Xobni appeared on Georgina's TechNet blog - I wonder how many start-ups can claim both of those accolades for their new product?!!

I haven't particularly used Xobni as a search tool as I'm happy with the results from Outlook 2007's own search, but I do like a few things about it. I find the at-a-glance access to recent conversations and attachments shared with a contact handy, and also the way the sidebar changes to show your most recently viewed message when you change your view to the calendar (it's very useful when that message is asking for a meeting, causing you to consult the calendar). Even if you don't want to take up screen real estate with the sidebar, in its collapsed form it provides more useful information than Outlook's own To-Do bar (in collapsed mode), which I used to use. I'm sure that others will find it useful in other ways - if you're an Outlook user it's certainly worth a try - you may well find it enhances your use of email in ways you never thought it needed enhancing!

I've just finished watching the samples of Sapien's new ScriptingAnswers.com "University" Class-On-Disc on Windows PowerShell Fundamentals. The HD video looks great and the content sample suggests that Don Jones' teaching would be well worth the price they're asking.

The spiel says '"University" titles are full-length self-paced training courses presented in a custom Adobe Flash interface. They include animations, hands-on activities, self-assessment quizzes, and other elements designed to duplicate the classroom experience as closely as possible - right on your desktop.'

I'm going to look to get the full PowerShell set (Fundamentals, Intermediate and Advanced) - currently available for $239 - a LOT cheaper than "the classroom experience"!

* This isn't a paid commercial ;-) I am in no way affiliated to Sapien Technologies although I did meet Don Jones once and found him to be a thoroughly decent guy. :-)

The FAQs on the departmental website at work is being replaced by a Tips section and around the same time the was a request for submissions for our new staff newsletter. This was my contribution...

Windows Live Photo Gallery

Microsoft provides a suite of free software under its Windows Live banner which provide enhancements to software included in Windows Vista, although the good news for Windows XP users is that you can take advantage of them too. The most significant piece of the suite is Windows Live Photo Gallery which is a simple to use, but very useful tool for importing photos from your camera, organising and editing and sharing them. The photo import tool is one of the best available, allowing you to easily group the photos on your camera into groups by the date taken, and you can easily alter the groupings so you get all the shots from last weeks holiday in one folder and the week before in a different one, or a different folder for every day or whatever you choose. Then you can rate and tag your photos, so you can easily show off just the 5-star snaps of your holiday in a slideshow, burn to cd, or upload them to Flickr. There's also an excellent panorama feature, which doesn't just work for creating wide landscapes - you can stitch photos horizontally and vertically to make a giant image and it doesn't matter if they're taken in portrait, landscape of at a jaunty angle - it'll work out how they all fit together. If you're not already using some other software to manage your digital photos on Windows, this is a really worthwhile download!

For more information about Windows Live Photo Gallery, got to http://get.live.com/photogallery/overview

Other applications in the Windows Live Suite that you may find useful are Windows Live Mail and Windows Live Writer. Windows Live Mail replaces Outlook Express on Windows XP or Windows Mail on Windows Vista and offers a number of enhancements. You can access multiple email accounts, including Hotmail and Gmail, you RSS news feeds and Windows Live Contacts (including your MSN/Live Messenger contacts) in one place. If you use Hotmail, this is easily the best way to access your mail and you can read and compose messages while you're offline. Window Live Writer is an editor for blog entries. If you have a blog, then you may want to give it a try since it's widely considered to be the best application of its kind and supports direct uploads to many of the most popular blogging platforms.

You can download Windows Live Photo Gallery and the rest of the Windows Live Suite from http://get.live.com

Take your files with you without a USB stick with Windows Live SkyDrive

There are many different alternatives for storing your files on the internet and many of them have similar features, so we don't have any reason for recommending Windows Live SkyDrive other than if you already use Hotmail or Windows Live Messenger (previously MSN Messenger), you've already for a SkyDrive account. With SkyDrive you can upload up to 5GB of files to your personal, shared or public folders, so you can keep some files private, share some with your friends and other with the whole internet. The only restriction is that the maximum single file you can upload is 50MB. Try it out at http://skydrive.live.com

Synchronise files between multiple computers and access them from anywhere with FolderShare

If you more than one PC, or even a PC and a Mac, perhaps a work computer and a home computer or a laptop, and you frequently find yourself moving files between them, then Windows Live FolderShare is a free service which may be of great help to you. Just install the client on your computers and then use the website to choose folders on those machines that you want to be synchronised and it'll just happen quietly in the background as long as both computers are on, for files up to 2GB. It works even if you have a firewall or if your computer is on a private network. A great additional feature is that if your computer is switched on with the FolderShare client running, you can logon to the FolderShare website to get access to any of your files on that computer from any web browser!

Find out more, and find the download links at http://www.foldershare.com/

Tab your way around

If you're doing work that involves a lot of typing, like filling in a web form, or even compiling an email in Outlook, then taking your hand away from the keyboard to click in the next box with the mouse can disrupt your flow. You can often get through a form a lot quicker by hitting the TAB key to move the cursor to the next box. Tabbed through too quickly? No problem, hold the SHIFT key and hit TAB to move backwards through the elements of the page or application.

A lot of the time you can avoid taking your hands off the keyboard at all. You can move through your open applications by holding the ALT key and hitting TAB, and yes, if you go past the application you want, you can keep holding ALT and SHIFT+TAB back to the previous application. On Windows Vista, you may be able to get a better view of the applications as you switch through them by using the Windows Logo key and TAB instead of ALT+TAB, but that is dependent on having that key and a graphically capable computer.

Learning the standard Windows keyboard shortcuts can be a real time-saver. Here's a quick overview of some more:
F1 : Show help
CTRL + A : Select all
CTRL + X : Cut
CTRL + C : Copy
CTRL + V : Paste
CTRL + Z : Undo
CTRL + Y : Redo
CTRL + S : Save
CTRL + ESC : Open Start menu (if you don't have a Windows logo key)
ALT + F4 : Close the current window
WIN + M : Minimize all windows

This one uses the mouse if you have one with a scroll-wheel:
CTRL + SCROLL : Zoom in/out (and also a quick way to change the view in Windows Explorer)

Where has the menu bar gone?

Newer versions of some Microsoft applications are missing the familiar menu bar (where you usually see menus such as File, Edit, View and Help). Prime examples of this are Windows Explorer in Windows Vista and the latest versions of Internet Explorer and Windows Media Player (7 and 11 respectively). Any amount of clicking or right-clicking around with the mouse won't find some of the options that are on these menus. The secret is to use the standard keyboard shortcut for accessing menu items - the left ALT key.

You can access the specific menus with their individual keyboard shortcut, e.g. ALT + F for the File menu or ALT + V for the View menu.

Use portable applications

Portable applications are most easily described as applications that can be run from a removable drive (like a USB flash drive), and take all their application data (settings) with them. There's a number of good reasons for using them:
1) You don't need to install them on a PC, so you don't need to have administrator rights.
2) You can take them with you, so you don't have to install an application and get it set up just how you like it multiple times.
3) Say you've written a web page and it looks fine in Internet Explorer, but you need to see how it looks in Firefox and Opera, you can use the portable versions without having to install them.
4) The more you install/uninstall software, the more likely you are to see decreased performance (from system registry growth and disk fragmentation).

There are portable versions of applications of practically every type. For example, all of these are available in versions which have been packaged to be portable:
Firefox (web browser with vast support for extensions)
VLC Media Player (media player which supports a large range of formats)
GIMP (image editor)
Audacity (audio file editor)
Foxit Reader (a great lightweight PDF file reader)
Skype (for making calls via the internet)
7-Zip (file compression utility)
FileZilla (FTP application)
uTorrent (bit torrent client)

A good place to start looking for portable applications which may be of use to you is http://www.portableapps.com and Wikipedia has a comprehensive list at http://en.wikipedia.org/wiki/List_of_Portable_Applications

I was just running this bit of PowerShell and it occurred to me that other than in the demo script that I presented last December, I hadn't actually posted this on my blog.

To find out the free disk space on the servers in an OU containing SQL Servers:

([ADSI]LDAP://OU=SQL Servers,DC=yourdomain,DC=com).psbase.Children | ?{$_.ObjectCategory -like "*computer*"} | %{Write-Host $_.name; gwmi win32_LogicalDisk -comp $_.name -filter "DriveType=3" | ft DeviceID, @{Label="Gb Free(Approx.)";Expression={[int]($_.Freespace/1GB)}} -a}

To use this in your environment, just change the LDAP path to something relevant to your Active Directory.

This is very similar to what was presented by Don Jones in an article in TechNet Magazine (I just happened to write this a week or two before that article arrived in the January issue of the UK version of the mag). The main difference was that Don was looking at a list of servers from a text file, but since the SQL Servers that I was interested in were all in a particular OU, I could just look in there and not have to keep a list up to date in a file as servers are added/removed.

So what this does is look at the child objects in the SQL Servers OU (using psbase to expose .Children, which is obscured by PowerShell's ADSI implementation), and filters the objects to only pass computers - there's no need to check free disk space on users/groups/etc!

([ADSI]LDAP://OU=SQL Servers,DC=yourdomain,DC=com).psbase.Children | ?{$_.ObjectCategory -like "*computer*"}

Then, for each of these computers we do two things. Firstly we write the computer's name out, then we look at the logical disks with WMI. We need to filter on DriveType to only pick up local fixed disks. Here I learned from Don that I could use the filter on the Get-WmiObject cmdlet, because I originally had:

gwmi win32_LogicalDisk -comp $_.name | ?{$_.DriveType -eq 3}

Finally, I'm writing each of the drives out in a table, with the free space in Gb, since I'm not really interested in a more granular view than that. The output looks a bit like this:

SQL1

DeviceID Gb Free(Approx.)
-------- ----------------
C:                     15
D:                     33
F:                    125

SQL2

DeviceID Gb Free(Approx.)
-------- ----------------
C:                     12
D:                     15
F:                     37
G:                     59
H:                    100

SQL3

DeviceID Gb Free(Approx.)
-------- ----------------
C:                      1
F:                     21
G:                     33
H:                     66

Looks like I'd best have a look at the system disk on that 3rd server!

Until now, I guess most Windows sys admins running Vista have been managing the various aspects of Active Directory, Group Policy, DNS, etc by opening a remote desktop on a server and running the admin tools there. Well Microsoft has finally released the Vista equivalent of adminpak.msi to manage roles and features on Windows Server 2008, including Server Core.

This requires Vista SP1 (but you'd already installed that, right?) and there are 32 bit and 64 bit versions available.

Once you've installed it, you'll need to go into the Programs and Features Control Panel applet and switch them on, then they'll appear in your Administrative Tools.

Last weekend one of our Exchange 2003 servers shut itself down when the drive holding the transaction log files filled up. That shouldn't have happened, so there was clearly something wrong. On replacing the disks with ones twice the size and resuming the Exchange service on the server we started seeing the logs for one particular storage group growing at a rate of a gigabyte every 10 minutes!

In those circumstances, the thing to do, before you run out of disk space, is to enable circular logging, although having done the math, we worked out that we could full backups, truncating the logs, for that storage group frequently enough to not switch to circular logging. However, we needed to resolve the problem as quickly as possible.

There were no errors in the event logs on the server or on MOM to help up isolate the cause of the problem, but by selectively dismounting the mailbox stores we were able to narrow down the source of the problem to a single database. Unfortunately that mailbox store housed the mailboxes for several senior people, so we wanted to keep downtime to a minimum.

On consulting the Education Support Centre and Microsoft UK's Eileen Brown, both suspected the same cause - a corrupt OST file where someone was running Outlook in Cached Exchange Mode. ESC had seen this problem once before, with the OST file of an Outlook 2007 user. Knowing that relatively few users have migrated from Outlook 2003 to 2007 we decided to look at them first.

You can find the users connected to a mailbox store, the client computer and the version of the client they are using with a single line of Powershell:

gwmi Exchange_Logon -namespace root\MicrosoftExchangeV2 -computername Ex01 -Credential (get-credential) | where{($_.LoggedONuserAccount -ne "NT AUTHORITY\SYSTEM") -and ($_.Storename -eq "Mailbox Store X")} | sort ClientVersion,LoggedOnUserAccount | ft LoggedOnUserAccount,ClientName,ClientVersion -a | out-file userClientVersion.txt

You'd just need to change the server name and mailbox store name to run this on your Exchange system. You don't have to run it from an Exchange server, but you will need to give it the credentials of an Exchange administrator account when prompted.

Just to reiterate - this was an Exchange 2003 server. Management of Exchange 2007 may be built on PowerShell, but that's not to say that PowerShell isn't useful to you if you're running Exchange 2003.

Fortunately for us the output produced gave us a short list of potential culprits using Outlook 2007, so we were able to call them up and ask them 1) if they were running in cached mode, 2) if they'd noticed any problems, and 3) to close Outlook. It only took a small number of calls to find the user with the corrupt OST file. If that hadn't been the case, we could have selectively disabled MAPI access for the users on that mailbox store, again using PowerShell.

Incidentally, it doesn't appear to me that it is possible to deny access using Cached Exchange Mode on a mailbox. The book "Professional Windows PowerShell for Exchange Server 2007 Service Pack 1" seems to suggest that this can be done with the Set-CASMailbox cmdlet, but in fact I find that the opposite is true - you can disable connections to the mailbox when the client is not using Outlook in Cached Exchange Mode. The way to disable Cached Exchange Mode is via GPO applied to the client.

I've been a bit behind on my RSS reading the last few days, but I was very pleased this morning to read the announcement that my favourite PowerShell development environment, PowerShell Plus has come out of beta.

I used PowerShell Plus to write my solutions for the Scripting Games and found it to really suit the way I like to work with PowerShell. It's great that they've made a commitment to keep it free for non-commercial use, so students and enthusiasts can make use of this great tool, even when the licence cost ($79.00) is very reasonable anyway!

What I especially like about it is the ability to very quickly iterate through small changes in the editor and see the results in the hosted shell, with a clear view of the value of my variables as I go. Plus the ability, especially when working with one screen, to have something open in the background and PowerShell Plus semi-transparent in the foreground, is a feature that I'm finding a lot more useful than I ever expected!

I've been looking forward to playing with Internet Explorer 8 for a while, so it's a little surprising that nearly 24 hours after Microsoft announced at MIX that the beta is available for download, I still haven't bitten the bullet and installed it. That's just because I've got my main desktop machine setup just nicely and my new laptop (more on that later) is still practically pristine, so I don't really want to install an early beta on either of them. That said, I get the impression that unless you're developing sites to take advantage of IE8 there isn't a great reason to use it yet. I think that'll change when some sites are altered to use some of the new features. I didn't know what to expect, but so far I'm neither disappointed nor blown awa