Tag Archives: Exchange 2003

How to Migrate Receive Connector’s from Exchange 2003 to Exchange 2007/2010 (Multiple IP Address Restrictions)

Setting up a new receive connector in Exchange 2007/2010 is pretty straightforward stuff and would hardly be worth writing a whole article about.

However, in a migration scenario where you need to migrate a specific receive connector from Exchange 2003 to multiple Exchange 2007/2010 servers and it has LOTS of IPs listed under Relay Restrictions the process can be a little more daunting.

Further, if you want to allow that list of IPs to relay to external domains without restriction, there is an additional step you must take under Exchange 2007/2010. Simply allowing those IPs to relay is insufficient.

Get the Massive List of IPs from Exchange 2003
The first thing you need to do is get the list of IPs under Relay Restrictions. If you have just a few IPs, this is no big deal and you’ll probably just write them down. If you’re in a situation like I was this past week though, you may have dozens and dozens or even hundreds of IPs, and writing them down is simply out of the question.

Fortunately, Microsoft makes it semi-easy with the SMTP Internet Protocol Restriction and Accept/Deny List Configuration (IPSec.vbs) script, which you can download here:

How to use the IPsec.vbs program to export an SMTP relay list from a computer that is running Exchange Server 2003

Once you download and extract the contents to your C: drive, just run the following to export a list of Relay Restrictions.

cscript IPsec.vbs –s ExchangeServer –o e –r relay –d DomainController > C:\exipsecurity\exportconnectionlist.txt

NOTE: You must TYPE this command in the command window from the c:\ExIPSecurity directory. DO NOT COPY AND PASTE… it won’t work if you do that. No, it makes no sense, it’s just one of the mysteries of the Microsoft ‘verse. Now that you have your list of IPs, it’s time to create your receive connector. Create a New Receive Connector on an Exchange 2007/2010 Server As I said before, creating a new receive connector in Exchange 2007/2010 is relatively straightforward, and you can find full details from Microsoft here: New-ReceiveConnector http://technet.microsoft.com/en-us/library/bb125139.aspxI’ve taken the liberty of writing out the command below though to do what we want. This is the command we’ll run on the first Exchange Hub Transport server (technically you could run it against all of your hub transports, but I’ve also included another command to copy the Remote IP Ranges to another server).  Note that you must list out all of the IPs you wish to add to the RemoteIPRanges separated by a comma:

New-ReceiveConnector "ReceiveConnectorName" -Server Exchange2010Server -Bindings -AuthMechanism None -PermissionGroups AnonymousUsers –RemoteIPRanges IPAddress1,IPAddress2,IPAddress3

Once you have the connector created on your first Hub Transport server, you can run this command to create an identical connector on the next Exchange Hub Transport server. Again, you could use the previous command. For the sake of argument though let’s say you’re adding a Hub Transport at a much later date and don’t have the original command or list of IPs handy. This command will create a new connector, and copy the Remote IP Ranges:

New-ReceiveConnector "ReceiveConnectorName" -Server Exchange2010Server -Bindings -AuthMechanism None -PermissionGroups AnonymousUsers -RemoteIPRanges ( Get-ReceiveConnector "Exchange2010Server\ReceiveConnectorName" ).RemoteIPRanges

Now that you have your connectors on all of your Hub Transport servers, it’s time to allow them to relay to external recipients.

Assign Permissions to Receive Connector to Relay to External Recipients

In Exchange 2010, it’s not enough to allow a server to relay by listing its IP, you must further elevate permissions to give it this capability.

To do so, just use the following command on each of your Hub Transport servers with the relevant Receive Connector installed, replacing the bold parts with the appropriate names for your environment.

Get-ReceiveConnector "Exchange2010Server\RecieveConnectorName" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

At this point, you’ll be able to change DNS records or otherwise redirect the relaying servers/devices to your Exchange 2010 environment, and all will work just as well as it did with Exchange 2003.

User with Exchange 2003 Mailbox Cannot Manage Membership of Exchange 2010 Distribution Group

Consider the following scenario:  You have added Exchange 2010 to your Exchange 2003 infrastructure and intend on running both simultaneously for a period of time.

You create a new Distribution Group in Exchange 2010, and use the Exchange Management Console/Shell to add multiple users as managers for the group, including one or more Exchange 2003-based users.  After doing so, the Exchange 2003 users cannot manage the membership of the distribution group through Outlook.

However, any Exchange 2010-based users can manage the membership of the group.

Root Cause
In Exchange 2003, you would specify a single manager for a Distribution Group by using Active Directory Users and Computers; specifically the Managed By tab in the properties of the group.

