Jake Kappus.comCertified Geek, Dad, MMA fan, and ocassional Pro Wrestler

I apologize for not writing part two of this article in a timely matter, then again, when is anything timely on this blog?  I seem to only get inspiration to write when it’s the most inconvenient, of course.  Like at 30,000 feet and all you have with you is your iPad.  Oh well, adapt and overcome.   If you want timely news and articles, go visit my boy Scott Feltmann.  Just be sure to click on his ads there, he needs to buy his future NHL star a new hockey stick. 

So, let’s talk about how external Exchange 2010 clients discover and are updated when you are not within the friendly confines of your company’s network.

By default, when first creating your profile, if you hadn’t already configured it, the Outlook client (2007/2010/2011) will query the following URL’s in the following order:

1. The autodiscover service connection point URL (if you are on an active directory joined workstation).  From the outside this should fail, and if it doesn’t, you need a new network security guy.
2. Then it will query the base domain of the email address you entered in the second line of the profile creation wizard.  So if your email is Jake@domain.com, that address would be: https://domain.com/autodiscover/autodiscover.xml.
3. Should that fail, it will immediately try http://domain.com/autodiscover/autodiscover.xml.
4. When/if that fails, it will then switch to https://autodiscover.domain.com/autodiscover/autodiscover.xml
5. Should that fail, it will then try http://autodiscover.domain.com/autodiscover/autodiscover.xml

If you are a visual kind of person (like me), here is the picture of how it works:

Now, if your environment is properly configured, this should be all you need, but there are two other ways that your client can use to find your shiny new Exchange 2010 environment.

1. The good old fashioned SRV record in DNS.   This method can be used internally as well.  This can be handy in multiple mail domain scenarios or migrations between forests.
2. You can also hard code Autodiscover settings into the registry and ensure your client doesn’t have to bother with going to look up it’s settings.   Unfortunately, in the event of a change in your Exchange environment to Autodiscover, this may not get updated and your clients could be left in the dark.

You must be asking at this point “what method should I configure here?”.   Well, it depends on your environment.  Most security conscious admins really do not like opening port 80 inbound to their Exchange servers, unless you have something like TMG and UAG and can use the handy dandy redirect rules there to redirect the client to https, aka tcp/443.

Since most organizations do not host their own website, it can be difficult to create a virtual directory under the base domain to forward to the CAS servers, I usually do not go the first route.

I usually always recommend creating an external DNS record for autodiscover.domain.com and point that to the same external IP address as you would for OWA, ActiveSync, Outlook Anywhere, etc.  Finding the record may take a few extra milliseconds, but it works flawlessly and doesn’t require getting the web developers involved and having to translate your communications to Linux/Apache for them, causing all sorts of confusion for those that don’t understand the Microsoft language of love.  If you have TMG or UAG in your environment, then publish both http (with a redirect)and https there and off you go!

What’s that I hear?  You want to know what this does for you?  Well, the same thing as it does for internal clients!  If you need a refresher, scroll down and read part 1 of this article.  After the client authenticates to active directory, which the client will be prompted for if the client hasn’t already asked you for your active directory credentials in the wizard, it will send down to the client the same .XML file that you get as an internal user, except that since you are now outside of the company network, the client will read the second half of the .XML file after the EXPR section, and use those URL’s to connect to the various Exchange services such as The availability service, offline address book, Active Sync (if you are using your phone or tablet) and the Exchange Control Panel via OWA.  This ensures you can connect to all of the features of Exchange that you know and love when you are in the office, but now from that Caribou Coffee shop that you love to sit at when not in the office.   Pretty cool huh?

You can configure these URL’s either via the Exchange Management Console GUI or via the Exchange Management Shell, if you have confidence in your Powershell-fu.   I have a nifty little script that I stole borrowed from Pat Richard and Patricio Anderson that does the trick, by setting all of the URL’s for me automagically with only a few keystrokes.   Saves me the embarrassment of going back and fixing a typo later on.

Note that autodiscover does not have a GUI tab to set it’s URL’s, and the external URL is not set by default.   You have to use the EMS to set the URL’s for autodiscover.   Note:  if you have multiple sites with Exchange CAS role servers, do not set the external URL on the sites that are not Internet facing, this will break your proxy between sites and will attempt to redirect externally instead.  Only set the external URL’s on Internet facing CAS servers!

