Exchange 2010 Namespace considerations

For some of us, migrating from Exchange 2003 to Exchange 2010 is an exciting concept, with tons of new features, simpler high-availability features and a lot more power for the users

One of the common overlooked design pieces of a Microsoft Exchange 2010 architecture is the namespace considerations

Legacy Environments

for most Exchange 2003 environments the following names are usually in play

  • – MX Record, mail flow
  •, OWA, OMA, EAS, (Web Services) – Certificate Name

This is not always the case, some people will just use for everything, and this also works great.  Your edge configuration will apply certain requirements/restrictions on how you configure your existing namespace, but this is all relatively simple in Exchange 2003 compared to some of the considerations in Exchange 2010.

Exchange 2010

Most organizations are deploying Exchange 2010 in a highly available configuration, and many are implementing site resilient considerations also, this can lead to a complex namespace design that should be carefully considered and design before the first server is deployed in your organization.

Some things to consider in Exchange 2010 from a high availability standpoint are

Internet Presence

  • webmail, – Primary point of presence, OWA, OA, EAS, OAB – Certificate Name

Auto discover Service

  • – auto configuration URL– Certificate Name

Client Access Arrays

  • – Internal AD reference to CAS Array for each site
  • – Internal AD reference to CAS Array for each site
  • – Assigned to VIP of Load balancer for HA CAS – Certificate Name
  • – Assigned to VIP of Load balancer for HA CAS – Certificate Name


  • – Name used for redirection to 2003 during migration – Certificate Name

Site Resiliency

  • – alternate internet pointe of presence– Certificate Name

Failback URLs

  • – DNS Failback URL for timeout consideration – Certificate Name
  • – DNS Failback URL for timeout consideration – Certificate Name

As you can see there is a lot to consider here before jumping in and throwing some servers up, and some of these names may not be required, or can be consolidated with others depending on your edge topology

For more detailed information on namespace design please check out the TechNet article located here

The Power of Community – Usergroups

Some of you will know that I am active in a number of regional user groups, in fact, some of you may have found me or my blog by attending one of the events I have spoken at or helped co-ordinate.

The Boise user group scene has kind of dried up over the last few years and I endeavor to help change that.  It was always a goal of mine to have an active and vibrant forum for local users to network and discuss topics of interest, and while we are served very well by the local VMware user group (with over 100 people in regular attendance) I feel the general IT scene is underserved still

Recently I assisted Jeff Wilding and some Microsoft Staff kick off the Boise Microsoft Unified Communications User Group by presenting a piece on Exchange migrations and some of the considerations to be made in this space.  After assisting him with preparations, and giving my presentation I was asked if I would be interested in taking a larger role in future events and I have committed myself to helping this group succeed.

I also feel now would be a great time to get the Boise IT Pro User Group back up and running with a regular schedule, and with such a broad focus the topics could be endless

If you, or someone you know are interested in this space, and helping out the local IT community do not hesitate to get in touch with Jeff Wilding, Mark Rezansoff or myself

Regional Groups

You will notice a new page listed at the top of my blog that will display the most current info I have on a number of regional user groups that I have participated in, as well as any other prudent industry events that may be of interest

UAG in a Multi-Platform world

I have had queries from a couple of clients of mine regarding the deployment of UAG in a multi platform environment, not only Windows, but Mac OS X, Linux, Mobile devices etc.  The demand seems to be for a secure connectivity solution that can handle this sort of bi-modal environment with minimum aggravation to users

one particular client emphasized a client-less solution to meet there needs as they are considered early adopters on the OS front and as we all know, that usually breaks software clients!

UAG seems to be synonymous with Microsoft Direct Access, and as an advanced platform for the deployment of Direct Access, that is an understandable misinterpretation, but UAG is much more than just a heavy duty implementation platform for Direct Access

The Trust Pyramid

As a new generation of users and devices enter the workplace, IT is presented with a set of new and unique challenges, to deliver content anywhere it’s desired to facilitate business needs, but keep it secure and manageable, also for business reasons, but how do we accomplish that when so many devices are not managed? personal cell phones, iPads, home computers? do we just block access from these devices? that’s fast becoming an unavailable option, especially as board level staff are bringing their shiny new iPad to the table.

The Trust pyramid fits nicely with UAGs remote access technologies, as each of them provide a different level of access and control while being deployed and managed from a common platform from an IT perspective

  • Direct Access – Windows 7 Enterprise Only, Full, always on network access for the most trusted and managed of systems
  • SSL VPN – Multi platform/browser, Configurable access to applications and services for less managed devices such as non domain OS X systems and Linux boxes
  • Web Portals – Multi platform/browser, Restricted, specific access to applications for personal devices unknown to the IT department

As part of the pyramid we also take into account what we present, not just how we present it, for instance a user accessing the network via direct access may have full access to LOB and CRM systems, but users coming in on a personal tablet may be limited to non restricted file data and email, by providing separate connectivity mechanisms in this manner, UAG helps us meet the IT governance needs of our organization while also empowering users to do things whatever way is convenient for them.


Aside from Direct Access which I’m sure will have numerous posts of it’s own, SSL VPN connectivity through UAG provide non Windows 7 systems (either via ActiveX for IE sessions, or Java for non IE sessions) seamless access to systems configured to utilize it, this can spread the remote access to non Microsoft devices, and third-party browser software such as Mozilla and Opera.  SSL VPNs allow access to desired network services that would otherwise not allow access without a traditional fat-VPN configuration (and the client that goes with it usually).  These operate by creating a secure tunnel between your device and the UAG server and then funneling any data appropriate to the connection over the secure tunnel.  as this technology utilizes SSL and HTTPS technology there are very few circumstances where it does not work.

Web Portals

Web portals are the most restricted of access methods, providing an interface to access a web application that is fronted by the UAG itself, so users are actually talking to UAG, and in most cases UAG talks to the back end servers on their behalf.

This allows IT to be a little more liberal with the devices they allow access to the portals, as the access is so limited, and provides access to the users that they desire, email, SharePoint, or whatever the corporation deems available.

These can be configured and customized to a high level, even presenting different portals to different sets of users to really fine grain the access to the system.