Monday, 30 November 2015

Exchange - What type of client sent an email?

Introduction


In this post, I'll show you how to work out which client was used to send a particular email by using the Message Tracking Logs in Exchange 2010, Exchange 2013 or Exchange 2016. See below.


Message Tracking Logs


In the message tracking logs, there is a SourceContext field which reports the ClientType property for SUBMIT events. SUBMIT events are where the Mailbox Transport Submission service passes on a message to the Transport service, i.e. when the Exchange server picks up the email from the mailbox outbox and passes it on for delivery. 

There's no SUBMIT event when an external sender sends an email to one of your users. This means that there's no ClientType property for these emails. 

To do some testing, I sent emails using ActiveSync, OWA and Outlook and then did some message tracking to see what I could find.


ActiveSync


In this example email, I’ve sent an email using ActiveSync (with the subject ActiveSync) and you can see the message tracking log output shows the ClientType as AirSync highlighted at the bottom:

Get-MessageTrackingLog -Start "11/24/2015 10:00" -MessageSubject ActiveSync | fl TimeStamp,Sender,Recipients,MessageSubject,SourceContext

image

Outlook Web Access


Emails sent using OWA has a ClientType of OWA. That’s good. That makes sense:

Get-MessageTrackingLog -Start "11/24/2015 10:00" -MessageSubject OWA | fl TimeStamp,Sender,Recipients,MessageSubject,SourceContext

image

Outlook


As for Outlook, the ClientType came up as Outlook right? Ahem. No. MOMT. MOMT is MAPI on the Middle Tier which basically includes clients that connect using Outlook or any other application that connects using RPC/HTTP or MAPI/HTTP. See below:

Get-MessageTrackingLog -Start "11/24/2015 10:00" -MessageSubject "Outlook 2253" | fl TimeStamp,Sender,Recipients,MessageSubject,SourceContext

image

Windows 10 Mail App


If you haven’t yet come across this, you’ll soon find out that it connects using ActiveSync. See below:

Get-MessageTrackingLog -Start "11/24/2015 10:00" -MessageSubject "Windows 10 Mail" | fl TimeStamp,Sender,Recipients,MessageSubject,SourceContext

image


Monitoring emails


Monitoring emails also have a ClientType and this is Monitoring. See below:

Get-MessageTrackingLog -Start "11/25/2015 21:00" -MessageId 07f6a25a51914f1cac5ed1ec244caabd@litex01.litwareinc.com | fl TimeStamp,Sender,Recipients,SourceContext

image

Get client type for an email


I’ve written a small PowerShell function that you can use to pipe your message tracking log into and it will give you a more user friendly output. Instructions for use are below:

1 - Copy this PowerShell function into your Exchange Management Shell window:

function Get-MessageClientType
    {
        $MessageTrackingLog = @($input) | ? {$_.SourceContext -match "ClientType"}
        $Output = @()
        foreach ($Message in $MessageTrackingLog)
            {
                $ClientType = $Message.SourceContext -split "," | ? {$_ -match "ClientType"}
                $ClientType = $ClientType -replace (" ClientType:","")             
                $OutputLine = New-Object System.Object
                $OutputLine | Add-Member -Type NoteProperty -Name TimeStamp -Value $Message.TimeStamp
                $OutputLine | Add-Member -Type NoteProperty -Name Sender -Value $Message.Sender
                $OutputLine | Add-Member -Type NoteProperty -Name Recipients -Value $Message.Recipients
                $OutputLine | Add-Member -Type NoteProperty -Name MessageSubject -Value $Message.MessageSubject
                $OutputLine | Add-Member -Type NoteProperty -Name ClientType -Value $ClientType
                $Output += $OutputLine
            }
        $Output
    }


2 - Use Get-MessageTrackingLog to get the messages you need and then pipe it into Get-MessageClientType to get the ClientType. See below:

Get-MessageTrackingLog -Start "11/24/2015 10:00" -Recipients administrator@litwareinc.com -ResultSize Unlimited | Get-MessageClientType | ft

image

