We recently added x07 to our domain, doing the standard migrate from x03 over to a new box. Everything went surprisingly smoothly except for a few 'glitches' of which I will write more in different blogs.

What I want to talk about today is an issue that arose due to the requirement that our outgoing email continue to be sent through our x03 system and not our brand, spanking new x07. I won't go into the reasons involved, but suffice to say we had our marching orders.

One of the beauties of all the work MSoft has poured into x07 is how remarkably it plays well with others, or at least with x03. We moved the mailboxes and it did not matter whether incoming mail hit the x03 or the x07, it got delivered correctly. The reason for this is that x07 automatically a routing connector to the old x03 system that routes it to the x07 system (if boxes are not local). This is wonderful, but it also tripped me up.

I had assumed that the solution would simply be to add a Send Connector to the X07 box. Basically anything that was going to be routed via SMTP would be directed to the old x03 box. It was very simply to setup - go into the Exchange 2007 Management Console, go under Organization Configuration and thence into Hub Transport. Select the Send Connectors tab, right-click and select "New Send Connector...".

I won't go into how to create a new SMTP Send Connector, it is fairly straightforward -> give it a good name; specify that this is an "Internal" connector (we are all on the same team after all); add the address space of * and an appropriate cost (I initially selected 20 but just make sure it is lower than what you have for the rule sending to your Edge server); select to route through a smart host and specify the X03 box as your smart host; I chose "None" for my authentication since this was for testing; and voila!

It initially appeared to work and then all of a sudden emails were getting hung up. Sending an email threw it into a void until eventually an NDR would be generated with the following line:

Oops.

The culprit, of course, is that each of the two systems, x03 and x07 have routers that send the email back and forth. They are so happy doing such a thing that they won't pass it out, just back and forth, back and forth, back and forth.

My initial thought was to see if I could modify the Routing Connector that was automatically added by x07 during the install. It had a weight of "1", which meant that it was THE rule. As a result, the rule that goes to the Internet is ignored (having been bumped up) and evertime the x07 system passes an outside email to the x03 system, the x03 system insists on passing it back. However, I know of now simple way to do this. Opening up the router in x03's System Manager results in the following error "Exchange System Manager version 8.0.30535.0 or greater is required to edit this object. See About dialog for version information". So that won't work. The Send Connectors section of the x07 Management Console does not show this. I am sure there is an easy way to do this (probably through powershell) but I did not find one.

So instead, went back to the x03 box and set the internet smtp route to ALSO have a value of "1". For some reason which I can not easily fathom, mail started to flow through the x03 box. What confuses me is how the x03 box, having TWO connectors of value "1" seems to select the correct one. Perhaps it automatically selects the earlier one, or perhaps it is something as odd as the fact that the x03->Internet connector comes alphabetically before the x03->x07 connector.

What ever the solution - I would like to close with that old, old MSoft test answer which sadly disappeared a while ago - "Solution should not works, but appears to".

We recently installed x07 and migrated over from our x03 box to encounter an odd surprise (among many) - a number of the mailboxes were listed as "Linked Mailboxes". A Linked Mailbox is a mailbox which is "linked" to a foreign account (for example in another forest). The problem lay in the fact that we were not in a forest with other domains (any more) and all of the mailboxes had always been local to our domain.

There appeared to be no rhyme nor reason - the accounts did not depend on when they were created, nor what database they were in. It did not matter what OU, what DL, what anything. One person would be taken, another left behind (in the linking sense).

A bit of background before I reveal the answer so you might understand how this could happen. We were around in the old Exchange 5.5 days, using NT 4.0. Ah, the good ole days <g>. When we migrated to w2k and x2k we did it by creating a completely new domain within a forest housed elsewhere. Eventually, for political reasons, we ended up leaving that forest, which involved a whole lotta info I don't want to go into here. We moved them to w03 with x03. Now we were keeping our w03 domain/forest (for now) and simply upgrading x07.

