Debunking the top 5 Myths concerning Cross-Forest Exchange Migrations

Exchange Cross-Forest migrations are not as impossible, expensive or complex as you may think. If you are considering merging an Exchange organization into another organization, you should know that it can be done and you can do it.

Cross organizational moves are complex and on my last large cross-org project we had nearly 100 Exchange 2007/2010 servers and over thirty locations with multiple SMTP paths. Moreover, we were dealing with two separate AD forests with absolutely no automated directory synchronization. Even with these challenges plus WAN link migrations we established a process to successfully migrate roughly 600 people in a six hour window with minimal personnel and an exceptionally low failure rate. If you do the math you will see that we built capability to migrate 2400 a day or 16,800 people per week. Since we are not running four shifts a day, seven days a week I have a few moments to talk about how can do it too.

As you read this, you will notice that I have included code samples, a few tips and some overall ideas to enforce by conviction that this can be done without expensive tools and to illustrate my points. You should not take this article as a complete migration guide but as a confidence builder. There are far more technical strategies that are better described somewhere else such as sizing, migration throughput, error handling, WAN moves, server centralization, scheduling and the overall technical aspects of the scripting and process. I have tried however to give you enough information so you can understand how manageable this process really is.

So let’s set the stage. You are tasked with planning the migration of thousands of Exchange users from one company/organization to another. You have trusts in place and accounts in each Forest with rights and you have read very little documentation that would suggest you can accomplish this on your own. Moreover, you have a quote for $500,000 worth of migration software and have no idea how you will maintain your budget or if the software is even worth it.

Myth 1:

Migrating Exchange mailboxes from one org to another without 3rd Party tools is suicide


In my last large cross-org migration project, we moved roughly 30,000 mailboxes using the standard Exchange 2007 “Move-Mailbox” PowerShell command. The syntax is described here:

Having said that let me point out that you should augment that command with additional scripts that provide additional error-handling and account management. In the end, the Move-Mailbox command is the only tool I use to migrate terabytes of Exchange information from one organization to another.  I will show you the command in a moment, but first let’s talk about how we use it:

  •  For bulk moves, we script the command against a text file that contains the names we wish to migrate. I prefer this better than using an AD group to list the migration candidates since it allows us to “lock” the group and easily manipulate the names if so desired.
  • Perform your AD work ahead of schedule. Create Mail-enabled user objects in the target domain and instruct the user community in advance as to how to change passwords and logon. You should avoid using AD Contacts and focus on Mail-enabled users in order to maintain passwords, groups and other attributes before, during and after the moves. This part of the project is critical and deserves its own section as you must maintain all X500, SMTP attributes. Moreover, it is important to cross-pollinate the LegacyExchangeDN value in one directory as an X500 address in the opposite directory for each mailbox. This will dramatically reduce and possibly eliminate reply failures and meeting ownerships.




  • Use the Move-Migration script to Mailbox-enable the target object and move the mail but use an outside process to handle all account changes in the source domain. This will give you more control and reliability of the source objects.  The Move-Mailbox script can perform these functions but there is little in the way of error-handling so if the AD is not responsive or there is a connection failure during object modifications, the Move-Mailbox command does not always recover. It is super reliable as a mail migration tool and semi-reliable with its AD changes so focus on its benefits and shore-up its weaknesses.
  • Execute a series of Post Scripts to perform any additional cleanup you may require for the accounts and mailboxes. There will be plenty. You will need a script to disconnect (do not delete in case you need to reconnect later) the mailbox on the source object and to turn it in to a Mail-enabled object with all the previous addresses and mail attributes. You will need another script to compare the object to make sure it is correct.

Just to make sure my point is perfectly clear, this is the exact code we use for every migration:


$import = Get-Content $textfile

$SourceCredential = get-credential

$TargetCredential = get-credential

$targetGC = ""

$sourceGC = ""

#move the migrated user's mailbox

$report = "g:\migrations\results\MailboxMove-$(Get-Date -format 'yyyy-MM-dd hh-mm-ss').xml"

Move-Mailbox -Identity $item -TargetDatabase $database -GlobalCatalog $targetGC -SourceForestGlobalCatalog $sourceGC -SourceForestCredential $SourceCredential -TargetForestCredential $TargetCredential -confirm:$False -RetryInterval 00:00:30 -BadItemLimit 50000 -IgnorePolicyMatch -AllowMerge -ReportFile $report


It is very, very simple. We create variables for the credentials and the Domain Controllers and allow the target database to be entered as a string so the execution of the migration looks something like this:

./migrationscript -textfile "C:\Group1.txt" -database "SERVERA\Storage Group 01\Database-01"

So let me explain a few of the details in this script. First, we force the retry interval to 30 seconds instead of the default 60. This is important since there is a delay between the time you write the object in AD and when the target Exchange server acknowledges the write. Also, there is a bug in the Move-Mailbox script that reports “Failed to set basic mailbox information, will retry in 60 seconds.”

You are more likely to see this message when performing cross-forest migrations:

“Failed to set basic mailbox information, will retry in 60 seconds”

Microsoft should rename this function to “Waiting” instead of “Failed” and you should just consider this 30 seconds part of the migration and move on!

Second, we set the BadIemLimit to a high number but we have NEVER seen a SINGLE item get dropped. Lastly, we added the IgnorePolicyMatch and -AllowMerge in order to meet our own goals.

TimeSaver-Make sure all of the target Exchange 2007 servers only have one Storage Group and one Mail Store. In bulk migrations, we found that roughly 5% of the migrations resulted in a (complete) disconnected mailbox in the designated target store and an empty connected mailbox in a completely different store. It seems that at some point during the end of a mailbox migration, the target server cannot enable the mailbox and Move-Mailbox creates a new empty mailbox on the same server on a different store. No error is flagged and the only way to detect this was to write a script:

get-mailboxserver | where {$ -like "SERVERNAME*"} |Get-mailboxStatistics | where {$_.DisconnectDate -notlike "" -and $_.Displayname -notlike "*test*"} | sort LastLogonTime | ft DisplayName, LastLogonTime, Database -wrap

This script is pretty simply as it is only looking to see if there are mailboxes that are in a disconnected state. This will be the case if the mailbox has been moved to another database or server or if the mailbox suffered the “split” problem as described.  However, by targeting a server with only a single database you eliminate this problem and have no need for my clever script.

Myth 2:

You must use 3rd party tools to automate the Outlook profile changes


This is even more false than the first item since Outlook 2007 will correct itself automatically! Yes, you read that correctly. Outlook 2007 will sense the change and use the Autodiscover feature to find the target AD and automatically reset the Exchange server connection settings. For Outlook 2003 clients you can use Microsoft’s Exchange Server Profile Redirector Tool which for us has a 90-95% success rate.

The profile redirector can be easily deployed from a logon script. You can place the redirector files in the netlogon share and execute it from a logon script like this:

%logonserver%\netlogon\exprofre.exe /targetgc= /n /v

