Exchange 2010 DAG Network Configuration

I have seen many DAG deployments with mis-configuration for DAG networks, especially when the DAG is accross multiple sites. I am posting an example configuration here to show how the DAG networks should be set up.

The example makes the following assumption:

• 2 AD Sites: Site1 & Site2
• 4-node DAG with each Site having two DAG nodes

IP address Configuration  

Server	Network\IP
MBX1	MAPI: 192.168.10.11 Replication: 10.1.10.11
MBX2	MAPI: 192.168.10.12 Replication: 10.1.10.12
MBX3	MAPI: 192.168.20.13 Replication: 10.1.20.13
MBX4	MAPI: 192.168.20.14 Replication: 10.1.20.14

By default, the DAG network will be set up like this: 

DAG Network Name	Subnets	Interfaces
DAGNetwork01	192.168.10.0/24	192.168.10.11 192.168.10.12
DAGNetwork02	10.1.10.0/24	10.1.10.11 10.1.10.12
DAGNetwork03	192.168.20.0/24	192.168.20.13 192.168.20.14
DAGNetwork04	10.1.20.0/24	10.1.20.13 10.1.20.14

The problem of this configuration is the cross-site log repliation will use the MAPI NIC on the servers instead of using the dedicated Replicaiton NIC because there is no DAG network that has been defined between 10.1.10.0/24 and 10.1.20.0/24.

	DAGNetwork01	DAGNetwork02	DAGNetwork03	DAGNetwork04
DAGNetwork01	MAPI	-	MAPI\Replication	-
DAGNetwork02	-	Replication	-	-
DAGNetwork03	MAPI\Replication	-	MAPI	-
DAGNetwork04	-	-	-	Replication

The solution is to collapse default DAG networks as below:

DAG Network Name	Subnets	Interfaces	Replication Enabled
DAGNetwork01	192.168.10.0/24 192.168.20.0/24	192.168.10.11 192.168.10.12 192.168.20.13 192.168.20.14	No
DAGNetwork02	10.1.10.0/24 10.1.20.0/24	10.1.10.11 10.1.10.12 10.1.20.13 10.1.20.14	Yes

Make sure log replication is disabled on DAGNetwork01 so that log shipping will always use the replicatio NICs first, but will still fail over to the MAPI NICs. If you don't disable replication on DAGNetwork01, DAGNetwork01 will have the same weight as DAGNetwork02 when the servers choose to ship logs.

Hardware Load Balancing a Relay Connector

This is not a re-post of Pmeijden's blog, but you should read his blog first in order to understand what I am trying to show here.

One of the solutions mentioned in his article is to

1. Add HLB IP to the Anonymous Relay connector on each HT server.
2. Create IP Allow rules with a default Block rule on the HLB to control who can relay

This has been proved to work. But if email from outside also goes through the HLB, inbound email will hit the Anonymous relay connector instead of Default Receive Connector since the Anonymous Relay Connector has a specific IP defined. This would still work if you have any hosted service (Postini, FOPE, etc) or another OnPrem email gateway. All you have to do is to add Postini\FOPE\Gateway IP to the allow rule. So your server still cannot be used for open relay.

But what if you don’t have either of those or you just don’t want any other traffic to hit the Anonymous Relay connector (for logging\troubleshooting purpose). So the solution is to do the following:

• Add additional NIC to each HT server with additonal IP

Note: do not add the additional IP to the existing NIC as this will also register the additonal IP on the DNS server. If you use an additional NIC, you can then disable DNS registration on the NIC. Also, you do not need to define Default Gateway for the additoinal NIC since it only needs to talk to the load balancer which is on the same subnet.

• Change the Default Receive Connector to listen on the original IP\NIC and the Anonymous Receive Connector to listen on the additional IP\NIC.
• Create a 2^nd VIP on the HLB to balance between the additional IPs over TCP 25
• Add HLB IP to the Anonymous Relay Connector.
• On the HLB, create IP allow\block rule to only allow specific IPs to hit the 2^nd VIP.    

Now inbound mail will hit the Default Receive Connector while relay mail will hit the Anonymous Relay Connector.

LyncSocial is out

LyncSocial (Beta) is the first FREE application for Microsoft Lync that allows users to update your Lync, Twitter and LinkedIn statuses simultaneously. LyncSocial is a simple way to enhance your social media presence without taking the extra time to login and post to different platforms. Simply include #TW for Twitter or #LI for LinkedIn in your Lync status to automatically update these platforms.
LyncSocial can be downloaded here.

Exchange 2010 Certificate Planning

 I feel it’s necessary to make some standard clarification here to facilitate any future E2010 deployment.

1.       Wildcard certificate not recommended due to Lync. Always use UCC cert that support SAN name. But if you do use wildcard, remember to set EXPR Provider to msstd:*.contoso.com.

