Anything for sysadmins!


Send as distribution group

In the Exchange GUI there's no option to provide someone the send-as permission on a distribution group. To do this you'll have fire up the Exchange Management Console.

[Powershell]Add-ADPermission <distribution group> -ExtendedRights Send-As -User <user> -AccessRights ExtendedRight | fl[/Powershell]

User: domain.local\<username>
Identity: domain.local/Distribution Groups/<distribution group>
Deny: False
AccessRights: {ExtendedRight}
ExtendedRights: {Send-As}
IsInherited: False
InheritedObjectType :
InheritanceType: All

You can use the Get-DistributionGroup command to pipe distribution groups to the Add-ADPermission command.

[Powershell]Get-DistributionGroup <distribution group name> | Add-ADPermission -ExtendedRights Send-As -User <user> -AccessRights ExtendedRight | fl[/Powershell]

Note: The settings need to propagate through the Exchange server's cache. This can take up to 2 hours. Until this time when you try to send from the distribution list, you'll get a message back stating that it's not allowed to send as this distribution list. You can force an update by restarting the Information Store, however the mailboxes will be unavailable until the service has restarted.


New-MoveRequest Error

While testing the cross-forest migration of a mailbox, I ran into an error.

Microsoft.Exchange.MailboxReplicationService encoutered an exception. Error: MapiExceptionNetworkError: Unable to make connection to the server. (hr=0x80004005, ec=24r23)

This seems to happen when the server is not able to reach the server by using its NetBIOS name. After resolving the DNS issues I was able to run the New-MoveRequest command without any errors.


Force address book update

All Exchange administrators will eventually come to a point where they have to forcefully update the Exchange offline address book (OAB). However this is not as straight forward as one would hope. The following steps have to be taken to force an update.

  • In the Exchange Management Console go to Organization Configuration and select Mailbox.
  • Go to the Offline Address Book tab
  • Right-click the address book that you want to update and select Update

That much was quite straight forward. Now to have the OAB be available right away you'll have to restart the Microsoft Exchange File Distribution service.

All of this can also be done in powershell by running the following commands.

Get-OfflineAddressBook | Update-OfflineAddressBook
net stop MSExchangeFDS && net start MSExchangeFDS


Shared SMTP namespace during cross-forest migration

Exchange 2010 has been released quite some time ago, and I'm finally looking into it. As I'm also moving to a new domain which makes the transition a bit harder, but a name change of the domain is also necessary.

The mail flow will go from several SMTP servers to a mail proxy (Postfix) which has a couple of entries in the virtual file and also relays some domains to Forest B.

During the migration both forests will be used. Both forests will use e-mail addresses. This is often referred to as a shared SMTP namespace. One of the problems with a shared SMTP namespace is that it introduces mail loops if you set both mail servers to non-authorative. Setting 1 server to Authorative will cause problems with the mail flow if that server is also the originating server. Resulting in DNRs being send. I'm my case it's not feasible to use multiple domains, which is an often mentioned solution. The image below shows my solution to this problem.

Using a custom header in the e-mail messages you can make sure the mails don't loop (which happens to unresolved recipients). In Forest A the HUB servers are set to add a header X-Loop with the value 1 using transport rules. If the mail is relayed to Forest B and the recipient can't be resolved there, it relays back to Forest A. The Hub servers there are also configured with a transport rule that drops the message if the header X-Loop is set to 1. Therefore it doesn't loop and gets dropped. I've chosen to drop the message instead of sending a DNR because of backscatter which might get you blacklisted. Same story goes for Forest B only then X-Loop is set to 2.

To make sure that the header is not overwritten between Forests, I've set an exclusion on the rule to not set X-Loop if it's already set.

How to configure the HUB servers

First add the following rule to all HUB servers in Forest A:

  • Go to Organization Configuration -> Hub Transport
  • Go to the Transport Rules tab
  • Add a new Transport Rule
  • Set a name and click next

  • Click next as this applies to all messages on this server. You'll get a message which lets you confirm that it's applied to all messages.

  • Check set header with value and set both blue fields to the desired values. In my case I've set header to X-Loop and value to 1 (the value of Forest A). Then click next

  • Check Except when the message header contains specific words and set the blue fields to the values defined above with the value of the other forest. In my case I've set message header to X-Loop and specific words to 2 (the value of Forest B). Then click next

  • Confirm all the values and click finish

This transport rule sets the header in the message. Now we have to make sure that the message gets dropped when it returns.

I'll make this a bit shorter as most of the steps are the same as the above one.

  • Create a new transport rule and set it to resemble the following image


You should do the same for the other forest, only then with different values in the headers.