You may notice that we are not using many of the switches here. That is by design.  By not adding the /F switch we are removing Outlook Favorites. By omitting the /A switch Outlook must download a new copy of the address book.  Since we omitted /O the OST file will be renamed instead of deleted. If you have strange problems with Outlook after test migrations you may want to add the /O switch in order to nuke OST files as they can be a problem. We left the/N switch in order to clear the nickname cache.

ExProfre is pretty sophisticated since it only makes changes when it detects the original mailbox is gone (converted to a Mail-Enabled object for example) and there is an entry in the target domain for the user.

Here is the link to the tool:

TimeSaver- Outlook problems will represent 5-10% of your help desk calls and the default fix for nearly all Outlook problems is to create a new fresh profile.

Myth 3:

Delegates and customized Mailbox Permissions are lost- FALSE


This is false since the source rights on the mailbox will come over as part of the Move-Mailbox process. In cross-forest migrations the original AD accounts in ForestA can be used to access the mailbox in ForestB. This behavior is supported by default by Move-Mailbox but not always desired. If for example, you plan for the users to begin using accounts in ForestB to access mailboxes in ForestB then the old Access Control Entries for ForestA could create some problems. We found that the legacy credentials may work for accessing the mailbox in ForestB but other Exchange functions in the new Forest did not work with the old credentials. This problem can be overcome by nesting certain Forest groups into each other for a true Forest trust or you can simply write a script to remove the old ACLS from the new mailbox. Here is an example of that code:

Get-Mailbox -Server "TARGETSERVER" | Get-ADPermission | where { ($_.IsInherited -eq $false) -and ($_.User -like “LEGACYDOMAIN\*") } | Remove-ADPermission -confirm:$false

Get-Mailbox -Server "TARGETSERVER" | Get-MailboxPermission | where { ($_.IsInherited -eq $false) -and ($_.User -like "LEGACYDOMAIN\*") } | Remove-MailboxPermission -confirm:$false

The permissions are split between ADPermission and MailboxPermission so you must run two commands to remove them completely. Moreover, there is no -server option with Get-ADPermission or Get-Mailboxpermission so you have to first enumerate the object using Get-Mailbox. Once you have the users for a particular server you can pipe the results to get the permissions limited by the ACLS that contain the domain name you wish to remove. You can then pipe the results to remove the permissions.

It is also important to note that Delegates will also come over but remember that with Outlook, the X.500 address is used behind the scenes to link users with mailboxes. So for this to work, you need to copy the LegacyExchangeDN value from each mailbox in the source domain and populate the migrated target object with a matching X500 proxy address. This will ensure that the delegate remains linked with the appropriate user. Here is a Microsoft article that explains the process in a little more detail:

The Move-Mailbox command should take care of this by itself, but it would be a good idea to write a script to collect the attribute then report on it after a group has been migrated just to make sure things are set as they should be. We don’t want end-user complaints to be our indicator that a directly entry is wrong!

Myth 4:

Cross-Forest Migrations are too complex and time-consuming-FALSE


Well, I say False but let me clarify. Yes, they are complex but they are manageable. Yes they are time-consuming but you can spend most of the time upfront in preparation and keep the actual migrations to a minimum. Here are some of the things you can do to make the process easier.

1)      Try to minimize expectations for the migrations. I usually send an email to the migration team and management that sets the expectations a little lower than we can deliver. For the most part, the migration will go far smoother than this message suggests but it sets the expectations to something we know we can deliver:

  • For the first week please choose recipients from the Global Address List instead of typing their name or using reply.
  • PST should be identified before the migration as the Outlook profile may “forget” about them even though they have not been moved or deleted.
  • The migration cannot move corrupt or damaged Outlook items. Our target is to move 99.9% of the mailbox items and provide a report when a corrupt or otherwise unmovable item is found.
  • Outlook may take a long time after the migration to recreate its offline cache (OST)
  • Many customized settings in Outlook may be gone
  • Delegates will need to be setup again
  • ny customized Outlook rules will need to be setup again
  • If they have SmartPhones configured, they will no longer work
  • You may get notifications for meetings that have already passed or ones you have already dismissed.

2)      To make the transition smoother, I would highly recommend the installation of the Microsoft Exchange Server Inter-Organization Replication tool. This tool will provide Free/Busy information across the two organizations and it will set the environment up to replicate other Public Folders if necessary. This tool is probably the easiest tool to setup and will provide the most value with the least amount of overhead. I usually install the tool on a Public Folder server in the Target organization and the publisher on a Public Folder server in the source organization.  The link to this free tool is here: Download the tool and expand to get the setup instructions. Once setup, this tool has never failed me.

3)      Move Workgroups at a time. Coexistence is by far the biggest point of confusion. “Have I been moved?” “Why does his/her email look differently than mine?” Moreover, when you move a workgroup together they become a support system for each other in the event that something does not go smoothly. When choosing who to move when, if you focus on business groups as the primary differentiator you will reduce helpdesk calls and overall confusion.

4)      Once you begin the migration, you should drive the migration to a conclusion. Every day you maintain a split organization you run an overly complex organization. Moreover, if your organization is not using automation to keep the directories synchronized every day that passes opens the door for more directly conflicts as people are added, removed or changed. You must minimize the amount of time you are coexisting on multiple platforms or in this case multiple Exchange organizations.

Myth 5:  

You must hire expensive Subject Matter Experts for your migration-False


This is absolutely false if you have some bright folks on your team who understand Powershell and Directory updates.  Having been hired to do many of these types of projects, I can say that I am usually only involved in the first 20-30% of the moves.  So someone like me is often involved in the beginning phases to get the migrations teams quickly ramped up and the process defined and refined so it is easy to repeat.

Most organizations just don’t have the time to (self) ramp up and continue to perform their day to day operations so bringing in an outside person/group to kick things off is pretty common but certainly not a requirement.

For example, unless you have done a considerable number of Cross-forest migrations, you may not truly appreciate the negative impact WAN links and remote Domain Controllers have on the process. Intra-Org moves say between two sites in the same organization works perfectly and rather fast. In a Cross-Organizational move however, the performance of the migration can be painfully slow and AD replication will offer considerable delays and even potential problems with conflicts. Moreover, targeting Exchange servers in various sites and locations means you are never really sure how fast the process will be and your projections will likely be WAY off.

Understanding those potential obstacles up front means you can plan around it and put into place a very consistent, reliable and predictable process. Here is one example of a process we have refined with experience:

CrossImage2One thing  we have learned with this model is we do not have to change the migration scripts to target different DCs and servers and most importantly we know exactly what our migration capacity is and can hit our projected numbers every single time with no surprises. As I mentioned before, it is also important that the target Exchange servers have only one storage group and one mail store. This will eliminate a potential problem with mailboxes that may “split” across stores.

To move people to remote servers after this move, you would just use the normal Move-Mailbox command or even the GUI to distribute the mailboxes. This process is reliable and a simple “Fire and Forget” operation since you can just queue them up before you go to bed at night!


Move-Mailbox “Failed to set basic mailbox information, will retry in 60 seconds”

Having done cross-forest migrations since the Exchange 5.5 days, let me say that they are complex, there are many things that can go wrong and that it is almost ALWAYS cheaper to do it without expensive tools as long as you are careful and do extensive testing.