Pro tip: Technically, you do not need to add the external URL for Autodiscover as long as your DNS names are correct.  But it is helpful to add them if you are integrated with Lync and/or Sharepoint.

The Powershell command to set autodiscover URL’s are:

Set-autodiscovervirtualdirectory -identity “server name/autodiscover (default web site)” – externalurl https://autodiscover.domain.com/autodiscover/autodiscover.xml.

Set this on all of your Internet facing CAS servers (this is where the script comes in handy!) or use remote Powershell instead.

Set the other external URL’s for the other services as follows:

Set-ewsvirtualdirectory -identity “server name/EWS (Default web site) -externalurl https://owahostname.domain.com/EWS/exchange.asmx

Set-owavirtualdirectory -identity “server name”/owa (default web site) -externalurl https://owahostname.domain.com/owa

Set-ecpvirtualdirectory -identity “server name”/ecp (default web site) -externalurl https://owahostname.domain.com/ecp

Set-oabvirtualdirectory -identity “server name/oab (default web site) -externalurl https://owahostname.domain.com/oab

Set-activesyncvirtualdirectory -identity “server name”/Microsoft-Server-ActiveSync (default web site) -externalurl https://owahostname.domain.com/Microsoft-Server-ActiveSync

Set-umvirtualdirectory -identity “server name”/unifiedmessaging (default web site) -externalurl https://owahostname.domain.com/unifiedmessaging

Pro tip: you can just type in -id server name/autodiscover* as a faster way to enter the server name and to prevent using quotes in your command.

Whew!  That was a lot of commands!  Especially while typing on an iPad!  ensuring your external URL’s are set properly is a key component to ensuring your Exchange environment works as designed and keeps your users happy, which is why we all do this, right?

Pro tip: do not use your CAS array name as your external URL name.   This can cause performance issues upon connecting to Exchange externally as the CAS array internal name and IP address are cached and will attempt to connect to that IP address first before attempting to connect to the external URL’s.  Ross Smith of the Exchange Product Team has a great article about this here:

Finally, a lot of my clients ask me if there is any way to control access to those services from the outside.  Some go as far as not configuring the external URL’s, thinking it will prevent access.  Well, it does, in theory, but then your services do not work properly!  If security is a concern, consider using Microsoft Unified Access Gateway to lock down access to these services to specific groups of users, or even specific workstations.   There are ways to only allow specific types of phones and active sync devices via the active sync policies.  You could even go as far as implementing certificate based authentication with TMG.  My compadre Jeff Gulliet has a phenomenal article about how to implement that solution here.

Thats all folks!  As usual, leave your comments below and have a great day!

You may be tempted to wing it
Use a hardcoded link submit it
But performance will suffer
When you’re left to your druthers
Should have Autodiscovered
Then all would be well
The Autodiscover Song
http://blogs.technet.com/b/exchange/archive/2008/08/08/3406026.aspx

I usually don’t like to write how-to articles.  Don’t get me wrong, I love helping people and that’s why I love consulting, but I leave the how-to articles to my friends Scott Feltmann, Elan Shudnow and Jeff Guillet.   Me on the other hand, am an entertainer, always have been.   I like to hit the topics that no one usually wants to touch.  Like our friend the Exchange Autodiscover service.

Over the past few months, I’ve been called in by several clients to clean up the work of other “Exchange experts” who underbid me (well, the company I work for), and then pass off the work as a job well done.   Then, when they leave and move on to their next work of art, the clients call me back and ask them to fix the laundry list of “out of scope” issues the “expert” left behind.

More times than most, one thing fixes 90% of these issues.  Sing it with me kids….A-U-T-O-D-I-S-C-O-V-E-R.

What Does Autodiscover do?

Why, I’m so glad you asked!    Here is the official Technet description of the service.  (Yes, I am the MASTER of cut and paste!)

The Autodiscover service does the following:

• Automatically configures user profile settings for clients running Microsoft Office Outlook 2007 or Outlook 2010, as well as supported mobile phones. Phones running Windows Mobile 6.1 or a later version are supported. If your phone isn’t a Windows Mobile phone, check your mobile phone documentation to see if it’s supported.
• Provides access to Exchange features for Outlook 2007 or Outlook 2010 clients that are connected to your Exchange messaging environment.
• Uses a user’s e-mail address and password to provide profile settings to Outlook 2007 or Outlook 2010 clients and supported mobile phones. If the Outlook client is joined to a domain, the user’s domain account is used.

Now, that’s pretty self-explanatory, right?   From what I’m seeing in the field, I think most people are reading the first sentence and clicking the next link.  (…and I thought I had a severe case of ADD!)

AUTODISCOVER DOES MUCH MORE THAN PROFILE CREATION PEOPLE!

Let’s read the second bullet, you know, the one they didn’t read!

• Provides access to Exchange features for Outlook 2007 or Outlook 2010 clients that are connected to your Exchange messaging environment.

Now, first a little bit of side info that’s pretty valuable for this topic.  Exchange 2007 and 2010 uses Exchange Web Services (EWS) to serve clients like Outlook 2007, 2010, (2011 for you Mac users), OWA, ActiveSync, and even that waste of silicon the Blackberry.

No really, I may end up voting Republican if Obama doesn’t ditch the BB and get a real phone.

Outlook 2000 or 2003 does not use the Autodiscover service.  But that doesn’t mean you shouldn’t deploy it if you use those clients exclusively.  Remember those ActiveSync clients, they need some Autodiscover love too!

If you are still on Office 98 call me, please. I’ll steal some 2007 or 2010 licenses for you somehow.  (Kidding!)

With EWS, these clients get the much improved Availability Service (Free/Busy for those of you still suck on 2003), Out of Office, MailTips, Offline Address Book and even access to the new, and seriously cool Exchange Control Panel, securely and efficiently! (read: No WebDav!)

Besides, when you take advantage of that new kick-ass cross-site DAG you just implemented, how are your Outlook clients going to find their mailbox after your basement datacenter just took in several hundred gallons of the Minnesota River, and you (thankfully) failed over to the backup datacenter?  Magic?  A quick desktop support staff?  Nope, Autodiscover.

So here’s how it works:

When you first setup the Outlook or ActiveSync client internally from a domain joined client, the client will query the Autodiscover Service Connection Point for the list of CAS servers. The client sends an HTTP POST command to the Autodiscover service. This command includes XML data that requests the connection settings and URLs for the Exchange services that are associated with the Outlook provider. The service will gather the locations of the different Exchange Web Services (EWS) from Active Directory which will then present the client with the results in an HTTP request formatted in XML.

What if something changes or breaks?

The Outlook client queries Autodiscover periodically (1 hour).  If there are changes in the Exchange architecture, Autodiscover will change the profile automatically. If Outlook fails to connect to the Exchange server, it will attempt to connect to the URL’s it was presented every five minutes.

Now when the underlying network layer disconnects, after the first initial reconnection, Outlook’s MAPI layer will attempt to query Autodiscover every six hours.

Note:  For the client changes to take effect, you still need to restart the client or do a manual “Repair” under Account Settings.

The Service Connection Point

Let’s talk about the SCP Connection point.  This is AUTOMAGICALLY created by setup when you install the Client Access Role.   Setup will register this connection point under the CN=Services, CN=Microsoft Exchange, CN=Administrative Groups, CN=”AG NAME”, CN=Servers, CN=Servername, CN=Protocols, CN=Autodiscover container.  The Internal domain joined Outlook client will query AD for these connection points.  AD will return a list (one for every CAS server in the organization and another set of lists with the CAS servers in your site and outside your site), and will usually take the first one in the closest or same AD Site on the list.

Now before you go all ADSIEdit on your NTDS.dit, hold yer horses!  You do realize you have options that do not involve an authoritative restore after you accidentally bump the delete key on the root container, right?   In the Exchange Management Shell (oh come on, Powershell isn’t that bad!), you can use your carefully planned out Autodiscover URL to set the Autodiscover Internal URI value.

Set-ClientAccessServer -Identity “CAS-01″ -AutoDiscoverServiceInternalUri https://cas01.contoso.com/autodiscover/autodiscover.xml