In Exchange 2010, you can set multiple managers for a Distribution Group by using the Exchange Management Console/Shell.  This is done by going to the properties of the specific Distribution Group, and then clicking on the Group Information tab.  The “Managed By” section will allow you to add as many members as you wish.

When a group is created in Exchange 2010 and multiple managers are specified, only one of those managers (the first one added), will appear on the “Managed By” tab if you look at the properties from within Active Directory Users & Computers on a computer with the Exchange System Manager installed.

Therefore, as far as Exchange 2003 is concerned, only one user actually has “manage” permissions for the Distribution Group.

If you only have one Exchange 2003 user that needs permissions to manage the Distribution Group, you can use Active Directory Users & Computers to set them as the manager of the group.

That action will not affect the other managers of the group specified in the Exchange 2010 Management Console as long as they are homed on an Exchange 2010 server.

If you have multiple Exchange 2003 users that need to manage the membership of a Distribution Group, you will have to migrate those users to Exchange 2010.

Additional Information
In addition, you will likely need to ensure that you follow the instructions in this blog from Microsoft:


By default, users are prevented from managing the membership of a Distribution Group in Exchange 2010 even if they are specified under “Managed By:” on the Group Information tab.  The above blog outlines this behavior in Exchange 2010 and the steps/scripts necessary to remedy it.

EMS Command to Set Legacy Outlook Web Access in Exchange 2010

If you will be running Exchange 2003 & 2010 simultaneously with mailboxes in both environments, you’ll need to run the Set-OWAVirtualDirectory command on each CAS Server in your organization.  The command to run is:

Set-OWAVirtualDirectory -Identity "CASServer\owa (Default Web Site)" -Exchange2003URL https://legacy.webmail.domain.com/exchange

Simply change the relevant parts to reflect the settings in your environment.  This will tell Exchange 2010 OWA to redirect for clients with Exchange 2003 mailboxes to the appropriate OWA server.

Exchange Server: How to use the InterOrg Replication Tool to Replicate Free/Busy Between Exchange 2003 & 2007

Recently, the company I work for acquired another large enterprise. In order to facilitate the integration of the two companies, I was required to get the Free/Busy calendar information flowing between the two organizations Exchange Servers. In our situation we were running Exchange 2003 Front-End and Back End servers with Exchange 2007 Edge Transports. The acquired company was running Exchange 2007 with separate mailbox, client access, and hub transport servers.

For us, this was a short term thing as we were migrating to Exchange 2010 anyway. Nevertheless, it was exceedingly important we get this running quickly.

Microsoft actually has three excellent articles on deploying the InterOrg Replication Tool:

InterOrganization Replication Tool

Installing, configuring and using the InterOrganization Replication Tool

How to Use the Exchange 2003 Version of the Inter-Organizational Replication Tool with Exchange 2007

Between those three articles, you can easily get the InterOrganizational Replication Tool set up and configured… but not necessarily operational.
; )

There are three important bits of information those three articles neglect to mention.

In our situation, we purchased another company and needed to replicate Free/Busy information.

However, since the purchased company was in another country and hadn’t been secured to our standards yet, we had strict firewall policies in place between our organizations (even though we were connected via a private VPN at this point).

Obviously RPC (utilizing TCP port 135 and a random port between 1024 & 65535) had to be opened up between our two Exchange servers in order for the Replication Tool to do its magic. However, we also happened upon another interesting fact while watching the traffic flow through the firewall. We kept having issues with it working, and it turns out that RPC needs to be open to the relevant domain controllers in the sites for both sides of the connector.

Effectively, when trying to authenticate to Active Directory, the Replication Tool is trying to authenticate directly against the domain controller and not the Exchange server it is actually connecting to.

Seems obvious now, but there is nothing in the Microsoft documentation that discusses that… it just references the ports to the Exchange servers.

Additionally, we had another little hiccup. We had prepped our Exchange 2003 organization already for the Exchange 2010 migration. Even though we had no actual Exchange 2010 servers in the organization yet, the legacyExchangeDN attribute for all new contact records (utilized for the Replication Tool) was being set to the Exchange 2010 Organization (which was non-existent), not the Exchange 2003 Organization.

This prevented the InterOrg Replication Tool from functioning. We ended up using ADModify.net from Microsoft (an awesome tool) to bulk modify all of the contact records (hundreds) we had imported into Active Directory. We looked at an old account to get the proper format for the Exchange 2003 legacyExchangeDN setting and changed all of the new contact records.

Finally, it’s important to note that the Exchange servers you connect to from the InterOrg Replication Tool need to be the backend servers if you have a split role environment (which we did on both sides).

Once that was done, coupled with the Firewall rules and the legacyExchangeDN modification, we were up and running with the precious Free/Busy data being freely replicated between our organizations.