First, let me start off with one of the first thing you will likely see in your tests:

“Failed to set basic mailbox information, will retry in 60 seconds”

This error is recoverable. In fact, it is really just a warning that it took a little longer to stage the target Exchange Mailbox.


So what is happening is Move-Mailbox is in the process of Mailbox-enabling the target AD account and it was unable to confirm the creation. The tool is designed to wait a while and then confirm its existence again. Now, here is where it gets strange….if you search enough you will find the Move-Mailbox command line reference on TechNet.

This article includes the following details on Retry Interval:

RetryInterval Optional Microsoft.Exchange.Data.EnhancedTimeSpan The RetryInterval parameter specifies the interval for retrieving the move’s status from the server.

Unfortunately, Microsoft leaves out two very important pieces of information:

1)      The Syntax is 00:00:00 (Hours:Minutes:Seconds)

2)      No matter what you use as a valid, the status screen will continue to show a 60 second delay ““Failed to set basic mailbox information, will retry in 60 seconds”

For Syntax and testing, I would recommend you start with 00:00:30 which is essentially half the default period. Your Move-Mailbox Script should look something like this:

Move-Mailbox -identity $item -TargetDatabase $TargetExchange -GlobalCatalog $GC -SourceForestGlobalCatalog $SGC -NTAccountOU $OU -SourceForestCredential $SourceCredential -TargetForestCredential $TargetCredential -confirm:$False -BadItemLimit 0 -RetryInterval 00:00:45 -SourceMailboxCleanupOptions MailEnableSourceAccount -ReportFile $report

Now, here is where things get fun. After you add the RetryInterval 00:00:45 the status screen will still say “will retry for 60 seconds” but if you time it you will see that the value you entered is honored.

In the migrations I have done, I have found that 30-45 seconds seem to work best for me. Also, I have also found that while Move-Mailbox tends to do a pretty good job at moving messages, it does not seem to be as robust when working with the AD. The performance of the DC, the proximity to the script execution and other less-measurable factors can easily trip this up in a cross-forest migration. I recommend that you push as much of the AD tasks outside of Move-Mailbox in order to increase the effectiveness of your migration. In short, try to do the Account Setup and Account cleanup tasks OUTSIDE of Move-Mailbox.

I have some scripts, a project overview and other helpful suggestions for a Cross-Forest move of mailboxes. Stay tuned!


SmartPhones and the Global Address List

Microsoft has released a small piece of software that allows mobile devices to access the Global Address List within your Exchange environment. While ActiveSync is the agent most think of when SmartPhones are mentioned, this particular add-on actually leverages the Public Virtual Directory in IIS and not the ActiveSync agent. In this article, I will show you the program’s features and what you need to do to get it working in your environment. There are a few assumptions here; you are using ActiveSync to keep Pocket Outlook up to date with your Exchange Server 2003 mailbox and you have network connectivity to a Front End server or your Mailbox Server/Front End Server. Also, for this tool to work, the server you connect to must have the /Public virtual directory loaded in IIS. (It is there by default)

If you have read my blog, then you already know that I had a boating mishap during Spring Break. My MPX220, Garmin GPSV and my pride got dunked in salt water and damaged. The next week was spent discovering all the new features of Windows Mobile 5 on my brand new Cingular 8125 (HTC Wizard). Two irritating things I found right away was that my new $500 phone did not have the new AKU 2.0 up-to-date features and Windows Mobile 5 still has no access into the Global Address List. After days of searching, I found that Cingular may one day post an update for AKU 2.0 and Microsoft has an excellent add-on for mobile devices called Microsoft Global Contact Access.

Microsoft Global Contact Access

There are two flavors of this application. One is roughly 400K and is designed for the smaller SmartPhone screens and the other is 700K and is better suited for Pocket PCs. The Samsung i700, the Palm Treo 700W and Cingular 8125 devices are technically both, but you would be encouraged to use Pocket PC applications for the most part since those are formatted for the larger screens and usually comes with a few more features. The download locations for each are located on the downloads page of the Windows Mobile add-on site:

Installation is easy as you need only to run the setup on your machine and let ActiveSync install the application. For you propeller heads, you can still just copy the CAB file to the device and launch it to install the application.

Once installed, you should notice three additional applications in the Start Men
u; Find Contact Online, New Email and New Meeting. If you are running the SmartPhone version you will not get the New Emailapplication.

New Meeting

Since the names are all self-explanatory, let’s just go over the basics first.

newmeetingNew Meeting fires up a meeting request pane. If you know the SMTP address of the attendees you wish to invite then you need only to key their addresses into the Attendees box. Remember to separate the names with a semi-colon.

If you want to choose these users from the GAL, then use the Find Contacts Online option from the Options selection at the bottom of the screen.

The Find Contact application is then launched. findcontactKey in the name of the person you wish to find and click Find to begin the launch. After the lookup is complete, you should see the results. Scroll down to choose the correct contact and click Done when you found the right one.

Note: If you have not configured the logon credentials for these new tools, you should then get prompted to enter your password and potentially the domain name, user name, server name, etc. These settings should match what you have already entered for the ActiveSync components.

freebusyNow things start to get really interesting. Now that you have selected all the attendees, the meeting time, subject line, notes, etc you can check the group’s free-busy data. (Yeah, you heard me right)




How Find Contact Works

As I mentioned before, these tools to not currently leverage ActiveSync. In my larger SmartPhone deployments, I have created new Virtual Servers in IIS (on the Front Ends) to support Active-Sync and NAT’ed these IPs and Virtual servers from the outside using only port 443. Of course Network Load Balancing is much better, but in some situations I can’t use it.

SmartPhonelockdownWhat you have with this design is the minimum footprint required to support ActiveSync synchronization over the wire. Unfortunately, this configuration is so locked-down; it will not allow the Find Contact features to work! Here is why:

ActiveSync uses GETS, POSTS and OPENS to synchronize against the /Microsoft-Server-ActiveSync application that is loaded on the Exchange 2003 Servers:

POST, /Microsoft-Server-ActiveSync, User=STEVEBRYANT&DeviceId=200687CAB5517E14783A6C62D31D4DC1&DeviceType=PocketPC&Cmd=GetItemEstimate&Log=V4TNASNC:0A0C0D0FS:0A0C0D0SP:1C7I5801S74670R0S0L0H0P

So my locked down configuration works just peachy. Unfortunately, the Find Contact function must access the /Public virtual directory since that is where Free/Busy information is kept:

GET, /public/, Cmd=freebusy&start=2006-04-18T00:00:00-04:00&end=2006-04-19T00:00:00-04:00&interval=30&u=SMTP:Jason%2eSherry%40theproexchange%2ecom&u=SMTP:Steve%2eA%2eBryant%40theproexchange%2ecom

To ensure these online GAL-lookup features work, you will need to make sure the /Public virtual directory is loaded.

This does not mean that you need any of the OWA tools installed though. Mobile ActiveSync and the GAL Lookup tools will work just fine using minimal components in IIS. Loading the Public virtual directory will provide support for the necessary Cmd=freebusy and Cmd=galfind commands as the Find Contact application does not use the web controls needed for OWA.

