Autodiscovery and commercial certificates error in exchange 2007

When you install the Client Access server role on a computer that is running Exchange 2007, a new virtual directory named Autodiscovery is created under the default Web site in Internet Information Services (IIS). T

his virtual directory handles Autodiscovery service requests from Outlook 2007 clients and supported mobile devices in the following circumstances:

- When new user account is configured or updated

- When a user periodically checks for changes to the Exchange Web Services URLs

When underlying network connection changes occur in your Exchange messaging environment.Additionally, a new Active Directory object named the service connection point (SCP) is created when you install the Client Access server role.The following figure illustrates how a client connects to a Client Access server the first time from inside the Exchange messaging organization.

 If you are using the new outlook 2007 client, the client will use the HTTPS based distribution method for distributing OAB,GAL,OOF and free/busy information. Microsoft decided to use the HTTPS method to overcome the issues related to the difficulties appeared in managing public folders. Exchange always using secure communication with clients and servers for example it always uses SSL, Secure SMTP and secure RPC. 

If you are using the default settings in Exchange 2007 you will not have any problems, however the default setting is not enough for most organization, because you might want to use a commercial certificates for securing the SMTP or HTTP traffic and this is where the issues arises, because you will encounter an error when using Autodiscovery, OAB, OOF or any HTTP/S web service because if we bind an commercial SSL certificate with an external name to the Exchange 2007 server, users will experience an error message when using Autodiscovery URL,OOF URL and OAB URLs indicating that either object doesn't exist or connection failed when connecting to those URLs internally because users will connect to those URLs using the Internal FQDN obtained the SCP (service connection points) located in the Active directory, while IIS is configured to use SSL certificates that use FQDN with the external name of the servers and thus the connection will fail, be ware of 2 points:

-          This issue will not occur of you are not using split DNS infrastructure.-          Commercial certificate providers don't issues certificate with internal FQDN names like ( .local or .dom) So how to solve it, there is so many ways o solve it as following:

-         if you are using a certificate from a provider that allow multiple SPN names to the certificates (which most of certificate providers don't allow) you can use the following CMDLET to create a certificate request with multiple SPNs: New-ExchangeCertificate -generaterequest -subjectname dc=com,dc=Synergyps,o=Synergyps Corporation,cn=exchange.Synergyps.com -domainname CAS01,CAS01.exchange.corp.Synergyps.com,exchange.Synergyps.com, ,autodiscover.Synergyps.com -path c:\certrequest_cas01.txt

-         if you are using a commercial certificate from Verisign or  Godaddy the above method will not work, so to work around it you can use the following CMDLET to update the SCP inside of the AD: Set-WebServicesVirtualDirectory -Identity EWS* -ExternalUrl Https://mail.synergyps.com/EWS/Exchange.asmx -InternalUrl Https:// mail.synergyps.com/EWS/Exchange.asmx.-         the previous command will update all of the services (OAB,Free/Busy,OOF,GAL) address, but if you are interested in updating the Autodiscovery SCP only you can use the following CMDLET: Set-ClientAccessServer -Identity CASserver1 -AutoDiscoverServiceInternalUri https://mail.synergyps.com this will allow you to use a commercial certificate along with your secure deployment of exchange 2007 and avoid the common errors most of the customers complained from when using AutoDiscovery service.