HMC: Autodiscover works but Exchange 2007 users cannot download the OAB

Hi,

A few months back I was hit with an OAB issue, I actually raised a case to PSS as it was so odd but ended up resolving it myself before they called.

I was tasked with performing a 'staged migration' from HMC3.5 and Exchange 2003 to HMC4.5 and Exchange 2007 for a Customer. This was theoretically possible because Cobweb have both solutions deployed in the same Forest (cool huh).

Normally we would perform the HMC upgrade and then move mailboxes to Exchange 2007 with a period of confirmed outage to the customer, moving them in a big bang migration approach. But this customer was so large and needed continous messaging that this was not possible.

So I devised the following.

1. Upgrade the mailboxes for their users during the day to Exchange 2007
2. Keep them under HMC3.5 (this went through major testing in our Labs) and locking them out from Control Panel Management
3. Once all mailboxes we upgraded, confirm all was OK and then perform a 30 second 'flip' moving all their HMC data to HMC4.5 and the corresponding panel.


This needed pin point accuracy as not to cause them any outages. It was also crucial the permission group changes from HMC3.5 to 4.5 was performed flawlessly as access to Public Folders, the GAL, and other objects was controlled this way.

When in the lab I noticed an issue IF the customer was an HMC3.5 and Exchange 2003 customer prior to HMC4.5 and Exchange 2007 going into the Forest and Exchange Org.

Any customer I upgraded in testing that were created after the HMC4.5 installation worked fine. It just affected pre-4.5 customers. It caused an issue with the Offline Address Book.

Here is what Autodiscover gave back when looking at an upgraded mailbox

















It’s missing the OAB URL.

The OAB was there and accessible for all Exchange 2003 users yet to have their mailboxes moved, and version4 was available. If I checked connection status I could see the Public Folder referral happen before I download the OAB from the Exchange 2003 server. So I knew this was working. It just didn't work once for users once their mailbox was moved to Exchange 2007.

Exchange 2007 CAS and Mailbox can perform a referral to an OAB on an Exchange 2003 server. So I knew this wasn't an incompatibility problem. This was also a single AD site, so there was no crazy Exchange 2007 to 2003 referrals happening across AD sites.

So what was the issue?

It turns out that the 'Exchange Domain Servers' Security Group was not granted permissions on the legacy OAB. This was due to the OAB existing prior to HMC4.5 and Exchange 2007 going into the Forest and Exchange Org. Any customer created after this had no issues.

Adding the correct permissions to allow this Security Group access fixed the issue. Adding the permissions via ADSIEdit, "Configuration Container, Services, Microsoft Exchange, Address List Containers, Offline Address Book, select customer OAB"

Now when I go back to Outlook I can see OAB availability and download it successfully.

As a side note both the GAL and AL also had this permission discrepancy. But it did not seem to create any ill side effects. As a best practice measure I also set the correct permisssions on these objects also.

Oliver Moazzezi MVP - Exchange Server

duplicate SID from OS templates during Active Directory creation

I built a new test Forest in my Test Lab, deploying from a template Windows 2003 and 2008 images.

The Forest consisted of a Root and 2 childs, an example:

contoso.com
tailspintoys.contoso.com
forthcoffee.contoso.com

I had read an article on the myth of changing the SID of a machine when deploying or cloning from a template. The article is here

However when I came to build my first child domain, I had major issues during the DCPROMO process. The Active Directory installation wizard informed me that the specified domain already existed.


















Now this was news to me :-) and a quick double take confirmed it indeed did not exist, and then I realised both the root Domain Controller that was already running and this new Child DC were spun from the same template.

I remembered that when you DCPROMO a server the SID for the domain is taken from the first server to be promoted - and there was my issue.

So ensure that you use Newsid (retired now and not supported for Windows 2008 R2 or Windows 7) or ensure you properly sysprep any of your templates in your test or production virtualized environments.

Oliver Moazzezi

MVP - Exchange Server

Disable EHLO on an Exchange Send Connector

I recently had an incident where a client running Exchange 2007 could not send mail to his chosen smarthost. In this instance the customer did not want to use DNS to route outbound internet mail but rather through their ISP - using the free and not premium service.

Exchange could not send email through the smarthost, however using that smarthost in an email client allowed mail to pass without any authentication.

It turned out that the smarthost didn't support pipelining (see here) so the Send Connector was modified to send out via SMTP instead of EMSTP.

This simply means Exchange sent a HELO rather than an EHLO.

To modify a Send Connector to send via HELO perform these steps in Powershell.

Set-SendConnector -Identity [Send Connector Here] -ForceHELO $true

More information here

Oliver Moazzezi

MVP - Exchange Server