2.       You do NOT put the actual CAS array name into the certificate. The only place cas array name is being used is the RPCClientAccessServer attribute for mailbox database. Outlook clients will use this for MAPI\RPC connection. It’s not over HTTPS, so no need to put that in the cert. Normally the cas array name will be the internal FQDN, such as casarray.contoso.local. But if you happen to have internal domain name be the same as external domain name, make sure you DO NOT have a DNS record for cas array name. If you do, this will slow down the initial connection of Outlook Anywhere. Do not use the actual CAS array name (casarray.contoso.local or casarray.contoso.com) as the URL for any virtual directory (owa, ecp, activesync, ews, oab, etc). Create a different name such as owa.contoso.local for the internal URL.

3.       If you have ISA\TMG at front, issue a cert using internal CA for the backend exchange server. The public cert should go on to ISA\TMG or load balancer if you do SSL offloading.

4.       I wouldn’t recommend to put the internal server FQDN to the public cert (and you really don’t need to) as this will expose your server to the outside world.

5.       So in a nutshell, the basic names you would need in the cert would be:

Owa.contoso.com

Autodiscover.contoso.com

Legacy.contoso.com (if doing co-exist)

failback.contoso.com (for datacenter failover and failback)

                smtp.contoso.com (if secure SMTP is required)

References:

http://blogs.technet.com/b/exchange/archive/2010/11/22/3411576.aspx

http://www.howexchangeworks.com/2011/06/should-cas-array-url-be-part-of.htm

Just based on my understanding and experience. Any comments is highly welcomed.

Move mailbox from Exchange 2010 On Premise to Office 365

Screenshots below outlines the process of moving a mailbox from on-premise Exchange 2010 enviroment to Office 365.

Assumptions:

• Primary SMTP Domain: CONTOSO.COM
• Federated Service Domain: SERVICE.CONTOSO.COM
• External URL for Co-exist Exchange 2010 server: OWA.CONTOSO.COM

Prerequisites:

• Rich Co-exist has already been established between On-prem Exchange and Office 365 (refer to Exchange Hybrid Deployment Configuration Tips: Sharing Free/Busy Information and Exchange Server Deployment Assistant on how to) 
• Mailbox Replication Proxy Service has been enabled on the co-exist Exchange 2010 server.

Steps:

1. From EMC On-Premise, go to Recipient Configuration -> Mailbox, highlight the mailbox you are going to move, click New Remote Move Request from the Action pane

2. Choose Office 365 as the target forest; specify external URL of your co-exist Exchange 2010 server with an account that has adequate permission to the on-premise Exchange environment

3. Enter the federated service domain as the Target Delivery Domain

4. After the remote move request has been generated successfully, go to EMC Cloud -> Recipient Configuration- > Move Request to verify the status of the move request. You can also run Get-MoveRequest | Get-MoveRequestStatistics from a remote powershell session that connects to Office 365 to verify the status.

5. The move request has completed successfully.

6.  As a result, user4 now is showing as the Contact in on-premise Exchange

    And a mailbox in Office 365.

Exchange 2010 Federated Delegation with TMG

During a recent rich co-exist deploymnet between on-premise Exchange 2010 and Office 365,  I noticed therer is a problem establishing organizational relationship from Office 365 to on-premise Exchange coexist server when on-premise Autodiscover is published by a TMG server. Exchange 2010 federation uses SAML tokens—not user accounts—to authenticate against IIS for EWS calls. TMG doesn’t know how to validate SAML tokens, so the incoming requests can’t be authenticated and passed on to the Exchange Server 2010 coexist server. Every time a cloud user tries to view free/busy information of an on-premise user, there is a log in the TMG server indicating "Access Denied"

The end result is that we couldn’t get a proper sharing relationship setup and you can’t federate calendar data.

When we knew what the problem was, fixing it involved modifying the OWA and ECP virtual directories on all of our Exchange Server 2010 CAS servers to perform FBA, then modifying the Web listener on our TMG Server to disable pre-authentication. Finally, we needed to modify the authentication settings for each of the TMG publishing rules for ActiveSync, Outlook Anywhere, and OWA to set them to No Delegation, But Client May Authenticate Directly, and to revise the Users settings from All Authenticated Users to All Users. Revising the Users settings is important; without this, ISA won’t pass any connections on to the CA servers. You may also need to verify that the authentication settings of your other Exchange virtual directories are valid; many organizations will allow basic authentication between TMG and their CAS servers, but require NTLM or Windows Integrated from external clients to TMG.

If you’re using multiple Web listeners to publish Exchange 2010, then your step may be different. The federated delegation feature requires direct access to the EWS vdir on your CAS servers, and EWS is typically published on TMG as part of the Outlook Anywhere rules. If you publish those using a separate Web listener—which will require a separate IP address, FQDN, and SSL certificate—you can simply disable pre-authentication for that Web listener, but still allow it on your OWA, ECP, and EAS directories.

Calendar sharing and TMG FBA pre-authentication are both wonderful features, but at this point they are not compatible.

Exchange Certificate Renewal Causes Lync\Exchange IM Integration Fail

Recently ran into an issue where Lync\Exchange IM Integration stopped working after renewing the certificate on the Exchange server. This was caused by the change of the ThumbPrint of the certificate.

The ThumbPrint of the new certificate has changed and this needs to be updated by running the following Cmdlet

After updating the ThumbPrint, IM is available again in OWA.