Ah ha, you might say to yourself, clearly the mailboxes from the Exhange 5.5 days. Or the x2k days. Or the x03 days. Or something. Unfortunately for that theory while all of the mailboxes that were still 'linked' were from way back when some of the mailboxes created at that time were not 'linked'. I even delved into the address, since we were still porting around old x.500 ones from way back when. However, again, that was no distinguisher.

So I began to hunt through the AD properties and *AH HA* there it was - all the mailboxes whose msExchRecipientTypeDetails where 2, ie 'linked' (1 is 'user', 2 is 'linked', in 'legacy' it is not set), had an entry for 'msExchMasterAccountSid', but those with msExchRecipientTypeDetails = 1, ie 'user', did not.

Just to verify I ran a bit of the following code (c#) for a quick check, although you could also do a straight ldap outside of it:

String _tab = Char.ConvertFromUtf32(9);
using (StreamWriter _logFile = new StreamWriter(@"c:\results.txt"))
{
    using (DirectorySearcher _searcher = new DirectorySearcher(_ldapRoot))
    {
        _searcher.SearchScope = SearchScope.Subtree;
        _searcher.CacheResults = false;
        _searcher.PropertiesToLoad.Add("msExchRecipientTypeDetails");
        _searcher.PropertiesToLoad.Add("msExchMasterAccountSid");
        _searcher.PropertiesToLoad.Add("displayName");
        _searcher.PropertiesToLoad.Add("whenCreated");
        _searcher.Filter = "(ObjectClass=user)";
        SearchResultCollection _matches = _searcher.FindAll();

        foreach (SearchResult _match in _matches)
        {

            if (_match.Properties["displayName"].Count > 0 &&
                _match.Properties["msExchRecipientTypeDetails"].Count > 0)
            {
                _logFile.Write(_match.Properties["displayName"][0].ToString());
                _logFile.Write(_tab);
                _logFile.Write(_match.Properties["msExchRecipientTypeDetails"][0].ToString());
                _logFile.Write(_tab);
                _logFile.Write(_match.Properties["whenCreated"][0].ToString());
                _logFile.Write(_tab);
                if (_match.Properties["msExchMasterAccountSid"].Count > 0)
                {
                    _logFile.Write(ConvertByteToStringSid((byte[])_match.Properties["msExchMasterAccountSid"][0]));
                }
                _logFile.Write(_tab);
                _logFile.WriteLine();
                _logFile.Flush();
            }
        }
    }
}

The ConvertByteToStringSid was borrowed from this excellent entry -> http://www.codeproject.com/KB/cs/getusersid.aspx

Once I ran that I was able to look at my entries in Excel and verify that that was the case - boxes listed a 'User' did NOT have this entry and boxes listed as 'Linked' DID. Then it was simply a matter of hunting down more information.

It turns out that msExchMasterAccountSid hails as far back as x2k (at least). It is simply used to associate a mailbox with any 'well-known SID or external account'. If this is not used, the objectSid is used. Far more info can be found at Detecting and Correcting msExchMasterAccountSid Issues. This particular article references x03 but is undoubtedly still applicable to x07.

So what is the solution?

More hunting uncovered that a number of people were having success by simply disabling and reconnecting - http://www.fots.nl/index.php/archive/how-to-convert-linked-mailbox-to-user-mailbox/ which I find far more preferable than mucking around in AD. If you have a LOT of mailboxes that you need to de-link, I do not suggest using the Sample Script (http://technet.microsoft.com/en-us/library/bb123636(EXCHG.65).aspx) since that applies to x03 and will probably miss some critical AD schema mods), rather use powershell to disable and reconnect them.

Addendum: if you do disable the mailbox and it does not show up in the "Disconnected Mailbox" you can run the Clean-Mailboxdatabase command. Syntax: Clean-MailboxDatabase "serverName\storageGroup\mailboxDatabase"
Ex: Clean-MailboxDatabase "exMaster\Primary\Executive"

Can't be done.

Any attempt to install will be met with "This operating system in not supported..." Supposedly the next version of ISA will be happy, happy, joy, joy, but not this one.

Could there be a hackaround? Probably. Should you do it? Probably not. Hacks can leave doors open unless you are positive you know where all the moving parts are.

So, buck up and used the old w03. At least for now...