New locked down design

What we have learned is that these new features are very important to Windows Mobile users so your design should allow for access.


As I mentioned before, this design would be far more sophisticated with Network Load Balancing on the Front End Servers and some type of reverse-proxy server such as ISA 2004 or Firepass F5 between the Internet clients and the Front End servers. It is also important to note that the ONLY port that should be opened is 443.


Out of Office = Come rob my house

One of the coolest things about Outlook 2000, was the ease at which we could create rules and manage Out of Office replies. This feature has become even easier still with support not only for Outlook, but for the Outlook Web Access product as well. In fact, most corporate mail platforms allow some level of automated replies for OOF we well as functions that request delivery and read receipts. So the real question is whether your company should allow, support and troubleshoot these functions. While the internal value of these features is clear, the implications of these messages being sent out to Internet hosts are not always understood. Let me give you an example:


Subject: Out of Office AutoReply: Need V1agra? Ch3ck 0ur l0w price$$

I will be out of the office until June 5 and will have limited access to email as I am away on vacation with my family. We are out of the country and not watching the house, but have left the back door open in case you need anything.

For those of you from work, please contact Kendall as she is in charge of everything except for really important things that should be sent to Haley (when she gets back from her trip to Japan.)

Talk to you when I get back!


Office: 770-555-1212

Cell: 678-555-1212

Home: 404-555-1212”

OK, so what are we saying in this message? Our house is empty and likely our office is as well. I am out of the country with my family and I do not fully trust Kendall with the office functions. We have also disclosed the travel plans of a co-worker. Now I know my example is a little extreme, but you have to admit it is not too far from the truth. A quick Google search on a phone number will return your home address and with one more click you can get directions to almost anyone’s home or office. Pretty scary huh?

When I first began researching this problem, I found that security experts have been warning people for years about the risk if Internet Out of Office and other auto-replies. Here are a couple of references I found while doing a quick search on the subject:

  • Out of Office used to target home burglary:

“In December 2002, a British hi-tech group released a warning that thieves could use e-mail lists to send mass-mailings in order to retrieve vacation auto-replies. The auto-replies could be cross-referenced with publicly available personal information, and used to target the home of a vacationer. At the time of the warning, an FBI public affairs officer told ABC News that it “has some indication that there might be some of this activity.”

  • Corporate Risk to Out of Office replies

“According to Chris Poulos, Trend Micro Australia and New Zealand managing director, recent research has shown that criminal organizations use mass emails to search for auto-reply messages generated by key personnel such as senior management and financial staff.
He warns this can result in substantial financial loss, damaged credit ratings and is an invasion of personal privacy, as an auto-reply can open the door to hackers and spammers and provide opportunity for identity theft and telephone fraud.”

  • Out of Office replies increases SPAM

” If you use “vacation/out of office” replies on your e-mail account when you’re away, you automatically generate a reply to each incoming spam message that confirms that your address is valid, and that someone is reading it (see “What should not be done about ‘spam’?”, below). This makes it more likely that your address will be sold/swapped by spammers.”

Out of Office replies are not the only automated chink in the armor. Within Exchange and Outlook, there are six types of automated responses that are available:


1) Non-Delivery Reports (NDRs)

2) Delivery Report (Delivery Receipt)


3) Out of Office Responses (Configurable through Outlook)

4) Auto forward Rules (Configurable through Outlook)

5) Auto-reply rules (Configurable through Outlook)

6) Read Receipts (Managed by the Outlook client)

I took an informal poll to other Exchange MVPs and large system operators and was told that most disable all automated replies, especially those that verify a successful delivery. This would include Delivery Reports, Out Of Office replies and any auto-reply rule from Outlook. What I found (by sending test messages to people in large Fortune 500 companies) is that most block nothing. This really surprised me considering the fact that most analysts including Gartner report that unsolicited mail (SPAM) accounts for over 60% of the total messages being delivered over the Internet. Can you imagine the message volume created by large companies just to reply to all the SPAM?  The biggest risk could actually be the phisher’s who are writing code to extract personal information from messages whose subject lines read “Out of Office” or “OOF” My signature includes my full name, company name and phone numbers. I probably don’t want identity thieves knowing all that information as it could help them to learn more about me.

Best Practices for Businesses

So now that we know the problem, what do we do? To begin, we should as a general rule disable any automatic replies that would indicate a success. Let’s start with the server level settings. Using the Exchange System Manager console, we can open and modify the behavior for the Default “*” domains. Within this setting, we can define the default settings.


Using the Exchange System Manager, we can add specific format rules for specific domains. This ability allows us to adjust the auto reply settings different for our business partners.

Is it from this settings screen that we are able to define all of the server reply settings for the organization. This is an important distinction as there is no granular way to apply settings like this for individuals or servers. Instead, we have one set of choices for the entire Exchange organization as a whole.


From a security standpoint, blocking automatic replies, Out of Office replies and Outlook auto forward from being sent out to the Internet is a good starting point.

Out of Office, Auto Replies and Auto Forwards

These three settings are actually controlled by the Outlook client. Exchange 2003 (and Outlook 2003) allows these rules to be fired from the server itself and no longer require the Outlook client to be running. The first thing we want to do is use the ESM to restrict OOF replies from being sent out to the Internet. This is the key point of this article for reasons I have already mentioned. What these settings also do is restrict any Outlook mailbox rules from sending any type of auto reply or auto forward. Auto forwards are dangerous to your organization because of the ease at which corporate intelligence could be sent out to unknown and uncontrolled accounts. Auto-replies likewise provide the same type of risks that Out of Office rules apply in that they can send out corporate intelligence as well as sensitive user information such as message signatures or custom reply text. Another reason for turning these off is mail volume. When you receive an unsolicited message, an auto reply message would be sent back to the sender. Most of the time, the return address is false to an NDR is returned to your sender. In short, one SPAM message becomes three your server has to process and two the client must read which wastes productivity.

Non-Delivery Reports

Another best practice is to allow non-delivery reports to be sent. While some who are more security-conscious that I (imagine that) may say that this helps SPAMers, I think of NDRs are a basic troubleshooting tool required by both system administrators and users. If a partner fat-fingered your email address, wouldn’t you want that person to know? If you have any question on this subject ask someone in your sales department and they will be able to present better arguments than I ever could. For most companies, the benefit to NDRs outweighs the risks and so NDRs are allows to be sent to Internet hosts.

Delivery Reports

Technically, delivery reports (delivery receipts) also disclose information that could potentially be used by SPAMers to confirm email addresses. I have yet to see this exploited and it too can be used as a valuable tool that vendors and partners can use to verify message delivery. Most companies (even financial institutions and government facilities) I work with have left this setting on and most experts agree that the ability to provide delivery reports is mostly benign.

Read Receipts

You may have noticed that there is no setting in the ESM to block responses to read receipts. This is another client-controlled setting and one that is difficult to block without buying third-party tools or creating a custom Event Sink in Exchange. What you can do, however is block (or allow) read receipts directly from the Outlook 2003 client itself. From the Tools, Options menu, you can click the E-Mail Options button to access the Tracking Options page. From here you can configure the client to process read receipt request automatically or even to ignore the requests altogether.


