Now the Autodiscover.XML file does have some more informations for Outlook to use. One very important URL to use are the Exchange Web Services. Normally for sending and receiveing an E-Mail the EWS configuration is not necessary. But as soon as your users try to configure their Out of Office Assistant (OOF) they use EWS to do this. So when the URL of EWS is not available useres are unable to configure OOF.

Also the information for OWA and the Offline Address Book (OAB) will be configured with the XML.

From here you can test your Autodiscover configuration. Remove both options for “Guessmart” (this is for POP3 and IMAP testing) and click Test.

The results will now be shown. The tab Log will provide the information how Outlook was able to find the autodiscover.xml file. As stated in Part 1 a domain joined client will use the SCP. If this is for any reason not successfull it will look like that:

Outlook will try the different options (see Part 1) to get the XML file. If it is not successful it will keep retrying it until the last option – search for an SRV-Record even does not work:

So Outlook was not able to get an XML file. Also this will be stated on the Results tab.

Part 1 of our Series introduced the Service Connection Point. Now when Outlook tries to reach the SCP it will get a response with a Servername and an URL (you remember?)

Outlook now tries to reach that URL because it is interested to get the information provided within the XML. The response of Autodiscover from an Exchange 2016 Server after a default installation will look like this:
Here we can see a lot of information. Let’s break down the information to a few less and readable segments – for instance the protocol types EXCH and EXPR

<Protocol>
<Type>EXCH</Type>

<Protocol>
<Type>EXPR</Type>

The different type of protocols define the configuration to know if the connection is meant ‘internal’ or ‘external’
EXCH is the internal configuration
EXPR is the external configuration

The definition ‘internal’ or ‘external’ does not always mean the connection will be outside your network or inside. It depends on what DNS is getting back to your client when we try to reach for example our OWA URL https://webmail.domain.local/owa/

Outlook first tries to reach the internal URL. If this is sucessful the internal URLs will be used. If not – no response for example than the external URL will be used.

When Outlook was able to figure out on which URLs Exchange can be reached it tries to open that connection.

So keep one very important thing in your mind: Autodiscover is simple the process to send an XML file to Outlook so that it does know where it should connect. Not more or less.

Everyone is talking about Autodisover in Exchange and since Exchange 2013 it is more important than ever. But did you really know how the process works?
I know – there are plenty of blog posts out in the internet but I thought I start the challenge from scratch and do it the complete way.

Let’s do some steps behind Autodiscover and what it is:
From an Outlook configuration perspective Autodiscover is just an XML file with some content – brought to you by your Exchange Servers. Outlook tries to find its configuration by using the Autodiscover-Service.

Outlook tries 5 ways to figure out where the Autodiscover XML File could be reached:

Service Connection Point in Active Directory (only for domain joined clients

Normally a domain joined client will always use the SCP. For this blog post we will figure out what the SCP is.

A Service Connection Point (SCP) is a property that can be found in the Configuration Partition within Active Directory. In it’s simplest definition it is a URL to your Exchange server. You configure this URL by setting the AutoDiscoverServiceInternalUri within the Set-ClientAccessServer (Exchange 2013) or Set-ClientAccessService (Exchange 2016).

So with just one simple command you configure the SCP to reflect your Exchange Servers. After the default installation of Exchange the internal hostname will be listed there – for example: https://forpeex16-01.domain.local/Autodiscover/Autodiscover.xml

If you add another server a second SCP with https://forpeex16-02.domain.local/Autodiscover/Autodiscover.xml will be created.

Because of the namespace design in Exchange it is highly recommended to change this URL to something like https://autodiscover.domain.local/Autodiscover/Autodiscover.xml

Behind Autodiscover is your loadbalancer IP or if you do not have a loadbalancer the IP-Adresses of your CAS Servers (Exchange 2013) or Mailbox-Servers (Exchange 2016).

From an Outlook-Client perspective Outlook is configured to use the SCP on a domain joined machine. This is hardcoded in Outlook. OK – enough for today – I’ll have enough to say about Autodiscover the next time…

Many of you use Outlook to connect to your Exchange-Server, right?
When did you last update your Outlook to the latest version? Wow, you installed Service Pack 1 for Office 2013?
If yes than you have a very old version of Outlook.

While many of our customers do have their Exchange nodes well connected some are asking: Can we put the second node of our DAG into a location where we have a hughe TCP round trip time?

The answer is: Yes and No. It depends? This was the answer you are searching for, right?

From a supportability perspective 500ms round trip time is the maximum supported value.

So now it is your decision to install the Node or not. BTW: An easy way to figure out the round trip time is to use pathping or ping. But hey – is ICMP only really the right thing to measure the round trip time?

You install Exchange Cumulative Updates as soon as they arrive, right? You do your daily job while maintaining Mailboxes and Distribution Groups?.
Now it is time to get in touch with the upgrade-process. While you know the details about PAM/SAM from my other blog posts we can directly head over to installing your next Exchange Cumulative Update.

You have seen my last post about Active Manager. You are now familiar with PAM/SAM and BSC and BCSS. For all of you haven’t seen the article I’ll follow up on Best Copy Selection (BSC) and Best Copy and Server Selection (BCSS). BSC was the Exchange 2010 name for BCSS as it is called in Exchange 2013.

As soon as the Active Copy of a Database is no longer available BCSS tries to enable the best available copy. There are a few steps included in this process. One step is to decide the best available copy of the database. This will be done by checking the Mailbox-Server AutoDatabaseMountDial Setting. If the number of missing logfiles is equal or less than the value of AutoDatabaseMountDial Exchange tries to mount the database.
If the value is greater Active Manager tries to find another copy (if they are available) to be activated.

And why I’m discussing all this?
Because it is important during planned maintenance to set the Server into Maintenance that PAM knows not to activate that copy of a database. More about Maintenance will be available soon!

Sizing your Exchange server is a very common task for an Enterprise Architect like me. On a regular basis I will check the recommended Hardware-Sizing for our customers.

Many of our deployments are installed on physical boxes but some are also virtualized. In aspects of sizing there aren’t really any differences. I do not want to share now the well known (you did know this, right)? sizing recommendation from Microsoft: Exchange 2013/2016 Sizing recommendation

I want to share the real numbers. For instance:
A Customer with 2360 Mailboxes is running Exchange 2013 on physical Hardware with 128GB RAM (hey – wasn’t there the recommended limit with 96GB)? on a two node DAG.

Sometimes all databases are on one Server and the RAM Usage is on 101GB. The performance of Exchange is still perfectly – no reports for slow Outlook connections in Online mode or anything else.

Another customer is using a virtualized environment with 64GB RAM for approx. 2200 users. Here we also do not see any issues with the size of RAM

So – just a hundred users less and running fine with 64GB.

Even if there are other recommendations – just check out the downscaling side of live. As long as there are no compliants from your users and Managed Availabilty is running fine (more on this in another post) everything is fine.

The only thing to keep in mind with RAM is: Do not run your Exchange 2013/2016 server with less than 7GB – otherwise you will need a lot of time for wating until tasks are done. Even my demo-environment runs on Windows Azure fine in that configuration (D2 VM)