Wednesday, 7 November 2012

Installing, Configuring Exchange 2007 Edge Server (Part 2)

Installing, Configuring Exchange 2007 Edge Server (Part 2)

In Installing, Configuring Exchange 2007 Edge Server (Part 1) we started the installation of an Exchange 2007 Edge server at the DMZ.
So far we installed the Exchange Edge role on a standalone Windows 2003 server. The server is still not connected to the rest of the Exchange organization running internally. Indeed we could employ Edge as the perimeter server even if we were not running Exchange internally. As is, Edge only requires port 25 communications and the configuration of send/receive connectors, to act as a relay to any SMTP server.
However, quite obviously, Edge also includes special support for running together with an internal Exchange 2007 organization. This functionality is provided by the EdgeSync service. Running on an internal Hub transport server, EdgeSync pushes information to the Edge server. The following is some of the information transferred; more details are available from the article EdgeSync Replication Data:
  • Email routing configuration such as the list of accepted domains and connector configuration.
  • Recipient information that is especially useful for rejecting emails addressed to invalid recipients.
  • Safe Sender lists configured at each of the recipient mailboxes.
Making this information available to the Edge server enables the immediate filtering of emails. Furthermore, once the system is deployed, an Administrator will be able to manage the Edge server from the internal network. Configuration changes are simply pushed by EdgeSync, reducing the need to log on to the Edge server directly.
All this is achieved without compromising the need for isolation. EdgeSync only requires the opening of an additional port at the firewall separating the internal and perimeter networks. This is port 50636, a custom secure LDAP port to which ADAM is listening.
Another point to notice is the fact that information only flows from the internal to the perimeter network and not the other way round. Again this meets our isolation requirements. If the information at the perimeter were to be poisoned, this information would not get propagated internally.

DNS Configuration

Before proceeding further we have to take care of name resolution. Both Edge and internal Hub servers need to be able to resolve each other's name through DNS. For this to work we will add host (A) records for each of the Edge/Hub transport servers.
In a typical DMZ configuration the perimeter and internal networks run on different subnets. In our case we have these settings:
Perimeter subnet:
Edge Server Name: abcd.exchinbox.local
Edge Server IP:

Internal subnet:
Hub Server Name: exchsrv.exchinbox.local
Hub Server IP:

We start from the internal DNS server. This is the one used by the Hub transport. Thus we add an A record for the Edge server named 'abcd'. We add this under the Forward Lookup Zone for exchinbox.local.
Internal DNS Server

Host Record Settings

We now test name resolution and port 25 connectivity. This telnet command will verify both:
telnet abcd 25
Telnet test

Note: If running Windows 2008, install the telnet client from Server Manager | Add Features, select the check box for the Telnet Client and complete the wizard.
Now we move to the perimeter network and create an A record for the Hub named 'exchsrv'. If the perimeter were running its own DNS server, we would create the A record there, as we did for the internal network. Otherwise we just edit the hosts file located under:
<Windows dir.>\system32\drivers\etc
Here we add the line: exchsrv
Hosts File

We now perform the same telnet test to verify name resolution and connectivity from edge to hub:
telnet exchsrv 25

Creating an Edge Subscription

It is now time to setup EdgeSync. This process starts from the edge server machine. At the Exchange Management Shell we run:
New-EdgeSubscription -file c:\temp\EdgeSubscription.xml
The file parameter identifies the path where an Edge Subscription XML file is to be created.

On running the command we are greeted with a very informative warning that is worth reading:
"Creating an Edge Subscription makes the configuration of this Edge Transport server ready to be managed via EdgeSync. Any of the following types of objects that were created manually will be deleted: accepted domains; message classifications; remote domains; and Send connectors. Also, the InternalSMTPServers list of the TransportConfig object will be overwritten during the synchronization process. The Exchange Management Shell tasks that manage those types of objects will be locked out on this Edge Transport server. You must manage those objects from inside the organization and allow EdgeSync to update the Edge Transport server. EdgeSync requires that this Edge Transport server is able to resolve the fully qualified domain names (FQDN) of the Hub Transport servers in the Active Directory site to which the Edge Transport server is being subscribed. Those Hub Transport servers must be able to resolve the FQDN of this Edge Transport server. You should complete the Edge Subscription inside the organization in the next "1440" minutes before the bootstrap account expires."
Hitting 'Y' will complete this step and the Edge Subscription file is created. Here is what it looks like:
XML Subscription File

We now transfer this file to the Hub Transport server. Here at the Exchange Management Console under Organization | Hub Transport we select New Edge Subscription and follow the wizard that opens.
Importing Edge Subscription