Do this on every CAS server in your organization and it will return a properly formatted list to you every time.   Well, maybe.  Unless you neglected to plan for Autodiscover properly and did not include the server (or another hostname like Autodiscover) name on your brand new and very carefully crafted SAN certificate.

If this happens, you get the dreaded certificate error!  Plan, plan, plan, I say!

Certificates are another thing that gets a lot of “experts” into trouble.    Microsoft recommends using a SAN (Subject Alternative Name) Certificate, also called a UC (Unified Communications) Certificate.    A lot of them try get away with using a single name certificate, but it really is more trouble than it is worth.  I never recommend their use.

Make sure whatever name you use for your Autodiscover url, there is a valid certificate imported and assigned in Exchange with that name in the SAN field!

The names Microsoft recommends are:

CN (Common Name): *owaname*. Domain.com
SAN: Autodiscover.domain.com
SAN: legacy.domain.com (for legacy coexistience to Exchange 2003, if needed)

Note:  Personally, I like to add the local CAS server names into the cert as well, just to cover for any static client issues or testing.  It is not required though by any means.  With properly configured URL’s, you do not need to add them.  It’s just my personal preference after some late nights of troubleshooting some wacky environments. YMMV J

I could go much deeper into this subject, but I’m out of…ahem, beverages.   In Part II of this thrilling series on Autodiscover, I will go into external Autodiscover configuration, OCS/Lync dependencies, and how your phone finds Exchange from anywhere in the world.

For more information:

White Paper: Exchange 2007 Autodiscover Service
http://technet.microsoft.com/en-us/library/bb332063%28EXCHG.80%29.aspx

Understanding the Autodiscover Service: Exchange 2010 SP1
http://technet.microsoft.com/en-us/library/bb124251.aspx

And if you’re really geeky:
[MS-OXDISCO]: Autodiscover HTTP Service Protocol Specification
http://msdn.microsoft.com/en-us/library/cc433481%28EXCHG.80%29.aspx

Cost of Exchange Consultant to help attempt to recover your database = $124,000

Cost for Kroll OnTrack to write custom software to recover your damaged database = $120,000

Reliable and verified Exchange aware backups: Nice

Implementing high availability using best practices: Priceless

I passed 70-662 and 70-663 last week to earn the MCITP: Enterprise Messaging Administrator certification for Exchange 2010.

Now what?

2 exams down and one more to go until I achieve the MCITP: Enterprise Messaging certification.  I finally ventured down to Appleton to take the MCTS: Exchange 2007 exam and passed with 1000.  Not sure how I pulled that off, but I have been studying pretty hard for that one.

Feeling either confident or cocky (not sure which one), I decided to save a trip and sit the first of the MCITP exams for Exchange as well.  Well, remind me not to do that before at least cracking open a book to at least go over what was on the exam.  I passed, but barely.  So next Wednesday I’ll sit the last exam and I’ll get to add another credential to my portfolio.

SQL 2008 next (and this one isn’t voluntary…I’m not a fan of SQL)

After months of begging, I finally got an invitation to go to the biggest Microsoft propoganda display in the country.  Microsoft TechEd 2008.  4 days of nothing but Microsoft.  I’m excited as hell, not because of the massive amount of geekness I will be experiencing, but because it’s going to be a hell of a learning experience.  I’m excited to learn more about Office Communications Server 2007 and Exchange 2007.  Both of which I’ve taken an interest in (professionally of course).  I’ll also be arriving in Orlando early to take part in their MCSE upgrade bootcamp which should result in me leaving Orlando an MCITP: Enterprise Administrator on Windows Server 2008.

That’s not all.  I scored a seat at OCS Ignite in Chicago as well.  If I don’t learn anything by then, then I might as well hang it up.    Maybe I’ll attempt the OCS 2007 MCTS exam while I’m there?

The best part about all of this is that we found someone to take the kids for 10 days and Melissa gets to go with me to Chicago and then to Orlando for TechEd.  Even if we only get the nights together down there, it’s still a vacation to us!  No kids=vacation! 

I’m going to try and make one of the TNA tapings while I’m down there too.

I’ve heard a rumor that Freddie Jacobs will also be making a surprise appearance one late weekend in June somewhere in Illinois.  Stay tuned for that one.

June is becoming one crazy month for me.