MSExchange.org Monthly Newsletter of September 2011 Sponsored by: MetalogixWelcome to the MSExchange.org Newsletter by Henrik Walther, Exchange MVP, MCA: Messaging (Exchange Ranger) Apprentice, MCTS Windows Server 2008, MCITP Exchange 2007, MCSE 2003 Messaging/Security. Each month we will bring you interesting and helpful information on Exchange Server. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: henrik@msexchange.org Key eDiscovery Issues to Consider in 2011 written by Osterman Research
1. The Not So Well-Known OWA 2010 SP1 Failback URL OptionWelcome to the September 2011 edition of the MSE Newsletter! This month I want to talk about a not so well-known but quite cool site resilience feature that was introduced with Exchange 2010 SP1. With Exchange 2010 SP1, we have the option of configuring a so called OWA failback URL. The OWA failback URL is intended for customers that are deploying an Exchange 2010 site resilient solution with at least two Internet-facing datacenters and that provide OWA access from the Internet. Those of you who have read my Designing a Site Resilient Exchange 2010 Solution and Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization series may have noticed that, I didn't really talk much about the OWA Failback URL feature. When it comes to the Designing a Site Resilient Exchange 2010 Solution series, the reason is simple. Exchange 2010 SP1 hadn't RTM'd back when I wrote this article. In regards to the Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization, it was simply because I forgot to include it. Since the OWA failback URL depending on the specific scenario can be quite an interesting configuration to perform in the environment, I thought it would make sense to cover it in this month's MSE Newsletter. I'll also make sure both of the above mentioned articles series will be updated with information about why and how the OWA failback should be configured in an Exchange 2010 SP1 site resilient solution that consists of at least two Internet-facing datacenters. Why use the OWA failback URL? So when performing a datacenter switchover from the primary datacenter to the failover datacenter, one of the steps is to update internal and external DNS records that point to the failover datacenter, so that Exchange clients connect to the failover datacenter. For more details see my Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization articles series (more specifically part 12). A time comes where the organization will want to switch Exchange services back to the primary datacenter (see part 13 of the my Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization articles series for details). As most of you probably know, changing a DNS record isn't instantaneous. That is depending on the time to live (TTL) value set for the particular DNS record, it can take several minutes or hours before the update is reflected. To work around this issue, it's recommended to configure Exchange specific DNS records with a TTL of 5 minutes. Duing so will make the DNS record update effective relative quickly depending on factors such as the DNS zone used by external clients, the AD site topology used on the internal network and the DNS client cache on the workstation used by the end-users. When it comes to Outlook Web App (OWA), another factor to include is the Internet browser cache on internal as well as external client machines. What I mean here is that the Internet browser isn't controlled by the DNS client cache on the machine. Instead most Internet browsers have a so called browser cache. For instance, the cache time-out value for Internet Explorer is 30 minutes by default (can be changed with a registry key - for more info click here). This means that even though the DNS cache on a client machine has been updated to point to the correct IP address after a datacenter switchover, the Internet browser may still point to the wrong IP address for up to 30 minutes after the DNS cache has been updated. If this is the case and the end-user tries to access his mailbox using OWA, he will still be pointed to the failover datacenter and will be asked to enter his credentials. After having done so, Exchange will look up his mailbox and find out that it's active in the primary datacenter and tell him to instead use "https://primary.domain.com/owa" to access his mailbox. This is default Exchange 2010 redirect behavior between Internet-facing datacenters. The end-user will do so but because the Internet browser believes the IP address hasn't been updated, the end-user will be brought back to the failover datacenter and once again be asked to enter his credentials. Basically the end-user will have been caught in a loop until the Internet browser cache times out. Configuring an OWA Failback URL To rectify this rather annoying issue, you as an Exchange administrator can configure a failback URL on the OWA virtual directory (see Figure 1).
The FQDN used for the failback URL must be included in the Exchange UC/SAN certificate as it's used by OWA to perform an HTTPS redirect to the other datacenter.
To set a OWA failback URL, use the following command: Set-OwaVirtualDirectory -Identity "EX01\OWA (Default web Site)" -FailbackUrl "https://failback-1.exchangeonline.dk/owa"
Remember you should configure a failback URL for both datacenters. The failback URL for the failover datacenter could for instance be named "https://failback-2.exchangeonline.dk/owa". In addition, bear in mind you must configure DNS records for the failback URLs in both external and internal DNS. Lastly, these records should never be changed during a datacenter switchover since the whole idea is to have a DNS record that hasn't been updated. Ok so if we have configured a failback URL of "https://failback-1.exchangeonline.dk/owa" in the primary datacenter, if the end-user's Internet browser cache hasn't been updated, Exchange will detect the loop and tell the client machine to use OWA failback URL FBA page with a continue link the end-user can click on. When doing so, the OWA failback URL configured on the OWA virtual directory will be used to get the client machine to connect to the correct datacenter.
Until later, Note: 2. Order Henrik Walther's Exchange Server 2007 book
Key eDiscovery Issues to Consider in 2011 written by Osterman Research
3. MSExchange.org Learning Zone Articles of InterestWe have a great group of articles in the Learning Zone that will help you get a handle on your most difficult configuration issues. Here are just a few of the newer and more interesting articles:
4. KB Articles of the MonthBelow you can find the Exchange 2010, 2007, and 2003 related KB articles that were published since the last MSE newsletter. Exchange Server 2010
Exchange Server 2007
Exchange Server 2003
Key eDiscovery Issues to Consider in 2011 written by Osterman Research
5. MSExchange.org News of the Month
6. Ask Henrik Walther a questionQUESTION: If you move a mailbox from a mailbox database hosted in an Exchange 2010 SP1 datacenter to a mailbox database in another datacenter and a different Client Access array is associated with each mailbox database, would you then need to manually update the Outlook profile afterwards? We have a mix of Outlook 2007 and 2010 clients. ANSWER So when moving a mailbox from a mailbox database with one RpcClientAccessServer value to a database with another RpcClientAccessServer value (both in-site and cross-site), the Outlook client will not be automatically updated with the new value unless the CAS server or array specified for the source database is made unavailable to the client. This is true for both Outlook 2007 and Outlook 2010. Actually, I've seen more than once that a profile repair was necessary even though the source CAS server or array was unavailable. This is because the RPC CA service doesn't respond with a ecWrongServer like previous versions of Exchange did. Key eDiscovery Issues to Consider in 2011 written by Osterman Research
TechGenix Sites
|