Edge Subscription Wizard

In the introductory step note the checkbox saying:
'Automatically create a Send connector for this Edge Subscription'
This will create the connectors necessary for emails to flow between Edge and Hub transports.
Edge Subscription Warning

The final wizard step reminds us to open port 50636 for the EdgeSync service to be able to push information to ADAM.
"EdgeSync requires that the Hub Transport servers in Active Directory site Default-First-Site-Name must be able to resolve the IP address for abcd.exchinbox.local, and be able to connect to that host on ports 50636."
Completing the subscription, we can immediately have a look at the new configuration elements that were created. Under Organization | Hub Transport | Edge Subscriptions we find the registration of the 'abcd' server.
Subscription Configuration Object

Under Organization | Hub Transport |Send Connectors we have two new send connectors:
New Send Connectors

EdgeSync in Action

In my test environment EdgeSync kicked off immediately and completed the first synchronization. However I did come across reports claiming that the Microsoft Exchange EdgeSync service needed a restart. Don't forget EdgeSync runs at the internal Hub Transport and this is where you will find the service.
Synchronization Service

Thereafter synchronization will follow a fixed schedule:
Every 1 hour - Configuration information
Every 4 hours - Recipient information
Every 5 minutes - Topology information
We can easily verify whether the first synchronization pushed the expected information to the Edge server. From the Edge server management console, we check the list of accepted domains that were configured internally.
Accepted Domains

While we are at the Edge server, we can verify if configuration changes were locked as promised earlier on creating the Edge Subscription. Here I tried to edit one of the send connectors and was promptly blocked:
Locked Configuration

"This task may not be run on an Edge Transport server that is subscribed to an Active Directory site. You must perform this operation on a Hub Transport server in the subscribed Active Directory site. The changes will be replicated to the Edge Transport server when synchronization next occurs."
Now let's see what happens when the configuration changes at the Hub Transport. Here at the "EdgeSync - Inbound to Default-First-Site-Name" Send Connector, I configured exchsrv.exchinbox.local as the smart host to be used by the Edge server for inbound emails.
Smart Host Configuration

This change won't be visible to the Edge server until the next synchronization cycle unless we force it to. From the Exchange Management Shell we first run:

This returns a report showing that everything is synchronized except for the SendConnectorStatus.
Next we run:

This will force an immediate synchronization pushing the new Send Connector settings to the Edge. Of course the same cmdlets also come very handy when troubleshooting.

Final Tips

With the Edge Server role, Exchange 2007 provides a good DMZ citizen that is able to satisfy the isolation restrictions imposed by the perimeter network. This is achieved whilst retaining a good level of integration.
EdgeSync provides the necessary link that allows us to manage the Edge server from the internal network. However it is important to understand the work that is going on behind the scene. If new recipient mailboxes are created or a new accepted domain is added, the Edge server won't know of these until synchronization kicks in. If this is an issue, we should force synchronization from the command shell with Start-EdgeSynchronization.
Of course apart for port 25 don't forget to open port 50636 for EdgeSync to work. EdgeSync traffic only flows from the Hub to the Edge transport. Thus we only need port 50636 open at the firewall separating the internal network from the perimeter (in that direction).
One of the areas where I see problems most often is name resolution. The Edge server needs to resolve the names of all hosts it will be interacting with, including those of the internal Hub transport. Same goes for the internal network. Here the Edge server name must also be resolvable through DNS.

Installing, Configuring Exchange 2007 Edge Server (Part 1)

Installing, Configuring Exchange 2007 Edge Server (Part 1)

Despite the success in conquering internal corporate networks, earlier Exchange versions failed to replicate the same success at the DMZ. One reason for this was the Exchange server installation requirements that included IIS and Active Directory. These are often considered too cumbersome for hosts running internet facing services.
Splitting functionality into distinct roles, allowed Exchange 2007 to provide the first DMZ friendly solution. The Edge server role was thus born, an SMTP transport where email hygiene applications filter emails before allowing entry and exit to/from the internal network.
Today we walk through the installation of an Exchange Edge server. We also configure this to connect to the Exchange servers running internally.

Network Layout

We start our walk with a look at the network layout. A typical DMZ is shown below. Internet originating email is received by the Edge server. If accepted this is relayed to the internal Exchange Hub transport. In case of outgoing email, the Hub transport uses the Edge server as a smart host.

