Evolution of Microsoft Unified Communications with Lync Server 2013 and Exchange Server 2013.

Microsoft has been in a forward march with their messaging and collaboration applications, which a majority of businesses run on today. The trend has been toward cloud, the word everyone is using today. As for Microsoft, they are making the business case stronger for what they call Hybrid deployments. These allow Exchange and Lync on-premise and Exchange Online and Lync Online coexistence. In the 2013 release of both applications, Microsoft has increased the coexistence of infrastructure between on-premise and cloud, in addition to a slew of new features for both Exchange and Lync.

Lync 2013 takes the features introduced in Lync 2010 and builds upon them, making a solid case for an upgrade.

Lync 2013: Server Components and High Availability

The roles in Lync 2013 have been significantly consolidated as has been the expected lifecycle progress in the application. The Edge role had been consolidated from OCS to Lync 2010. In Lync 2013 the Archiving, Monitoring, and AV Conferencing roles have been consolidated and no longer will be installed as separate roles. The Director role stays much the same but now is implied by Microsoft as an optional role. Lync 2010 introduced the functionality of a backup registrar where if a user’s home pool were to fail, they would connect to the backup for voice resiliency. The issue here was that the user would suffer limited functionality since this backup was not their home pool. Lync 2013 enhances this by replicating all user data to all Lync servers in the enterprise. This allows for a user to fail over to a backup pool and retain full functionality. In terms of full functionality, there is preservation of ALMOST all functions for a user failed over to a backup pool. The Response Groups Services will not fail over; thus, in a failover, those functions would be inhibited until the user’s home pool is restored. Lync 2013 also introduces backend database SQL mirroring instead of SQL Clustering which lowers management and overall deployment costs. Lync 2013 Persistent Chat is also the evolution of the Group Chat (Persistent Chat). In Lync 2013, this is a more tightly woven feature and an actual server role definable in the topology unlike in Lync 2010. The client is also consolidated to the single Lync 2013 client.

Lync 2013: Enterprise Voice and Response Groups

Lync 2010 was on track to being a full PBX replacement; however, it still did lack some features business with enterprise grade PBX’s have come to rely upon. Lync 2013 enhances voice features in making the case more compelling as an enterprise grade voice solution. Lync 2013 supports inter-trunk (M-N) routing. Inter-Trunk routing allows Lync to handle traffic between multiple phone systems and allows Lync to receive and then hand off calls to another PBX. This is a very important function for larger enterprises running multiple voice systems, which is a very common occurrence. The Mediation role has also been enhanced by allowing for multiple trunks to different gateways, and also gateways having multiple trunks to Mediation servers. Number manipulation has also been improved by allowing trunk translations for modification of the CALLED and CALLING numbers before passing the call to the next hop. This is a very significant change in allowing Lync 2013 to be configurable and comparable to PBX’s further down the lifecycles. There have been numerous enhancements to Lync 2013 Voice. The details are vast and will be covered separately. The Lync 2013 Response Group services remain mostly unchanged; however, the Manager Role and Administrator Role have been added to alleviate some tasks functionality.

Lync 2013: E-911

The distribution of notification to security personnel can now be done by a group rather than a specific SIP URI. This allows for ease of management with security personnel turnover. The Location Information Service (LIS) can now be specified on the number of hours to wait before requesting a location update. Disclaimers are now also definable per location policy rather than being global. The Lync 2013 client running on Windows 8 also allows for Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED). This helps in locating the clients in the LIS.

Lync 2013: Lync Online and Mobility

Exchange 2010 has been able to deploy a hybrid system and now Lync 2013 shares this same configuration option. In Lync 2013 you are now able to deploy a single SIP domain between the cloud and on-premise. Users may be spread between cloud and on-premise servers. This results in a true Hybrid Voice system. A company may now deploy a gateway locally and have all users in the cloud connecting to voice services locally with Media Bypass as an option to avoid hair pinning through Microsoft cloud servers.
The mobility platform gets a much needed makeover allowing for the user to make Audio and Video calls over their mobile devices. The data for this would utilize the mobile data network or a WiFi connection. This is a feature that had been lacking in the Lync 2010 mobile platform. It is also worth mentioning that Response Groups may ONLY be deployed on-premise. In a Hybrid Voice deployment, users acting as agents would need to be located in on-premise servers.

