Monthly Archives: June 2011

Blank Page in OWA 2010

If you’re anything like me there will be times when you’re so busy (or maybe a little lazy) you might just count hope on the fact that a Microsoft install will check installation prerequisites and warn / install them for you.

Unfortunately Exchange 2010 isn’t one of those installations.  Using a default install of Windows Server 2008 R2.  I performed an installation of Exchange Server 2010.  Using only the pre-installation checker during the installation process I installed only what was requested to get Exchange 2010 to install.  For the most part this was fine.  It gave me a functioning Exchange 2010 test server.

It wasn’t till I tested OWA that I found it didn’t install or notify me of all the prerequisite web components.

When I browsed to OWA I was redirected to https://exchangeserver.local/owa/auth/logon.aspx?url=https://exchangeserver.local/owa&reason=0

Fortunately the fix was rather simple.  It required two PowerShell commands and no Exchange service restarts.

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart

Update Rollup 3 for Exchange Server 2007 SP3 fails

Over this weekend I had to install Update Rollup 3v2 for Exchange 2007 SP3.  Installation went fine on our Windows 2003 Operating Systems.  When I came to applying the Rollup on our Windows 2008 R2 servers I hit a snag.

When I went to install the patch, the installation wizard would get to the point of stopping services and then roll-back.  It would then display the following message.

Setup Wizard for Update Rollup 3 for Exchange Server 2007 (KB 935999) ended prematurely because of an error. Your system has not been modified. To install this program at a later time, please run the installation again.

