Exchange Server 2007 Service Pack 2

Brief Description
The new capabilities of Exchange Server 2007 deliver the advanced protection your company demands, the anywhere access your people want, and the operational efficiency you need.

Overview
Microsoft Exchange Server 2007 Service Pack 2 (SP2) has been designed specifically to help meet the challenges of any business and the needs of all the different groups with a stake in the messaging system. Exchange Server 2007 SP2 is a mission-critical communications tool that enables employees to be more productive and access their information anywhere and anytime while providing a messaging system that enables rich, efficient access to e-mail, calendar items, voice mail, and contacts. For the administrator, Exchange Server 2007 SP2 provides advanced protection options against e-mail security threats, such as spam and viruses, as well as the tools to help manage internal compliance and high availability needs. For an overview of the new features that are available in Exchange Server 2007 SP2, see "What's New in Exchange Server 2007 SP2".
Download: Exchange Server 2007 Service Pack 2

Installing, Configuring Exchange 2007 Edge Server (Part 2)

The EdgeSync service glues together the internal Exchange 2007 servers to the perimeter Edge servers. This is achieved whilst retaining the necessary isolation between the two network segments.

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: 192.168.0.0/255
Edge Server Name: abcd.exchinbox.local
Edge Server IP: 192.168.0.5

Internal subnet: 192.168.10.0/255
Hub Server Name: exchsrv.exchinbox.local
Hub Server IP: 192.168.10.60

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.

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

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:
\system32\drivers\etc

Here we add the line:
192.168.10.60 exchsrv

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:

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.

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.

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.

Under Organization | Hub Transport |Send Connectors we have two 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.

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.

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:

"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.

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:
Test-EdgeSynchronization

This returns a report showing that everything is synchronized except for the SendConnectorStatus.

Next we run:
Start-EdgeSynchronization

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.

Source: http://www.exchangeinbox.com/article.aspx?i=134

Installing, Configuring Exchange 2007 Edge Server (Part 1)

The DMZ is a network segment where security considerations dominate the choice of what gets installed. Exchange 2007 is considered by many to be the first DMZ friendly release. Today we start installing an Exchange 2007 Edge server and look at what makes Edge a good DMZ citizen.

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 adminstop.com.

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'

   

2. Select the Computer Name page and click Change

   

3. Click More

   

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

   

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.

At the Role selection step we select the Exchange 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

   

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...'

   

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

   

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

   

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.

Part 2: Installing, Configuring Exchange 2007 Edge Server (Part 2)

Source: http://www.exchangeinbox.com/article.aspx?i=131