You can also use this command to get all the emails sent using one of the client types. See below for how to get just the emails sent using ActiveSync clients: 

Get-MessageTrackingLog -Start "11/24/2015 10:00" -Recipients administrator@litwareinc.com -ResultSize Unlimited | Get-MessageClientType | ? {$_.ClientType -eq "AirSync"} | ft


Conclusion


In this post, we've gone through how to identify whether an email was sent using Outlook, OWA or ActiveSync. This should prove to be quite useful when troubleshooting users' email issues. 

Thursday, 26 November 2015

Exchange 2016 - Create new OWA virtual directory

See below instructions on how to recreate the OWA Virtual Directory on Exchange 2016 or Exchange 2013.


Remove the OWA virtual directory


To remove the OWA virtual directory on server litex02, run the command below then press Y when prompted.

Get-OwaVirtualDirectory -Server litex02 | Remove-OwaVirtualDirectory

clip_image004


Create a new the OWA virtual directory:


To create a new OWA virtual directory on server litex02, run the command below:

New-OwaVirtualDirectory -Server litex02 -InternalUrl https://mail.litwareinc.com/owa -ExternalUrl https://mail.litwareinc.com/owa

clip_image005

This resolves a number of issues with OWA and is a helpful thing to know as it’s often quicker to do this than to troubleshoot some issues.








Wednesday, 25 November 2015

Exchange 2016 Mailbox Database Whitespace

You can use either the Get-MailboxDatabase cmdlet or eseutil to figure out how much whitespace there is in your Exchange 2010, 2013 or 2016 mailbox database. Below I’ll demonstrate how to use both methods.


Get-MailboxDatabase


If we run the Get-MailboxDatabase cmdlet with the status switch, we can get an estimate of whitespace.

Get-MailboxDatabase "Mailbox Database 1051570769" -Status | fl Name,AvailableNewMailboxSpace

image

Here we can see an estimate of 105.1MB of whitespace in the database.


Eseutil /ms


The most accurate method is to use eseutil with the /ms switch. The /m switch specifies that we want to run eseutil in file dump mode where we will get attributes of various files. The /m mode includes a modifier and in our case we will use ‘s’ which dumps the space usage of the database.

The disadvantage is this command requires the database to be offline.

1) Dismount the database by running this command:

Dismount-Database "Mailbox Database 1051570769" -Confirm:$false

2) Run the eseutil /ms command:

eseutil /ms “C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 1051570769\Mailbox Database 1051570769.edb”

3) Mount your database again:

Mount-Database "Mailbox Database 1051570769" -Confirm:$false

Below you can see all three commands running in one go which only dismounts the database for a few seconds:

image

There’s a lot more information when using eseutil but I’ve highlighted the whitespace which is 105.063MB. You can see that the operation completed successfully in 2 seconds to run so you don’t need much downtime for this.

Automating eseutil /ms

I think I have a bit of a problem in that whenever I see more than one PowerShell command, I have to write it into a function. Here goes then. This function will get the whitespace for a particular mailbox database that you specify. It also works out the mailbox database path and passes this to eseutil so you only need to tell it the database name. Ensure you use a database on the same server as you’re running the command as eseutil can’t run remotely.

1) Copy the below function and paste into your Exchange Management Shell window:

function Get-MailboxDatabaseWhiteSpace
    {
        Param(
        [Parameter(Mandatory = $true)]
        [string] $Database
        )

        $MDB = Get-MailboxDatabase $Database
        Write-Host Dismounting $Database -ForegroundColor Green
        Dismount-Database $MDB -Confirm:$false
        eseutil /ms $MDB.EdbFilePath
        Write-Host Mounting $Database -ForegroundColor Green
        Mount-Database $MDB
    }


2) Run the function using the command below:

Get-MailboxDatabaseWhiteSpace -Database "Mailbox Database 1051570769"

image

Now you know how to accurately figure out how much whitespace you have.

Tuesday, 24 November 2015

Exchange 2016 - Search-AdminAuditLog

This cmdlet helps answer the age old questions: Who deleted that distribution group? Who deleted that mailbox? Who changed that setting? This applies to Exchange 2013 and Exchange 2016.

