Exchange Queue & A
Outlook Anywhere and IPv6, the Remote Connectivity Analyzer, and More
Henrik Walther
Q We have just finished deploying Exchange 2007 on Windows Server 2008-based servers in our organization and things are working very well, with one exception. Even though we have configured Outlook Anywhere (formerly known as RPC over HTTP) following the guidance in the Exchange 2007 documentation on Microsoft TechNet, we can't connect to the Exchange 2007 Client Access servers from an Outlook 2007 client on the Internet, no matter what we try. We have made sure the SAN certificate is trusted by the client and that TCP port 443 is open on the firewall connected to the Client Access servers. Have you ever seen this type of issue?
A As a matter of fact, I have. You mention that Exchange 2007 was installed on Windows Server 2008-based servers. When a Client Access server has been installed on a Windows Server 2008 server, it's important to keep in mind that Outlook Anywhere won't work properly if IPv6 is enabled on the server. Since IPv6 is enabled by default when Exchange 2007 SP1 is installed on Windows Server 2008, you must make sure to disable it. I've seen several cases where this resolved the issue.
For more information about why Outlook Anywhere and IPv6 on Windows Server 2008 form a bad cocktail, and how you disable IPv6 properly on Windows 2008 servers without breaking Exchange 2007, I recommend you check out the blog post from the Exchange team at Microsoft found at
msexchangeteam.com/archive/2008/06/20/449053.aspx. This issue should be fixed with Exchange 2007 SP1 Rollup 4.
Q I am currently implementing Outlook Anywhere and Exchange ActiveSync in our Exchange 2007-based messaging environment, and I was wondering if it is somehow possible to test whether Outlook Anywhere will work as expected on the other side of our perimeter network. In addition, I want to make sure the Autodiscover service has been properly configured in our environment. Can you give me any pointers?
A Yes, it is possible to test whether Outlook Anywhere is working correctly. Two Microsoft employees (Shawn McGrath from the Exchange Product Group and Brad Hughes from Product Support Services) have created a Web-based tool called the Exchange Server Remote Connectivity Analyzer (ExRCA). The tool (in Figure 1) should still be considered a prototype, but I have not experienced any bugs or odd behavior whatsoever. The tool can perform Outlook 2007 Autodiscover and RPC/HTTP connectivity tests; it can also test whether Exchange ActiveSync and inbound SMTP mail flow works as expected. Although ExRCA currently isn't supported by Microsoft, I highly recommend it for any remote connectivity tests against Exchange 2007.
.gif)
Figure 1 Exchange Server Remote Connectivity Analyzer start page (Click the image for a larger view)
Q Our organization, which uses Exchange Server 2007, is in the planning stages of deploying standby continuous replication (SCR). We want to have a second set of data for each of the mailbox databases created on our non-clustered Exchange 2007 SP1 Mailbox servers in another site. We have been reading a lot about SCR in the Exchange 2007 documentation on Microsoft TechNet but still have a question we haven't managed to get answered there: if we activate an SCR target, will this have the same effect as a Move-Mailbox with the –ConfigurationOnly parameter specified for all user mailboxes in a particular mailbox database? In other words, only change the Exchange server location in the Active Directory.
A Since you're using non-clustered Mailbox servers (otherwise known as a standalone Mailbox server) as source SCR servers, your understanding is correct. Because you will be activating the SCR copy on a different server, database portability will be used. This means that the Exchange server location in Active Directory for the user mailboxes in the respective mailbox database will change.
If source SCR servers in your Exchange 2007 environment were either clustered continuous replication (CCR)- or single copy cluster (SCC)-based, and you used a passive node in a failover cluster as the SCR target, you would activate the SCR target with the same name, and the Exchange Server location in Active Directory would not change.
Q We have just finalized deployment of Exchange Server 2007 in our enterprise environment and were wondering if it's supported to move the six Exchange 2007 security groups, which were created by Exchange 2007 setup when the forest and domains are prepared for installation of Exchange 2007, to another organizational unit instead of the Microsoft Exchange Security Groups OU, which is created in the root domain.
A Unlike Exchange 2000/2003, which didn't allow you to move the Exchange groups to another OU within the forest, Exchange 2007 actually supports doing this. You can see that the six Exchange 2007 security groups (see Figure 2) created when the forest is prepared for Exchange 2007 are stamped with two unique properties; the first is a well-known GUID and the second is a distinguished name that can change.
.gif)
Figure 2 Exchange Server 2007 security groups (Click the image for a larger view)
These two properties, and the fact that they are added to the respective forest's OtherWellKnownObjects attribute when setup is run, ensure that Exchange will be able to find the security groups anywhere in the forest. So you can go ahead and move the groups anywhere you want to, even to another domain in the forest! Additional details can be found in Ross Smith's excellent Exchange 2007 Permissions FAQ (
technet.microsoft.com/bb310792) included within the Exchange 2007 documentation on Microsoft TechNet.
Q Because of some restructuring in our Exchange 2007-based messaging environment, we want to move the file share witness for each of our Exchange 2007 CCR Mailbox servers to another Hub Transport server. Can you provide some guidance on how this is accomplished in a supported fashion?
A Moving the file share witness from one Exchange 2007 Hub Transport server to another is very straightforward. You simply use the steps that you followed when you initially configured the file share witness for your clustered Mailbox servers. The only difference is the path that you specify to the server. The appropriate steps can be found in the How to Configure the File Share Witness section in the Exchange 2007 documentation on Microsoft TechNet (see
technet.microsoft.com/bb124922).
By the way, you should know that if you made use of a CNAME record to point to your Hub Transport server when you configured the file share witness, the task would then simply be a matter of you changing the fully qualified domain name (FQDN) of the target host to which the alias in the respective CNAME record points (see Figure 3).
.gif)
Figure 3 CNAME record pointing to a target host for a file share witness (Click the image for a larger view)
Bear in mind, though, that if you have cluster nodes located in different sites, site resilience guidance from the Exchange Product group has changed (see
msexchangeteam.com/archive/2008/04/03/448615.aspx). Basically, the Exchange product group no longer recommends that you use CNAME records in Exchange 2007 Geo-Cluster environments.
Q We're planning to improve the security settings for the Exchange 2007 messaging servers in our organization. Part of our security optimization plan is to encrypt the volumes on which the Exchange databases are located. We wondered whether it is recommended or even supported to store Exchange database files on a volume that has been encrypted using Encrypting File System (EFS) encryption.
A The answer is a clear no. Placing Exchange 2007 databases on an EFS-based encrypted volume is not supported by Microsoft. In fact, it is unsupported for .edb, .log, .stm (Exchange 2000/2003), .dat, .eml, and .chk files. The primary reason is that this type of encryption results in additional overhead, which significantly affects performance.
To help secure your Exchange 2007 data files further, you should prevent unauthorized access to the Exchange computer and use the S/MIME message format to encrypt message data. Also, if you install Exchange 2007 on Windows Server 2008, consider using BitLocker to protect the volumes.
Q I've just installed Exchange 2007 SP1 on a Windows Server 2008 server that is also a domain controller. Since I don't use IPv6 in this environment, I disabled it under Network Connections after Exchange 2007 SP1 had been installed, and then I rebooted the server. When it came back online, the Exchange 2007 services no longer started. Error 214, logged in the Application log, contains the following information:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1712). Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC).
A I've seen several reports on this behavior. Although it's not good practice to install any of the Exchange 2007 server roles on a Windows Server 2008 server that's also acting as a domain controller, having one or more Exchange 2007 server roles running on a domain controller with IPv6 disabled should work, especially since this is a common scenario in test labs and elsewhere. The solution as of now is to re-enable IPv6 on the server. Rumor has it that Exchange 2007 SP1 Rollup 4 will fix this issue.
Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 14 years of experience in the IT business. He works as a Technology Architect for Interprise Consulting (a Microsoft infrastructure Gold partner based in Denmark) and as a Technical Writer for Biblioso Corporation (a US-based company that specializes in managed documentation and localization services).