Exchange Queue & A: Connect and Conquer

Connection concerns, managing a fleet of mobile devices, SAN list limits and Exchange grouping are on the minds of this month’s readers.

Henrik Walther

Consistent Connections

Q. Our company has transitioned to a site-resilient Exchange 2010 infrastructure consisting of two Exchange 2010 multi-role servers: one in the primary datacenter (Active Directory site 1) and one in the failover datacenter (Active Directory site 2). The IT group has installed the Exchange 2010 management tools on their workstations, which are physically located in a third Active Directory site (Active Directory site 3).

We’ve noticed that when launching the Exchange Management Shell (EMS), the respective workstations connect randomly to the Exchange 2010 servers in Active Directory site 1 and Active Directory site 2. We would like these workstations to always establish a connection to the remote Windows PowerShell virtual directory on the Exchange 2010 server located in Active Directory site 1. Do you know if we can do this?

A. There’s a valid reason for the built-in logic you’re seeing. This is designed to achieve Exchange management redundancy and distribute management sessions among multiple Exchange 2010 servers so that a single server doesn’t take the entire load.

To answer your question, though: Yes, there is a way to hardcode the specific Exchange 2010 server to which the workstations should connect. Log on to the workstation and change the EMS shortcut. Do this by opening properties for the EMS shortcut (see Figure 1).

Figure 1 Opening the property page for the Exchange Management Shell shortcut.

Change the Target from this:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command ". 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"

To this:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command ". 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServerEX01"

The server to which you want the desktops to connect is named EX01 in this example. Click Apply, then OK and launch the EMS. The session will now establish a connection on EX01 (see Figure 2).

Figure 2 The Exchange Management Shell connects to the Exchange Server specified in the shortcut.

One World, One DAG

Q. We’re running Exchange 2010 throughout our organization. We have a datacenter in Europe and one in the United States. We have a single Database Availability Group (DAG) stretched across the two datacenters. There are four DAG members in Europe and four DAG members in the United States.

Each datacenter has a dedicated Active Directory site, so the DAG members in Europe and the U.S. datacenters are on different subnets. Each DAG member has two NICs—one MAPI and one Replication network. We’ve created static routes and collapsed the DAG networks based on instructions in previous Exchange Queue & A columns.

Things are working as expected, with one important exception. When we’re moving the cluster core group from the current Primary Active Manager owner to another DAG member, the group is moved just fine. However, the DAG member from which the PAM is moved loses the default gateway setting on the MAPI NIC. This means that afterward, it can’t communicate with any of the servers in the other datacenter. Have you heard of this issue and do you have a workaround or a fix?

A. Yes, I’ve seen this issue myself. And even though this issue is cluster/DAG related, the fix is surprisingly simple. You need to apply the hotfix described in this Microsoft Knowledge Base article.

Manage Mobile Mayhem

Q. My customer has just transitioned from Exchange 2003 to Exchange 2010. Most of their users rely heavily on their smartphones, which synchronize with Exchange via Exchange ActiveSync (EAS). When they were on Exchange 2003, they used the “Microsoft Exchange Server ActiveSync Web Administration Tool” to remote wipe lost or stolen mobile devices. They know they can initiate remote wipes and more using either the Exchange Management Console or Shell, but they would prefer to use a Web-based tool like the Microsoft Exchange Server ActiveSync Web Administration Tool. Do you know if a similar tool exists for Exchange 2010?

A: One of the really nice introductions made with Exchange 2010 was the Exchange Control Panel (ECP). This is a Web module that essentially replaces the old Outlook Web Access (OWA) options page (see Figure 3). You can manage all kinds of mailbox-related settings by logging into OWA, selecting “Options” and then “See All Options.”

Figure 3 Accessing Exchange Control Panel via Outlook Web App.

One of the new options in the ECP is under “Phone,” then “Manage Phones.” Here you’ll see a list of all device partnerships (all devices synchronized with respective mailboxes). You can also delete device partnerships and initiate a remote wipe against a mobile phone (see Figure 4). Pretty neat stuff, right?

Figure 4 Managing mobile devices via the Exchange Control Panel.

It gets better. The ECP was developed with not only users in mind—Exchange administrators can also use it to configure miscellaneous Exchange organization settings and to manage user mailboxes. One of your options as administrator is to delete device partnerships or initiate remote wipes against a mobile phone on behalf of the user (see Figure 5).

Figure 5 Managing mobile phones on behalf of your business users.

So the ECP gives you plenty of options when it comes to managing mobile phones via a Web-based module.

Outer Limits

Q. We have a customer that plans to have more than 60 fully qualified domain names (FQDNs) on the SAN list of a SAN certificate. Do you know if this is even supported? They use Exchange 2010 and Forefront Threat Management Gateway (TMG) 2010. They need that many FQDNs because they’re configuring rich coexistence between their Exchange 2010 on-premises solution and Office 365.

A. Neither Exchange 2010 nor TMG 2010 sets any hard limits. The limit is set by the authority issuing the SAN certificate, and of course by the size limitation of the certificate itself. Although not a hard limit, most certificate authorities recommend fewer than 40 SAN list entries. Keeping the SAN list at less than 40 entries is a good idea, because the list makes the size of the certificate larger for each name added. In practice, therefore, it’s better to keep it to 40 as a maximum.

Some proxy devices only support the first 10 SANs in a certificate. For most, the primary concern is keeping the initial congestion window from growing too large. The SSL handshake “Server Hello” message is the first thing the SSL socket sends back to the client. If that’s too big, the initial congestion window (TCP stuff) is set high for the socket connection and will cause sub-optimal socket IO.

Try to keep the number of entries at fewer than 40. Larger lists can lead to poor performance. A certificate with 40 SAN list entries would also be quite expensive and an administrative nightmare.

Authentically Virtual

Q. We’re running Exchange 2010. We publish OWA, EAS and Outlook Anywhere (OA) to the Internet with Forefront TMG 2010, which also pre-authenticates Exchange clients connecting from the Internet. We want to provide forms-based authentication to both external and internal OWA/ECP users, so we’ve created an additional Web site in IIS. We created a new /OWA and /ECP virtual directory beneath this site. We configured this based on the recommendations in this blog post on the Microsoft Exchange Team blog and it works just fine.

We’d like to add an /RPC (OA) virtual directory to the second Web site, but we haven’t really been able to find any documentation on how to do that. Can you enlighten us?

A. Windows Server 2008 support specifies different Web sites for the RPC Proxy component, but only running in a single site, not multiple Web sites. Exchange 2010 does not support OA in Web sites other than the Default Web Site on a Client Access Server. Also, Windows and Exchange Server do not support RPC Proxy or OA running on multiple Web sites on the same server. This has been the case since Windows Server 2003 and Exchange 2003, where RPC over HTTP was introduced.

Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 15 years experience in the IT business. He works as a technology architect for Timengo Consulting (a Microsoft Gold Certified Partner in Denmark) and as a technical writer for Biblioso Corp. (a U.S.-based company specializing in managed documentation and localization services).

Related Content

• Exchange Queue & A : Configuration Conundrums
• Exchange Queue & A: Migrations and Transitions
• Exchange Queue & A: Gone to the DAGs