Outlook 2003 (and Outlook XP) comes with a tracking options page that allows you to control, how requests and processed including read receipt requests. Don’t be misled by the indication that the read receipt option “Only applies to Internet Mail accounts” as this setting applies for clients connected to an Exchange server as well.

WARNING: If your Outlook 2003 client connects to a POP/IMAP/SMTP server then you could be exposing much more by issuing mailbox rules as the client’s IP address is put into the message header when the reply is generated. For some reason, Microsoft has even published a how-to article that shows you how to  “Determine a recipient’s IP address by using read receipts.” Here is the link in case you are interested.

Lastly, I mentioned earlier that there is no ESM option for blocking read receipts from Internet delivery. For most companies the inability to easily remove these types of notifications does not pose a serious problem. If your company has identified that read receipts should be blocked, then you are not out of luck as there are third-party tools available as well as some simple scripts you can write to block the request before it ever gets to the Outlook client.

Contrary to popular opinion, Microsoft and Exchange server does conform to the SMTP RFCs for message delivery and format. When a sender requests a read receipt, two header fields are added to the message: Read-Receipt-To and Disposition-Notification-To. Instead of programmatically blocking read receipts from leaving the system, we can write an Event Sink for the SMTP stack that strips these two header fields from incoming messages. The IIS 5 and 6 both support the use of “OnArrival transport events” which is what we would want to use for this. A really good example of such a script can be found at Péter’s example provides the syntax for a VBScript that does just the trick with only a few lines of code:

Const cdoRunNextSink = 0

Sub ISMTPOnArrival_OnArrival(ByVal Msg, EventStatus)
‘ remove read receipt request fields
Set Flds = Msg.Fields
With Flds
‘ update the mail header
End With

‘ save changes to the mail

‘ continue execution with the next sink
EventStatus = cdoRunNextSink
End Sub

Simply register the .VBS file you create with this code on all the servers that directly receive the mail from the Internet (any “gateway” server running Windows 2000 or Windows Server 2003 machine running SMTP and you are in business!


Auto-generated responses are an excellent way to trouble-shoot the delivery of mail. It is good practice, however to disable responses that can compromise your business intelligence or provide personal information to others on the Internet. Automatic notifications that have the ability to auto-forward information to outside resources is definitely a no-no. Moreover, Out of Office responses are helpful for internal notifications but can seriously compromise corporate and personal safety when sent to Internet addresses. Use common sense when establishing your acceptable-use policies and ultimately in configuring your Exchange environment.

Microsoft Identity Integration Server Setup and Configuration Guide Exchange 5.5 to Active Directory Document

Download the entire process in PDF format MIIS Deployment for Exchange 5.5


There are situations where Exchange 5.5 will need to coexist with other directories for extended amounts of time. It is estimated that over 20 million Exchange 5.5 seats will remain in that environment for years to come. This is a troubling thought for Microsoft and indeed for those procrastinating companies since Exchange 5.5 support is over.
Having said that, the estimate remains and so does the problem of coexistence. In this example, we have an Exchange 5.5 organization that will need to stay synchronized with several other Active Directory environments running Exchange 2000 and Exchange 2003. To support this requirement, we need to ensure we have selected the fields and formats needed to allow message flow to work across different system types.


The first thing we need to do is map out the directory requirements:

From the AD Domain to Exchange 5.5

a) Mail-enabled Contacts –> Exchange 5.5 custom recipients Name, Address, Company, title and Phone Number Fields SMTP, X.500 and X.400 addresses

b) Mailbox-enabled Users –> Exchange 5.5 custom recipients Name, Address, Company, title and Phone Number Fields SMTP, X.500 and X.400 addresses

c) Mail-enabled groups –> Exchange 5.5 custom recipients SMTP, X.500 and X.400 addresses

From Exchange 5.5 to the AD Domain

a) Exchange 5.5 custom recipients –> Mail-enabled Contacts Name, Address, Company, title and Phone Number Fields SMTP, X.500 and X.400 addresses

b) Exchange 5.5 custom recipients –> Mailbox-enabled Users Name, Address, Company, title and Phone Number Fields SMTP, X.500 and X.400 addresses

c) Exchange Distribution Lists –> Mail-enabled Contacts SMTP, X.500 and X.400 addresses Ownership and Support

While building the system, we found many more useful fields and attributes that should be added and we created intelligent discovery and join rules as well as highly detailed projection rules. This basic list you see above expanded to include hundreds of fields.

Product Choice

As you can imagine, there are many products available to perform this type of directory synchronization. HP offers a product called LDSU and less-expensive offerings such as SimpleSync are also available. We chose Microsoft’s Identity Integration Server 2003 because of its support for AD, Exchange and ability to synchronize with Lotus Notes, SQL and DBMS.

Test Lab Environment

The most important aspect of MIIS is your test environment. It is from this environment that you test new scripts, attribute flows, join rules, etc. For us, we have built an entire lab environment that includes MIIS, Exchange 5.5 and Exchange 2003 (on Windows 2000 Server) in virtual images that can be transported, copied and distributed to those who need a better understanding of the systems.

Servers and Configuration

There are three servers in this test environment. All are patched to the current date and homogenized with test data.


The MIIS virtual machine has all the required components installed locally to fully manage and run the MIIS environment. SQL Server 2000 Enterprise, SP3 is installed and fully patched. Microsoft Identity Integration Server 2003, SP1 is also installedimage002. In order to manage and maintain MIIS, Microsoft Visual Studio .NET 2003 is installed as well.
Computer name MIIS

  • WorkGroup                       WorkGroup
  • IP                               
  • Administrator                 administrator
  • Password                           MSEvent.123



Active Directory

On this image, we have Exchange Server 2003 as well as the domain services for the domain. Windows Server 2000 in installed as is the Support Tools (ADSIEdit is handy for this type of work)image004

  • Computer Name       ALPINEMAIL
  • Domain             
  • IP                         
  • Administrator           administrator
  • Password                     MSEvent.123


Exchange 5.5

The MIIS virtual machine is running Windows 2000 Server and Exchange 5.5. It is a domain controller as well as the global catalog server for

  • Computer name    EXCHANGE55
  • Domain                    EX5.COMimage006
  • IP                     
  • Administrator      administrator
  • Password               MSEvent.123



Setting up the MIIS Environment


To help reduce the risk of applying changes back to the source systems, it is very important that each environment establish a working account for the MIIS system to use. In our examples, we have created an account in both domains called MIIS. These accounts should not be in the administrators or domain administrators group.

  • MIIS Account name      MIIS
  • Password                          MSEvent.123

Active Directory

It is important that this account not be given too much access to the Active Directory.

  • In the root of the Active Directory domain, give the MIIS account the following permissions:
    • Read
    • Replicating Directory Changes
    • Replication Synchronization
  • In the container or OU you wish to use to import metaverse data, give the MIIS account the following permissions:
    • Full Control ƒ
      • These rights could probably be tuned down finer in order to restrict group policy and some Exchange attributes, but this setting is the bare minimum for this container