Unknown by some but Exchange has auditing enabled for all tasks, whether you use PowerShell or the Exchange Admin Center to perform the task and you can search this audit log using the Search-AdminAuditLog cmdlet. Make sure you are a member of the Organization Management or Records Management groups or have the View-Only Audit Logs role assigned.


Who deleted a Distribution Group?


In this example, we’ll look for all the instances where a distribution group called finance was deleted. We’ll search for all entries since midnight on 19th November 2015:

Search-AdminAuditLog -Cmdlets Remove-DistributionGroup -StartDate "11/19/2015 00:00" | ? {$_.ObjectModified -match "finance"}

image


Here we can see that the Administrator user (see the Caller property) has deleted the Finance distribution group which was originally in the path litwareinc.com/Users/Finance (ObjectModified property) at 19/11/2015 22:24.


Who changed a setting?


In this example, we are looking for the user who changed any of the InternalDNSServers settings on the transport server configuration:

Search-AdminAuditLog -Cmdlets Set-TransportService -Parameters InternalDNSServers

image

Here we can see that there are two entries in the log but it would be great if we could get the exact values that were used. To do this, run the command below:

Search-AdminAuditLog -Cmdlets Set-TransportService -Parameters InternalDNSServers | % {$_;$_.CmdletParameters}

image

Here we can see the audit log entry followed by the parameters used when the command was run just after it. To explain the above example - the Administrator user set the InternalDNSServers parameter to 4.2.2.2 on LITEX02 at 14:36 on 15/11/2015 then at 14:40 on the same day, he set the InternalDNSServers parameter back to null.

Quite a useful way to tell what was done to a server in case there are issues after a change is made.


What did that administrator do?


In this next example, I’ll demonstrate how to figure out all the tasks the administrator user or another user has performed since 14th November. Run this command:

Search-AdminAuditLog -UserIds Administrator -StartDate "11/14/2015 00:00" | FT RunDate,OriginatingServer,CmdletName,Succeeded

image

Here you can see all the cmdlets the Administrator user has run. Note that you can see which commands were run on all servers in the organization. In this organization there is an Exchange 2016 server, LITEX02 and an Exchange 2013 server, LITEX01.


Conclusion


In this post, I’ve demonstrated how to search the admin audit log to find out who has deleted objects or changed settings from within the Exchange Admin Center or the Exchange Management Shell. This applies to both Exchange 2013 and 2016.

Monday, 23 November 2015

Your message wasn't delivered because the recipient's e-mail provider rejected it

The full error message is below:

#< #5.7.133 smtp;550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup; authentication required; Delivery restriction check failed because the sender was not authenticated when sending to this group> #SMTP#

In this case, an email was sent to a distribution group and the problem is that the distribution group was created with default settings which means it doesn't receive email from external senders. Yes, you read that right. You can even see it in a picture. See below:

image

To allow senders inside and outside your organization to send email to that group, check the box “Senders inside and outside of my organization” then click save. 

You can also make this change using PowerShell as below:

Set-DistributionGroup Finance -RequireSenderAuthenticationEnabled $false

image

Now you should be able to send to this group.

Thursday, 19 November 2015

Outlook 2013 - Allow this website to configure server settings?

When using the SRV autodiscover method, you may get this warning when Outlook is started up:

“Your account was redirected to this website for settings. You should only allow settings from sources you know and trust.”

image_thumb20

This will pop up every time that Outlook opens and periodically while Outlook is running. This is because Outlook has found our autodiscover SRV record that is configured for the email domain litwareinc.com. In this case, the SRV record is _autodiscover._tcp.litwareinc.com. For more information about configuring SRV records for autodiscover, see here.

The server we have configured in the SRV record is mail.litwareinc.com and this is the same server we can see in the notification above.

The warning is expected and can be safely ignored or suppressed. To suppress the error, we need to add a registry value in each user’s registry. 

First, open up regedit then browse to the RedirectServers subkey using the path relevant to the version of Outlook you’re using:

Outlook 2010:

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover\RedirectServers