Lync 2013 introduces many new features, not of all which have been discussed here. A couple more notable enhancements are Voice support on virtual desktops and integration with Skype. A complete list of server features may be found here at Lync New Server Features. A complete list of client features may be found here at Lync New Client Features.

Exchange 2013 also has evolved as a messaging platform. The new features introduced are a positive direction forward in availability and features. The Exchange platform also becomes more tightly integrated with Lync as a Unified Communications platform. An example of this integration is Lync 2013 archive now utilizes Exchange 2013 Archive stores. In addition contacts are now in a Unified Contact Store which allows all contacts in Exchange 2013 and access them from either Lync 2013 or Outlook 2013.

Exchange 2013: Server Roles and Administration

The Exchange 2013 roles consist of more of a front end, back end configuration, familiar from legacy versions of the product. The Client Access role is front facing and services SMTP, POP, OWA, and mobility. The basis of consolidation of the Client Access Server and Hub Transport roles are from Exchange 2010. The backend Mailbox role stays much the same and utilizes the powerful Database Availability Groups of Exchange 2010.
The Exchange Management Console (EMC) makes an exit with the introduction of the Exchange Administration Center (EAC). This new interface allows for management of Exchange Online and/or Exchange on-premise, Hybrid deployments.

Exchange 2013: Topology and Architecture

Coexistence is only supported with Exchange 2007 and Exchange 2010; all other legacy infrastructures are not supported for coexistence. The only supported underlying host OS is Windows Server 2008 R2. Outlook Anywhere (RPC over HTTPS) is now the only means for Outlook connectivity and all RPC connectivity is now outdated legacy. Public Folders are still here in Exchange 2013. The Public Folder strategy now takes advantage of high availability of the mailbox databases. The Public Folder hierarchy now uses the mailbox databases instead of a Public Folder Database. The Outlook Web App is also now available in Offline mode. The transport pipeline now consists of 3 tiers: Front End Transport Service, Hub Transport Service, and Mailbox Transport Service. The functions of these services are spread between the Client Access and Mailbox roles in tendering a messaging infrastructure.

The additional features of Exchange 2013 are many more and a full list of new features is available here at additional Exchange 2013 features.
Microsoft’s evolution of their messaging and collaboration suite with Exchange 2013 and Lync 2013 is a strong step forward in market domination. By building on the powerful tools Microsoft is once again proving to be the leader in Messaging and now Voice technologies.

Article on Exchange 2013 Client Access Server Role published

Article on Exchange 2013 Client Access Server Role published by Microsoft.

Exchange 2013 Client Access Server Role

By Ross Smith IV [MSFT]

In a previous article, I discussed the new server role architecture in Exchange 2013. This article continues the series by discussing the Client Access server role.

While this Exchange server role shares the same name as a server role that existed in the last two Exchange Server releases, it is markedly different. In Exchange 2007, the Client Access server role provided authentication, proxy/redirection logic, and performed data rendering for the Internet protocol clients (Outlook Web App, EAS, EWS, IMAP and POP). In Exchange 2010, data rendering for MAPI was also moved to the Client Access server role.

In Exchange 2013, the Client Access server (CAS) role no longer performs any data rendering functionality. The Client Access server role now only provides authentication and proxy/redirection logic, supporting the client Internet protocols, transport, and Unified Messaging. As a result of this architectural shift, the CAS role is stateless (from a protocol session perspective, log data that can be used in troubleshooting or trending analysis is generated, naturally).

Session Affinity