Exchange Server 2003 (or 2000)

Some mail attributes require read permissions from the Exchange 2003 organization. It is a good idea to assign the same MIIS account the following permissions to the Exchange organization:

  • Exchange View Only Administrator

Exchange 5.5

In order for MIIS to write to the Exchange directory, we repeat a similar process. As before, an account needs to be created. In our lab, we created a domain account named MIIS and made sure the account was not added to any administrative group. Then from the Exchange Admin application, give the account the following rights:

  • Search Permissions to the Organization
  • View Only Admin to the Site you will connect to for directory writes
  • Admin to the container the MIIS server will use for directory writes

Note: In some cases, Search permissions will not work against the organizational such as when the DS Site Configuration for the site is incorrect or when the Anonymous account has been disabled or deleted. In these instances, it you may need to give the MIIS account greater access to the organization (this does not automatically give the account permissions to user objects as rights in the org-level are not inherited down to the site and container levels). The Admin role is sufficient in all cases to perform searches against the global address list. Verify that the account does not have permissions to the recipient’s container.

Management Agents

In the initial setup, there are two management agents. One MA connects to the Legacy Exchange 5.5 organization while the other connects to the product CRM Active Directory. As business break out of the Exchange 5.5 organization, they will need their own Management Agent added to initialize the connection and maintain directory Sync. These management agents control attribute flow, connection settings and are called (by name) from the custom provisioning code that has been written for this example. A third management agent has been added for country-code lookups, but it is not fully integrated and optional.

Management Window

The Identity Manager is where most of the work is done for MIIS. It is from this program that we configure the connections, attribute flow, replication schedule and monitor the system for errors and problems. It can be launched from the Start Menu and has several selections at the top of the screen. We will focus on the Management Agents screen for now.


Metaverse Object

Before we get into the management agents, we need to get a better understanding of what we are doing with MIIS and how we plan to do it! We will be importing Mailbox, DL and contact information from Exchange 5.5 and placing that information in a SQL database. This Metaverse will contain a global directory of names imported from Exchange 5.5 as well as names imported from other Active Directory domains. We have defined how these objects will look in the Metaverse by creating a generic MV object called a Metaverse_Contact.

This object type was created from scratch and contains specific fields needed for our immediate needs and some fields we think will be needed later for additional functionality.

Here are the attributes you need to add as well as the characteristics of the attribute:

Assistant                                               String     (indexable)             Not Multi-valued

c                                                              String     (indexable)             Not Multi-valued

cn                                                            String     (indexable)             Not Multi-valued

co                                                            String     (indexable)             Not Multi-valued

company                                                String     (indexable)             Not Multi-valued

department                                            String     (indexable)             Not Multi-valued

displayName                                         String     (indexable)             Not Multi-valued

division                                                  String     (indexable)             Not Multi-valued

employeeID                                           String     (indexable)             Not Multi-valued

EmployeeStatus                                   String     (indexable)             Not Multi-valued

employeeType                                      String     (indexable)             Not Multi-valued

facsimileTelephoneNumber                String     (indexable)             Not Multi-valued

givenName                                            String     (indexable)             Not Multi-valued

groupType                                            Number                                  Not Multi-valued

hideDLMembership                             Boolean                                 Not Multi-valued

homeMTA                                            Reference (DN)                     Not Multi-valued

homePhone                                           String     (indexable)             Not Multi-valued

info                                                         String     (indexable)             Not Multi-valued

initials                                                    String     (indexable)             Not Multi-valued

l                                                               String     (indexable)             Not Multi-valued

legacyExchangeDN                             String     (indexable)             Multi-valued                         Indexed

locality                                                   String     (indexable)             Not Multi-valued                 Indexed

mail                                                         String     (indexable)             Not Multi-valued                 Indexed

mailNickname                                        String     (indexable)             Not Multi-valued

manager                                                 Reference (DN)                     Not Multi-valued

MapiRecipient                                      Boolean                                 Not Multi-valued

mobile                                                    String     (indexable)             Not Multi-valued

msExchAssistantName                       String     (indexable)             Not Multi-valued

msExchExpansionServerName           String     (non-indexable)    Not Multi-valued

msExchHideFromAddressLists         Boolean                                 Not Multi-valued

msExchHomeServerName                   String     (indexable)             Not Multi-valued

msExchMasterAccountSid                 Binary    (indexable)             Not Multi-valued

msExchOriginatingForest                   String     (indexable)             Not Multi-valued

nTGroupMembers                               Binary    (indexable)             Multi-valued                         Indexed

o                                                              String     (indexable)             Not Multi-valued

otherHomePhone                                 String     (indexable)             Multi-valued                         Indexed

otherTelephone                                    String     (indexable)             Multi-valued                         Indexed

pager                                                      String     (indexable)             Not Multi-valued

physicalDeliveryOfficeName             String     (indexable)             Not Multi-valued

postalCode                                            String     (indexable)             Not Multi-valued

proxyAddresses                                   String     (indexable)             Multi-valued                         Indexed

Rfc822Mailbox                                      String     (indexable)             Not Multi-valued

sn                                                            String     (indexable)             Not Multi-valued

st                                                             String     (indexable)             Not Multi-valued

streetaddress                                        String     (indexable)             Not Multi-valued

targetAddress                                      String     (indexable)             Not Multi-valued                 Indexed

telephoneAssistant                             String     (indexable)             Not Multi-valued

telephoneNumber                                                String     (indexable)             Not Multi-valued

textEncodedORAddress                     String     (indexable)             Not Multi-valued

title                                                         String     (indexable)             Not Multi-valued

uid                                                          String     (non-indexable)    Not Multi-valued

It is possible to clean up these entries in order to further trim down unnecessary attributes. In some instances, you may want to create additional attributes for specific tasks for example. You could create an attribute to denote whether an item should be written to the target directory and perform a filter against that field. In addition, you could create “work” fields to hold any type of data you wish to key upon in code.

Exchange 55 GAL MA

OK, so now that we know the Metaverse (MV) object we are going to target, we can take a deeper look at the agents that collect and distribute the data. Each MA contains connection information to a specific directory. As a result, each MA is also known as a Collector Space (CS). To view the settings on the Exchange 55 GAL MA, we need only to double click the agent from the mimage002 (1)ain agent screen.

This page shows us the base Management Agent (Exchange Server 5.5) and the name we have provided to identify the Agent. This name is used within the source code to identify the Connector Space.


Connection to Organization

In this page, we identify the Exchange 5.5image004 server we will connect to as well as the credentials we will use. You can see that we have specified the MIIS user account in order to restrict our permissions to the Exchange environment. Moreover, you should notice that we are not using the standard port of 389 for our LDAP connections. This server is also a Windows 2000 Server running Domain Controller services so we had to change the Exchange 5.5 port for LDAP to port 390.



Configure Sites

It is from this screen that we identify the sites that contain the objects we want to image006synchronize (copy to) with the AD. From this screen, we can identify any other servers we want to target (not required for this installation) as well as the containers we want to choose.

