Exchange 2007 – Service Pack 1 – Service Pack 3 Address List Segregation Tool Version 2.2.1 .NET – Part 2 (Adding in a second environment plus additional configuration)…
One of the first things that you might have noticed is that there is a change to the version number of the ALST as I begin this part (Part 1 used version 2.2.0 of the tool whereas this version is based around 2.2.1) – and you might be thinking – why!!!!?
Well, just as I published the last article I was doing some further testing in my lab and I discovered that although I could connect to the Segregated Environments via OWA with no issues, I could not get users to connect via the full Outlook client – each time that I tried to configure a MAPI profile I would get one of the following error messages when attempting to resolve a Segregated user against their respective GAL:
- Bookmark not found
- Cannot resolve the name
I checked though the original Whitepaper several times cross checking the code which my application uses against the instructions and indeed the scripts as supplied within – each time I found that they were identical (I even asked my wife to double check).
In the end (and indeed what has caused the delay to this update) I asked if the original author of the white paper could help (at Microsoft) – unfortunately this did not yield a solution to the issue (but did give me a firm if somewhat odd support stance for Segregation of Exchange 2007 – more on this later).
So there I was – stuck in the wild without support (not that Microsoft really should or need to give me support)
Anyhow, to cut a very long story short; today I decided that I would sit down and pretty much go through my code line by line comparing it to the whitepaper and if that did not help I was going to go through every single permission and ADSI value to see if I could spot a discrepancy of any kind.
The good news is that with a clear head and indeed this new determination – I found the solution very quickly – in essence all of the code that the tool produces was indeed true to the whitepaper – but there was something missing from the whitepaper which allowed for Outlook clients to correctly resolve the name to an address list.
If you have read the whitepaper (which I recommend) you will know that the default GAL is in effect removed from the organisation (by way of permissions being denied on it), however Outlook will attempt to resolve a user against the GAL which is defined in the Active Directory attribute “showInAddressBook” for a given user.
There is no provision in the whitepaper to change the default value of showInAddressBook (which is unsurprisingly the default global address list when a user is created) – once this value is change to the “DistinguishedName” of the Child Companies GAL Outlook clients can login.
Once I had worked this out, I needed to modify the code in the ALST to provide not just for OWA, but also for Outlook (in essence I had to change the way in which the Segregate a Single User and Multiple users worked within the application).
So, I have updated the original download of the application with the new version (2.2.1) – and indeed if you have already downloaded and installed the tool – I have released a patch file which is located here:
In order to install the patch file – copy it to the installation root directory of the ALST tool on the server / workstation where you originally installed the tool and overwrite the version which is already present.
I already used the tool and provisioned users – what do I do?
The good news is that this is pretty straight forward – all you need to do is install the patch as described above on then re-segregate your existing users (via the Segregate Multiple Users or Single user function (remember that you will need to load the configuration for each company BEFORE you re-segregate.
It does not matter that they have already been processed by a previous version of the tool – the ALAST will apply the missing attributes to enable Outlook access.
Part 2 – Now begins
In the last part of the ALST 2.2.0 configuration tool I introduced the tool, its requirements, installation and how to Segregate your Exchange environment and add in a first hosted company.
In this part I would like to cover the following elements of the tool;
- How to add a second company to the environment
- How to Segregate individual users
- Custom Actions included within the tool
- Working with the full Outlook client
All of the above, bar one (Working with the full Outlook client) will be covered within a downloadable video (or you can view it online from the site) the other elements I will be covering below.
Using the Tool – Segregation of the Second Company
The following video can be viewed downloaded for offline viewing.
There are two levels of Outlook configuration which can be applied – one which matched internal access to Segregated environments and the other which is more akin to Hosted configurations and makes use of Outlook Anywhere (the latter will be covered in the Advanced Section).
Although in the main the process of pointing Outlook at the correct environment is not that different than that of setting up a normal MAPI profile there are some subtle differences that should be noted.
The instructions below are based around Outlook 2003 – but should not be all that different for versions of Outlook higher.
Open the MAPI control panel – click on the “Add” button – see below
Provide a name for your profile – then click “OK” – see below
Choose the Add a new e-mail account – then click on the “Next” button – see below
Choose “Microsoft Exchange Server” from the options – and then click on the “Next” button – see below
Enter in the name of the Exchange Server relevant to your Segregated configuration – and then for your User Name (which in actual fact is the alias that is allocated from the “Companies e-Mail Address Policy in the ALST” – this is relevant as it should be the same as the UPN for the user – see common problems later on).
Click on the “Check Name” button – see below
If everything is going to plan; Outlook should then resolve both the server and the mailbox, if so click on the “Next” button – see below
Click on the “Finish” button to complete the Wizard – see below
Open Outlook and choose the profile that you have just configured – see below
In order to logon properly you will need to use the UPN of the user (which as mentioned above should match the alias that you provided to configure the MAPI profile – see below
Advanced Configuration – Outlook Anywhere
In the main, if you are Segregating as part of a hosting scenario you will probably be making use of Outlook Anywhere to connect the full Outlook client to your Exchange Server. Whereas it is beyond the scope of this article to take you through the configuration of OA on the Exchange Server (if you are really interested I did a two part set for .:ENOW’s ESE which are located here and here).
The configuration of OA is only a slight variation on the above – the main change is that when you get to Step 6 (above) – see below
You should click on the “More Settings” button which will display the following dialog
Here you should choose the “Connection” tab – and then tick the “Connect to my Exchange Mailbox using HTTP” – then click on the “Exchange Proxy Settings” button which will open up the following dialog
Here you should complete the OA configuration for your Exchange Server server, then once done click on “OK”, and “OK” again to complete the profile wizard.
You should ensure that the Primary SMTP Mail address for a user is the same as the UPN (User Principle Name).
So as an example –the following is the UPN in Active Directory Users and Computers:
Therefore the Primary SMTP Address for the User should be when viewed in the Exchange Management Console:
The configuration of the Primary SMTP address is controlled in the ALST via the Company Address Policy – e.g. %g.%[email protected]
Clarification on Microsoft’s Segregation Support Stance
As alluded to at the beginning of this article, during my research a member of Microsoft’s support division explained to me;
We do not support setting up any hosted environment via script or tool
Which seemed a little odd to me, as indeed the Whitepaper describes supported scenarios which are based upon the scripts within the white paper – upon further pressing the actual point being made was that Microsoft will NOT support any segregated environment that is setup using a tool or script that has not been expressly developed by them. In a way that is fair enough and I can see the point to it – but as my tool makes use of the exact same scripts that they do support perhaps it is a little draconian.
However I cannot ignore the above – therefore I have to state that you should not use my tool in production, unless you are 100% sure that it has worked in test. Even then you should compare the output scripts of the tool against those that are provided in the whitepaper – this way, if you need to make that call to Microsoft you can say hand on heart that you followed the steps in the whitepaper.
Anyhow that concludes my coverage on the ALST and Segregating Exchange 2007 – I hope that you will find this useful