Category Archives: Exchange 2007

Encrypted / Password ZIP email attachments stripped

I recently migrated from an Exchange 2007 Edge server to an Exchange 2010 Edge server.  I used the opportunity to not carry over some of the legacy settings and start clean.  Everything appeared fine till a few weeks later.

A user complained that their ZIP files were being stripped in attachments.  Their attachments would arrive with a TXT extension on it.  Within that TXT file it would say “This attachment was removed.”.  Having never seen this before and able to successfully email myself ZIP attachments I put it down to the senders email filtering.  The recipient was adamant that it wasn’t the senders fault.  So I managed to get a hold of the questionable ZIP files and send them to myself via Gmail, sure enough the attachments failed to arrive.  So began my investigations…

Not doing any filtering on our HUB or Mailbox servers I was immediately able to eliminate those services.  I then inspected our AV / Spam provider and confirmed via their logs that these emails were successfully passing to our Exchange Edge network.  So I focused my attention here.

Comparing the decommissioned Exchange 2007 Edge to the 2010 Edge I ran the PowerShell command Get-TransportAgent.  This outputted the below on each server.  The difference being that the “Attachment Filtering Agent” was disabled on the old Exchange 2007 Edge.

Image1. Exchange 2010 Edge

Image 2. Exchange 2007 Edge

On the new Exchange 2010 Edge I ran Get-AttachmentFilterEntry and inspected what default Attachment Filtering Microsoft had specified.  ZIP attachments was not one of them.  Never the less, as a test, I disabled Attachment Filtering with the PowerShell command

Disable-TransportAgent -Identity “Attachment Filtering Agent”

I then resent myself the failed ZIP files.  To my surprise they were successfully received.  Doing some research online seemed to indicate that this was the solution many people took to resolve this same issue.  This seemed like a pretty piss poor solution that I wasn’t going to accept.  Not if it meant that I would have to disabled all attachment filtering just for ZIP files.

I re-enabled the Attachment Filtering with Enable-TransportAgent -Identity “Attachment Filtering Agent”

After quite a few hours of playing around I finally found a viable solution.  The ZIP file I had been working with turned out to be an encrypted / password protected zip file.  Because of this the Exchange Edge server was having issues identifying the type of attachment.  By modifying the EdgeTransport.exe.config file I managed to find a workaround while continuing to maintain attachment filtering.


1.       Go to the Edge server

2.       Stop the Transport service.

3.       Locate the EdgeTransport.exe.config file. This file is located in the following path: drive:Program FilesMicrosoftExchange ServerV14Bin

4.       Add the following entry between the <appSettings> element and the </appSettings> element of the EdgeTransport.exe.config file:

5.       <add key=”AllowInvalidAttachment” value=”true” />

6.       Restart the Transport service.

Increasing the Rules Quota limit in Exchange Server 2007

Many admins probably wouldn’t know that there is a size limit set on mailbox rules.  The default value in Exchange 2007 and 2010 is 64 KB.  It may seem small but up until recently I never had a need to change this value at a global or user level.

Every so often, though, you come across a user that’s the exception rather than the rule… so to say.  The only indication you’ll get that the user is over the limit is a warning on the user’s desktop when they attempt to create another rule via Outlook.

“One or more rules could not be uploaded to Exchange server and have been deactivated. This could be because some of the parameters are not supported or there is insufficient space to store all your rules.”

Using Outlook Web Access will present the user with a slightly different message.  OWA seems to do a better job at a more descriptive error message and even suggests a resolution for the user.

“Outlook Web Access cannot save the rule that you specified. Either the rule exceeds the maximum size limit for individual rules, or all your rules together, including this rule, exceed the size limit for rules. Remove some conditions, actions, or exceptions and try again.”

If the user is unable, or in my case unwilling, to clean up some rules.  You can hop onto an Exchange server via Powershell and change their Rules Quota limit.

As mentioned, the default limit is 64 KB.  There is a hard maximum which is 256 KB.  Any value up to 256 KB is valid to use.  In the example below I select a user via their email address to increase their quota to the maximum 256 KB.

get-mailbox [email protected] | Set-Mailbox -RulesQuota 256kb

We can easily check the new rules quota size for the user with the below command.

get-mailbox [email protected] | ft RulesQuota

Microsoft Knowledge Base article

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.