Note: It is important that you select both the source containers and target containers from the Containers window. Deselected containers will not be used for either reading or writing with MIIS.


 Select Object Typesimage008

We need to expose several different types of information from the Exchange 5.5 environment. You will probably need to use the Show All checkbox to select each of these object types.





Select Attributes

In our case, we are selecting a few more attributes than required per our list of requirements, but the additional fields we have identified will allow us to better connect the directories now and for later projects.

You will certainly need to select the Show All checkbox to get to all of these attributes:

  • C
  • Cnimage002 (2)
  • Co
  • Company
  • Department
  • Description
  • Extension-Attribute-1
  • facsimileTelephoneNumber
  • giveName
  • Hide-From-Address-Book
  • Initials
  • L
  • Mail
  • MAPI-Recipient
  • Mobile
  • otherMailbox
  • pager
  • physicalDeliveryOfficeName
  • postalAddress
  • postalCode
  • Proxy-Addresses
  • Rdn
  • Report-To-Originator
  • Report-To-Owner
  • Rfc822Mailbox
  • Sn
  • St
  • Street
  • Target-Address
  • telephoneNumber
  • textEncodedORaddress
  • title
  • uid

Configure Connector Filter

The connector filter is used to specify things we do not want to replicate. In our environment, we have chosen not to replicate anything that does not have an Internet Address. We could also choose not to replicate hidden objects or objects with certain key words in the Custom Attribute field or similar. The object types you see listed in this window are specific to Exchange 5.5.image004 (1)

groupOfNames –distribution list

organizationalPerson -mailbox

Remote-Address –custom recipient

These are the only objects you really need to focus on when building filters in this Exchange management agent.

Configure Join and Projection Rules

This is where things can get a little confusing with MIIS. It is important that each person in your organization only exist in the directories once. This sounds pretty basic, but if there are more than one of you, then mail flow could break. The problem is that in many cases, a company has a contact or custom recipient in one system that “points” to a mailbox in another system.  Because of that, you may be in two directories at once. Now, if we should try to combine those directories, we need to make sure there is some logic that does not allow duplicate entries to be created.

Join Rules

The purpose of a join rules is to try to match objects before creating them. For example, let us assume that someone in one directory has created n custom contact or recipient for someone in another directory. By default, both would be copied to the metaverse.


This part in of itself does not create a problem. It is when that objects are written back that we have issues as duplicate items will be written which will certainly cause a disruption in mail flow within that system.


To prevent this from happening, we use join rules to “connect” duplicates in the metaverse.


You can create very specific join rules to follow your business logic For example, you may have items in an HR system that should take precedent over other source systems in which case you could join based on a specific field type or format.

In this example, we are joining objects if the mail attribute is matched. In other words, if an object using the mail attribute: is in the metaverse, another object using the same mail attribute will “join” the existing one. This prevents the mail address from being used more than once in the environment. In fact, we are using two rules for each object type:

  • Join if mail attribute is matched
    • If a contact, group or user is imported into the metaverse with a specific mail attribute, no other other object may overwrite it. This means that user objects may “join” existing contact objects if the custom recipient already exists for that user. The drawback to this example would be that the entry could have incomplete directory information and that the real mailbox would not be authorative for the object.
  • Project is mail attribute is not matched
    • If the RFC822mailbox field is populated and the there is no match for the mail attribute, then the object will be automatically projected into the Metaverse

Configuring the basic join rules I have described is a fairly easy task and should take no longer than a few short minutes to apply. Open the Configure Join and Projection Rules selection from the Exchange 55 GAL MA agent.

You will need to add two rules to each of the object types you wish to synchronize. For this example, we will add the following:


  • Declared Projection Rule based on the Metaverse_Contact object type.
  • Direct Join rule based on the mail field between the “mail” data source attribute and the “mail” attribute on “Metaverse_Contact.


  • Declared Projection Rule based on the Metaverse_Contact object type.
  • Direct Join rule based on the mail field between the “mail” data source attribute and the “mail” attribute on “Metaverse_Contact.


  • Declared Projection Rule based on the Metaverse_Contact object type.
  • Direct Join rule based on the mail field between the “mail” data source attribute and the “mail” attribute on “Metaverse_Contact.

You should notice that the projection rules follow the join rules. You can create multiple join rules for each object type and you can specify custom rules to handle joins. For our purposes, the standard mail mapping fields will suffice.

Configure Attribute Flow

This step will likely take the most time and you should pay close attention to the detail. As we map fields from Exchange to the metaverse and visa-versa we have to pay close attention to the flow direction as well as any advanced rules we need to apply. As you will find out, standard mapping rules will allow us to meet our objectives. From the Configure Attribute Flow screen, you can see that we are configuring flow for all three object types we wish to synchronize.

image002 (3)

To make things simple for this installation, we are importing each of the Exchange settings into a single object type called Metaverse_contact. Moreover, we are only exporting objects into the Exchange environment as Remote-Address (custom recipients) and only into a specific, pre-determined container. When specifying attribute flow, you choose the source, the target and the fields you wish to map. In addition, you can specify any advanced mapping type you wish to use. When using the advanced features, we can select more than one object type as a source and the source code we wish to use to handle the business logic. Let’s go over an example. You should notice that the mail field highlighted in the picture shows an Advanced mapping rule is in place. If we click Edit, we can see which rule is being identified.

From the advanced flow options window, we can see that a specific flow rule named “mail” is identified. This tells MIIS that when performing an import on this object, it should reference the extension DLL identified in this MA (we will get to that later in the document) and that the logic in that code should be applied to this flow.

Inside our extension DLL, we have a sub called:

  Public Sub MapAttributesForImport(ByVal FlowRuleName As String, ByVal csentry AsMicrosoft.MetadirectoryServices.CSEntry, ByVal mventry AsMicrosoft.MetadirectoryServices.MVEntry) ImplementsMicrosoft.MetadirectoryServices.IMASynchronization.MapAttributesForImport

Within this sub, there are several import rules defined. This is the one named mail:

Case "mail"

                If csentry(FlowRuleName).IsPresent Then

                    Dim work As String = csentry(FlowRuleName).Value

                    work = Replace(work, "/", "")

                    work = Replace(work, "\", "")

                    mventry(FlowRuleName).Value = work

                End If

The purpose of this code is to cleanout illegal characters such as the “/” and “\” from the mail address (SMTP Address). An illegal address of Atlanta/sales@companya.comwould be changed to While the illegal characters would remain in the Exchange system, they would be clean in the metaverse and then legal to push to AD.

Export Attribute Flow (Send to Exchange from Metaverse)

Here are the current flow settings for the Exchange MA. You can see from this table, that we did not require specialized code to manipulate the data. Instead, we elected to clean the information during the import process so that data in the metaverse is “normalized”.


Import Attribute Flow (Send to Metaverse from Exchange)

Importing Exchange information into the metaverse required much more work in that we needed to reformat, clean and construct new fields based on information collected from other fields. In order to correctly populate the proxyaddresses attribute, we had to contruct the field based on three Exchange 5.5 fields; otherMailbox, rfc822Mailbox and textEncodedORaddress. Custom code was created to combine these strings into a collection in order to populate the multi-value field in the MV. To see the source code for the specific rules extensions, refer to the code section at the end of this document.


Exchange store size is a matter of comfort

Margie Semilof wrote a great article on Exchange store sizes and I was fortunate to be able to contribute my thoughts on the subject.

“While there’s no drop-dead limit for an Exchange Server database store, there are some guidelines to help put messaging administrators in a comfort zone.”

To read the entire article, click here.

Security ‘to-do’ list

Security is not a sexy topic, but things can get downright ugly when the executive’s password is found out or someone attacks and cripples your mail server.

Often, a company is unable to prioritize security until something terrible happens and the payroll summary mysteriously appears in the break room or your server is getting constantly bombarded with mail or packet bombs. More often, it is this pain that provides the security “wake-up call” for many companies.

The purpose of this paper is to provide a short list of things you can do to protect your servers and messaging environment from attacks.

  • Physical Server Security. As simple as this may seem, you would be surprised as to how many mail servers I have seen in someone’s cubicle or in a general area of the building. All production servers should be logged off and behind a locked door of some kind. Do not underestimate the curiosity of your co-workers especially around review time. Depending on the account that is currently logged on, every mailbox could potentially be accessed by anyone who could walk up to the server and use the keyboard.
  • Network Security. In a word, Firewall.
  • Password Security. By enforcing strong passwords and regular change intervals you can make it more difficult for hackers to collect passwords. Also, use SSL to encrypt the usernames and passwords for your HTTP, POP, IMAP and (outgoing user) SMTP authentication.
  • Antivirus. This area has shifted into the security model as an outbreak or malicious attack could cripple your systems. There are three areas of major concern we will discuss: SMTP, the Exchange Store and the client machines.
  • SMTP Relay. An open relay invites spam, jeopardizes the stability of your environment and could potentially get you blacklisted from other domains as an open relay server.

Physical Security
As mentioned earlier, there should be physical security between your Exchange servers and the rest of the population. This means a locked door of some kind that restricts access to the machines. Also, there should be some type of monitoring system in place to track changes to the server and access. Perhaps this simply means a clipboard that each administrator uses to record the time and day when they use the server console or reboot the server. Auditing should be turned on and each administrator should be using their own account and not a shared account. If you do not adhere to these “rules” then you will have no idea who rebooted the computer in the middle of the day or if someone is intentionally or accidentally crashing the systems.

It is incredibly important to provide some protocol separation between your Exchange server and the Internet. In the event that you are connecting to branch offices or remote offices that are connecting to the Internet without a good firewall, then you may also need to separate your servers from those remote offices.

At a minimum, we are trying to protect our server from UDP and TCP attacks. Packet filtering and blocking is the bottom-line requirement. There are several acceptable ways of protecting your network and allowing access to the Exchange servers, but we will start with the most sophisticated method that allows application filtering and monitoring.

Microsoft ISA Server
Within your DMZ, you can place an ISA server. This box will provide firewall and proxy cache access for your clients. This server can do some incredible things with application publishing including the ability to “proxy” MAPI requests to the Internet without exposing your Exchange 2000 server. It also provides a mechanism for content scanning in order to accept mail and scan it for attachments or keywords. It can then send the mail to your Exchange Server in your private network.

Exchange 2000 Front End Server
Exchange 2000 now supports a server configuration that allows clients to access their mailboxes and Exchange content through a central server. This server acts as a relay for the client. When a FE server is placed in your DMZ or otherwise accessed by a POP, IMAP or HTTP client, the request is relayed to the appropriate backend server automatically.

Firewall Appliance or Server
Just about any firewall will allow packet and port filtering in order to protect your network and Exchange environment. While this is a good start for protecting your servers, it falls short of complete protection since you have to open ports to allow access to the data in your private network. For example, port 25 must be opened to allow for SMTP traffic, port 80 for HTTP.

By the time you open the necessary ports for HTTP, POP, IMAP and SMTP access you have opened many of the well-known ports and have invited outsiders to attempt hacks into your systems.

If you are using the HTTP, POP or IMAP functionality to allow access to your mail servers, you need to make sure that you have enabled SSL on each of these protocols, including the virtual SMTP server you are using for outbound mail for your POP and IMAP clients. If you are allowing those protocols and not requiring SSL, then you are letting your users send their usernames and passwords as clear text over the Internet.

The first thing you need to do is establish a Certificate Authority in your organization and request a ticket for your server. The ticket will refer to the DNS name of the server so that it matches the name you will request. The following articles discuss how to apply the ticket and secure your web services:;en-us;Q320291.

From within the Exchange 2000 protocol item in the System Manager, you should also associate your ticket with the IMAP and POP Services. To lock down the SMTP service, you need to be more careful since this service affects mail routing as well. An excellent article that details the processes for these services and the overall process can be found at;en-us;Q319574.

This is one of the most important aspects of security and something that is often overlooked. There are three areas of protection you need to consider:

  • Inbound (outbound is also a good idea) SMTP mail scanning.Third-party tools can be purchased that run on Exchange 2000 or on a separate box to collect, scan and forward SMTP messages. I highly recommend the Sybari Antigen for this purpose because of it’s sheer speed and the fact that it comes with multiple scan engines, which are very helpful for new viruses.
  • Store Scans. You should also plan on a tool to scan the Exchange stores periodically for viruses in the public and private stores. Again, Antigen is a great tool for this as it uses the new Exchange 2000 API and can not only scan the stores, but monitor the X.400 and MTA services as well for signatures.
  • Client Protection. One of the reasons virus outbreaks can be so devastating is many were written to automatically use the address book to propagate messages out to those we know. You would open a message from a friend just to find out that it contained a virus. There are several add-ins to help protect the client machines from known viruses, but one of the best approaches is a free tool called the Outlook Security Patch. Outlook 2002 has this feature built in, but it is a separate download for Outlook 2000. When this tool is installed, programmatic access to the address book will be blocked. In addition, you can block access to file types as well including .EXE and .COM files and other attachments. this will greatly reduce your risks from an internal outbreak.

Open SMTP Relay=BAD
If you upgraded your Exchange 5.5 server or if someone changed the default Exchange 2000 settings, your server may be an open relay. What this means is that your server could be used to send messages for spam purposes. This is also bad for a number of other reasons, including the embarrassment when your server is used to send unsolicited spam mail for diplomas or “Hot Asian Babes.” Also, this added traffic could cripple your server or your network and cause your company e-mail to bounce or sit in queues for days. On top of that, there are services on the Internet that detect and report open relays. Some companies use these blacklists to ban mail from certain domains. If your server is detected to be an open relay, you may find yourself unable to send mail to certain domains. Some of these services detect that Exchange is an open relay even though it may be closed. Here is an article that describes this aspect in more detail:;en-us;Q304897By default, Exchange 2000 required authentication in order to relay. If you have a requirement to use Exchange 2000 as a relay server, we recommend that you read this article for specific instructions on how to make sure it is secure:;en-us;Q293800

You can take steps now to make your Exchange environment more secure. You are far better off doing these things now rather than later.