Outlook 2013:

HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\AutoDiscover\RedirectServers

image

As you can see, by default there are entries for autodiscover.hotmail.com and autodiscover-s.outlook.com.

Next, right click and create a new string value with the name of the server we are redirecting to in the SRV record, in our case this is mail.litwareinc.com.

image

Once done, you should no longer be prompted with this warning.

Ok, that’s great but what happens if you have a few thousand machines across the business that need this change. In that case, you can make the changes above then export the RedirectServers registry subkey to a .reg file then deploy it in a user logon script or using Group Policy Preferences.

To use a logon script, add this line to the script where \\server\share\RedirectServers.reg is the path to your exported registry key:

regedit.exe /s \\server\share\RedirectServers.reg

If you want to use Group Policy Preferences then create a new Group Policy Object and link it to your user OU. Once done, browse to User Configuration\Preferences\Windows Settings\Registry and create a new registry item with the below settings:

Action: Update
Hive: HKEY_CURRENT_USER
Key Path: Software\Microsoft\Office\15.0\Outlook\AutoDiscover\RedirectServers
Value name: mail.litwareinc.com
Value type: REG_SZ

image

You’re now able to deploy your fix.

Wednesday, 18 November 2015

Exchange 2013, 2016 - Connecting to remote server failed with the following error message

Yesterday I saw an issue where the Exchange Management Shell wouldn't connect so thought I'd replicate it in my lab and let you know how to fix it. The error is below:

New-PSSession : [litex01.litwareinc.com] Connecting to remote server litex01.litwareinc.com failed with the following error message : [ClientAccessServer=LITEX01,BackEndServer=litex01.litwareinc.com,RequestId=357032aa-2312-477e-be88-8d99 db9027c5,TimeStamp=18/11/2015 00:40:28] [FailureCategory=Cafe-SendFailure]  For more information, see the about_Remote_Troubleshooting Help topic.

image

After looking through the event logs, I came across this event which provides a bit more information:

Event ID:      15021
An error occurred while using SSL configuration for endpoint 0.0.0.0:444.  The error status code is contained within the returned data.


image

As I can’t get into the Exchange Management Shell to check the Exchange certificate assignment, I moved on to check IIS. Both the Default Web Site and the Exchange Back End website need to have this certificate assigned. In IIS, you can’t have both sites listening on port 443 without a hostname configured so Microsoft have got around this so that when Exchange is installed, the Exchange Back End web site actually has a binding of port 444 for HTTPS which matches the event above. So, we’ll go ahead and check that this web site has the correct certificate configured in the bindings.

To check this, first open up IIS Manager:

image

Then right click on the Exchange Back End and click on Bindings:

image

Double click on https and ensure that there is a certificate selected:

image

As you can see, there’s no certificate selected. Go ahead and select the correct certificate:

image

Once done, click on OK then click Close. Close and reopen the Exchange Management Shell and now things look much better:

image

Outlook and OWA should now start to work also. All the best!

Tuesday, 17 November 2015

Exchange 2013, 2016 - Zen Spamhaus RBL not working

Zen Spamhaus give you a way of testing whether your block list transport agent is working. An interesting scenario can occur where this doesn’t work.


How to test your Block List Provider is working?


To test that your Zen Spamhaus block list provider is working, send an email from your Exchange account to nelson-sbl-test@crynwr.com. It’ll attempt to send you an email from a blacklisted IP and then send you the SMTP conversation by email. You should get a reply back like below:


Testing your SBL block. See http://www.crynwr.com/spam/ for more info.

Testing your SBL block. See http://www.crynwr.com/spam/ for more info.

Please note that this test will not tell you if your server is open for relaying. Instead, it tests to see if your server blocks email from IP addresses listed in various blocking lists; in this case, the SBL list.

Here's how the conversation looked from sbl.crynwr.com.

Note that some sites don't apply the SBL block to postmaster, so I use your envelope sender as the To: address.

I connected to <your IP> and here's the conversation I had:

220 server.domain.com Microsoft ESMTP MAIL Service ready at Tue, 25 Aug 2015 15:38:07 +0100 helo sbl.crynwr.com
250 server.domain.com Hello [192.203.178.107] mail from:<>
250 2.1.0 Sender OK
rcpt to:<mark@mydomain.co.uk>
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
From: nelson-SBL-test@crynwr.com
To: mark@mydomain.co.uk
Date: Tue, 25 Aug 2015 14:38:22 -0000
Message-Id: <1440513502@sbl.crynwr.com>
Precedence: junk
Test message
250 2.6.0 <1440513502@sbl.crynwr.com> [InternalId=219] Queued mail for delivery quit Successful termination. As far as I can tell, the email was delivered. That might not be what you want.


As you can see, the email was delivered. That’s definitely not what we want.  


How to fix the Zen SpamHaus block list provider?


The problem here is that our internal DNS server is using a DNS forwarder that cannot resolve the names we require. The way it needs to work is that when your Exchange server receives a connection from an IP which is submitting an email, it does a DNS forward lookup on <the IP in reverse>.zen.spamhaus.org.

To demonstrate a failed DNS lookup for Zen SpamHaus, we can do a lookup for 2.0.0.127.zen.spamhaus.org (127.0.0.2 in reverse) on Google’s DNS servers like below:

nslookup
server 8.8.8.8
2.0.0.127.zen.spamhaus.org

image

As you can see above, this fails: Non-existent domain

If we change the DNS server to use one of the domain controllers (192.168.0.8) that is configured to use the root hints and no forwarders then this works:

nslookup
server 192.168.0.8
2.0.0.127.zen.spamhaus.org

image

We can now go ahead and send another test email to nelson-sbl-test@crynwr.com and we get a response as below to say that the email is blocked as it was found on an RBL:



Testing your SBL block. See http://www.crynwr.com/spam/ for more info.

Please note that this test will not tell you if your server is open for relaying. Instead, it tests to see if your server blocks email from IP addresses listed in various blocking lists; in this case, the SBL list.

Here's how the conversation looked from sbl.crynwr.com.

Note that some sites don't apply the SBL block to postmaster, so I use your envelope sender as the To: address.

I connected to <your IP> and here's the conversation I had:
220 server.domain.com Microsoft ESMTP MAIL Service ready at Thu, 12 Nov 2015 21:50:20 +0000 helo sbl.crynwr.com
250 server.domain.com Hello [192.203.178.107] mail from:<>
250 2.1.0 Sender OK
rcpt to:<mark@mydomain.co.uk>
550 5.7.1 Recipient not authorized, your IP has been found on a block list Terminating conversation



This looks much better. All the best!

Monday, 16 November 2015

Exchange 2013, 2016 - Autodiscover with multiple domains and single name certificate

When setting up multiple email domains, you require a namespace for the Exchange CAS services such as OAB, EWS, Outlook Anywhere and you also need an autodiscover.domain.com A record for each domain that you require autodiscover for. In this post, I’ll demonstrate how you can configure Autodiscover for multiple domains while using only a single name on your certificate.

Background on the SRV autodiscover method


Outlook can use different methods to find the autodiscover response - see here. One of these methods uses an SRV record such as _autodiscover._tcp.domain.com to provide the hostname of your Exchange server such as mail.litwareinc.com. The Outlook client then retrieves the autodiscover XML file using the URL https://mail.litwareinc.com/autodiscover/autodiscover.xml. As you can see, there is no HTTPS connection made to https://autodiscover.domain.com and therefore there is no need for this name on the certificate.

Lab setup


In this demonstration, we have an Exchange 2013 and 2016 server in the organization. The accepted domains are below:

  • litwareinc.com
  • litwareinc-marketing.com
  • litwareinc-sales.com

Our certificate only has a single name - mail.litwareinc.com and all virtual directories, our Service Connection Points (AutodiscoverServiceInternalUri) and Outlook Anywhere hostnames/URLs are all configured to use mail.litwareinc.com.

Create the SRV records


For more information on how to create SRV records, see here. For our domains, we need to create the same SRV record in each of the forward lookup zones on our internal and external DNS servers. The SRV record we need is below:

