I find it peculiar how sometimes you look at a method of accomplishing a specific task with Exchange server and you think - “I doubt I will ever need to use that” - so you pass it by and think little of it (perhaps it is just me).

However despite the above recently I have had cause to become very familiar with the process of Segregating Exchange 2007 Address Lists whereby in effect you can host two or more organisations out of a single Exchange server installation (or Organization) without them being aware of one another - this was something that I thought I would not use.

Now some of you might be thinking - but its very easy to get versions of Exchange (from Exchange 2000) to handle SMTP mail as multiple organizations - to which you are quite correct - however that assumption based on a SMTP authoritative domain perspective - but consider the following scenarios (both scenarios assume Exchange 2007 as the Mail System in use);

Setting the Scene - Example 1:

You have set yourself up as a business that “hosts” e-mail for two companies, each company has its own SMTP domain and its own set of internal mail users.

Each company is a completely separate entity and indeed has nothing to do with one another - the only commonality is that they both buy in their e-mail service from you.

How would you keep each companies Address Books separate from one another, you obviously do not want the employees from one company being able to see the other.

Setting the Scene - Example 2:

Another scenario is that you could have a company that has taken over another - where they adopt a “Parent / Child” operation where the child to all intents and purposes remains an independent trading arm. The Parent company wishes for the child to join their mail system, but again would like to employees in each to remain logically separated from each other - but use the same mail system.

The Solution:

Now the above scenarios are achievable within Exchange 2007 (SP1) by using a process called “Address List Segregation” this is what I would like to discuss in depth  within this article.

First things first, I am not the first blogger to discuss this process - Rui Silva did a very good sequence of articles on how you could begin to setup Hosted Exchange solution which are posted here: http://www.msexchange.org/articles_tutorials/exchange-server-2007/migration-deployment/shared-hosting-exchange-2007-part1.html over on MSExchage.org - this article is pretty good as a starter, and indeed it eludes to the full Microsoft Article on this subject which is located here: http://technet.microsoft.com/en-us/exchange/bb936719.aspx

You might at this stage be asking that “if it has been covered both by others and indeed Microsoft - why I am covering it again?“.

I have decided to cover this again because recently I have come in contact with Exchange 2007 Address List Segregation under two different support scenarios’s both of which have left me thinking that although there is detailed documentation available to accomplish this task it can be a little bit confusing.

Therefore I would like to try to provide an article that not only makes the process a little simpler - but also provides a tool that will help you get to your end objective in simple steps.

Before we begin I would like to establish that setting up Hosting with Exchange 2007 as a independent entity is not necessarily a recommended solution by Microsoft, for many reasons, examples of which are licensing considerations and complexity requirements which may arise if you become a major hosting platform - however it is accepted that Organizations (such as my own) will go out and do it to in order to provide alternatives to perhaps Microsoft’s own hosted services with a understandable to view maintaining control.

Considering the above if you are embarking upon Address List Segregation (as a hosted solution provider) you should understand the “Supported” and “NOT Supported” configurations:

Supported (As Per Microsoft):

Companies that want to totally segregate their address lists can do so by removing access to the Default Global Address List and creating two or more address lists or virtual organizations. You can also set up additional functionality to restrict searching via Outlook Web Access to particular organizational units (OUs) or specific address lists using the msExchQueryBaseDN attribute.

Unsupported (As per Microsoft):

This configuration is one where companies may want to totally segregate their address lists and still have access to the Default Global Address List, or try to split the Global Address List (GAL) into two separate address lists. An example of this configuration would be a company with two groups of 500 users that belong to the Sales and Finance departments. Both groups are in the GAL, however the desire is to have everyone access the GAL except one group. If you are going to segregate your address lists, then they will be segregated. Attempting this configuration will cause problems with the check names functionality which will prevent users from creating Outlook profiles, and can also break the OAB Generation Process. This also allows Outlook users to see all of the Address Lists from within Outlook, which cannot be changed.

You should also be aware of the following recommendations PRIOR to proceeding:

• You MUST be running Exchange 2007 SP1
• Your Organization should be a native Exchange 2007 Organization (not in Interop mode with 2003 or 2000)
• It is recommended that your AD configuration is a Single Forest and Single Domain
• It is recommended that your AD Domain / Forest is operating at Full Windows 2003 Functionality

 

Assumptions:

This article makes the following assumptions:

• You environment is pure Exchange 2007 SP1 with Windows 2003 at least 1 Windows 2003 Domain Controller operating in Native Mode.
• You have one Forest and one Domain
• All roles are installed on the same Exchange server (although the tool that is supplied does support Multiple Role Servers)
• You have take a backup of your Exchange Server(s) and Domain Controller(s) - including Active Directory BEFORE you begin - there are some processes that you will go through that are not reversible easily - where a restore from Backup would be the better course of Action
• The two example organisations used in this article will be called:
  • TopSpinToys
  • TwinTwistToys
