Adventures with Distribution Groups in Exchange 2010

Because no one should have to suffer alone.
Distribution Groups: Because no one should have to suffer alone.

I was involved in the process of migrating a company from Exchange 2007 to 2010. So far, it’s been smooth sailing with the exception of a small hiccup here and there. One of these hiccups, has to do with the new implementation of the RBAC security model in Exhcange 2010 and how that affects managers of distribution groups.

The distribution group manager just clicks the Modify Members button for instant user management joy.
The distribution group manager just clicks the Modify Members button for instant user management joy.

An organization may have hundreds of distribution groups set up in Exchange for various projects, management groups, initiatives, you name it. In a dynamic environment such as this, people are being added to and removed from distribution groups all the time. This is why Exchange admins appoint managers for distribution groups.

A distribution group manager is a regular user with the exception that they can add or remove people from the group that they manage. The manager usually makes changes to the group using the address book in Outlook. In previous versions of Exchange, when an administrator would appoint a user as a manager of a distribution group, all the administrator would have to do is open the Exchange Management Console, add the user as the manager, open Active Directory Users and Computers, open the distribution group properties and give the manager rights to modify the group.

I suppose that like most admins who had upgraded from earlier versions of Exchange, I was surprised when managers of various distribution groups started complaining that they were getting an error when they tried to add or remove people. Distribution group managers who were able to modify the group before the upgrade to Exchange 2010, were getting errors stating something to the effect of:

Changes to the distribution list membership cannot be saved. You do not have sufficient permission to perform this operation on the object.

Turns out there may be a couple of different things going on here. First, the default permissions for Exchange don’t allow users to manage groups and must be changed. The Default Role Assignment Policy for users needs to be changed if you want your managers to be able to administer their distribution groups. To do this, log into your OWA server’s Exchange Control Panel and take the following steps:


  1. Click on Roles and Auditing
  2. Click on User Roles
  3. Click on Default Role Assignment Policy
  4. Click on Details
  5. Put a check in the box next to MyDistributionGroups
  6. Marvel at how easy that was. A little too easy…

There is one caveat: enabling this setting allows users to create, delete, and modify distribution groups resulting in… DISTRIBUTION GROUP ANARCHY! RUN FOR YOUR LIVES!!!

This is what distribution group anarchy looks like: users all hopped up on venti lattes and unlimited distribution group management.

I think that for most organizations, this setting isn’t sufficient for their needs. To further button down these access settings, a custom role can be created using The Exchange Management Shell. Luckily for us, the sharp folks over at the Exchange Team Blog created a PowerShell script that restores sanity to your distribution group settings by giving managers back the ability to manage their distribution groups while keeping them from being able to make new groups or delete them.

You can download the PowerShell script here:
You can read about using the script (which I highly recommend) here:

Second, you may find that you can use the Exchange Management Console (EMC) to modify distribution group memberships but managers who need to use Outlook to administer their groups can’t. To make editing distribution groups work in Outlook, you may need to change each distribution group to be Mail Universal Distribution Groups as well. You can do this in the EMC by right-clicking on the distribution group in question and selecting the “Convert to Universal Group” option.

Further reading:


Oddness when creating a dynamic distribution list in Exchange 2007 with custom filters

I recently ran into an interesting bug in Exchange 2007. I was creating a dynamic distribution list in the Exchange Management Shell. I set up a custom filter so that if a user’s AD account description had the word “common” in it, that user would be excluded from the distribution list.

Here’s the code for the DL:

New-DynamicDistributionGroup "EveryoneBlah" -OrganizationalUnit "" -RecipientContainer "" -IncludedRecipients MailboxUsers

Here’s the code for the filter:

Set-DynamicDistributionGroup EveryoneBlah -RecipientFilter {(((RecipientType -eq 'UserMailbox') -and -not (description -like 'common'))) }

When I tried to test the filter by viewing the filtered list of recipients using the Exchange Management Console or by using the Exchange Management Shell, I would be shown a list of the users that the filter had been applied to BUT that list would not be limited by the RecipientContainer that had been specified.

So I did some searching and asking around and was pointed to this guy’s blog. He found out that this is actually a bug in Exchange 2007! The dynamic distribution group and the filter work just fine. It’s Exchange 2007’s functionality to SHOW the correct list of users that the DL is applied to that’s wonky.

Further Reading:

Looking for an AD account that is associated with an email address?

From time to time I find myself looking for an account that is associated with a specific email address. If the email address in question is an alias, a simple search in Exchange won’t turn up any results. Running a query in Active Directory Users and Computers can locate the information easily.