As I alluded to in the sever role architecture blog post, Exchange 2013 no longer requires session affinity at the load balancer. To understand this better, we need to look at how CAS2013 functions. From a protocol perspective, the following will happen:

  1. A client resolves the namespace to a load balanced virtual IP address.
  2. The load balancer assigns the session to a CAS member in the load balanced pool.
  3. CAS authenticates the request and performs a service discovery by accessing Active Directory to retrieve the following information:
  1. Mailbox version (for this discussion, we will assume an Exchange 2013 mailbox)
  2. Mailbox location information (e.g., database information, ExternalURL values, etc.)
  1. CAS makes a decision on whether to proxy the request or redirect the request to another CAS infrastructure (within the same forest).
  2. CAS queries an Active Manager instance that is responsible for the database to determine which Mailbox server is hosting the active copy.
  3. CAS proxies the request to the Mailbox server hosting the active copy.

The protocol used in step 6 depends on the protocol used to connect to CAS. If the client leverages the HTTP protocol, then the protocol used between the Client Access server and Mailbox server is HTTP (secured via SSL using a self-signed certificate). If the protocol leveraged by the client is IMAP or POP, then the protocol used between the Client Access server and Mailbox server is IMAP or POP.

Telephony requests are unique, however. Instead of proxying the request at step 6, CAS will redirect the request to the Mailbox server hosting the active copy of the user’s database, as the telephony devices support redirection and need to establish their SIP and RTP sessions directly with the Unified Messaging components on the Mailbox server.

CAS Protocol Arch
Figure 1: Exchange 2013 Client Access Protocol Architecture

In addition to no longer performing data rendering, step 5 is the fundamental change that enables the removal of session affinity at the load balancer. For a given protocol session, CAS now maintains a 1:1 relationship with the Mailbox server hosting the user’s data. In the event that the active database copy is moved to a different Mailbox server, CAS closes the sessions to the previous server and establishes sessions to the new server. This means that all sessions, regardless of their origination point (i.e., CAS members in the load balanced array), end up at the same place, the Mailbox server hosting the active database copy.

Now many of you may be thinking, wait how does authentication work? Well for HTTP, POP, or IMAP requests that use basic, NTLM, or Kerberos authentication, the authentication request is passed as part of the HTTP payload, so each CAS will authenticate the request naturally. Forms-based authentication (FBA) is different. FBA was one of the reasons why session affinity was required for OWA in previous releases of Exchange – the reason being that that the cookie used a per server key for encryption; so if another CAS received a request, it could not decrypt the session. In Exchange 2013, we no longer leverage a per server session key; instead we leverage the private key from the certificate that is installed on the CAS. As long as all members of the CAS array share the exact same certificate (remember we actually recommend deploying the same certificate across all CAS in both datacenters in site resilience scenarios as well), they can decrypt the cookie.

Proxy vs. Redirection

In the previous section, I spoke about CAS proxying the data to the Mailbox server hosting the active database copy. Prior to that, CAS has to make a decision whether it will perform the proxy action or perform a redirection action. CAS will only perform a redirection action under the following circumstances:

  1. The origination request is telephony related.
  2. For Outlook Web App requests, if the mailbox’s location is determined to be in another Active Directory site and there are CAS2013 members in that site that have the ExternalURL populated, then the originating CAS will redirect the request unless the ExternalURLin the target site is the same as in the originating site – in which case CAS will proxy (this is the multiple site single namespace scenario).

Proxy-Referral
Figure 2: Exchange 2013 Client Access Proxy and Redirection Behavior Examples

  1. For OWA requests, if the mailbox version is Exchange 2007, then CAS2013 will redirect the request to CAS2007.

Outlook Connectivity

For those of you paying attention, you may have noticed I only spoke about HTTP, POP, and IMAP. I didn’t mention RPC/TCP as connectivity solution that CAS supports. And that is for a very specific reason – CAS2013 does not support RPC/TCP as a connectivity solution; it only supports RPC/HTTP (aka Outlook Anywhere). This architecture change is primarily to drive a stable and reliable connectivity model.