• The HOSTING Organization will be called MaverickHosts

 

Requirements:

The following tools and steps should be taken PRIOR to beginning this article

• ADSI Edit is installed on your Exchange 2007 Server, ADSI edit is part of the Windows 2003 support tools - to download the latest version please click here: http://www.microsoft.com/downloads/details.aspx?FamilyID=96a35011-fd83-419d-939b-9a772ea2df90&displaylang=en
• For simplicity you should be logged onto your Exchange Server with an Account with is both a FULL EXCHANGE ADMIN and DOMAIN ADMIN
• This entire article is based around a tool that I have written specifically for the purposes of configuring Hosted Exchange 2007 environments (The Exchange 2007 Address Lists Segregation Tool)- it is available as a free download from here: http://www.telnetport25.com/legacySites/software/ExchangeSegSETUP.exe more information (including installation instructions) are available in the following steps.

 

When you are happy that you comply with the above you can proceed.

About the Address Segregation Tool;

The Address Segregation Tool (download link above) is a Freeware tool that I have developed which is designed to help people whom wish to create a Segregated Environment within Exchange 2007 SP1.

Essentially when it is installed it will scan your Exchange environment and collect relevant data that is then used to create the many Powershell / Exchange Management Shell Script files to achieve the goal of a segregated system.

As mentioned above the entire process of segregating an Exchange 2007 environment is not a recommended one therefore it is important that you know that this tool creates code that changes both Active Directory and indeed your Exchange installation to potentially irreversible levels (unless you have a that backup that we mentioned above) therefore IT IS HIGHLY RECOMMENDED that you test this tool in a LAB prior to use within ANY production system – I cannot accept any responsibility nor make any warranty as to the stability of this tool – it is provided “as it” - aside from all that scariness I think that it is a pretty cool tool

Installing the Address Segregation Tool on your Client Access Server:

Or indeed any Exchange 2007 server in your environment, however, I have found that the code produced by the tool runs best from the CAS - you should also note that the program only installs files to its default installation directory - no files are placed in Windows or System32 - therefore if you wish to delete the program just remove the installation folder.

Before you install the tool on your choosen Exchange server (recommnded CAS should you have a split box installation) you should open the Exchange Management Shell and type in the following CMDLET:

Set-ExecutionPolicy RemoteSigned

This ensures that the configuration phase of the Address Segregation Tool works correctly.

In order to install the tool - download it from the Link and save it to a location appropriate for installs on your Exchange server - when the download has completed double click on the “ExchangeSegSetup.exe” file - see below;

 

When you have double clicked on the file the installation wizard will begin - see below;

Generally speaking unless there is a good reason I would leave the installation defaults as per above - if you change the “Destination Folder” setting please make a note of it as you need to recall it in order to run the program.

The default location is “C:\SegTool” - if you are happy with that click on the “Install” button.

When the installation is complete - using Windows Explorer navigate to the installation folder (if you choose the default this will be C:\SegTool) where you should be presented with a Window which looks like the following;

 

Double click on the “Start.vbs” script - this will begin the process of scanning your environment for the relevant Exchange information required for it to operate - see below;

When the environment scan has completed the main program will execute - this MIGHT take a little time after the above Window has closed - please wait until the main program has started - which should look like the following;

Review the following settings within the above window to ensure that the startup has completed correctly:

• Company Options -> Computer Domain Context
• Exchange Server Options -> CAS Server Name
• Exchange Server Options -> OAB Generation Server Name
• Exchange Server Options -> Domain Controller
• Exchange Server Options -> Exchange Organization

 

When you are happy with the setting above you can close the program (via Application Controls -> Exit).

Configure the dsHeuristics Value using ADSI edit

Modifying the dsHeuristics values changes that way in which “List Object” permissions principle is displayed from an Active Directory perspective - essentially this is modified for performance reasons.

On your Exchange Server open ADSI edit and navigate to the following location:

[ CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=lab,DC=justice,DC=com ] - see below;

Right click on the “Directory Services Entry” and from the Context Menu that appears choose the “Properties” option and then locate the “dsHeuristics” value - see below;

Select “dsHeuristics” and then click on the “EDIT” button - you will be presented with an Edit dialog - enter in 001 as the new value and click on the “OK” button - see below;

When the edit box has closed you can exit ADSI Edit.

I would like at this point to close Part 1 of this article - in Part 2 (hopefully up in the next 48 hours) I plan to cover the following areas:

• Generation of all Powershell / Exchange Management Shell Code using the Address List Segregation Tool
• The Correct sequence to execute the code
• Further changes required to AD

 

In the mean time I recommend that you have a look through the full TechNet article as, although it is a heavy read it contains from fascinating insights to how configurable Exchange is and just for my own curiosity if you are interested in hosting Exchange post a comment.