Exchange 2007 Autodiscover certificate mismatch

Hello, the company that I work for is trying to switch from Exchange 2007 SP1 to Office 365.  However, when we try the cutover migration, 365 doesn't recognize our Exchange server.  After a bit of research, I discovered that there is a certificate
mismatch that is causing the problem.  
I've been searching for a way to solve this problem for a couple of days now and have not yet found a solution.  We'd like to keep the autodiscover location, but change the certificate that is bound to it.  We
have a matching certificate installed, but for some reason, Autodiscover keeps pointing toward the wrong certificate (that doesn't even exist).
Any help would be greatly appreciated

We purchased new certs from GoDaddy and inserted them into exchange (overwriting the old certs and CAs), and this seemed to correct the certificate mismatch.  However, when I run the Remote Connectivity Analyzer, I get this:
Connectivity Test Failed
Test Details
<input class=" __ecpStyleButton" id="testSelectWizard___CustomNav3_buttonStartOver" name="testSelectWizard$__CustomNav3$buttonStartOver"
style="padding:8px 8px 8px 29px;text-align:left;border-style:none;cursor:pointer;background-image:url(https;background-background-repeat:no-repeat;" type="submit" value="Start Over" /><input class=" __ecpStyleButton"
id="testSelectWizard___CustomNav3_buttonRunAgain" name="testSelectWizard$__CustomNav3$buttonRunAgain" style="padding:8px 8px 8px 29px;text-align:left;border-style:none none none solid;cursor:pointer;border-left-color:#cccccc;border-left-width:1px;background-image:url(https;background-background-repeat:no-repeat;"
type="submit" value="Run Test Again" />
<input class=" __ecpStyleButton" id="testSelectWizard_ctl12_btnExpandAll" name="testSelectWizard$ctl12$btnExpandAll" style="padding:8px 8px 8px 29px;text-align:left;border-style:none
solid none none;cursor:pointer;border-right-color:#cccccc;border-right-width:1px;background-image:url(https;background-background-repeat:no-repeat;" type="submit" value="Expand All" /><input class="ecpStyleButtonImageOnly
__ecpStyleButton" id="testSelectWizard_ctl12_btnSaveXml" name="testSelectWizard$ctl12$btnSaveXml" style="padding-padding-bottom:6px;padding-text-align:left;border-style:none;cursor:pointer;background-image:url(https;background-background-repeat:no-repeat;"
title="Save as XML" type="submit" value="" /><input class="ecpStyleButtonImageOnly __ecpStyleButton" id="testSelectWizard_ctl12_btnSaveHtml" name="testSelectWizard$ctl12$btnSaveHtml" style="padding-padding-bottom:6px;padding-text-align:left;border-style:none;cursor:pointer;background-image:url(https;background-background-repeat:no-repeat;"
title="Save as HTML" type="submit" value="" />
The Microsoft Connectivity Analyzer is attempting to test Autodiscover for [email protected].
Testing Autodiscover failed.
Additional Details
Elapsed Time: 7624 ms.
Test Steps
Attempting each method of contacting the Autodiscover service.
The Autodiscover service couldn't be contacted successfully by any method.
Additional Details
Elapsed Time: 7624 ms.
Test Steps
Attempting to test potential Autodiscover URL https://paidwarranty.com:443/Autodiscover/Autodiscover.xml
Testing of this potential Autodiscover URL failed.
Additional Details
Elapsed Time: 1237 ms.
Test Steps
Attempting to resolve the host name paidwarranty.com in DNS.
The host name resolved successfully.
Additional Details
IP addresses returned: 12.192.135.43, 50.232.20.50
Elapsed Time: 129 ms.
Testing TCP port 443 on host paidwarranty.com to ensure it's listening and open.
The port was opened successfully.
Additional Details
Elapsed Time: 152 ms.
Testing the SSL certificate to make sure it's valid.
The certificate passed all validation requirements.
Additional Details
Elapsed Time: 342 ms.
Test Steps
The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server paidwarranty.com on port 443.
The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
Additional Details
Remote Certificate Subject: CN=www.paidwarranty.com, OU=Domain Control Validated, Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US.
Elapsed Time: 247 ms.
Validating the certificate name.
The certificate name was validated successfully.
Additional Details
Host name paidwarranty.com was found in the Certificate Subject Alternative Name entry.
Elapsed Time: 1 ms.
Certificate trust is being validated.
The certificate is trusted and all certificates are present in the chain.
Test Steps
The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=www.paidwarranty.com, OU=Domain Control Validated.
One or more certificate chains were constructed successfully.
Additional Details
A total of 1 chains were built. The highest quality chain ends in root certificate CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US.
Elapsed Time: 39 ms.
Analyzing the certificate chains for compatibility problems with versions of Windows.
Potential compatibility problems were identified with some versions of Windows.
Additional Details
The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled.
Elapsed Time: 5 ms.
Testing the certificate date to confirm the certificate is valid.
Date validation passed. The certificate hasn't expired.
Additional Details
The certificate is valid. NotBefore = 2/24/2014 3:11:57 PM, NotAfter = 2/24/2016 3:11:57 PM
Elapsed Time: 0 ms.
Checking the IIS configuration for client certificate authentication.
Client certificate authentication wasn't detected.
Additional Details
Accept/Require Client Certificates isn't configured.
Elapsed Time: 371 ms.
Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
Additional Details
Elapsed Time: 241 ms.
Test Steps
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://paidwarranty.com:443/Autodiscover/Autodiscover.xml for user [email protected].
The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
Additional Details
A Web exception occurred because an HTTP 404 - NotFound response was received from IIS7.
HTTP Response Headers:
Content-Length: 5401
Cache-Control: private
Content-Type: text/html; charset=utf-8
Date: Mon, 02 Mar 2015 14:58:45 GMT
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Elapsed Time: 241 ms.
Attempting to test potential Autodiscover URL https://autodiscover.paidwarranty.com:443/Autodiscover/Autodiscover.xml
Testing of this potential Autodiscover URL failed.
Additional Details
Elapsed Time: 5175 ms.
Test Steps
Attempting to resolve the host name autodiscover.paidwarranty.com in DNS.
The host name resolved successfully.
Additional Details
IP addresses returned: 157.56.234.137, 157.56.244.217, 157.56.236.89, 157.56.232.9
Elapsed Time: 327 ms.
Testing TCP port 443 on host autodiscover.paidwarranty.com to ensure it's listening and open.
The specified port is either blocked, not listening, or not producing the expected response.
 <label for="testSelectWizard_ctl12_ctl06_ctl00_ctl01_ctl01_tmmArrow">Tell
me more about this issue and how to resolve it</label>
Additional Details
A network error occurred while communicating with the remote host.
Elapsed Time: 4847 ms.
Attempting to contact the Autodiscover service using the HTTP redirect method.
The attempt to contact Autodiscover using the HTTP Redirect method failed.
Additional Details
Elapsed Time: 995 ms.
Test Steps
Attempting to resolve the host name autodiscover.paidwarranty.com in DNS.
The host name resolved successfully.
Additional Details
IP addresses returned: 157.56.234.137, 157.56.244.217, 157.56.236.89, 157.56.232.9
Elapsed Time: 16 ms.
Testing TCP port 80 on host autodiscover.paidwarranty.com to ensure it's listening and open.
The port was opened successfully.
Additional Details
Elapsed Time: 111 ms.
The Microsoft Connectivity Analyzer is checking the host autodiscover.paidwarranty.com for an HTTP redirect to the Autodiscover service.
The redirect (HTTP 301/302) response was received successfully.
Additional Details
Redirect URL: https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
HTTP Response Headers:
Connection: close
Pragma: no-cache
Cache-Control: no-cache
Location: https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
Elapsed Time: 137 ms.
Attempting to test potential Autodiscover URL https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
Testing of this potential Autodiscover URL failed.
Additional Details
Elapsed Time: 729 ms.
Test Steps
Attempting to resolve the host name autodiscover-s.outlook.com in DNS.
The host name resolved successfully.
Additional Details
IP addresses returned: 132.245.64.242, 132.245.3.130, 132.245.92.226, 132.245.82.50, 132.245.81.194, 132.245.81.130, 132.245.88.194
Elapsed Time: 17 ms.
Testing TCP port 443 on host autodiscover-s.outlook.com to ensure it's listening and open.
The port was opened successfully.
Additional Details
Elapsed Time: 53 ms.
Testing the SSL certificate to make sure it's valid.
The certificate passed all validation requirements.
Additional Details
Elapsed Time: 221 ms.
Test Steps
The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server autodiscover-s.outlook.com on port 443.
The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
Additional Details
Remote Certificate Subject: CN=outlook.com, OU=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=WA, C=US, Issuer: CN=Microsoft IT SSL SHA1, OU=Microsoft IT, O=Microsoft Corporation, L=Redmond, S=Washington, C=US.
Elapsed Time: 127 ms.
Validating the certificate name.
The certificate name was validated successfully.
Additional Details
Host name autodiscover-s.outlook.com was found in the Certificate Subject Alternative Name entry.
Elapsed Time: 1 ms.
Certificate trust is being validated.
The certificate is trusted and all certificates are present in the chain.
Test Steps
The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=outlook.com, OU=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=WA, C=US.
One or more certificate chains were constructed successfully.
Additional Details
A total of 1 chains were built. The highest quality chain ends in root certificate CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE.
Elapsed Time: 38 ms.
Analyzing the certificate chains for compatibility problems with versions of Windows.
Potential compatibility problems were identified with some versions of Windows.
Additional Details
The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled.
Elapsed Time: 5 ms.
Testing the certificate date to confirm the certificate is valid.
Date validation passed. The certificate hasn't expired.
Additional Details
The certificate is valid. NotBefore = 1/21/2015 10:45:26 PM, NotAfter = 1/21/2016 10:45:26 PM
Elapsed Time: 0 ms.
Checking the IIS configuration for client certificate authentication.
Client certificate authentication wasn't detected.
Additional Details
Accept/Require Client Certificates isn't configured.
Elapsed Time: 158 ms.
Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
Additional Details
Elapsed Time: 277 ms.
Test Steps
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml for user [email protected].
The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
Additional Details
An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name
(UPN).
HTTP Response Headers:
request-id: d823479c-c259-4474-8b3f-df60b4898533
X-CasErrorCode: UnauthenticatedRequest
X-FEServer: BY2PR12CA0033
Content-Length: 0
Cache-Control: private
Date: Mon, 02 Mar 2015 14:58:53 GMT
Set-Cookie: ClientId=GILRU7BQ40ROHZE90FEIA; expires=Tue, 01-Mar-2016 14:58:54 GMT; path=/; secure; HttpOnly
Server: Microsoft-IIS/8.0
WWW-Authenticate: Basic Realm=""
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Elapsed Time: 276 ms.
end
I've enabled basic authentication on the RPC virtual directory on the Exchange CAS in IIS and then restarted IIS, as suggested in another forum (https://social.technet.microsoft.com/Forums/exchange/en-US/69d83444-0528-4e39-a5e9-eb9040501be1/remote-connectivity-analyzer-problem?forum=exchangesvr3rdpartyappslegacy)
and am still getting the same results from the Remote Connectivity analyzer.
On a side note, we have reviewed multiple Exchange Deployment Assistance, including the one that you referred to, and are attempting a cutover migration.

Similar Messages

  • Exchange 2007 Webmail certificate Renewal

    Hi,
    If any one knows more details about how to renew the webmail certificate in Exchange 2007, Webmail certificate is ging to expire soon ...EventID 12018

    You can use powershell cmdlet Import-ExchangeCertificate to renew the certificate.
    To enable the certificate, execute Enable-ExchangeCertificate -Services IMAP,POP,IIS,SMTP -Thumbprint <cert-thumbprint-here>
    For more info, visit
    https://www.digicert.com/ssl-certificate-renewal-exchange-2007.htm

  • How to export an exchange 2007 owa certificate from production to lab environment

    I'm setting up an Exchange 2007 Lab but I have a trouble regarding exchange's certificate
    Note: My lab environment is not conected to internet
    I've followed the next link but it doesn't work
    https://www.digicert.com/ssl-support/pfx-import-export-exchange-2007.htm
    Once I finished all the steps if I run the next powershell command get-excahangecertificate I see that my exchange certificate has the status as unknown
    I'm not sure if the problem is related with the server is not conected to internet, so exchange is not be able to check the status of the certificate.
    I've tried to turn off the Check for publisher’s certificate revocation option on the server
    To do this, follow these steps.
    Start Internet Explorer.
    On the Tools menu, click Internet Options.
    Click the Advanced tab, and then locate the Security section.
    Click to clear the Check for publisher’s certificate revocation check box, and then click OK.
    After the update rollup installation is complete, turn on the Check for publisher’s certificate revocation option.
    But it still not working
    Could anyone help me?
    Thanks in advance

    Hi Pardo,
    According to your description, I understand that the exchange certificate cannot work and display unknown status after import it.
    If I misunderstand your concern, please do not hesitate to let me know.
    Depending on the results of “Get-ExchangeCertificate | FL”, please pay attention to following points:
    1. RootCAType: Registry
    “An internal, private PKI root CA that has been manually installed in the certificate store.”
    2. Status: Unknown
    “This status generally indicates that the status of the certificate cannot be verified because the certificate revocation list (CRL) is unavailable or this server cannot connect to it.”
    The reason why it failed is that internal Exchange server cannot connect to CRL. As you mentioned, exchange can’t be able to check the status of the certificate.
    More information about Certificate Use in Exchange Server 2007, please refer to
    Certificate Fields and Configuring Access to the Certificate Revocation List
    section in below link:
    http://technet.microsoft.com/en-us/library/bb851505(v=exchg.80).aspx
    However, we can renew a certicate from local CA:
    http://technet.microsoft.com/en-us/library/bb310781(v=exchg.80).aspx
    Best Regards,
    Allen Wang

  • Exchange 2007 Renew Certificate via IIS Manager

    I am currently in the process of renewing the Exchange 2007 certs and have searched through forums in regards to this topic and can't seem to come across a proper answer. Is it possible to renew the Exchange 2007 cert using the IIS Manager or is Powershell
    the only way of doing so? Under the "IIS Manager > expanding server name > expand websites > default website properties > Directory Security > Server Certificate" you are presented with the option to renew the existing cert. This to
    me seems a lot easier than using shell to request a whole new cert. I am not a fan of the how Powershell can be a bit destructive when requesting a new cert and overwriting the existing one leaving your little ways of backing out if something goes wrong. Can
    someone confirm if using IIS manager is a viable way of renewing the Exchange 2007 cert. I prefer to keep the exact settings of the existing certificates.
    Thank you,
    Emmanuel
    Emmanuel Fumero Exchange Administrator

    Hi
    Yes its possible in Exchange  2010 through EMC . Not sure if this works in Exchange 2007 since i haven't tried renewing through GUI in exchange 2007 and currently do not have any customers running e2k7 to check this option. Probably you can give it
    a try in Exchange 2007 and see if these options are visible. Please check the following,
    When you right-click your Exchange Server, you can select New Exchange Certificate, which will launch the New Exchange Certificate Wizard.
    After defining a friendly name, you are ready to provide all needed information:
    After clicking Finish, you will have a certificate request that you can use ti get a certificate from your own CA, or from an external CA. The Exchange Management Console will show the request as well
    1.Start the Exchange Management Shell. Click Start > Programs > Microsoft Exchange Server 2007, and then click Exchange Management Console.
    2.Click the link to "Manage Databases", and then go to "Server configuration".
    3.Select your certificate from the menu in the center of the screen (The certificate will be listed by the Friendly Name you chose when creating the CSR), and then click the link in the Actions menu to "Complete Pending Request".
    4.Browse to the certificate file you just copied to your server, then click Open > Complete.
    URGENT!! You may receive the following error: "The source data is corrupted or not properly Base64 encoded." You can ignore this error
    5.Press F5 to refresh the certificate list. Verify that it says "False" under "Self Signed".( if its 3rd party or feom CA)
    6.To enable your certificate, return to the Exchange Management Console and click the link to "Assign Services to Certificate."
    Hope this helps
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as
    Answer” if a marked post does not actually answer your question. This can be beneficial to other
    community members reading the thread.
    Regards
    Sathish

  • Exchange 2007 Wildcard Certificate Supported in iPhone?

    Does the iphone support the use of a wildcard certificate?
    Our exchange infrastructure utilises a wildcard (*.companyname certificate) from godaddy. All the windows mobile 6.0 devices work fine however I know that windows mobile 5.0 did not support wildcard certificate, any help would be good.
    Thanks.

    I've manually installed the client based certificate on the iPhone (a wildcard from Network Solutions), no dice.
    Going to try using the server's cert this time...

  • Autodiscover after deploying Exchange 2013 CAS in a Exchange 2007 organization

    I am deploying Exchange 2013 CAS in a Exchange 2007 organization. Will all the clients be directed to the Exchange 2013 CAS servers for autodiscover. Will there be any issue with outlook clients connecting to their mailbox servers in Exchange 2007

    All clients should be pointed to the Exchange 2013 CAS for the autodiscover service. This means:
    A. For local clients
    You need to modify the autodiscover Internal URI on the Exchange 2007 server and point it to Exchange 2013. For example, if you are using split-brain DNS on the Local Network and mail.yourdomain.com is resolved to Exchange 2013 local IP, the Exchange 2007
    Autodiscover Internal URI should be "https://mail.yourdomain.com/Autodiscover/Autodiscover.xml" 
    Exactly the same way, you should modify the Exchange 2013 Autodiscover Internal URI and use the same address "https://mail.yourdomain.com/Autodiscover/Autodiscover.xml"
    B. For remote clients - all clients will hit the Exchange 2013 CAS first (ex. mail.yourdomain.com)
    If the user's mailbox is on Exchange 2007 server, the correct XML will be generated and provided, and the user will be proxied for Outlook Anywhere/ActiveSync and redirected for OWA/WebServices
    If the user's mailbox is on Exchange 2013 server, the correct XML will be generated and provided
    Bottom line - based on the location of the user's mailbox, Exchange 2013 will generate and provide the correct XML file (there is not proxying involved in providing the Autodiscover info).

  • Legacy Namespace for Exchange 2007 to 2013 co-existence

    We are migrating from Exchange 2007 to 2013, during the co-existence phase, where is the legacy.{domain.com} namespace used? We are at the point now that we want to move all services over to the Exchange 2013 CAS servers, however... GPO settings
    are used to point outlook clients to mail.{domain.com} for Outlook Anywhere. If DNS is updated to point mail.{domain.com} to the Exchange 2013 servers, will there be an issue with connectivity for people still on the Exchange 2007 servers? Do these people
    need to point to legacy.{Domain.com} or will mail.{domain.com} proxy the connection to the legacy namespace? I would like to know if the GPO settings will interfer with the settings that Autodiscovery provide back.
    I have read a bunch or articles on the approach, but I am still fuzzy on where legacy.{domain.com} comes into play.
    Thanks in advance for your help.

    In coexistence with exchange 2013 and legacy version the request happens in 2 types.
    For Exchange 2010 –
    Exchange 2013 does a Proxy for owa and ews requests for users in exchange 2010.
    For Exchange 2007 –
    Exchange 2013 does redirection for owa and ews requests for users in Exchange 2007.
    Certificates:
    All the required SAN entries for UM,webservices and activesync should be created.
    Add external owa legacy URL to the public certificate and install it on both Exchange 2007 and
    Exchange 2013 only then owa redirection will work.
    You need to Include internal Legacy. Domain.com on Exchange 2007 Certificate for OWA co-
    Existence.
    Following change needs to be done in Firewall
    External OWA URL should be directed to exchange 2013 Internet Facing CAS.
    External EWS URL should be directed to  exchange 2013 Internet Facing CAS.
    External Autodiscover URL should should be directed to  Exchange 2013 CAS.
    External ActivesyncVirtualDirectory should be directed to Exchange 2013 CAS.
    External UMvirtualDirectory should be directed to  Exchange 2013 CAS.
    Create new NAT rule on firewall for Legacy.domain.com to Exchange 2007 CAS. You can do this as well.By doing this users will be able to log on directly using the URL https://legacy.domain.com/owa with
    a mailbox on Exchange 2007.
    External and Internal DNS settings
    Public DNS - Map all of your external public DNS records (ews,owa,activesync etc.,) to your
    exchange 2013 public IP if you have dedicated one for 2013 or FQDN of your internet facing CAS server.
    Example:
    Current external owa URL (contoso.domain.com) – point it to dedicated exchange 2013 public ip or internet facing exchange 2013 CAS FQDN.
    Current External Autodiscover – point it to dedicated exchange 2013 public ip or internet
    facing exchange 2013 CAS FQDN
    Internal DNS – Configure the Exchange 2007 to point SCP AutoDiscoverURI to Exchange 2013 Client
    Access FQDN by changing DNS entry for Autodiscover.domain.com to exchange 2013 CAS sever Ip
    address
    The internal DNS records should point to the internal host name and IP address of your Exchange
    2013 Client Access server
    Make sure that legacy.contoso.com resolves to CAS2007 in internal and external DNS.
    Authentication Settings:
    This part is little bit tricky. You need to plan according to your organization. If you have FBA configured in TMG or ISA server then you need to configure accordingly.
    Set the owa virtual directory authentication only to  Basic in exchange 2007.
    In exchange 2013 set owa virtual directory to only (Windows Authentication) or only (form-based authentication) or only (Basic, No redirection, SSL Enabled) depends according to your setup.
    Things to check:
    If you have redirection configured in IIS on the Exchange 2007 Server Make sure that the above
    Virtual Directories doesn’t have it configured.
    If you have FBA enabled on ISA or TMG then disable FBA on Exchange 2013 CAS else users will be prompted twice for authentication
    For further references you can refer my article below
    http://exchangequery.com/2014/09/24/owaews-configuration-in-exchange-20132007-coexistence/
    Remember to mark as helpful if you find my contribution useful or as an answer if it does answer your question.That will encourage me - and others - to take time out to help you Check out my latest blog posts on http://exchangequery.com Thanks Sathish (MVP)

  • Troubleshooting and Introduction for Exchange 2007/2010 AutoDiscover - Details about "Test E-mail AutoConfiguration"

    AutoDiscover is a new feature in Exchange 2007, to provide access to Microsoft Exchange features (OAB, Availability service, UM) for Outlook 2007
    clients or later.
    We can determine whether problems related to AutoDiscover via OWA.
    For example:
    OOF is not working in Outlook Client but it is working in OWA.
    When we realized this issue is not related to Outlook Client side and network side after performing some troubleshooting steps, it should be something
    abnormal on AutoDiscover.
    There is a common tool to check AutoDiscover in Outlook, Test E-mail AutoConfiguration.
    Today, we will introduce AutoDisocver and “Test E-mail AutoConfiguration” in details. Hope it is helpful for AutoDiscover troubleshooting and self-learning.
    1. Differences between “Test E-mail AutoConfiguration” and other tools
    The “Test-OutlookWebServices” cmdlet allows us to test the functionality of the following services:
    Autodisocver
    Exchange Web Services
    Availability Service
    Offline Address Book
    When we run “Test-OutlookWebServices”, it returns all the web services’ states.
    However, some information are useless for some scenarios.
    For example:
    We just want our Exchange 2010 Server working internally. So it is unnecessary to enable Outlook Anywhere.
    However, when we run “Test-OutlookWebServices”, it returns Outlook Anywhere errors because the Outlook Anywhere does not need to been enabled.
    In contrast, using “Test E-mail Autodiscover” is more intuitive.
    If there is any problems, it will return error code from the test result, like 0x8004010F etc. We can do some research from TechNet articles or MS
    KBs.
    Although it is difficult to say where the specific problem is just via the error codes, we can combine with IIS logs to perform troubleshooting and
    find the root of problem.
    2. How to use “Test E-mail AutoConfiguration” Tool
    a. Open Outlook, we can find there is an Outlook Icon at the right bottom of System tray. Holding down “Ctrl” button and right click the Outlook Icon, we will see “Test E-mail
    AutoConfiguration” option. Please see Figure 01.
    Figure 01
    b. Click “Test E-mail AutoCofiguration” and input user name, uncheck the “Use Guessmart” and “Secure Guessmart Authentication” checkboxes, then click “Test”. Please see
    Figure 02.
    Figure 02
    c. “Test E-mail AutoConfiguration” result panel and log panel. Please see Figure 03 and Figure 04.
    Figure 03
    Figure 04
    3. How to understand “Test E-mail AutoConfiguration” result
    According to the Figure 03, we found there are many URLs in the “Test E-mail AutoConfiguration” result panel. Let us understand the details of these
    URLs.
    If we these URLs are not the correct ones, we can re-setting or re-creating them via commands.
    - Internal OWA URL:
    https://vamwan310.vamwan.com/owa/
    OWA internal access.
    - External OWA URL:
    https://mail.vamwan.com/owa/
    OWA external access.
    - Availability service URL:
    https://vamwan310.vamwan.com/EWS/Exchange.asmx
    Free/Busy, OOF and meeting suggestions.
    - OOF URL:
    https://vamwan310.vamwan.com/EWS/Exchange.asmx
    Out of Office access.
    - OAB URL:
    https://vamwan310.vamwan.com/OAB/023ef307-b18a-4911-a52c-de26700f6173/
    OAB access.
    - Exchange Control Panel URL:
    https://vamwan310.vamwan.com/ecp/
    ECP access.
    4. AutoDiscover Tips
    - AutoDiscover Service itself is a web application running on the AutoDiscover virtual directory (not a server service) designed to provide connection information to various
    clients.
    - The AutoDiscover service is automatically installed and configured when CAS role is added to any Exchange Server.
    - AutoDisocver virtual directory is created in IIS within the Default Web Site.
    - A Sercive-Connection-Point (SCP) object is created in AD.
    - The SCP contains a URL to the AutoDiscover service. This is for intranet clients so they do not have to use DNS to locate the AutoDiscover service.
    - In AD this object is located at the following location:
    DC=<domain>, CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=First Organization, CN=Administrative Groups, CN=Exchange Administrative
    Group, CN=Servers, CN=<CAS Name>, CN=Protocols, CN=AutoDiscover, CN=<CAS Name>
    - Setup creates the AutoDiscover URL based on the following structure:
    <CASNetbiosName>.domain.com/AutoDiscover/AutoDiscover.xml
    If a PKI certificate is not already present, a self-signed certificate is installed on the Default Web Site. 
    To help allow this certificate pass the Issues to test it is set up with a Subject Alternative Name containing urls.
    If a PKI certificate is present, that certificate is utilized and configured for use in IIS.
    The Outlook Provider is used to configure separate settings for the Exchange PRC protocol (internal to network), Outlook Anywhere (Exchange HTTP protocol), and WEB:
    EXCH, EXPR, WEB
    The
    EXCH and EXPR setting are vital for the proper configuration of Outlook.
    5. AutoDiscover Workflow
    General Process flow:
    There are various components surrounding the AutoDiscover Service and all are necessary to complete a request. Including IIS, AutoDiscover service
    itself, the provider, and AD.
    a.
    Client constructs service URL and submits Autodiscover Request. First attempt to locate the SCP object in AD. So, DNS is not needed.
    b.
    IIS Authenticates User.
    c.
    Is the Autodiscover service in the appropriate forest?
    + If YES.
        1)
    Parse/Validate Request
        2)
    Is there a provider that can service the Request?
    ++ If YES
          a)
    Config provider processes request and returns config settings.
          b)
    Return config setting to client
    ++ If NO
    Inform client we cannot process request
    + If NO.
    Redirect client to Autodiscover service in the appropriate forest.
    Methods to find Autodiscover services: SCP and DNS
    Domain-joined
    a. Find SCP first.
    The SCP contains the URL to the AutoDiscover service.
    URL: https://CAS01.contoso.com(CAS’ FQDN)/AutoDiscover/AutoDiscover.xml
    If more than one SCP object is found in AD (it means there are multiple CAS servers in the Exchange organization), Outlook client will choose one of the SCP entries that
    are in the same site to obtain the AutoDisocover URL.
    b. If we cannot find SCP object, then Outlook client will use DNS to locate AutoDiscover.
    Outlook parses out the domain (SMTP suffix) via your EmaiAddress, then attempts to connect to the predetermined order of URLs via the suffix.
    For example: If my email address is
    [email protected]
    Outlook tries POST commands to the following order of URLs:
    https://contoso.com/autodiscover/autodiscover.xml
    https://autodiscover.contoso.com/autodiscover/autodiscover.xml
    NOTE: The URLs above is by design, hardcode
    and cannot be changed.
    c.
    If those fail, Outlook tries a simple redirect to another URLs in IIS:
    http://contoso.com/autodiscover/autodiscover.xml
    http://autodiscover.contoso.com/autodiscover/autodiscover.xml
    If none of these URLs work then DNS is most likely not set up correctly.
    We can test that by pinging one of the above URLs.
    If that is successful, we must ensure the URLs contoso.com or autodiscover.contoso.com are actually pointing to the CAS server.
    If the ping fails then there is a chance that DNS is not set up correctly so be sure to check that the URLs are even registered.
    NOTE: If contoso.com is a non-CAS server,
    we should add a Host record with just AutoDiscover. And point that entry to your CAS server that is running AutoDiscover.
    d.
    If still failed, we can use DNS SRV lookup for _autodiscover._tcp.contoso.com, then “CAS01.contoso.com” returned. Outlook will ask permission from the user to continue
    with AutoDiscover to post to https://CAS01.contoso.com/autodiscover/autodiscover.xml
    Non-Domain-joined
    It first tries to locate the Autodiscover service by looking up the SCP object in AD. However the client is unable to contact AD, it tries to locate
    the Autodiscover service by using DNS.
    Then, same as step b, c, d in
    Domain-joined scenario.
    6. How to change the AutoDiscover
    service location order forcibly?
    By default, Outlook client locates AutoDiscover service in that order above.
    We can also change the order forcibly.
    a.
    If we want to locate AutoDiscover service via one of the autodiscover URLs, please running following command in EMS:
    Set-ClientAccessServer -identity <servername> -AutodiscoverServiceInternalUri https://autodiscover.contoso.com/autodiscover/autodiscover.xml(URL
    that you want)
    b. If we want to locate AutoDiscover service via
    SRV record, please follows this KB to set up SRV:
    http://support.microsoft.com/kb/940881
    7. How to check AutoDiscover Healthy
    a. We should make sure the AutoDiscover
    is healthy before using AutoDiscover to perform troubleshooting.
    b.
    We can browse following URL in IE explorer:
    https://autodiscover.vamwan.com/autodiscover/autodiscover.xml
    If it returns “code 600”, that means AutoDiscover is healthy.
    Screenshot as below:
    c. AutoDiscover itself returns errors to the requesting client if the incoming request does not contain the appropriate information to complete a
    request.
    The following table explains the possible errors that could be returned.
    Error   Value
    Description  
    600
    Mailbox not found and a   referral could not be generated.
    601
    Address supplied is not   a mailbox. The provided email address is not something a client can connect to.   It could
    be a group or public folder.
    602
    Active Directory error.
    603
    Others.
    The 600 “Invalid Request” error is returned because a user name was not passed to the service. That is OK for this test because this does confirm
    the service is running and accepting requests.
    d.
    If AutoDiscover service is not working well, I suggest re-building the AutoDiscover Virtual Directory for testing.
    Steps as below:
    1) Running following command in EMS to remove the AutoDiscover VD (we cannot delete it via EMC):
    Remove-AutodiscoverVirtualDirectory -Identity "CAS01\autodiscover(autodiscover.contoso.com)"
    Please refer:
    http://technet.microsoft.com/en-us/library/bb124113(v=exchg.141).aspx 
    2)
    Running following command in EMS to verify whether we have removed the AutoDisocver VD successfully:
    Get-AutodiscoverVirtualDirectory | FL
    Please refer:
    http://technet.microsoft.com/en-us/library/aa996819(v=exchg.141).aspx
    3)
    Running following command in EMS to re-creating a new AutoDiscover VD:
    New-AutodiscoverVirtualDirectory -Websitename <websitename> -BasicAuthentication:$true -WindowsAuthentication:$true
    Please refer:
    http://technet.microsoft.com/en-us/library/aa996418(v=exchg.141).aspx
    8. Common issues
    a. Outlook Disconnection
    Issue and Troubleshooting
    Issue:
    Sometimes the Outlook clients cannot connect to the Exchange server after migrating to a new Exchange server or changing to new CAS. The Outlook clients
    always connect to the old CAS server.
    Troubleshooting:
    To solve this issue, we should change the SCP via following command:
    Set-ClientAccessServer -Identity
    <var>CAS_Server_Name</var> -AutodiscoverServiceInternalUri
    https://mail.contoso.com(newCAS’FQDN)/autodiscover/autodiscover.xml
    b. Autodiscover
    Certificate issue
    Tips on Certificate:
    Exchange requires a certificate to run an SSL protocol such as HTTPS. We can use the certificate that supports subject alternate names (SAN) in Exchange.
    This is to allow the certificate to support resources that have different names, such as Outlook Anywhere and the Autodisocver Web application.
    Issue and Troubleshooting
    Issue:
    We receiver the Certificate Principal Mismatch error when we use a SAN certificate.
    Troubleshooting:
    1) Please determine the FQDN that the client
    uses to access the resource. Steps as below:
    OutlookàToolsàAccount
    SettingsàE-mailàclick
    the Exchange accountàChangeàMore
    SettingsàConnectionàExchange
    Proxy Settingsànote the FQND that list in the
    Only connect to proxy servers that have this principal name in their certificate box.
    2)
    Please using EMS to determine the value for the CerPrincipalName attribute: Get-OutlookProvider
    This command returns the result for the EXPR name.
    3)
    Please re-setting the CertPrincipalName attribute to match the FQDN via following command:
    Set-OutlookProvider EXPR –CertPrincipalName: “msstd:<FQDN the certificate is issued to>”
    9. Resource for reference:
    Autodiscover and Exchange 2007
    http://technet.microsoft.com/en-us/library/bb232838(v=exchg.80).aspx
    White Paper: Understanding the Exchange 2010 Autodiscover Service
    http://technet.microsoft.com/en-us/library/jj591328(v=exchg.141).aspx
    Certificate Principal Mismatch
    http://technet.microsoft.com/en-us/library/aa998424(v=exchg.80).aspx
    Please click to vote if the post helps you. This can be beneficial to other community members reading the thread.

    HI,
     I get following?  when run the test?  user is login to Domain A but accessing exchange in Domain B?

  • Unrecognized certificate when Outlook 2010 tries to connect to Exchange 2007 on SBS 2008

    Hi all,
    I believe this is a security issue rather than a connectivity or configuration problem.
    Running Outlook 2010 on Windows 7 trying to connect to Exchange 2007 on SBS 2008, I receive the following error:
    "The name of the security certificate is invalid or does not match the name of the site"
    When I view the certificate I see that it was issued to "zx-server" by "zx". This is NOT my domain CA nor is it a certificate I recognize. I use a self-issued certificate (i.e. issued by the SBS box). I also receive this certificate error when I browse to
    the internal website (companyweb). No other computers on the network are seeing this behaviour.
    I have checked the certificate stores in certmgr and I can't find any such certificate or CA. I have also searched the entire hard drive with no luck. I have run Kaspersky AV, Malwarebytes and MS Security Essentials several times but I can't find any malware.
    I also recently installed Comodo Firewall (the problem began after this).
    I need to find and remove the certificate and prevent it from being presented to me every time I try to connect to the server. All help, advice and suggestions appreciated.
    Aide

    Hi,
    It’s really a common issue.
    This issue occurs if the following conditions are true:
    You replace the default self-signed Exchange Server 2007 or Exchange Server 2010 certificate with a different certificate.
    Note The Setup program in Exchange Server 2007 or in Exchange Server 2010 creates a default self-signed certificate when Exchange Server 2007 or Exchange Server 2010 is installed.
    The common name on the replacement certificate does not match the fully qualified domain name (FQDN) of the URL that is stored in the following objects:
    o   
    The Service Connection Point object for the Autodiscover service
    o   
    The
    InternalUrl attribute of Exchange 2007 Web Service (EWS)
    o   
    The
    InternalUrl attribute of the Offline Address Book Web service
    o   
    The
    InternalUrl attribute of the Exchange unified messaging (UM) Web service
    By default, the URL that is stored in these objects references the NetBIOS name of the server. For example, a URL that resembles the
    following URL is stored:
    https://NetBIOS_name.contoso.com/autodiscover/autodiscover.xml
    This may differ from the host name that is used in the FQDN of the replacement certificate. For example, the replacement certificate
    may have an FQDN that resembles the following FQDN:
    mail.contoso.com
    This issue causes a name mismatch error to occur. Therefore, you receive the security warning message when you try to connect Outlook
    2007 to the mailbox.
    For more detailed information about the procedures to fix the issue, please refer to the following KB article:
    Title: Security warning when you start Outlook 2007 and then connect to a mailbox
    that is hosted on a server that is running Exchange Server 2007 or Exchange Server 2010: "The name of the security certificate is invalid or does not match the name of the site"
    URL:
    http://support.microsoft.com/kb/940726
    Regards,
    James
    James Xiong
    TechNet Community Support

  • Problem: Mixed Exchange 2007 / 2013 CAS Servers with wildcard certificates in Europe and non-wildcard Certficate in China

    Hi,
    we have following problem. We have a mixed multi-domain one-forest AD environment. We also have still a mixed exchange 2007 / 2013 environment. We also have different CAS Servers for 2007 SP3 (RU15) and 2013 (CU8) in europe and one 2007 SP3 (RU15) CAS Server
    in China, because of bad connection to Europe. For the Migration to 2013 in Europe we installed a wildcard-certificate *.xyz.com and used the Set-OutlookProvider EXPR -CertPrincipalName msstd:*.xyz.com, so the wildcard certificate is accepted. Everything in
    Europe works fine, inside and outside also between exchange 2007 and 2013 (both CAS Server 2013 and 2007 use the same wildcard certificate). But since the change of the Set-OutlookProvider EXPR we are facing problems with our CAS Server in China, because this
    server has a different non-wildcard certificate and a different domain name (cas-server.xyz-china.com instead xyz.com). Now we have the problem that this Chinese CAS server the Outlook Anywhere does not work anymore and prompts always for the username. As
    I see it is because of the EXPR change. Is it possible to set the the Outlook-Provider EXPR per Cas-Server ? (They also have their own Autodiscover on this front-end server). Because I see that the Outlook-Provider can only be stored forest-wide.
    If not the other solution would be to register the chinese cas server in our xyz.com domain and use the same wildcard certificate on this system right ?
    Any help would be appreciate….

    Yes setting the EXPR value is most likely the cause of your issue.  When you set this value you are telling Outlook to only accept connections from connections that have the cert with the subject name you specify here.
    Unfortunately, based on my experience I believe this is an organization wide setting and cannot be configured on a CAS by CAS basis (If I'm wrong someone please keep me honest :)).  
    So the only option would you have is to change all the URLs to be on *.xyz.com domain.  There's no need to change the domain the server actually resides on.  The other option would be to purchase a UCC Cert with all the names you need and apply
    to all your CAS servers and reset the EXPR value. 
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread

  • "Name on the Security Certificate is Invalid or Does not Match..." using Outlok 2007 w/ Exchange 2007

    Good afternoon!
    We just completed our Exchange 2007 implementation (migration from Exchange 2003... a fun romp of 24 straight hours for the final push) and noticed an error that only occurs on Outlook 2007 clients connecting to the Exchange 2007 server: "Name on the Security Certificate is Invalid or Does Not Match the Name on the Certificate".
    Now, I've done my reading into this and have determined that due to how Outlook 2007 clients managed their OAB, it is essentially through a web virtual directory now, no longer through Public Folders and this is essentially the base of our issue. See, our mail server has an internal FQDN of mail.ourdomain-domain.com whereas it has an external FQDN (which is what the SSL Cert is tied to) of owa.ourdomain.com.
    So, essentially what I'm seeing is our internal Outlook 2007 clients (limited to I.S. employees only right now, thankfully) are seeing this SSL error because Outlook 2007 is trying to pick up the OAB using the internal FQDN instead of the external FQDN (which would work as well, due to some internal DNS trickery we have configured).
    My question is (finally), is there a way to circumvent this internally so we never see this SSL error prompt or a way to force Outlook 2007 to use the external FQDN? I have made sure all the settings in Exchange Management Console for OAB and the like have both the internal and external FQDN set to owa.ourdomain.com (the valid SSL name), but it does not appear to have made a difference. Granted, I have not rebooted... but I do not think that is necessary in this instance.
    Any suggestions would be appreciated. Thanks!!

    Hi All,
    1) I am using Windows SBS Server 2008 with Exchange 2007 installed on it. With all the Certicate configured internally. We haven’t purchased the Certificate from any outside authority yet.
    2) Also, user were getting Error message "The name on the security certificate is invalid or does not match the name of the site" in outlook, to resolve this issue I followed the steps mention on "http://support.microsoft.com/kb/940726" &  “http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/thread/697f79e2-ca8f-4a2e-bae5-55d3fa7f703f/?prof=required” however I was able run only first command as I was unable to find "EWS (Default Web Site)", "oab (Default Web Site)", "unifiedmessaging (Default Web Site)".
    3) After reaserching, I run following commands to get the status, location of WebServicesVirtualDirectory, OABVirtualDirectory & UMVirtualDirectory
    [PS] C:\Windows\System32>Get-WebServicesVirtualDirectory | fl
    Name                          : EWS (SBS Web Applications)
    Server                        : PASVR01
    InternalUrl               : https://sites/EWS/Exchange.asmx
    ExternalUrl              :
    [PS] C:\Windows\System32>Get-OABVirtualDirectory | fl
    Name                          : OAB (SBS Web Applications)
    Server                        : PASVR01
    InternalUrl               : https://sites/OAB
    ExternalUrl              :
    [PS] C:\Windows\System32>Get-UMVirtualDirectory | fl
    Name                          : UnifiedMessaging (SBS Web Applications)
    Server                        : PASVR01
    InternalUrl               : https://sites/UnifiedMessaging/Service.asmx
    ExternalUrl               :
    4) Then after getting the correct locations of all the directory I run the following commands to change the internal url on existing Certs
    Set-ClientAccessServer -Identity PASVR01 -AutodiscoverServiceInternalUri https://pasvr01/owa/autodiscover/autodiscover.xml
    Set-WebServicesVirtualDirectory -Identity "PASVR01\EWS (SBS Web Applications)" -InternalUrl https://pasvr01/owa/ews/exchange.asmx
    Set-OABVirtualDirectory -Identity "PASVR01\OAB (SBS Web Applications)" -InternalUrl https://pasvr01/owa/oab
    Set-UMVirtualDirectory -Identity "PASVR01\UnifiedMessaging (SBS Web Applications)" -InternalUrl https://pasvr01/owa/unifiedmessaging/service.asmx
    5) However, this does'nt resolved our issue so run the following commands to change the external url on existing Certs
    Set-WebServicesVirtualDirectory -Identity "PASVR01\EWS (SBS Web Applications)" -ExternalUrl https://exchange.domain.com/owa/ews/exchange.asmx
    Set-OABVirtualDirectory -Identity "PASVR01\OAB (SBS Web Applications)" -ExternalUrl https://exchange.domain.com/owa/oab
    Set-UMVirtualDirectory -Identity "PASVR01\UnifiedMessaging (SBS Web Applications)" -ExternalUrl https://exchange.domain.com/owa/unifiedmessaging/service.asmx
    6) I also tried running "New-ExchangeCertificate -PrivateKeyExportable $True -Services “IMAP, POP, IIS, SMTP” -SubjectName “cn=PASVR01" as I have deleted one of the certicate on this server in past.
    7) Following was the status of internal and external URL.
    [PS] C:\Windows\System32>Get-WebServicesVirtualDirectory | fl
    Name                          : EWS (SBS Web Applications)
    Server                        : PASVR01
    InternalUrl               : https://pasvr01/owa/ews/exchange.asmx
    ExternalUrl              : https://exchange. exchange.domain.com /owa/ews/exchange.asmx
    [PS] C:\Windows\System32>Get-OABVirtualDirectory | fl
    Name                          : OAB (SBS Web Applications)
    Server                        : PASVR01
    InternalUrl               : https://pasvr01/owa/oab
    ExternalUrl              : https://exchange. exchange.domain.com/owa/oab
    [PS] C:\Windows\System32>Get-UMVirtualDirectory | fl
    Name                          : UnifiedMessaging (SBS Web Applications)
    Server                        : PASVR01
    InternalUrl                   : https://pasvr01/owa/unifiedmessaging/service.asmx
    ExternalUrl                   : https://exchange. exchange.domain.com/owa/unifiedmessaging/service.asmx
    10) Still we are facing this issue of "The name on the security certificate is invalid or does not match the name of the site" in outlook.
    PLEASE HELP ME TO RESOLVE THIS ISSUE.
    Thanks in Advance,
    Asif

  • Exchange 2007 Out of Office Certificate Error

    Hello,
    I have an Exchange 2007 Server and for some odd reason this week, we have been having issues enabling Out of Office in Outlook. It is some sort of issue with the Autodiscover service, but despite reading forum post after forum post, nothing has worked for
    me. At first when we would go into Outlook and click on Out of Office, it would freeze and then say the server is unavailable. I realized that it was trying to resolve a URL so I added a manual A record in the DNS server pointing to the local IP of the server
    and it fixed the issue, kind of. Now when we click on Out of Office Assistant, we get a security certificate error and it is driving my users crazy. I have updated the SRV record and many things, still unable to get it to work. 
    Any help would be super!! 
    Thanks!

    Hi,
    1.First of all please check the name what you are using for autodiscover service is available on SAN certificate.
    2.Please check the name resolution is happening for autodiscover namespace.
    I.e if you try to resolve autodisccover.mydomain.com (or) mail.mydomain.com in your problematic PC it should have to resolved in to cas server ip address or in some scenarios it will get resolved in to LB
    3.Then please check whether you have properly set the autodiscover internal URL in all the cas servers.
    It might be like below
     https:\\autodiscover.mydomain.com\autodiscover\autodiscover.xml
    (or)  
    https:\\mail.mydomain.com\autodiscover\autodiscover.xml
    4.Then please check for the web services url in all the cas servers and that is the major thing which will make the availability services (i.e OOF,free busy lookup) to work perfectly .
    5.In the problematic please uncheck the internet proxy exceptions.
    6.You cane use test email configuration to check whether the outlook client is fetching up the proper url for autodisocver and ews .
    7.test-outlookwebservices (we can use this command to check the fuctionality of autodiscover for an problematic user account)
    8.Please check the root certificates in the problematic client to check whether it is a expired or not .Root certificates is nothing but the one which will come by default with OS .
    9.If all the above is set as perfect but still you are facing the issue.Please follow the below one and this may be not required.
    Please export the san certificate from exchnage to pfx file which should have to include the certificate key by using MMC.Then import the pfx file in to problematic client .Let us see what happens .
    Same on my side i am having few questions about your environment .
    1.Are you facing any certificate errors in OWA .Because why i am asking please check the installed SAN certificate in exchange is valid and or it is not expired ?
    2.what is the problematic client operating system veriosn?
    Please reply me if you have any issues .
    Regards
    S.Nithyanandham

  • Certificate errors on Exchange 2007

    We have a Exchange 2007 server that is recording certificate errors in the event log (server & domain names changed for post):
    Microsoft Exchange could not find a certificate that contains the domain name contoso.com in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector DNS with a FQDN parameter of contoso.com.
    Microsoft Exchange could not find a certificate that contains the domain name server.contoso.com in the personal store on the local computer.
    I have checked the configuration of the send and receive connectors:
    Get-SendConnector | FL name, fqdn, objectClass
    Name : DNS
    Fqdn : contoso.com
    ObjectClass : {top, msExchConnector, mailGateway, msExchRoutingSMTPConnector}
    Name : Host IT SMTP
    Fqdn : contoso.com
    ObjectClass : {top, msExchConnector, mailGateway, msExchRoutingSMTPConnector}
    Get-ReceiveConnector | FL name, fqdn, objectClass
    Name : Default servername
    Fqdn : servername.contoso.com
    ObjectClass : {top, msExchSmtpReceiveConnector}
    Name : Client servername
    Fqdn : servername.contoso.com
    ObjectClass : {top, msExchSmtpReceiveConnector}
    There is an installed certificate:
    {mail2.contoso.com, www.mail2.contoso.com, autodiscover.contoso.com, legacy.contoso.com} - IMAP, POP, IIS, SMTP valid until 09/01/2016
    There was a expired certificate:
    {servername, servername.contoso.com} - SMTP valid until 08/12/2010
    The fact that the mail is still working despite the expired certificate, makes me wonder if I could just change the receive connectors to use mail2.contoso.com instead of servername.contoso.com
    In the same vein, could I change the send connector to mail2.contoso.com from contoso.com

    Hi,
    Don’t modify the FQDN value on the default Receive connector Default <Server Name> that's automatically created on Mailbox servers. If you have multiple Mailbox servers in your Exchange organization and you change the FQDN value on the Default
    <Server Name> Receive connector, internal mail flow between Mailbox servers fails. For more information about it, please refer to fqdn parameter in the following article:
    http://technet.microsoft.com/en-us/library/bb125140(v=exchg.80).aspx  
    I suggest we can renew the expired certificate with names: contoso.com, servername.contoso.com instead of changing the FQDN of receive connector and send connector:
    http://blogs.technet.com/b/exchange/archive/2007/07/02/3403301.aspx  
    Thanks,
    Winnie Liang
    TechNet Community Support

  • DPM 2012 - Protect Exchange 2007 in untrusted domain (either via Creds or Certificates)

    Hi,
    I am trying to protect an Exchange 2007 Server which is in an untrusted domain.
    I have tried using both credentials (isNonDomainServer) and via Certificates and have no joy.  Both methods work in terms of getting the agent installed and communicating with DPM.  The agent shows OK in the console and I can browse
    fine when creating a new PG.
    The problem I have is that "All Exchange Storage Groups" is not available as a selection to backup, obviously neither are any of the information stores.
    First question, is backup of Exchange supported in an untrusted domain?  This says it is:  http://technet.microsoft.com/en-us/library/hh757801.aspx  but I read conflicting advice elsewhere.
    Second question, this is the biggie - any ideas on how to get Exchange visible as a selection?
    So far I have:
    Confirmed that LCR is not configured (I am not sure if it *was* at some point though, because there is a disk on the server labled LCR)
    Checked in the DPM agent directory locally and I can see that ExchangeCmdletsWrapperCurr.errlog is created and/or updated when I expand the server name on the DPM server and the server and information stores are listed in the file.  This tells me communication
    is fine, and that the DPM agent on the exchange server can "see" exchange
    Checked the Exchange VSS writer and it is listed and in a healthy state
    Thanks!

    Upgraded to System Centre 2012 R2 and no difference.  I am assuming that its a compatability\support issue, i.e its not supported.  The documentation says otherwise, but its confusing to say the least.
    d

  • Exchange 2007 - 2010 Outlook doesn't autodiscover after mailbox move

    We currently are in the process of migrating from Exchange 2007 to 2010.  When I move a mailbox to 2010, Outlook (2010 in this case), fails to connect to the new environment.  Restarting outlook does not help.  I am forced to change the
    servername in the mail applet.  How can we make this happen automagically?

    That URL points to the autodiscover.xml page on the 2010 CAS servers. Returns the typical
    <?xml version="1.0" encoding="utf-8"
    ?>
    - <Autodiscover
    xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    - <Response>
    - <Error Time="01:46:57.9070185"
    Id="814683946">
      <ErrorCode>600</ErrorCode>
      <Message>Invalid Request</Message>
      <DebugData
    />
      </Error>
      </Response>
      </Autodiscover>

Maybe you are looking for