The separation between DMZ and internal network limits the type of traffic between the two segments. In this setup, the Edge server machine cannot be a member of the internal domain. Furthermore the Edge is expected to only provide essential services so as to limit exposure to potential security attacks. These limitations are catered for by the Edge server installation requirements. In fact we will be installing Edge on a standalone Windows 2003 Server. Of course it is also possible to install this on Windows 2008. I will be highlighting some differences between to two platforms as we go along.
For the purposes of this article, the internal network is already up and running. The internal domain name is exchinbox.local. An Exchange Hub transport server is also in place accepting emails for the domain

Edge Installation Requirements

We start the Edge installation from a standalone Windows 2003 SP2 server. To satisfy the basic Exchange 2007 requirements we install the .NET Framework 2.0, MMC and PowerShell. With these bits out of the way, we look at some requirements specific to the Edge role.
First we have to configure the DNS Suffix for the Edge machine:
  1. Open the properties for 'My Computer'
    My Computer Properties

  2. Select the Computer Name page and click Change
    Computer Name Property Page

  3. Click More
    Computer Name Properties

  4. Enter the DNS name of the internal domain. In our case exchinbox.local
    DNS Suffix

  5. Finally we restart the machine
Next we have to make up for the lack of Active Directory services. Cutting the Edge server from the internal Active Directory is desirable from an isolation perspective. However AD also serves as the Exchange 2007 configuration repository. Thus a replacement that allows Edge to store its configuration is obviously required.
Thus on Windows 2003 we install the Active Directory Application Mode ADAM service. Just like Active Directory this is an LDAP directory service. However this will only be used to store information relevant to Exchange.
We download ADAM SP1 from the Microsoft download center. The Service Pack includes all the bits and can be installed directly on a machine where ADAM was never installed.
There is nothing worthy of note regarding the installation of ADAM. It is just a matter of clicking Next, 'I Agree' and Finish.
Note: ADAM is included with Windows 2003 R2. In this case use the Optional Component Manager to complete this installation.
Note: If we were installing Edge on Windows 2008 instead of ADAM we would install Active Directory Lightweight Directory Services (AD LDS).

Installing the Edge Server Role

We now satisfied the installation requirements. Using the Microsoft Update Service we make sure we also have all the latest updates. Finally we are ready to install the Edge Server role.
The usual Exchange 2007 installation Wizard greets us. Here we choose the Custom Exchange Server Installation option since Edge is not part of the typical installation.
Custom Exchange 2007 Installation

At the Role selection step we select the Exchange Server Role.
Edge Server Role

Note how on selecting the Edge role all other roles are grayed. Edge has to be installed on its own. All other roles are intended to run within the internal network. We should now be able to complete the installation as usual.

Looking at ADAM

As already discussed, in this setup ADAM is acting as the configuration repository for the Edge server. ADAM is really a sibling of Active Directory. Thus tools that we usually use against Active Directory are also available for ADAM. Let's use ADSI Edit to take a look at what ADAM is storing.
  1. Start MMC: Run | mmc.exe

  2. Open, File | Add/Remove Snap-in | Add | ADAM ADSI Edit
    ADSI Edit

  3. Add the Snap-In and click OK to close the Add/Remove Snap-in dialog
  4. Now right-click the ADAM ADSI Edit node and select 'Connect To...'
    Connect to ADAM

  5. At the Connections Settings Dialog change the port to 50389. This is the default port ADAM listens to.
    ADAM Port 50389

  6. Hit OK to connect and we are ready to browse the directory. Here is the all too familiar Exchange Administrative Group object...
    Administrative Routing Group

Final Tips

Today we started the deployment of an Exchange 2007 Edge server. We looked briefly at the general characteristics of the DMZ, the network segment to home our installation.
Next we looked at the installation requirements. These contribute greatly in making the Exchange 2007 Edge server role DMZ friendly. The requirements include ADAM. This fills up the void left by the lack of the Active Directory service, providing storage for the Edge server configuration. Once all requirements were satisfied, installing Edge was just a matter of selecting the custom installation type and the Edge server role.
In the next part of this article we will proceed with the configuration and connection of the Edge server to the Exchange servers running internally.

Installing, Configuring Exchange 2007 Edge Server (Part 2)

Upgrading from Exchange 2003 to 2010

Upgrading from Exchange 2003 to 2010

Microsoft Exchange Server 2010 brings a new set of great technologies. No surprise many are excited and looking forward to plan and deploy this new messaging infrastructure. Today we cover the basic steps that should be performed in organizations currently running Exchange 2003.