To understand why, you need to keep the following tenets in the back of your mind:

  1. Remember CAS2013 is an authentication and proxy/redirection server. It does no processing of the data (no rendering or transformation). It simply proxies the request to MBX2013 using the client protocol. In this case HTTP.
  2. CAS2013 and MBX2013 are not tied together from a user affinity or geographical perspective. You can have CAS2013 in one datacenter authenticate the request and proxy the request to a MBX2013 server in another datacenter. To enable this we had to change the communication protocols used between server roles. Moving away from RPC to the client protocols that are more tolerant of throughput & latency over WAN/Internet connections.
  3. For a given mailbox, the protocol that services the request is always going to be the protocol instance on the Mailbox server that hosts the active copy of the database for the user’s mailbox. This was done to ultimately uncouple versioning and functionality issues we’ve seen in the past two generations (i.e., have to deploy CAS2010, HT2010, MBX2010 together to get certain functionality and upgrading one doesn’t necessarily give you new capabilities and may break connectivity).

The last item is tied to this discussion of why we have moved away from RPC/TCP as a connectivity solution. In all prior releases the RPC endpoint was a FQDN. In fact, the shift to the middle tier for RPC processing in CAS2010 introduced a new shared namespace, the RPC Client Access namespace. By moving RPC Client Access back to the MBX2013 role, this would have forced us to use either the MBX2013 FQDN for the RPC endpoint (thus forcing an Outlook client restart for every database *over event) or a shared namespace for the DAG.

Neither option is appropriate and adds to the complexity and support of the infrastructure. So instead, we changed the model. We no longer use a FQDN for the RPC endpoint. Instead we now use a GUID. The mailbox GUID, to be precise (along with a domain suffix to support multi-tenant scenarios). The mailbox GUID is unique within the (tenant) organization, so regardless of where the database is activated and mounted, CAS can discover the location and proxy the request to the correct MBX2013 server.

RPC Endpoint
Figure 3: RPC Endpoint Changes

This architectural change means that we have a very reliable connection model – for a given session that is routed to CAS2013, CAS2013 will always have a 1:1 relationship with the MBX2013 server hosting the user’s mailbox. This means that the Mailbox server hosting the active copy of the user’s database is the server responsible for de-encapsulating the RPC stream from the HTTP packets. In the event a *over occurs, CAS2013 will proxy the connection to MBX2013 that assumes the responsibility of hosting the active database copy. Oh, and this means in a native Exchange 2013 environment, Outlook won’t require a restart for things like mailbox moves, *over events, etc.

The other architectural change we made in this area is the support for internal and external namespaces for Outlook Anywhere. This means you won’t need to deploy split-brain DNS or deal with all Outlook clients using your external firewall or load balancer due to our change in MAPI connectivity.

Third-Party MAPI Products

I am sure that a few of you are wondering what this change means for third-party MAPI products. The answer is relatively simple – these third-party solutions will need to leverage RPC/HTTP to connect to CAS2013. This will be accomplished via a new MAPI/CDO download that that has been updated to include support for RPC/HTTP connectivity. It will be released in the first quarter of calendar year 2013. To leverage this updated functionality, the third-party vendor will either have to programmatically edit the dynamic MAPI profile or set registry key values to enable RPC/HTTP support.

I do also want to stress one key item with respect to third-party MAPI support. Exchange 2013 is the last release that will support a MAPI/CDO custom solution. In the future, third-party products (and custom in-house developed solutions) will need to move to Exchange Web Services (EWS) to access Exchange data.

Namespace Simplification

Another benefit with the Exchange 2013 architecture is that the namespace model can be simplified (especially for those of you upgrading from Exchange 2010). In Exchange 2010, a customer that wanted to deploy a site-resilient solution for two datacenters required the following namespaces:

  1. Primary datacenter Internet protocol namespace
  2. Secondary datacenter Internet protocol namespace
  3. Primary datacenter Outlook Web App failback namespace
  4. Secondary datacenter Outlook Web App failback namespace
  5. Primary datacenter RPC Client Access namespace
  6. Secondary datacenter RPC Client Access namespace
  7. Autodiscover namespace
  8. Legacy namespace
  9. Transport namespace (if doing ad-hoc encryption or partner-to-partner encryption)