To run this query, take the following steps:

  1. Open the Active Directory Users and Computers mmc.
  2. Right-click on the domain and select the “Find” option.
  3. Select the “Custom Search” option from the “Find:” drop down menu.
  4. Click on the “Advanced” tab.
  5. In the field under “Enter LDAP query:” type the following: “(”.
  6. Hit the “Find Now” button and prepare for win.
I really have to find better examples to support my instructions.

Further Reading:

The Malformed MIME Dilemma

The company that I work for has an anti-virus gateway. The anti-virus gateway is a server which is positioned between our internal email servers and the outside world. It filters out SPAM emails and viruses while it allows legitimate emails to pass through it to the internal email servers so that they can be delivered to their intended recipients. If the anti-virus gateway cannot fully scan an email for viruses, it filters the email out and often sites “malformed_MIME” as the cause.

Obviously, its this guy’s fault.

MIME stands for Multipurpose Internet Mail Extensions. MIME is used to describe information about the content of an email and how it is formatted. There are standards that determine how a MIME email should be composed. One of these standards is RFC 5322 (formerly RFC 822 and RFC 2822). When an email is created in a fashion that doesn’t comply with RFC 5322, anti-virus software is often unable to effectively scan the entire email for viruses.

The company that I work for receives emails from hundreds of vendors each week. Some of those vendors use custom or specialty software to automatically create emails. The vendor’s email software may not create emails in a way that conforms to RFC 5322. When this happens, the email gets filtered out by my company’s  anti-virus gateway and business is hampered.

Some companies in this situation have decided to allow unscannable emails with malformed MIME types to be delivered normally. This behavior is risky, as the bad guys have found ways to use emails with malformed MIME types to crash email servers and hide viruses in emails so that anti-virus software has a hard time detecting it. It is also common for SPAM to have malformed MIME types. By not blocking emails with malformed MIME types, these companies may be delivering more SPAM to their users as well.

At this time, my organization is still blocking unscannable emails. We are also working with vendors who send us emails with malformed MIME types when they request information to investigate the matter further.

Has this ever been a concern for your organization? What do you think about this issue? Participate in the poll and post a comment!

Further Reading:

Exchange 2007 SP3 Rollup 3 – Unforseen Consequences

Did not see that coming.

If you have installed Rollup 3 on your Exchange 2007 SP3 email server then you might experience the following: When Mac users who send emails with .tiff or .pdf attachments to Windows users, the Windows users won’t be able to view the attachments! Sometimes Windows users who receive the attachment laden email, won’t even see the telltale paperclip symbol on these emails. It is only when the email is viewed from OWA or another Mac client that it’s attachments are made apparent.

Even though the rollup was released in April, Microsoft still hasn’t released a publicly available patch for it. At this time, you’ve got three things that you can do to try and resolve this issue:

  1. Uninstall Rollup3
  2. Call 1-800-microsoft and talk Microsoft support into giving you the hotfix
  3. Entering the following command in power shell on your Exchange server has reportedly helped some people: set-OrganizationConfig -ShowInlineAttachments:$true

Further Reading:

Outlook 2011 and the really low email attachment size limit

No. Not really.

Anyone with an Exchange 2007 email account who recently upgraded from Office 2008 to 2011 on the Mac might find themselves unable to send emails with attachments that are over 10MB in size.  While Entourage used WebDAV, Outlook 2011 uses Exchange Web Services (EWS) for email access. The default size limit for sending emails using EWS is 10MB. To fix this, you’ll need to edit a few files named “web.config” on the Exchange server, run a few commands and then reboot the sucker just because its a good time.

Here’s what you do:

  1. On your Exchange server go to “C:\Program Files\Microsoft\Exchange Server\ClientAccess\exchweb\ews”
  2. Make a copy the “web.config” file – just in case you break something.
  3. Open up the “web.config” file in notepad or Notepad++ (if you’re badass)
  4. Find the line with the following “httpRuntime maxRequestLength=”13280″”
  5. Change the 13280 value to whatever you want. Note that this value is in KB.
  6. Save and close the file
  7. Next, you’ll want to repeat steps 1-6 with the “web.config” files in the “\ClientAccess\owa” and “\ClientAccess\sync” folders.
  8. Open up the command prompt and enter “CD %windir%\system32\inetsrv”
  9. Enter the following commands:

    “appcmd set config “Default Web Site/ews” -section:requestFiltering -requestLimits.maxAllowedContentLength:#########”

    “appcmd set config “Default Web Site/owa” -section:requestFiltering -requestLimits.maxAllowedContentLength:#########”

    “appcmd set config “Default Web Site/Microsoft-Server-Activesync” -section:requestFiltering -requestLimits.maxAllowedContentLength:#########”

    Note: Replace the # with the values you entered in in the web.config files but this time in bytes. If you entered 100000 in the web.config file, enter 100000000 for the value in the command line.
  10. Enter the “iisreset” command
  11. Take a moment to reflect on how awesome you are for winning.
Further reading:

Create an SPF record like a boss

What’s an SPF Record?

Well friend, an SPF record helps to provide verification that an email came from a legitimate source. Why would you care about that? You see, most SPAM comes from illegitimate sources (go figure).  Spammers can make it look like an email came from a certain email address even though it didn’t; which is a reason why SPAM sometimes gets past SPAM blockers.

Quite inconspicuous.

This is where the SPF record comes in: the SPF record is actually just a listing of the addresses of a domain’s email servers. Basically, a domain like has a set of email servers that it uses to send it’s emails through. The SPF record for will contain a list of those email servers that I use to send emails. If sends an email to you, your email service can make sure that the email actually came from the domain by checking’s SPF record.

If a spammer tried to send SPAM email and make it look like it came from an email address any email server that received that email could check’s SPF record and confirm that the email was illegitimate. If all email services used SPF records, it would make it much harder for spammers to waste our time and resources with their inane, offensive, junk.

That’s cool. How do I set one up?

There’s a wizard over at that can guide you through the record creation process. Before you get all click-happy on that link, there is some information that you’ll need to gather first. You’re going to need:

  • A list of all of your domains – even the ones that you don’t send email with
  • A list of all of your outgoing email servers
  • Access to change your domain’s DNS records

Now you can go to and plug your domain/server info into the wizard. The wizard generates your SPF record for you which you can then add to your DNS records. Once you’ve generated your own SPF record, you might want to run it through this nifty SPF Record Checker to make sure that it works.

If your email is hosted by a service like Google Apps, the email service may provide information on creating SPF records for your domain. Check out these links for SPF record information for the following email hosting services:

Google Apps

Go Daddy


Aaannd yeah, you can pretty much find this information on your own by searching for a minute or two on Google.

Pro Tip: search for the name of your hosting service  + SPF record. Works like a charm.