Update Rollup 3v2 has some known issues (  The first issue relates to OWA –not my problem.  The other relates to the installation which produces the same error message I received.  If the %SYSTEMDRIVE%ExchangeSetupLogs folder has been deleted, renamed, or moved from the original Exchange installation it can produce this error.  The fix is to restore this installation folder or to create a new one.  A quick check and the folder did exist in my scenario.  Never the less I tried to rename the folder and create a new once with the same name.  Unfortunately the installation once again failed produced the same error.

My next step was to enable Windows Installer Logging. This can be done via the registry or by going to Microsoft at the following URL and selecting the link to enable logging.  This will run a small msi installer that will make the necessary registry changes.  It can also be switched off using this same method.

Once logging was enabled I re-ran Update Rollup 3v2.  When the installation failed again I went to the command prompt and typed the following, ‘cd %temp%’. This took me to the location of the Windows Installer log file.  After some investigating through the log I noticed a line indicating that I might have insufficient permissions.

Now I was logged in as an Enterprise Administrator so that couldn’t have been my issue.  One thing that I knew could cause administrator permission issues was UAC -which was on.  So I turned it to ‘Never Notify’ which is effectively off.  This required a reboot which I performed.

Once the server was restarted with UAC off I tried the installation again and Voilà.  The installation wizard was able to stop services and perform a successful patch.  At the completion of the wizard I turned UAC back on to its default setting and performed another reboot.


Server Specs
Windows 2008 R2 Enterprise SP1
Exchange Server 2007 SP3

Update Rollup 3-v2 for Exchange Server 2007 Service Pack 3 (KB2530488)

How to enable Windows Installer logging

Known Issues

Registry Changes to enable logging
Reg_SZ: Logging
Value: voicewarmupx

Dude, Where’s my mail statistics?

One thing that really bugged me when Exchange 2007 was released was the removal in the GUI to view mailbox size and total items.  I can’t figure out why?  Though I’m sure there is something written in 3pt text in an obscure TechNet article somewhere?!?!

In Exchange 2000/3 you would drilled down to your Storage Group / Mailbox Store / Mailboxes.  In Exchange 2007/10 it just doesn’t exist.  So how to you get this information?  PowerShell to the rescue… again.  Just another clear indicator that Microsoft wants us using PowerShell more and more.  Using Get-MailboxStatistics we can retrieve this basic information and so much more.


Running the Cmdlet by itself without any parameters will list DisplayName, ItemCount, and StorageLimitStatus for all mailboxes.

We can narrow it down to one user by using the following script.

Get-MailboxStatistics –identity “test.user”

If we want to replicate something similar to what we got in Exchange 2000/3 we can use the following script

Get-MailboxStatistics | ft DisplayName, LastLoggedOnUserAccount, TotalItemSize, ItemCount, LastLogonTime

Using the Format-Table cmdlet we can add a number of different columns in addition to the five above.  Below are columns we can display and filter on.


There are a few things we can now do to clean up our report.  TotalItemSize is returned to us in Bytes –not very user friendly.  So we can convert this to MB.  We can also sort our results by this column as well.

Get-MailboxStatistics | sort totalitemsize –Descending | ft DisplayName, LastLoggedOnUserAccount,@{n="Total Size (MB)";e={$_.totalitemsize.value.toMB()}}, ItemCount, LastLogonTime

So now we have something very similar like the old Exchange System Manager would have provided us on the screen.  In those days we would simply right click on our Mailbox container and select Export.  We can easily achieve the same thing with PowerShell.  Many people just redirect this output to a text file –which is fine.  The better way is to pipe it to a CSV file

Get-MailboxStatistics | sort totalitemsize –Descending | select-object DisplayName, LastLoggedOnUserAccount,@{n="Total Size (MB)";e={$_.totalitemsize.value.toMB()}}, ItemCount, LastLogonTime | Export-CSV –path ‘c:tempMailboxstats.csv’

Updated: The above line has been modified to include select-object instead of format-table due to using the Export-CSV cmdlet.

We now have a nice comma delimitated output file already sorted by Mailbox size.

Get-MailboxStatistics is a rather simple and easy to use cmdlet.  Once you become comfortable using the cmdlet, you can have a number of pre-defined scripts ready to run just how you like.

If you have a lot of mailboxes and want to disregard mailboxes below a certain size you could filter on TotalItemSize.  The below example will only return mailboxes greater than 100MB.

Get-MailboxStatistics |where {$_.TotalItemSize -gt 100MB} | sort totalitemsize | select DisplayName,ItemCount,@{n="Total Size (MB)";e={$_.totalitemsize.value.toMB()}} |ft -AutoSize

At a later stage I’ll touch on how to get this report to run to a schedule and email the output to yourself or a manager.


Exchange 2003 Mailbox view 

Dynamic Distribution Groups –dynamically disturbing

If you haven’t seen or used Dynamic Distribution Groups (DDG) in Exchange before, which rock have you been hiding under?  DDG has been around since Exchange 2007 and its precursor Query-based Distribution groups way back since Exchange 2000.  QBDG never seemed to get too much attention.  With the introduction of Exchange 2007 and PowerShell it’s become a lot easier to use and manage.

DDG works by querying Active Directory for object attributes. For example, Company Name or Department.  So the foundation of fully functioning DDGs is having an actively updated and maintained AD.  As everything Exchange, you can manage DDG in either the Exchange Management Console or via PowerShell.  EMC is great for quick and dirty work but PowerShell is where you can do some cool stuff with DDGs.

DDG has been on my mind recently so this was a great opportunity to not only touch on how to create and manage a DDG but also around some of the issues around them.

Creating a DDG via the console wizard is very easy and self-explanatory.  So I won’t go delve to deep into it.

Step to create are as follows…

Open the EMC

Navigate to Recipient Configuration -> Distribution Groups

Using the Action Pane select new Distribution Dynamic Group

The Dynamic Distribution Wizard will run.  Enter a name for the new distribution group and click next.

Select mailbox types to filter by (default is all) and click next.

Create your conditions and click next.

The final screen gives you a summary detailing your options.  Clicking New will create the DDG.

The console wizard has a number of limitations, namely you only have the option to query off three main attributes, State or Province, Department, and Company plus a half dozen or so custom attributes (which I’ve never used).  For many organisations though this is more than sufficient in creating those generic company and department wide lists.  It’s only when you start working with PowerShell that you can really take advantage of DDGs, but be mindful of how elaborate (or complicated) you get.

The PowerShell command to create a DDG is New-DynamicDistributionGroup.  So as an example, say you set the Company attribute under the Organisation tab within all AD User objects.  We would execute the following PowerShell script to create our new company wide Distribution List.

New-DynamicDistributionGroup –name “My Mailing List” –recipientfilter “(Company –eq ‘My Company Name’)” –recipientcontainer ‘mydomain.local’

Fairly straight forward right?  We specify in recipient filter to use the Company attribute and make sure it equals our company name.  If it does, the user will be part of our new distribution list called “My Mailing List”.

The important part to make note here of is the –recipientcontainer parameter.  By default when you create a DDG in PowerShell it will only run its query against the default Users container.  By specifying mydomain.local we are tell the query to run from the root of our domain and include all sub OU containers.

Say you want to now modify your new DDG to query only users in a particular OU called Australia.

Set-DynamicDistributionGroup –identity “My Mailing List” –recipientContainer “OU=Australia,DC=mydomain,DC=local”

The command is similar to our initial one.  We’re telling the script which DDG to modify but this time we only need to put the parameter we want to change.

To view who has been added to this DDG we would type the follow

$Users = Get-DynamicDistributionGroup –Identity “My Mailing List”

Get-Recipient –RecipientPreviewFilter $Users

What about something we can’t do in the EMC with Dynamic Distribution Lists?  Okay, say we are setting the Managers attribute in our organisation on User objects to specify who their manager / team leader is within AD.  We could create a team mailing list that would add users automatically as they move between managers / teams.

New-DynamicDistributionGroup -name "Team Leader Mailing List" -recipientfilter "((Manager -eq 'cn=Jane Doe,ou=Employees,ou=Australia,dc=mydomain,dc=local') -or (Name -eq 'Jane Doe'))" –recipientcontainer ‘mydomain.local’

There’s two parts to this command.  Firstly we query any users whose managers is called Jane Doe, and the only way to do this is to specify our manager’s full LDAP path.  The second part is actually telling the script to statically add in the manager of the team -as they won’t be managing themselves and would most likely have a different manager specified.

You can even add users of security groups to a DDG.  I’d only recommend this is very specific circumstances.  Only because you’re basing a dynamic list of a static list.  You may have good reason to do this however (e.g. You may have to add addition recipients but not want them part of the security group).

New-DynamicDistributionGroup -name "My Mailing List" -recipientfilter "((MemberOfGroup -eq My Security Group’) -or (Name -eq 'Jane Doe') -or (Name -eq 'John Doe'))" -recipientContainer 'mydomain.local'

Don’t get carried away with Dynamic Distribution Groups just because you can manage to find a query to add anyone you want.  The above script is a perfect example.

Things to make note of…

Don’t implement a Dynamic Distribution Group if it adds users that haven’t been requested part of a list.  These situations call for tradition distribution groups.  Forcing a DDG onto a team with superfluous users doesn’t achieve anything.

Be careful of users hijacking onto the back of a Dynamic Distribution Group.  DDGs are based on AD attributes.  Depending on your environment, users will be able to update certain attributions on their OU object.  If a user is allowed to update their own Title and your DDGs are based off Titles.  A user can move themselves in and out of Distribution Lists at will.

You will not be able to view DDGs through Outlook.  This is by design as you don’t want to overload AD with constant queries on distribution groups.  Keep this in mind when a user rings up asking why they are not part of a list.

Lastly, remember the -recipientcontainer parameter in your script.  I always forget this 🙂

EMC Message Tracking vs PowerShell Message Tracking

Okay so technically it’s all PowerShell right?!?  Well yes and no… more yes.  Sure, when you use the EMC Message Tracking tool, it creates the PowerShell command at the bottom of the window for you to copy and modify as you see fit.  For simple reports for one user on one Exchange server this is fine.  As soon as you need to run more complex reports for multiple user and servers you’ll quick see that doing it directly from PowerShell is much more effective.

Recently I was asked to run a number of reports based off 100+ users on multiple Exchange servers.  The EMC Message Tracking GUI is limited to running reports on one user and one server at a time so this just wouldn’t cut it for my situation.

So how do you make get-messagetrackinglog retrieve reports on multiple users and servers in one script?  Unfortunately you can’t just put multiple email addresses or servers after a parameter.

The trick here is to use the foreach-object cmdlet.  We can place all our users and servers into a variable and then use foreach (alias to foreach-object) to loop through all of our arguments.

In the below example I also use a variable for an output file and starting / ending date ranges.  In my situation it was about recycling the script for different reports as quickly as possible.

$servers = "server1","server2"
$senders = "[email protected]","[email protected]"
$outputfile = "C:tempoutput.csv

$start = “DD/MM/YYYY HH:MM:SS”
$end = “DD/MM/YYYY HH:MM:SS”

$(foreach ($sender in $senders) {
$(foreach ($server in $servers) {

Get-MessageTrackingLog -Sender $sender -Start $start -End $end -EventID “SEND” -Server $server -resultsize unlimited | select Timestamp, @{Name=”Recipients”;expression={$_.Recipients}}, MessageSubject, Sender

})}) | sort-object -property timestamp | Export-CSV -path $outputfile

We’ve now turned a basic command into quite a flexible script for receiving message logs out of exchange.

If you’re going to work out of Excel (or something similar) the sort-object is probably superfluous.  Where it’s useful is if you choose to output to the screen to quickly check what’s being returned.

By replacing

Export-CSV -path $outputfile


Format-Table –autosize

You can quickly see what results are returned.  Just remember to increase your screen buffer through the Powershell Window properties, else some columns might not be returned.

WARNING: 2 columns do not fit into the display and were removed.

Finally a note on the -resultsize parameter.  Without it your results would be limited to 1000.