As I previously mentioned, we have removed two of these namespaces in Exchange 2013 – the RPC Client Access namespaces.

Recall that CAS2013 proxies requests to the Mailbox server hosting the active database copy. This proxy logic is not limited to the Active Directory site boundary. A CAS2013 in one Active Directory site can proxy a session to a Mailbox server that is located in another Active Directory site. If network utilization, latency, and throughput are not a concern, this means that we do not need the additional namespaces for site resilience scenarios, thereby eliminating three other namespaces (secondary Internet protocol and both Outlook Web App failback namespaces).

For example, let’s say I have a two datacenter deployment in North America that has a network configuration such that latency, throughput and utilization between the datacenters is not a concern. I also wanted to simplify my namespace architecture with the Exchange 2013 deployment so that my users only have to use a single namespace for Internet access regardless of where their mailbox is located. If I deployed an architecture like below, then the CAS infrastructure in both datacenters could be used to route and proxy traffic to the Mailbox servers hosting the active copies. Since I am not concerned about network traffic, I configure DNS to round-robin between the VIPs of the load balancers in each datacenter. The end result is that I have a site resilient namespace architecture while accepting that half of my proxy traffic will be out-of-site.

namespace
Figure 4: Exchange 2013 Single Namespace Example

Transport

Early on I mentioned that the Client Access Server role can proxy SMTP sessions. This is handled by a new component on the CAS2013 role, the Front-End Transport service. The Front-End Transport service handles all inbound and outbound external SMTP traffic for the Exchange organization, as well as, can be a client endpoint for SMTP traffic. The Front-End Transport Service functions as a layer 7 proxy and has full access to the protocol conversation. Like the client Internet protocols, the Front-End Transport service does not have a message queue and is completely stateless. In addition, the Front-End Transport service does not perform message bifurcation.

The Front-End Transport service provides network protection – a centralized, load balanced egress/ingress point for the Exchange organization, whether it be POP/IMAP clients, SharePoint, other third-party or custom in-house mail applications, or external SMTP systems.

For outgoing messages, the Front-End Transport service is used as a proxy when the Send Connectors (that are located on the Mailbox server) have the FrontEndProxyEnabled property set. In this situation, the message will appear to have originated from CAS2013.

For incoming messages, the Front-End Transport service must quickly find a single, healthy Transport service on a Mailbox server to receive the message transmission, regardless of the number or type of recipients:

  • For messages with a single mailbox recipient, select a Mailbox server in the target delivery group, and give preference to the Mailbox server based on the proximity of the Active Directory site.
  • For messages with multiple mailbox recipients, use the first 20 recipients to select a Mailbox server in the closest delivery group, based on the proximity of the Active Directory site.
  • If the message has no mailbox recipients, select a random Mailbox server in the local Active Directory site.

Conclusion

The Exchange 2013 Client Access Server role simplifies the network layer. Session affinity at the load balancer is no longer required as CAS2013 handles the affinity aspects. CAS2013 introduces more deployment flexibility by allowing you to simplify your namespace architecture, potentially consolidating to a single world-wide or regional namespace for your Internet protocols. The new architecture also simplifies the upgrade and inter-operability story as CAS2013 can proxy or redirect to multiple versions of Exchange, whether they are a higher or lower version, allowing you to upgrade your Mailbox servers at your own pace.

View this post online.

ForeFront TMG SP2 Rollup 3

A short blog on the release of Rollup 3 for Microsoft Forefront Threat Management Gateway (TMG) 2010 Service Pack 2.

For Exchange, this Rollup fixes unexpected authentication prompts when using OWA published using Forefront Threat Management Gateway (TMG) 2010 in conjunction with RSA authentication and Forms-based Authentication (FBA). For a full list of changes, consult knowledgebase article kb2735208.

You can request Forefront TMG SP2 RU3 directly from support here