Prerequisites that must be met before we start the deployment:
  • Windows Server 2003 SP2 or later, Global Catalog servers in each site where Exchange Servers are located and Windows Server 2003 forest functional level.
  • Exchange 2003 Organization must be in native mode, with Exchange 2003 SP2 installed
  • In place upgrade is not supported, thus new hardware should be installed for the Exchange 2010 Servers. Hardware requirements may be found at the following link:
  • Operating Systems supported are Windows Server 2008 SP2 64-bit and Windows Server 2008 R2 64-bit Standard or Enterprise. Please note that Exchange Server 2010 is 64-bit only, i.e. there is no 32-bit version available for testing purposes and there are no 32-bit management tools. Management tools should be installed on a 64-bit operating system too.
  • If the organization has multiple sites, the first site to introduce Exchange 2010 should be the internet facing site. The upgrade then continues with non-internet facing sites.
  • If the solution design requires installing Exchange 2010 roles on multiple servers, then these should be installed in the following order:
    1. Client Access Server role
    2. Hub Transport Server role
    3. Unified Messaging Server role (optional, may be deployed later)
    4. Mailbox Server role
    5. Edge Server role (optional, may be deployed later)

The Installation Process

The installation process requires Active Directory to be prepared. In order to do that, the user should be member of the Schema Admins and Enterprise Admins security groups.
When transitioning from Exchange 2003 to 2010, we transition the Exchange specific permissions using the command that follows.
setup /PrepareLegacyExchangePermissions or setup /pl
The Active Directory schema must be extended with Exchange 2010 specific attributes thus we run:
setup /PrepareSchema or setup /ps
The next command to run is:
setup /PrepareAD or setup /p
This performs multiple tasks. It verifies that the schema has been updated, assigns specific permissions in the configuration partition, creates the Microsoft Exchange Security Groups organizational unit (OU) in the root domain of the forest, and prepares the local domain for Exchange 2010.
The last command of the preparation steps is:
setup /PrepareDomain or setup /pd
This also performs multiple tasks. It creates a new domain global group named Exchange Install Domain Servers in the current domain. Next it adds this group to the Microsoft Exchange System Objects container and to the Exchange Servers group at the root domain.
Note: For detailed Active Directory preparation steps please check:
Prepare Active Directory and Domains
The Exchange 2010 installation steps were discussed in Installing Exchange 2010 Beta. Thus we proceed with the so called coexistence scenario i.e. the moment when there are both Exchange 2003 and 2010 versions present in our organization.
In order to provide message transport coexistence between both versions, the setup will perform the following actions:
  • Ask for the Exchange 2003 bridgehead server to be identified
  • Create an Exchange Routing Group RG (DWBGZMFD01QNBJR) to host Exchange 2010.
  • Create routing group connectors between the Exchange 2003 bridgehead RG and the Exchange 2010 RG.
  • Create an Exchange Administrative Group AG (FYDIBOHF23SPDLT) to host Exchange 2010.
Since Exchange 2007, administrative groups and routing groups are no longer used. The same also applies to Exchange 2010. Thus the RG and AG are only created to allow coexistence with Exchange 2003. Furthermore the groups are only visible from the Exchange 2003 System Manager console. It is not allowed to make any configuration or membership changes to both of these. Again, same as in Exchange 2007, Exchange 2010 uses Active Directory sites instead of Routing Groups to define the routing topology.
Exchange 2003 System Manager

Client Access Server Role Coexistence