Service: _autodiscover
Protocol: _tcp
Port Number: 443
Host: mail.litwareinc.com
Priority: 0
Weight: 0

Confirm that the SRV records are set up correctly using nslookup


Run the below commands to check that the SRV record is created correctly:

nslookup
set q=srv
server 10.2.0.10 (this needs to be one of your internal DNS servers)
_autodiscover._tcp.litwareinc.com
_autodiscover._tcp.litwareinc-marketing.com
_autodiscover._tcp.litwareinc-sales.com

image

Repeat the above test but set the server to a public DNS server such as 8.8.8.8 so that you can check your public SRV records are created successfully.

Remove the autodiscover.domain.com A records


Outlook clients will attempt to connect to https://autodiscover.domain.com/autodiscover/autodiscover.xml before they attempt the SRV method. This will cause certificate errors as this name is not on the certificate. To prevent this, you need to remove the A records below:

  • autodiscover.litwareinc.com
  • autodiscover.litwareinc-marketing.com
  • autodiscover.litwareinc-sales.com

Test autodiscover


To test autodiscover, we’ll use a mailbox that only has an email address in the litwareinc-marketing.com domain. If the computer is joined to the domain then it will use the SCP which is mail.litwareinc.com and this should work. In this case, we want to test the SRV method so our computer needs to either be in a workgroup or outside the corporate network. In this case, it is inside the corporate network but is in a workgroup.

Below I’ll demonstrate that autodiscover works by creating a new Outlook profile:

image

We receive a notification that we will be redirected to https://mail.litwareinc.com/autodiscover/autodiscover.xml to configure server settings. To prevent being prompted for this, select the “Don’t ask me about this website again” checkbox:

image

image

As you can see above, our Outlook profile has now been autoconfigured successfully.

Note that using this method means that your users will need to use https://mail.litwareinc.com/owa for Outlook Web Access and that mobile devices need to be configured using mail.litwareinc.com.











Friday, 13 November 2015

Outlook 2013 repeated reconnect attempts with Exchange 2013 or Exchange 2016 MAPI/HTTP

There are reports of performance issues and repeated reconnects when using Outlook 2013 and MAPI over HTTP in Exchange 2013. The problem is that the header that the server uses to specify the connection keep-alive period as the server is processing the request is ignored by the client. 

This is fixed in the November 2015 update for Outlook 2013, KB3101488: https://support.microsoft.com/en-us/kb/3101488.

For more information about MAPI over HTTP and how to configure it, see here.

Thursday, 12 November 2015

Exchange 2013, 2016 - Single name certificate

Is it possible to configure Exchange 2010, 2013 or 2016 to use a single name certificate?


The answer is yes but I guess you'll want a little more information.

It's possible to configure all your virtual directory URLs, Outlook Anywhere and the AutodiscoverServiceInternalUri to use the same hostname, for example mail.litwareinc.com. 

Let's say we have configured our namespace for all services to use mail.litwareinc.com.

The problem comes when Outlook performs autodiscover and needs to connect to https://autodiscover.litwareinc.com/autodiscover/autodiscover.xml because you'll get a certificate warning as autodiscover.litwareinc.com is not on the certificate.

To get around this issue, you simply prevent Outlook using this method to find the autodiscover response by removing the A record and enable another method using an SRV record. Using this method, you configure an SRV record _autodiscover._tcp.litwareinc.com which directs Outlook to connect to mail.litwareinc.com. Autodiscover.litwareinc.com is not required on the certificate. 

For more information about configuring the SRV method for autodiscover, see here.

Wednesday, 11 November 2015

Exchange 2013, 2016 - Autodiscover SRV record

In this post, I’ll demonstrate how to configure Exchange 2013 or 2016 to use an autodiscover SRV record instead of an A record.


How does an SRV record work with Exchange and Outlook?


