Exchange Queue & A: Exchange Is Always Changing
Whether you’re changing default calendar days, datacenter endpoints or redirecting servers, you always have to be ready to make changes to Exchange.
Henrik Walther
The Monday Blues
Q. We’re a large European organization, and have just migrated from IBM Lotus Domino to Microsoft Exchange 2010. Most of our users use Outlook Web App 2010 as their default mail client. Several users have observed that “Sunday” is the default first day of the week set under Settings | Calendar in the Exchange Control Panel (see Figure 1).
.jpg "The default first day of the week for an Exchange 2010 mailbox")
Figure 1 The default first day of the week for an Exchange 2010 mailbox.
Because Monday is considered the first day of the work week in our region, we want to change this setting for all Exchange 2010 users in the organization. Can we use the Exchange Management Console (EMC) or the Exchange Management Shell (EMS) to do this centrally for all our users? We’ve looked on the property page for mailboxes in the EMC, and even via EMS using the Get-Mailbox cmdlet, but we can’t see any attributes that relate to first weekday of the week. Can you help?
A. Monday is the first day of the work week in most European countries, so I understand your frustration. Fortunately, it’s relatively easy to change this setting for all your users. You can’t do it using the EMC, but you can certainly do it with the Exchange Management Shell (EMS). Most would think you’d need to use the Set-Mailbox cmdlet to change that setting. Actually, you need to use the Set-MailboxCalendarConfiguration cmdlet.
Run the following command, and you’ll see all the calendar-specific settings you can manipulate for a mailbox (see Figure 2):
Get-MailboxCalendarConfiguration –Identity <user> | fl
.jpg "Change the default first weekday via the Exchange Management Shell")
Figure 2 Change the default first weekday via the Exchange Management Shell.
If you want to change the “WeekStartDay” to Monday for all users in the Exchange 2010 organization that had “Contoso” in the company attribute (for example), use the following command:
Get-User –Filter "Company –eq 'Contoso'" | Set-MaiboxCalendarConfiguration –WeekStartDay “Monday”
Return to Center
Q. We’ve been running Exchange 2010 for approximately a year now. We’re a large organization, and so far we’ve had a single datacenter hosting our Exchange 2010 messaging solution. We’ve introduced an extra datacenter so we can achieve mailbox resiliency on the site level. There will be active users connecting to both datacenters, so we’ve created a Client Access server array (CAS array) in the other datacenter.
We already moved the first 100 users to the new datacenter to verify things will work as expected. We’re not quite there. We see issues with having the Outlook MAPI client endpoint changed from “outlook-1.contoso.com” (CAS array object FQDN in first datacenter) to “outlook-2.contoso.com” (new CAS array object FQDN in the new datacenter).
The Outlook MAPI clients simply continue to use the old endpoint, which means Outlook clients create RPC sessions to the CAS array in the first datacenter and the CAS array then talks RPC with the mailbox servers in the new datacenter. Any idea whether this is intentional? If not, do you have any idea how we can fix it?
A. Some Exchange Queue & A readers will remember I’ve touched this subject before. When you move mailboxes from a datacenter with a CAS array to another datacenter with another CAS array, you don’t want to make the old endpoint unresolvable/unavailable. This will impact all the users that are active in the first datacenter.
The workaround here—although it isn’t pretty—is to update the Outlook MAPI profile for the users who had their mailbox moved to the new datacenter (using the “Repair Profile” option within Outlook. for instance).
Some of you may wonder why Exchange 2010 behaves this way. It worked just fine with previous versions of Exchange. Outlook MAPI clients now connect to the RPC Client Access service (RPC CA service) on the Client Access server role, not directly to the Store on the Mailbox server role.
In Exchange 2007 and earlier, when you moved a mailbox from one mailbox database to another, it would result in the source mailbox database sending an “ecWrongserver” to the Outlook client. That forced it to locate the mailbox in the database in which the mailbox is now stored.
The RPC CA service can’t respond with an “ecWrongServer” when a *over (database switch or failover) occurs between two datacenters (and the RPC CA service is available). Similarly, it can’t respond if you move a mailbox from a mailbox database in one datacenter to a mailbox database in another, where the RpcClientAccessServer attribute of the target database contains another fully qualifed domain name (FQDN).
During Exchange 2010 SP1 development, there were plans to introduce a so-called “Allow Cross Site RPC Client Access” option you would configure for a Database Availability Group (DAG). This option was deemed excessively complex, so it was cut right before Exchange 2010 SP1 shipped.
Can We Coexist?
Q. We’ve deployed Exchange 2010 into our Exchange 2003 organization. We’re currently planning to point the namespace we use to access a mailbox in the Exchange 2003 to the Exchange 2010 CAS array. We’ve already added a legacy FQDN (legacy.contoso.com) to the SAN/UC certificate, and we’ve configured the legacy URL on the OWA 2010 virtual directory.
We’ve enable SSL offloading on the load balancer solution that distributes client traffic across the CAS. We’ve also followed the steps in this TechNet Wiki article to configure SSL offloading on the Exchange 2010 CA servers. SSL offloading isn’t enabled on the Exchange 2003 front-end (FE) servers.
We’re a little unsure of whether SSL offloading will work in a coexistence scenario, where clients connect to the Exchange 2010 CA servers and are redirected to the Exchange 2003 FE servers. Do you know if this scenario will work?
A. Yes, OWA 2003 users access their mailboxes by authenticating against Exchange 2010 CA servers that redirect the session to Exchange 2003 FE servers. This will work even with SSL enabled on the load balancer solution and the Exchange 2010 CA servers.
Some of you might have expected another answer. Exchange 2003 URL configured on the OWA 2010 virtual directory must be in the form of “https://legacy.contoso.com/exchange” and not “https://legacy.contoso.com/exchange.” Otherwise, you’ll get an Event ID 91 in the Application log (see Figure 3).
.jpg "Error in Application log when legacy URL is configured with HTTP, instead of HTTPS.")
Figure 3 Error in Application log when legacy URL is configured with HTTP, instead of HTTPS.
The legacy URL must start with HTTPS and not HTTP. Because the Exchange 2010 CA servers simply redirect the client session to an Exchange 2003 FE server, it will work fine when using HTTPS for the OWA legacy URL.
Copy Queue
Q. When I work with miscellaneous Exchange 2010 DAG scenarios (usually in lab environments), I sometimes see an extremely high Copy Queue Length (see Figure 4).
.jpg "An extremely high Copy Queue is always a possibility.")
Figure 4 An extremely high Copy Queue is always a possibility.
The first time I noticed it I thought, “What the?” Upon further investigation, I can see that it’s the exact same number every time it happens. Do you know if this is a bug or something?
A. The number you’re seeing is the highest value you can set for Copy Queue Length. Log copying isn’t happening and the cluster database updates aren’t happening. A loss of network connectivity between DAG nodes usually causes something like this.
In a slow lab environment, this can occur on occasion. You shouldn’t see it in a production environment, though. If you do, I recommend trying to find the root cause for loosing network connectivity between the DAG nodes.
.jpg "Henrik Walther")
Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 16 years of experience in the IT business. He works as a Technology Architect for a Microsoft Gold Certified Partner in Denmark, and as a technical writer for Biblioso Corp. (a U.S.-based company that specializes in managed documentation and localization services). He’s also a contracted vendor working on various product teams (including the Exchange and Lync teams) at Microsoft.