So far we completed the Exchange 2010 setup. We now configure the server roles.
During the coexistence phase, we should change some DNS settings to provide a seamless transition. Let's assume our current Exchange 2003 server is accessed by name After installing Exchange 2010, a legacy name should be assigned to identify the Exchange 2003 infrastructure, for example we use This is done both at the internal and external DNS namespaces. In addition, the current DNS host name ( is assigned to the new Exchange 2010 server. Thus clients won't use the legacy name, they still continue to access their mailboxes without changing settings.
A new certificate should be issued because of Exchange 2003 and Exchange 2010 coexistence. Wildcard certificates and certificates that support Subject Alternative Names may be used.
We will assume that the primary external namespace for virtual directories is configured during the setup (for example Clients will use this name to connect from the Internet.
Coexistence between Exchange 2003 and Exchange 2010 Client Access will be provided by configuring the URL property on the /owa virtual directory. This is done from the Exchange Management Shell using:
Set-OWAVirtualDirectory "MAIL2010\OWA (Default Web Site)" -Exchange2003URL
If our company uses Outlook Anywhere, it should be enabled from the Exchange Management Shell using:
Enable-OutlookAnywhere -Server:MAIL2010 -SSLOffloading $false
In addition, forms-based authentication on the Exchange 2003 front-end server should be configured in order to have single sign-on between both versions.
The Offline Address Book generation service should also be moved to the Exchange 2010 CAS Role. From the Exchange Management Shell use the command that follows:
Move-OfflineAddressBook "Default Offline Address List" -Server MAIL2010
To enable Exchange 2010 and 2003 to communicate using Kerberos authentication, the configuration partition in Active Directory should be changed, so that the attribute msExchAuthenticationFlags of the Microsoft-Server-ActiveSync object is set to value 6.
At this point in time, all clients are connecting to the new Exchange 2010 Client Access Server using the name The mailboxes are still on Exchange 2003, so the Outlook Web Access experience is actually version 2003. They will connect to the new version of Outlook Web Access once their mailboxes are moved to Exchange 2010.

Hub Transport Server Coexistence

NOTE: If planning to employ the Exchange 2010 Edge Transport please skip this section. The following articles discuss deploying the Edge Transport server role. These were written for Exchange 2007 however they are still largely valid for Exchange 2010 as well:
Installing, Configuring Exchange 2007 Edge Server (Part 1)
Installing, Configuring Exchange 2007 Edge Server (Part 2)
Deploy an Edge Transport Server in an Existing Exchange Server 2003 Organization
Exchange 2010 provides two server roles for handling email transport, the Edge and Hub transport roles. In simple terms we can consider the Hub Transport to be the replacement for the Exchange 2003 transport functionality. Thus here we consider the transition from the Exchange 2003 transport to the Exchange 2010 Hub transport.
After installing Exchange 2010, the mail from/to the internet still flows through the Exchange 2003 bridgehead. In order to reroute the mail transport to go through the new Exchange 2010 Server, the inbound and outbound traffic should be reconfigured, depending on the company messaging infrastructure.
To allow inbound traffic from the internet, the SMTP gateway or firewall should point to the new Exchange 2010 Hub Transport server. In addition the Receive Connector at the Hub Transport should be configured to allow the "Anonymous users" permission group. In this manner the Hub Transport accepts incoming emails from external SMTP servers.
Anonymous User Permissions

To allow outbound traffic to the Internet, a Send Connector with * namespace should be configured to route outgoing messages directly or using smart host. This can be done from the Exchange Management Console or the Exchange Management Shell using the following command:
new-SendConnector -Name 'Internet Connector' -Usage 'Internet' -AddressSpaces 'SMTP:*;1' -IsScopedConnector $false -DNSRoutingEnabled $true -UseExternalDNSServersEnabled $false -SourceTransportServers 'MAIL2010'

Mailbox Server Role Coexistence

At the Exchange 2010 Management Console, mailboxes located on Exchange 2003 Servers are classified as "Legacy Mailbox".
Legacy Mailboxes

The process of moving mailboxes to Exchange 2010 is called Local Move Request (local is for moving within the same forest). When moving from Exchange 2003, the user is disconnected during the move process. Unfortunately online mailbox moves as discussed in Exchange 2010 Online Mailbox Move, a Deep Dive, are only possible if the source mailbox is located on Exchange 2007/2010.
Mailbox move requests can be performed using both Exchange Management Console and Exchange Management Shell. For example:
New-MoveRequest -Identity '' -TargetDatabase EX2010DB01
Once the mailboxes are moved, we should proceed with moving public folders. To discover public folder replicas, at the shell run the following:
Get-PublicFolder -recurse | FL Name,Replicas
The next step is to open the Exchange 2003 System Manager and to locate the Public Folder store database. Here right-click the database and choose Move All Replicas. When prompted to choose for a destination public folder database, select the one located on Exchange 2010.
The process can be monitored using the same Exchange Management Shell command:
Get-PublicFolder -recurse | FL Name,Replicas
The Exchange 2003 Recipient Update Service should also be reconfigured to use Exchange 2010 Servers. This is done from the Exchange System Manager.
At the end, mailboxes and public folder databases on Exchange 2003 servers should be deleted using the Exchange System Manager. This process does not delete the database files from the file system, so file deletion should be done manually.
When all resources are moved to the Exchange 2010 Servers, the routing group connectors between the Exchange 2003 and 2010 routing groups should be deleted using the Exchange 2003 System Manager.
Remove Routing Group Connector

Finally Exchange 2003 can be removed from Control Panel | Add Remove Programs on Windows 2003.
Uninstall Exchange 2003


Upgrading an Exchange Organization from version 2003 to 2010 is a process that requires analyzing the current messaging infrastructure and designing the new one.
The two versions can coexist. If properly planned, keeping in mind legacy applications running on Exchange 2003, we can avoid service interruption.
At the end, introducing Exchange 2010 should allow us to lower costs and at the same time improve productivity.