This opening segment introduces the advancements in namespace options in Exchange Server 2016. The advantages and disadvantages of bound and unbound models are discussed.
- [Instructor] Every great movie contains a scene where someone who thinks they're important meets someone who turns out to be important and ask them something to the effect of "What should I call you?" As we begin this course on the client access of exchange 2016 servers, it's only fitting that we should begin by establishing what people should call your exchange server. Historically, there have been several different namespace needs. If we had a highly available exchange organization with multiple servers and multiple locations, There would need to be a namespace for each location.
As well as fail back for Outlook web access. RPC clients. On top of that, we still needed the auto-discover, and a transport namespace just to get everything done. The introduction of database availability groups in exchange 2013, gave us the ability to identify an entire group of servers with the same namespace, regardless of location. This includes the fail over namespace. Access to the mailboxes has also been updated.
They now use the same protocols inside the network as outside. That means that the RPC is linked to the mailbox store. It no longer needs its own separate namespace. The functions of auto-discover and transport are still distinct enough that they need their own separate namespace. But this does significantly reduce the number of names needed to access exchange in a large organization. It may be that you will still benefit from identifying your data center separately.
So there are two different modes of namespace for exchange server 2016: Bound and UnBound. Unbound is what I've just been describing. In this scenario we choose one namespace for everything related to mailbox access and administration. That namespace will point to a cluster that can load balance request to the appropriate or available server. One of the most obvious benefits to this is in an automatic fail over situation when one site goes offline.
The same name can be used to automatically direct users to a new location. The downside is that a high-traffic scenario could cause us to redirect users to another site which, while it will work, is not guaranteed to have the same user experience. Which is Microsoft speak for "it could be a lot slower". So in an unbound model, we could get away with as few as three namespaces for our entire exchange deployment. One, for client access to their mailbox.
In this case, "mail.landonhotels.com". One for client configuration, which is "autodiscover.landonhotels.com". And one for transport, and that's out SMTP namespace. The alternative is to keep separate namespaces for different locations, or in some situations, different sides of the same data center. The mailbox databases can still replicate to both locations, but the users will generally be directed to the same site until there's a problem.
And then they can be manually redirected to another. The advantage is the users always get the best experience available. The downside is that there's a degree of manual redirection involved when a switch is needed. A user that's accustomed to typing "mail.landonhotels.com" into their web browser, or already has that configured in Outlook, would have to re-enter a new address to be able to use a separate site. The number of namespaces in this model is far better than it used to be, but this need for a manual change can still cause some confusion among your users when they have to enter "email1.landonhotels.com" when they have to access the Phoenix data center instead of the one here near the corporate office.
Now I made mention of using the same namespace, and this includes both inside and outside the office. That's become more and more important with the explosion of mobile devices. It's really helpful for a smartphone to be able to access the mailbox the same way, over the phone company's network, as it does on wifi. Whether that wifi is in the office, in a hotel, or at home. All this take is a split DNS configuration. But even that's optional.
You still have the option of as many namespaces as you want. The difference now is, the longer list is your decision. As we move into the next segment, we're going to take a look at how proxies and redirection can be used to maintain consistency in the user experience with the shared or distributed names.
- Planning namespaces
- Managing proxies and redirection
- Configuring client access
- Working with online servers
- Managing address lists and offline address books
- Allowing, blocking, and quarantining access
- Load balancing namespaces
- Troubleshooting POP/IMAP connectivity
- Troubleshooting Outlook Anywhere
- Resilient namespaces and URLs
- Configuring certificates for failover