Outlook 2007 and higher will attempt a number of different methods to find the autodiscover settings for your particular domain. The methods are tried in the order below and once an autodiscover response is received, no further methods are tried. In this example, our domain is litwareinc.com:
  1. Attempt to connect to the Service Connection Point in Active Directory. (This is configured using the Set-ClientAccessServer and the AutodiscoverServiceInternalUri parameter and specifies the URL to the autodiscover.xml file. It only works for domain-joined computers)
  2. Attempt to connect to https://litwareinc.com/autodiscover/autodiscover.xml
  3. Attempt to connect to https://autodiscover.litwareinc.com/autodiscover/autodiscover.xml 
  4. Attempt to locate the autodiscover.xml URL using the SRV method. (NB: Outlook 2007 requires the June 2007 update rollup: https://support.microsoft.com/en-us/kb/940881)
If none of these methods provides a valid autodiscover response then autodiscover fails.


What is an SRV record?


An example of an SRV record for Exchange 2010, 2013 or 2016 is below. In this example, our Exchange server namespace is mail.litwareinc.com.

Service: _autodiscover
Protocol: ._tcp
Port Number: 443
Host: mail.litwareinc.com
Priority: 0
Weight: 0

The Service name specifies the name of the service. For Exchange Autodiscover, this must be _autodiscover.

The Protocol informs the client whether this service uses TCP or UDP.


The Port number informs the client which port to connect on. 


The Host informs the client of the hostname it should be connecting to for this particular service. 


The Priority specifies which target server the client should connect to first. If two target servers have the same priority then the client looks at the weight for each and decides which to connect to based on which has the highest weight.


The Weight specifies the relative weight when priorities are the same. Larger weights have proportionately higher probability of being selected.



Remove the autodiscover A record


Removing the autodiscover.litwareinc.com A record means that clients will not be able to connect to this address. This is helpful as we now no longer need autodiscover.litwareinc.com as a name on our certificate and can use a single name certificate for Exchange to cut costs and simplify the namespace. 


Do I need autodiscover names on my certificate?


No, as long as there is no autodiscover.litwareinc.com A record in internal or external DNS, there is no need for this name on the certificate. As the client cannot resolve the IP, there is no way it can connect using this name. The client will then use the next method in the search for the autodiscover settings.




How to create an SRV record


Before you do this, ensure that you have set up an A record for mail.litwareinc.com in your internal and external DNS.

You need to create an SRV record in both your internal and external DNS. Use your DNS provider documentation to get instructions on how to set this SRV record up in you external DNS.

To create an SRV record in internal DNS, go through the steps below:

1) Log into a domain controller which hosts the litwareinc.com zone

2) Right click on the litwareinc.com zone and select Other New Records

image

3) Select Service Location (SRV) from the list

image

4) Click Create Record, enter the details below then click OK:

Service: _autodiscover
Protocol: _tcp
Port Number: 443
Host: mail.litwareinc.com
Priority: 0
Weight: 0

image

6) Check that your record appears by clicking on the _tcp subdomain under the litwareinc.com zone:

image

5) Check that your record was created successfully using nslookup

To do this, use the commands below:

nslookup
set q=srv
_autodiscover._tcp.litwareinc.com

image

Above, we can see that the SRV record exists and that it has provided the host mail.litwareinc.com.

Test Autodiscover


To check that it works, I have a client running Outlook 2013 that is not on the domain and we’ll go ahead and create a new Outlook profile:

image

image

image

We can see that we get this notification which states that we are redirected to mail.litwareinc.com which is as per our SRV record. 

image

We can select “Don’t ask me about this website again” so we are no longer prompted or you can add a registry entry to allow redirections to mail.litwareinc.com without prompting. See here for instructions on how to do that using regedit or deploy the setting using logon scripts or Group Policy.

image

This has worked and the account is set up correctly. We didn’t get an error to state that autodiscover.litwareinc.com is not on the certificate because this name is not used in the process.


Confirm settings using Outlook Test E-mail AutoConfiguration tool


To use this tool, see here. The results of the test can be seen below where we are getting a valid response:

image

If we click on the log tab, we can see the process that Outlook went through to get the autodiscover response. It fails on a number of different methods then eventually attempts the SRV record lookup and this provides the response.

image