Brand Representative for AJ Tek
Mar 30, 2018 - This article describes the process of creating new Outlook profiles (initially for a new Exchange mailbox) from the Office 365 edition of Outlook. E-mail clients that make use of Autodiscover includes Outlook 2007, Outlook 2010, Outlook 2013/16, Outlook 2011, Mac Mail, Entourage 2008 WSE and many.
I'm not sure if you've been through my guide, but it is a pretty comprehensive guide and may just fix this.
You need to make sure your OutlookAnywhere and AutoDiscover settings are setup properly along with Split-DNS. OutlookAnywhere and Split-DNS are vital for future-proofing your Exchange configuration and making it work properly now, regardless if you use Exchange 2007, 2010, 2013, or 2016. For Exchange 2013+, OutlookAnywhere is a requirement and Split-DNS is Best Practice. If you are on Exchange 2007 or 2010, and you do not have OutlookAnywhere enabled, enable OutlookAnywhere and follow this guide.
First thing is first, make a backup of your environment's configuration. Run the following commands in Exchange Management Shell to backup your configuration. Don't forget to change the RESOLVE-DNSNAME commands at the bottom so that they reflect your current OWA URL hostname and the Autodiscover record for your external domain name. The Start-Transcript/Stop-Transcript lines will output all of this to a text file in the current folder, as well as on screen.
Start-Transcript EnvironmentBackup.txt
Get-OutlookProvider | Format-List
Get-OutlookAnywhere | Format-List
Get-ClientAccessServer | Format-List
Get-ActiveSyncVirtualDirectory | Format-List
Get-AutodiscoverVirtualDirectory | Format-List
Get-EcpVirtualDirectory | Format-List
Get-OabVirtualDirectory | Format-List
Get-OwaVirtualDirectory | Format-List
Get-PowerShellVirtualDirectory | Format-List
Get-WebServicesVirtualDirectory | Format-List
Get-SendConnector | Where-Object {$_.Enabled -eq $true} | Format-List
Get-SendConnector | Where-Object {$_.Enabled -eq $true} | Get-ADPermission | Where-Object { $_.extendedrights -like '*routing*' } | fl identity, user, *rights
Resolve-DnsName -Type A -Name mail.domain.com
Resolve-DnsName -Type A -Name autodiscover.domain.com
Resolve-DnsName -Type A -Name mail.domain.com -Server 8.8.8.8
Resolve-DnsName -Type A -Name autodiscover.domain.com -Server 8.8.8.8
Resolve-DnsName -Type MX -Name domain.com -Server 8.8.8.8
Resolve-DnsName -Type TXT -Name domain.com -Server 8.8.8.8
Resolve-DnsName -Type A -Name i-should-not-exist.domain.com -Server 8.8.8.8
Stop-Transcript
NOTE: If you get errors on the Resolve-DnsName commands, please use the following NSLookup Commands instead.
nslookup -type=a mail.domain.com
nslookup -type=a autodiscover.domain.com
nslookup -type=a mail.domain.com 8.8.8.8
nslookup -type=a autodiscover.domain.com 8.8.8.8
nslookup -type=mx domain.com 8.8.8.8
nslookup -type=txt domain.com 8.8.8.8
nslookup -type=a i-should-not-exist.domain.com 8.8.8.8
Now that we have an Environment Backup, let's proceed with the steps to fix your environment.
As DNS is a vital component in any network, please make sure that Split-DNS is setup first before doing anything else. To make sure Split-DNS is working properly, review the Environment Backup - The 7 Resolve-DnsName commands at the end.
The first 2 Resolve-DnsName commands should both respond from an internal computer to the internal IP of your Exchange server (eg. 192.168.1.55).
To fix the internal records, the easiest way to do this is to create a DNS Zone (Active Directory - Integrated) for mail.domain.com (assuming that is your OWA URL) and then create a blank A Record and point it to your internal IP Address for your mail server (eg. 192.168.1.55). Then create another DNS Zone (Active Directory - Integrated) for autodiscover.domain.com and create a blank A record and point it to the internal IP Address of your mail server (eg. 192.168.1.55).
The next 2 Resolve-DnsName commands should both respond externally (Via Google's DNS) to your external IP of the mail server (eg. 38.55.11.55).
To fix the external records (more than likely, autodiscover is the one that doesn't exist and needs to be created), on your domain's external DNS Manager create an A record for autodiscover.domain.com and point it to the external IP of your mail server (eg. 38.55.11.55).
The 5th Resolve-DnsName command will show you your MX records on the internet. MX Records should NOT point to an IP Address as stated in RFC1035 (https://tools.ietf.org/html/rfc1035#section-3.3.9). They should have a priority at the beginning where the lowest number is the preference. If you are directing inbound mail traffic to an Anti-Spam 3rd party provider, this will be the hostname(s) associated with them. In the case of an onsite appliance, create a new A record called inbound.domain.com and give it the IP for your Anti-Spam Appliance, and then set the MX Records to 10 inbound.domain.com.
The 6th Resolve-DnsName command will show you your TXT records - these records are used for extra information in DNS, and one of the extra pieces of information you should have in there is an SPF record. A Sender Policy Framework (SPF) record identifies which mail servers are permitted to send email on behalf of your domain. The purpose of an SPF record is to prevent spammers from sending messages with forged From addresses at your domain. If your domain does not have an SPF record, some recipient domains may reject messages from your users because they cannot validate that the messages come from an authorized mail server. You should use an SPF Generator to get the proper syntax for your SPF Record (https://www.google.ca/search?q=SPF+Generator).
And the 7th Resolve-DnsName command should respond that this record does NOT EXIST. If it does resolve to an IP, there is likely a wildcard record on your domain (*.domain.com) that is pointing to your webserver. Some webhosting companies do this for subdomain management instead of putting an explicit hostname in their DNS records. It actually causes more problems than it fixes, so where possible, you should log into your domain's external DNS Manager and remove the wildcard record.
After Split-DNS is confirmed working, the next things to check and fix are the Virtual Directories and the Client Access Server Autodiscover URI. All InternalUrl and ExternalUrl's should be setup using the hostname mail.domain.com (assuming mail.domain.com is the OWA URL that you chose). You should always use NTLM over Basic authentication as Basic sends the username and password in the clear, and NTLM doesn't as it is Windows Authentication. On Exchange 2013+, you also have a new option called Negotiate, which is recommended, but if you have Outlook 2010 and Outlook 2007 clients, keep it with NTLM for backwards compatibility. For futureproofing, please also turn on SSLOffloading for OutlookAnywhere which is enabled by default on Exchange 2013+ (https://technet.microsoft.com/en-ca/library/dn635115(v=exchg.150).aspx#OA).
For Exchange 2007/2010
Set-OutlookAnywhere -Identity 'SERVERRpc (Default Web Site)' -SSLOffloading $true -ClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM
For Exchange 2013+ with backwards compatibility with Outlook 2010 and 2007
Set-OutlookAnywhere -Identity 'SERVERRpc (Default Web Site)' -SSLOffloading $true -ExternalClientAuthenticationMethod NTLM -InternalClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM,Negotiate
For Exchange 2013+ with Outlook 2013+
Set-OutlookAnywhere -Identity 'SERVERRpc (Default Web Site)' -SSLOffloading $true -ExternalClientAuthenticationMethod Negotiate- InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Basic,NTLM,Negotiate
Now that we've got OutlookAnywhere configured, let's configure the OutlookProvider settings. By default three Outlook Providers are used to configure settings individually for Exchange RPC protocol or internal clients (EXCH), Outlook Anywhere (EXPR) and WEB.
The EXCH setting references the Exchange RPC protocol that is used internally. This setting includes port settings and the internal URLs for the Exchange services that you have enabled.
The EXPR setting references the Exchange HTTP protocol that is used by Outlook Anywhere. This setting includes the external URLs for the Exchange services that you have enabled, which are used by clients that access Exchange from the Internet.
The WEB setting contains the best URL for Outlook Web Access for the user to use. This setting is not in use.
To harden security, it is best practice to set the CertPrincipalName for each of the Outlook Providers (it is also required if you have any lingering XP Clients that will use Outlook). This will make sure that only a certificate with a specific subject name will be accepted.
Set the CertPrincipalName for the OutlookProvider settings.
Set-OutlookProvider -Identity EXCH -CertPrincipalName msstd:(Subject name of certificate)
Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:(Subject name of certificate)
Set-OutlookProvider -Identity WEB -CertPrincipalName msstd:(Subject name of certificate)
Set the Client Access Server's Autodiscover record to the OWA Hostname:</p>
Set-ClientAccessServer -Identity 'SERVER' -AutoDiscoverServiceInternalUri 'https://OWAHOSTNAME/Autodiscover/Autodiscover.xml'
Set all VirtualDirectories (VDs) to the OWA Hostname using HTTPS except for the AutodiscoverVirtualDirectory which gets set to blank ($null) for InternalURL and ExternalURL. We will also turn on -RequireSSL for OWA and PowerShell VDs. We also will set the InternalNLBBypassUrl to $null. For most this works fine, however if you are using multiple exchange servers in an NLB Cluster or crossing Active Directory sites, don't set that to null. More information here: https://blogs.technet.microsoft.com/exchange/2008/07/18/ews-cas-to-cas-request-proxying/
Set-ActiveSyncVirtualDirectory -Identity 'SERVERMicrosoft-Server-ActiveSync (Default Web Site)' -ActiveSyncServer 'https://OWAHOSTNAME/Microsoft-Server-ActiveSync' -InternalUrl 'https://OWAHOSTNAME/Microsoft-Server-ActiveSync' -ExternalUrl 'https://OWAHOSTNAME/Microsoft-Server-ActiveSync'
Set-EcpVirtualDirectory -Identity 'SERVERecp (Default Web Site)' -InternalUrl 'https://OWAHOSTNAME/ecp' -ExternalUrl 'https://OWAHOSTNAME/ecp'
Set-OabVirtualDirectory -Identity 'SERVEROAB (Default Web Site)' -InternalUrl 'https://OWAHOSTNAME/OAB' -ExternalUrl 'https://OWAHOSTNAME/OAB' -RequireSSL $true
Set-OwaVirtualDirectory -Identity 'SERVERowa (Default Web Site)' -InternalUrl 'https://OWAHOSTNAME/owa' -ExternalUrl 'https://OWAHOSTNAME/owa'
Set-AutodiscoverVirtualDirectory -Identity 'SERVERAutodiscover (Default Web Site)' -InternalUrl $null -ExternalUrl $null
Set-PowerShellVirtualDirectory -Identity 'SERVERPowerShell (Default Web Site)' -InternalUrl 'https://OWAHOSTNAME/powershell' -ExternalUrl 'https://OWAHOSTNAME/powershell' -RequireSSL $true
Set-WebServicesVirtualDirectory -Identity 'SERVEREWS (Default Web Site)' -InternalUrl 'https://OWAHOSTNAME/ews/exchange.asmx' -ExternalUrl 'https://OWAHOSTNAME/ews/exchange.asmx' -InternalNLBBypassUrl $null
Set the FQDN option of all the enabled Send Connectors:
Get-SendConnector | Where-Object {$_.Enabled -eq $true} | Set-SendConnector -Fqdn OWAHOSTNAME
If you have ever examined an email message header, you would have noticed that it contains internal Exchange server FQDN information and IP addresses. This exposes the AD domain details of your network to the outside world. To prevent this information from escaping your network onto the Internet, you can use the Exchange header firewall to hide the internal server information. You do this by taking away the rights to send the internal details in a message header (ms-Exch-Send-Headers-Routing) on the send connector you use to send email on the internet.
Remove ms-Exch-Send-Headers-Routing rights on ALL Active Send Connectors:
Get-SendConnector | Where-Object {$_.Enabled -eq $true} | Remove-ADPermission –User 'Nt AuthorityAnonymous Logon' –ExtendedRights 'ms-Exch-Send-Headers-Routing'
Remove ms-Exch-Send-Headers-Routing rights on specific Active Send Connectors:
Get-SendConnector -Identity CONNECTORNAME | Remove-ADPermission –User 'Nt AuthorityAnonymous Logon' –ExtendedRights 'ms-Exch-Send-Headers-Routing'
Restart IIS and the Microsoft Exchange Transport Services to make the changes take effect immediately.
Making OWA easily accessible to users:
Another thing that is really handy is to make OWA accessible by HTTP redirecting to HTTPS so that your users don't have to remember to type HTTPS. The easiest and the best way that I've found to do this is to edit the Default Website's Error Pages and set the 403 error to redirect to https://mail.domain.com/owa. You will need to re-apply this after every Cumulative Update (CU) that you perform as the CUs will revert these settings to defaults.
To do this:
1. Open IIS
2. Navigate to the Default Web Site on the left.
3. On the right, double-click on Error Pages
4. Double click on the 403 Status Code.
5. Change the Response Action to 'Respond with a 302 redirect' and in the Absolute URL: type in https://mail.domain.com/owa
6. Press OK and close IIS.
7. Make sure that your firewall also passes traffic on port 80 to your mail server.
8. In your browser, type in mail.domain.com and hit enter. It should find it and redirect you to the OWA Login.
SSL Certificates
If you don't already have a proper 3rd party certificate, I would suggest taking the plunge for $29.88 USD - https://www.namecheap.com/security/ssl-certificates/comodo/positivessl-multi-domain.aspx - NameCheap has PositiveSSL Multi-Domain certs with the first 3 hostnames included. You're going to need at least 2 - mail.domain.com (OWA URL, and Subject of the Cert) and autodiscover.domain.com (Subject Alternative Name - or SAN). A wildcard certificate will work, but a SAN certificate is best practice as if a wildcard certificate is compromised, any name can be secured, but if a SAN certificate is compromised, then only those hostnames specified can be secured.
The time it will take you to troubleshoot trying to use a self-signed certificate or one from an in-house CA (if you have one).. will cost your company more money in terms of time than just buying a certificate using the link I gave you above. Oh, and I don't make any commission or anything from that link - it's a direct link to the SSL Cert you need.
Also, for Exchange testing, (Autodiscover and Connectivity) you can use Microsoft's TestConnectivity site to help troubleshoot your issues.
https://testconnectivity.microsoft.com
First thing is first, make a backup of your environment's configuration. Run the following commands in Exchange Management Shell to backup your configuration. Don't forget to change the RESOLVE-DNSNAME commands at the bottom so that they reflect your current OWA URL hostname and the Autodiscover record for your external domain name. The Start-Transcript/Stop-Transcript lines will output all of this to a text file in the current folder, as well as on screen.
Start-Transcript EnvironmentBackup.txt
Get-OutlookProvider | Format-List
Get-OutlookAnywhere | Format-List
Get-ClientAccessServer | Format-List
Get-ActiveSyncVirtualDirectory | Format-List
Get-AutodiscoverVirtualDirectory | Format-List
Get-EcpVirtualDirectory | Format-List
Get-OabVirtualDirectory | Format-List
Get-OwaVirtualDirectory | Format-List
Get-PowerShellVirtualDirectory | Format-List
Get-WebServicesVirtualDirectory | Format-List
Get-SendConnector | Where-Object {$_.Enabled -eq $true} | Format-List
Get-SendConnector | Where-Object {$_.Enabled -eq $true} | Get-ADPermission | Where-Object { $_.extendedrights -like '*routing*' } | fl identity, user, *rights
Resolve-DnsName -Type A -Name mail.domain.com
Resolve-DnsName -Type A -Name autodiscover.domain.com
Resolve-DnsName -Type A -Name mail.domain.com -Server 8.8.8.8
Resolve-DnsName -Type A -Name autodiscover.domain.com -Server 8.8.8.8
Resolve-DnsName -Type MX -Name domain.com -Server 8.8.8.8
Resolve-DnsName -Type TXT -Name domain.com -Server 8.8.8.8
Resolve-DnsName -Type A -Name i-should-not-exist.domain.com -Server 8.8.8.8
Stop-Transcript
NOTE: If you get errors on the Resolve-DnsName commands, please use the following NSLookup Commands instead.
nslookup -type=a mail.domain.com
nslookup -type=a autodiscover.domain.com
nslookup -type=a mail.domain.com 8.8.8.8
nslookup -type=a autodiscover.domain.com 8.8.8.8
nslookup -type=mx domain.com 8.8.8.8
nslookup -type=txt domain.com 8.8.8.8
nslookup -type=a i-should-not-exist.domain.com 8.8.8.8
Now that we have an Environment Backup, let's proceed with the steps to fix your environment.
As DNS is a vital component in any network, please make sure that Split-DNS is setup first before doing anything else. To make sure Split-DNS is working properly, review the Environment Backup - The 7 Resolve-DnsName commands at the end.
The first 2 Resolve-DnsName commands should both respond from an internal computer to the internal IP of your Exchange server (eg. 192.168.1.55).
To fix the internal records, the easiest way to do this is to create a DNS Zone (Active Directory - Integrated) for mail.domain.com (assuming that is your OWA URL) and then create a blank A Record and point it to your internal IP Address for your mail server (eg. 192.168.1.55). Then create another DNS Zone (Active Directory - Integrated) for autodiscover.domain.com and create a blank A record and point it to the internal IP Address of your mail server (eg. 192.168.1.55).
The next 2 Resolve-DnsName commands should both respond externally (Via Google's DNS) to your external IP of the mail server (eg. 38.55.11.55).
To fix the external records (more than likely, autodiscover is the one that doesn't exist and needs to be created), on your domain's external DNS Manager create an A record for autodiscover.domain.com and point it to the external IP of your mail server (eg. 38.55.11.55).
The 5th Resolve-DnsName command will show you your MX records on the internet. MX Records should NOT point to an IP Address as stated in RFC1035 (https://tools.ietf.org/html/rfc1035#section-3.3.9). They should have a priority at the beginning where the lowest number is the preference. If you are directing inbound mail traffic to an Anti-Spam 3rd party provider, this will be the hostname(s) associated with them. In the case of an onsite appliance, create a new A record called inbound.domain.com and give it the IP for your Anti-Spam Appliance, and then set the MX Records to 10 inbound.domain.com.
The 6th Resolve-DnsName command will show you your TXT records - these records are used for extra information in DNS, and one of the extra pieces of information you should have in there is an SPF record. A Sender Policy Framework (SPF) record identifies which mail servers are permitted to send email on behalf of your domain. The purpose of an SPF record is to prevent spammers from sending messages with forged From addresses at your domain. If your domain does not have an SPF record, some recipient domains may reject messages from your users because they cannot validate that the messages come from an authorized mail server. You should use an SPF Generator to get the proper syntax for your SPF Record (https://www.google.ca/search?q=SPF+Generator).
And the 7th Resolve-DnsName command should respond that this record does NOT EXIST. If it does resolve to an IP, there is likely a wildcard record on your domain (*.domain.com) that is pointing to your webserver. Some webhosting companies do this for subdomain management instead of putting an explicit hostname in their DNS records. It actually causes more problems than it fixes, so where possible, you should log into your domain's external DNS Manager and remove the wildcard record.
After Split-DNS is confirmed working, the next things to check and fix are the Virtual Directories and the Client Access Server Autodiscover URI. All InternalUrl and ExternalUrl's should be setup using the hostname mail.domain.com (assuming mail.domain.com is the OWA URL that you chose). You should always use NTLM over Basic authentication as Basic sends the username and password in the clear, and NTLM doesn't as it is Windows Authentication. On Exchange 2013+, you also have a new option called Negotiate, which is recommended, but if you have Outlook 2010 and Outlook 2007 clients, keep it with NTLM for backwards compatibility. For futureproofing, please also turn on SSLOffloading for OutlookAnywhere which is enabled by default on Exchange 2013+ (https://technet.microsoft.com/en-ca/library/dn635115(v=exchg.150).aspx#OA).
For Exchange 2007/2010
Set-OutlookAnywhere -Identity 'SERVERRpc (Default Web Site)' -SSLOffloading $true -ClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM
For Exchange 2013+ with backwards compatibility with Outlook 2010 and 2007
Set-OutlookAnywhere -Identity 'SERVERRpc (Default Web Site)' -SSLOffloading $true -ExternalClientAuthenticationMethod NTLM -InternalClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM,Negotiate
For Exchange 2013+ with Outlook 2013+
Set-OutlookAnywhere -Identity 'SERVERRpc (Default Web Site)' -SSLOffloading $true -ExternalClientAuthenticationMethod Negotiate- InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Basic,NTLM,Negotiate
Now that we've got OutlookAnywhere configured, let's configure the OutlookProvider settings. By default three Outlook Providers are used to configure settings individually for Exchange RPC protocol or internal clients (EXCH), Outlook Anywhere (EXPR) and WEB.
The EXCH setting references the Exchange RPC protocol that is used internally. This setting includes port settings and the internal URLs for the Exchange services that you have enabled.
The EXPR setting references the Exchange HTTP protocol that is used by Outlook Anywhere. This setting includes the external URLs for the Exchange services that you have enabled, which are used by clients that access Exchange from the Internet.
The WEB setting contains the best URL for Outlook Web Access for the user to use. This setting is not in use.
To harden security, it is best practice to set the CertPrincipalName for each of the Outlook Providers (it is also required if you have any lingering XP Clients that will use Outlook). This will make sure that only a certificate with a specific subject name will be accepted.
Set the CertPrincipalName for the OutlookProvider settings.
Set-OutlookProvider -Identity EXCH -CertPrincipalName msstd:(Subject name of certificate)
Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:(Subject name of certificate)
Set-OutlookProvider -Identity WEB -CertPrincipalName msstd:(Subject name of certificate)
Set the Client Access Server's Autodiscover record to the OWA Hostname:</p>
Set-ClientAccessServer -Identity 'SERVER' -AutoDiscoverServiceInternalUri 'https://OWAHOSTNAME/Autodiscover/Autodiscover.xml'
Set all VirtualDirectories (VDs) to the OWA Hostname using HTTPS except for the AutodiscoverVirtualDirectory which gets set to blank ($null) for InternalURL and ExternalURL. We will also turn on -RequireSSL for OWA and PowerShell VDs. We also will set the InternalNLBBypassUrl to $null. For most this works fine, however if you are using multiple exchange servers in an NLB Cluster or crossing Active Directory sites, don't set that to null. More information here: https://blogs.technet.microsoft.com/exchange/2008/07/18/ews-cas-to-cas-request-proxying/
Set-ActiveSyncVirtualDirectory -Identity 'SERVERMicrosoft-Server-ActiveSync (Default Web Site)' -ActiveSyncServer 'https://OWAHOSTNAME/Microsoft-Server-ActiveSync' -InternalUrl 'https://OWAHOSTNAME/Microsoft-Server-ActiveSync' -ExternalUrl 'https://OWAHOSTNAME/Microsoft-Server-ActiveSync'
Set-EcpVirtualDirectory -Identity 'SERVERecp (Default Web Site)' -InternalUrl 'https://OWAHOSTNAME/ecp' -ExternalUrl 'https://OWAHOSTNAME/ecp'
Set-OabVirtualDirectory -Identity 'SERVEROAB (Default Web Site)' -InternalUrl 'https://OWAHOSTNAME/OAB' -ExternalUrl 'https://OWAHOSTNAME/OAB' -RequireSSL $true
Set-OwaVirtualDirectory -Identity 'SERVERowa (Default Web Site)' -InternalUrl 'https://OWAHOSTNAME/owa' -ExternalUrl 'https://OWAHOSTNAME/owa'
Set-AutodiscoverVirtualDirectory -Identity 'SERVERAutodiscover (Default Web Site)' -InternalUrl $null -ExternalUrl $null
Set-PowerShellVirtualDirectory -Identity 'SERVERPowerShell (Default Web Site)' -InternalUrl 'https://OWAHOSTNAME/powershell' -ExternalUrl 'https://OWAHOSTNAME/powershell' -RequireSSL $true
Set-WebServicesVirtualDirectory -Identity 'SERVEREWS (Default Web Site)' -InternalUrl 'https://OWAHOSTNAME/ews/exchange.asmx' -ExternalUrl 'https://OWAHOSTNAME/ews/exchange.asmx' -InternalNLBBypassUrl $null
Set the FQDN option of all the enabled Send Connectors:
Get-SendConnector | Where-Object {$_.Enabled -eq $true} | Set-SendConnector -Fqdn OWAHOSTNAME
If you have ever examined an email message header, you would have noticed that it contains internal Exchange server FQDN information and IP addresses. This exposes the AD domain details of your network to the outside world. To prevent this information from escaping your network onto the Internet, you can use the Exchange header firewall to hide the internal server information. You do this by taking away the rights to send the internal details in a message header (ms-Exch-Send-Headers-Routing) on the send connector you use to send email on the internet.
Remove ms-Exch-Send-Headers-Routing rights on ALL Active Send Connectors:
Get-SendConnector | Where-Object {$_.Enabled -eq $true} | Remove-ADPermission –User 'Nt AuthorityAnonymous Logon' –ExtendedRights 'ms-Exch-Send-Headers-Routing'
Remove ms-Exch-Send-Headers-Routing rights on specific Active Send Connectors:
Get-SendConnector -Identity CONNECTORNAME | Remove-ADPermission –User 'Nt AuthorityAnonymous Logon' –ExtendedRights 'ms-Exch-Send-Headers-Routing'
Restart IIS and the Microsoft Exchange Transport Services to make the changes take effect immediately.
Making OWA easily accessible to users:
Another thing that is really handy is to make OWA accessible by HTTP redirecting to HTTPS so that your users don't have to remember to type HTTPS. The easiest and the best way that I've found to do this is to edit the Default Website's Error Pages and set the 403 error to redirect to https://mail.domain.com/owa. You will need to re-apply this after every Cumulative Update (CU) that you perform as the CUs will revert these settings to defaults.
To do this:
1. Open IIS
2. Navigate to the Default Web Site on the left.
3. On the right, double-click on Error Pages
4. Double click on the 403 Status Code.
5. Change the Response Action to 'Respond with a 302 redirect' and in the Absolute URL: type in https://mail.domain.com/owa
6. Press OK and close IIS.
7. Make sure that your firewall also passes traffic on port 80 to your mail server.
8. In your browser, type in mail.domain.com and hit enter. It should find it and redirect you to the OWA Login.
SSL Certificates
If you don't already have a proper 3rd party certificate, I would suggest taking the plunge for $29.88 USD - https://www.namecheap.com/security/ssl-certificates/comodo/positivessl-multi-domain.aspx - NameCheap has PositiveSSL Multi-Domain certs with the first 3 hostnames included. You're going to need at least 2 - mail.domain.com (OWA URL, and Subject of the Cert) and autodiscover.domain.com (Subject Alternative Name - or SAN). A wildcard certificate will work, but a SAN certificate is best practice as if a wildcard certificate is compromised, any name can be secured, but if a SAN certificate is compromised, then only those hostnames specified can be secured.
The time it will take you to troubleshoot trying to use a self-signed certificate or one from an in-house CA (if you have one).. will cost your company more money in terms of time than just buying a certificate using the link I gave you above. Oh, and I don't make any commission or anything from that link - it's a direct link to the SSL Cert you need.
Also, for Exchange testing, (Autodiscover and Connectivity) you can use Microsoft's TestConnectivity site to help troubleshoot your issues.
https://testconnectivity.microsoft.com
Hi,
We are having issues since a former update (since 2-4 months I'd say) to connect to a hosted Exchange Server 2007 using Outlook 2016 for Mac. We were able to connect successfully before without having issues, but now Outlook won't connect for a couple of minutes to finally be connected - though having then still other issues.
Like we can't set up a new Exchange account as autodiscovery seems to fail and we immediately get prompted to enter manually the server address. If we start Outlook, it won't connect for a couple of minutes (up to 20) to finally show connected. The Sync Errors window shows then quite a lot of messages with 'Outlook cannot connect to the Exchange server.' This then every time we start Outlook. If we set up an appointment we get then 'HTTP error. Access to the resource is forbidden - Error Code 18597' and the appointment wont get send out. And finally if we forward a mail we get a similar error message saying that there was a problem and the mail was moved to the Drafts folder instead. This might also happen randomly to newly created mails. Only if we close then Outlook to reopen the mail will be send out.
It seems to have started with an Office update (can't tell which version) and since then we experience serious connection issues.
This only affects Outlook 2016 for Mac. All other versions incl. Outlook for Windows are still working without connection issues.
It seems to be related to Auto Discovery somehow I guess. The remote analyser page says it should work - There is only one advise with potential compatibility problems while analysing the certificate chain. Though it did work before and still is working for Outlook for Windows incl. Office 365. Usually if we set up a new exchange account we got prompted to accept the changes made by the autodiscovery.xml file. But today we immediately simply get prompted to enter manually the server address while trying to set up a new account.
I wonder if maybe Outlook 2016 for Mac silently refuse the certificate causing then the Auto Discovery process to fail. And all the other versions simply ignore eventual certificate issues.
Because it's a hosted Exchange server we use DNS SRV to point then to the autodiscover.xml file from our Exchange provider.
The produced log file from Outlook 2016 for Mac is showing then the final step to resolve the settings via autodiscover, but to fail finally.
09/09/2016 13:21:44.771OUTLOOK (0xe736)0x19a000Outlookoutlook.account.exchange.addaccount.configibncfVerbose--- DNS SRV method
09/09/2016 13:21:44.772OUTLOOK (0xe736)0x19a000Outlookoutlook.account.exchange.addaccount.config ibn1jVerbose{'Details': 'No _autodiscover._tcp.OURDOMAIN.com service found'}
09/09/2016 13:21:44.772OUTLOOK (0xe736)0x19a000Outlookoutlook.account.exchange.addaccount.config ibn1jVerbose{'Details': 'No _autodiscover._tcp.OURDOMAIN.com service found'}
But actually using nslookup I'm able to resolve this one and also Outlook for Windows is happy using the 'Test E-mail Autoconfiguration' feature. And this DNS SRV was working before update X.Y.Z
Record your voice, have fun with the helium balloon and upload your recording to the cloud. Isn't it fun to inhale some helium from a balloon to pitch up your voice? It's all super easy.
I already have asked our Exchange provider, but they don't have a clue and actually won't be of any help at all.
I just have tried to install the latest available version 15.27, but still no success. :-(
I don't know what else to check. This is affecting several Mac users with Office 365.
Any help appreciated.
Kind regards
Ralph