Autodiscover

Hi Everyone!
Trying to get Blackberry 10 devices to autodiscover an Exchange Activesync server,
I'm administering this mailserver;  please don't ask me to "check with the admin"
Entering the account manually as an activesync account works fine; account get's setup and syncs without a problem
If a user navigates to Settings -> Accounts -> Add an account -> "Email, Calendar and Contacts" and fills out the username / password,  they are prompted with a "Provider Identity Not Verifiable" (no details,  only option is to cancle or continue)
Same mail account works great on iphone / android / various computers,  
Autodiscover works on all these devices,  enter email address + password,  and everything works.
Cert is publically signed, (Comodo if it's important!)
https://testconnectivity.microsoft.com returns no problems with autodiscover or pulling items from the mailbox
http://www.blackberry.com/eavt does not even display an activesync tab; only IMAP / POP3 / SMTP are displayed
On the EAVT tool,  none of the validation links appear to work,  though all services are up and working properly
As for the setup:
The domain itself is fairly simple; just web access and exchange for available services.
DNS is internally managed,  mail.domain.ca and autodiscover.domain.ca both point to the exchange server, .domain.ca and www.domain.ca both point to the web server.
Certificate was just installed a few hours ago,  
Browsing to mail.domain.ca in the web browser on a handheld confirms that the blackberry accepts and trusts the cert without a problem.  The certificate is a wildcard *.domain.ca (with a SAN covering .domain.ca as well) 
Anyone have any information that would help out here?  Got new people starting that are litterally half a world away,  and I need to get activesync working on their devices. 

That's how it's done...
How to create a Microsoft Exchange ActiveSync account with a BlackBerry PlayBook tablet or BlackBerr...
On the BlackBerry 10 smartphone:
From the home screen, swipe down and select Settings.
Select Accounts > Add Account > Advanced > Microsoft Exchange ActiveSync.
In the Description field, enter a description for the account.
In the Domain field, enter the NetBIOS Domain name (for example blackberry when the domain is called blackberry.com).
Enter the Username, Email Address and Password for the account.
In Server Address, enter the hostname of the Client Access that will handle Microsoft Exchange ActiveSync connections.
Select Next.
Select the items to sync and select  Save.
1. If any post helps you please click the below the post(s) that helped you.
2. Please resolve your thread by marking the post "Solution?" which solved it for you!
3. Install free BlackBerry Protect today for backups of contacts and data.
4. Guide to Unlocking your BlackBerry & Unlock Codes
Join our BBM Channels (Beta)
BlackBerry Support Forums Channel
PIN: C0001B7B4   Display/Scan Bar Code
Knowledge Base Updates
PIN: C0005A9AA   Display/Scan Bar Code

Similar Messages

  • Outlook autodiscover is not working for some users in coexistence

    Hi
    We are doing exchnage 2013/2010 coexistence
    Most everything is ok BUT outlook autodiscover is not working for some exchange 2010 users now that 2013 is in the front!!!.  We end up creating the profiles manually.  It has affected some but not all the users.
    I followed the instructions here but it didn't help.
    http://blogs.technet.com/b/tips_from_the_inside/archive/2012/01/11/autodiscover-fails-for-one-or-more-users.aspx
    Using outlook 2010, 2013, patches, .... didn't make a difference
    Would you please help?
    Thank you

    Hi 
    If it is affecting only few handful of users i could suspect a mailbox corruption and would recommend to move mailbox and see the results.
    Also you can try below
    You need to set the values MaxFieldLength, MaxRequestBytes & MaxTokenSize to below on Exchange 2010 CAS servers as well as Exchange 2013 CAS servers
    Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
    Name: MaxFieldLength
    Type: DWORD
    Value: 65534
    Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
    Name: MaxRequestBytes
    Type: DWORD
    Value: 16777216
    Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
    Name: MaxTokenSize
    Type: REG_DWORD
    Value: 48000 
    Just reboot the servers once its done and you will be good to go.
     References
    https://social.technet.microsoft.com/Forums/en-US/cc2929ac-4d36-4e84-a567-ce9b3bec1398/http-400-bad-request-on-iis-8-exchange-2013-cu2-on-windows-server-2012-autodiscovery-is-not?forum=exchangesvrgeneral
    http://blogs.technet.com/b/kristinw/archive/2013/03/28/recommended-changes-and-enhancements-to-support-exchange-in-an-enterprise-environment-whew.aspx
    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)

  • Cannot complete Lync2013 integration because autodiscover/metadata/json/1 does not exist

    Hello,
    I am trying to setup integration between Microsoft Lync 2013 Server and Exchange 2013 Server so that in OWA you can see presence information and also use Instant Messaging.
    I am able to complete all the steps except for the following line on the Lync server:
    New-CsPartnerApplication -Identity Exchange -ApplicationTrustLevel Full -MetadataUrl "https://autodiscover.domain.com/autodiscover/metadata/json/1"
    I am getting an error that its not found:
    New-CsPartnerApplication : Cannot bind parameter 'MetadataUrl' to the target. Exception setting "MetadataUrl": "The
    metadata document could not be downloaded from the URL in the MetadataUrl parameter or downloaded data is not a valid
    metadata document, error: The remote server returned an error: (404) Not Found."
    Now I've already followed THIS thread: http://blogs.technet.com/b/jenstr/archive/2012/11/22/getting-internal-server-error-500-when-creating-new-cspartnerapplication-for-exchange-2013.aspx  But that did not help me at all.  Nor should it because
    that particular thread is a procedure to remedy an error 500.  Remember I am getting an error 404.
    I can validate that the path to /autodiscover/metadata/json/1 does not exist because I get a 404 in any web browser that I attempt to access this path.  Also in IIS Manager on Exchange I do not even see a metadata folder.  IIS has been reset and
    also the server has been rebooted as of 7:40 AM EST today and the issue persists.
    I am not sure what goes in that location but I would be willing to accept if someone else would upload their metadata/json/1 file on SkyDrive and I could put it at this location.
    Otherwise Autodiscover service appears to be working as Outlook and Lync clients do not pose an error.  Testing e-mail autodiscover returns correct values and the paths /autodiscover/Autodiscover.svc and also autodiscover/autodiscover.xml are both reachable
    in a web browser.

    Hi KJSTech1,
    You could try to modify the autodiscover Url by following command.
    Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri "https://autodiscover.contoso.com/autodiscover/autodiscover.xml"
    Run the following command in Lync Management Shell.
    Set-CsOAuthConfiguration -Identity global -ExchangeAutodiscoverUrl "https://autodiscover.contoso.com/autodiscover/autodiscover.svc"
    After doing the above work, please re-run the New-CsPartnerApplication command to test.
    Best regards,
    Eric

  • How can I edit the way autodiscover.xml behaves in SBS 2008 and 2011?

    I have autodiscover working correctly on a few SBS 2008 and SBS 2011 servers. But, its doing its usual misbehaving. When setting up a new Outlook profile, the user enters their email address and password.  Autodiscover is successful in creating all
    the account settings, but at the end of the wizard a username and password window pops up with the users full email address incorrectly filled in as the username, which is why it didn't work.
    This has always been so annoying about SBS.  The user then has to be told to delete their email address in the username field, then fill in "domain\username" instead.  Only then is the authentication successful.
    I've read lots about people adding the external domain UPN Suffix to ADD&T, then manually changing ever users login to domain.com instead of domain.local.   Then you have to mess with the owa authentication settings in exchange to accept the
    UPN.   Its all too ridiculous.  There must be a simpler way.
    I have read about how you can control how the autodiscover.xml behaves, and there are examples of how to do it in this document:
    https://docs.google.com/viewer?a=v&q=cache:0jap1FNKgV0J:https://support.quest.com/Shared/Images/SOL51188_Outlook%2520Automatic%2520Account%2520Configuration.doc+&hl=pl&gl=pl&pid=bl&srcid=ADGEESjizUeFf-JYaM7ZdfIgUCKMMXtcCl0Y3pknFbuwd64GNHIEP1K8a_mpg2YIEisP6sz5DzbtVtdW4Pc42PE0Kjd6bz-3vXz0iaQm7FKi0AnwgvFG_41ZAkBLWynaJtf8s8xyi_d2&sig=AHIEtbSie1mEHTn8el4DPquNxrpovwknUQ
    The document above shows the settings we need to change.  It looks like we can add the local domain using DomainName into the autodiscover.xml and this will stop autodiscover reporting that the full email address is required.  So we
    should be able to get autodiscover to populate the username pop-up with with "domain\user" automatically. 
    OK, so my question is, how on earth do I edit these settings in SBS 2011?  I can't find any articles that talk about how to edit autodiscover. 
    If I could just edit this one setting (that Microsoft should have correctly configured in the first place) autodiscover will work perfectly for all existing users and all future users, without having to do anything.

    Just to straighten out a few things;
    1) This is NOT a bug, rather by design. Not every active directory has an exchange server in place, and MS is assuming you don't want to give your internal domain name out to people (which is why it doesn't default to domain\username)
    2) Going on what I said in 1), this is NOT SBS specific this is the same way with every Active Directory/Exchange install, keep in mind Microsoft did NOT specially design the software for SBS, they just bundled it into a supported configuration in a neat
    little package -since the Exchange server we run on SBS is the same Exchange server powering hundreds of hosted email providers -it makes sense why autodiscover doesn't provide the domain\username (imagine what a mess that would be!)
    3) I understand it's a little bit time consuming but it can actually be done for all users in a matter of seconds, select all users, right click and go to Properties, you can then choose the UPN Suffix for all users. When a new user gets created one of the
    settings in the wizard is the UPN suffix and is easily changeable as long as you notate for the person creating the user to do it. (The problem here is if you're using the SBS Console instead of AD to setup the User in which case that's just an oversight
    in design not a bug in the programming)
    4) You can most certainly have a powershell script that changes the UPN suffix from A to B, let me know if you're interested I'll dig one up for you. That can be run on a scheduled task and will solve the remaining issues you have :)
    I do see you mentioned it in number 3, I must have missed since I didn't re-read the OP before posting the article, however I just tested on several SBS 2011 machines and OWA authentication settings don't have to be changed at all, this worked immediately
    for Outlook Anywhere and Outlook Web Access in my lab and two different customer production systems.
    -GreenlightTech

  • Autodiscover URL returning error

    I have the AutoDiscover rule created in TMG and and it tests fine within the TMG console.
    However, when I hit the external URL lyncdiscover.domain.com I get this back:
    Unable to download / from lyncdiscover.domain.com
    Unable to open the Internet site.  The requested site is either unavailable or cannot be found.
    The rule is being hit if I filter the logging.  There just seems to be some problem with it downloading the autodiscovery info.
    Anyone else run into this?

    Here is my config that works.  I have split brain DNS, FE, Edge, and TMG with a third party firewall and TMG as the backend firewall.  I use an external web service name different than the internal pool.
    Identity                        : WebServer:<pool>.<External-Domain.com>
    FileStore                       : FileStore:<FESERVER>.<AD-DOMAIN.net>
    UserServer                      : UserServer:<pool>.<External-Domain.com>
    PrimaryHttpPort                 : 80
    PrimaryHttpsPort                : 443
    ExternalHttpPort                : 8080
    ExternalHttpsPort               : 4443
    PublishedPrimaryHttpPort        : 80
    PublishedPrimaryHttpsPort       : 443
    PublishedExternalHttpPort       : 80
    PublishedExternalHttpsPort      : 443
    ReachPrimaryPsomServerPort      : 8060
    ReachExternalPsomServerPort     : 8061
    AppSharingPortStart             : 49152
    AppSharingPortCount             : 16383
    McxSipPrimaryListeningPort      : 5086
    McxSipExternalListeningPort     : 5087
    LIServiceInternalUri            :
    https://<pool>.<External-Domain.com>/locationinformation/liservice.svc
    ABHandlerInternalUri            :
    https://<pool>.<External-Domain.com>/abs/handler
    ABHandlerExternalUri            :
    https://lyncweb.<External-Domain.com>/abs/handler
    DLExpansionInternalUri          :
    https://<pool>.<External-Domain.com>/groupexpansion/service.svc
    DLExpansionExternalUri          :
    https://lyncweb.<External-Domain.com>/groupexpansion/service.svc
    CAHandlerInternalUri            :
    https://<pool>.<External-Domain.com>/CertProv/CertProvisioningService.svc
    CAHandlerInternalAnonUri        :
    http://<pool>.<External-Domain.com>/CertProv/CertProvisioningService.svc
    CollabContentInternalUri        :
    https://<pool>.<External-Domain.com>/CollabContent
    CollabContentExternalUri        :
    https://lyncweb.<External-Domain.com>/CollabContent
    CAHandlerExternalUri            :
    https://lyncweb.<External-Domain.com>/CertProv/CertProvisioningService.svc
    DeviceUpdateDownloadInternalUri :
    https://<pool>.<External-Domain.com>/RequestHandler/ucdevice.upx
    DeviceUpdateDownloadExternalUri :
    https://lyncweb.<External-Domain.com>/RequestHandlerExt/ucdevice.upx
    DeviceUpdateStoreInternalUri    :
    http://<pool>.<External-Domain.com>/RequestHandler/Files
    DeviceUpdateStoreExternalUri    :
    https://lyncweb.<External-Domain.com>/RequestHandlerExt/Files
    RgsAgentServiceInternalUri      :
    https://<pool>.<External-Domain.com>/RgsClients/AgentService.svc
    RgsAgentServiceExternalUri      :
    https://lyncweb.<External-Domain.com>/RgsClients/AgentService.svc
    MeetExternalUri                 :
    https://lyncweb.<External-Domain.com>/Meet
    DialinExternalUri               :
    https://lyncweb.<External-Domain.com>/Dialin
    CscpInternalUri                 :
    https://<pool>.<External-Domain.com>/Cscp
    ReachExternalUri                :
    https://lyncweb.<External-Domain.com>/Reach
    ReachInternalUri                :
    https://<pool>.<External-Domain.com>/Reach
    WebTicketExternalUri            :
    https://lyncweb.<External-Domain.com>/WebTicket/WebTicketService.svc
    WebTicketInternalUri            :
    https://<pool>.<External-Domain.com>/WebTicket/WebTicketService.svc
    McxServiceExternalUri           :
    https://lyncweb.<External-Domain.com>/Mcx/McxService.svc
    McxServiceInternalUri           :
    https://<pool>.<External-Domain.com>/Mcx/McxService.svc
    AutodiscoverServiceExternalUri  :
    https://lyncweb.<External-Domain.com>/Autodiscover/AutodiscoverService.svc/root
    AutodiscoverServiceInternalUri  :
    https://<pool>.<External-Domain.com>/Autodiscover/AutodiscoverService.svc/root
    ExternalFqdn                    : lyncweb.<External-Domain.com>
    InternalFqdn                    :
    DependentServiceList            : {Registrar:<pool>.<External-Domain.com>, ConferencingServer:<pool>.<External-Domain.com>}
    ServiceId                       : 1-WebServices-1
    SiteId                          : Site:ABC
    PoolFqdn                        : <pool>.<External-Domain.com>
    Version                         : 5
    Role                            : WebServer

  • Exchange 2013 Upgrade to CU7 from SP1 - installs successfully - Can no longer connect via ECP/OWA/Powershell/Outlook/Autodiscover

    Hi There,
    I am having massive issues with my Exchange Server.
    I have 2 Nodes, one has CAS and Mailbox Roles, the other just Mailbox.
    I "upgraded" the CAS server to CU7 without any errors / issues.
    Once I had restarted, nothing worked any more..  I couldn't access ECP, OWA, Powershell, Autodiscover or get outlook to connect.
    I managed to get Powershell working, but changing the physical directory to "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell" from "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\PowerShell"
    But for the life of me I cannot get ECP or OWA working (haven't even tried anything else)!
    I am getting a load of Events with ID 1003.
    The only error I am getting is:
    Server Error in '/ecp' Application.
    Method not found: 'Boolean Microsoft.Exchange.Net.Wopi.WopiRequestPathHandler.IsWopiRequest(System.Web.HttpRequest)'.
    Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
    Exception Details: System.MissingMethodException: Method not found: 'Boolean Microsoft.Exchange.Net.Wopi.WopiRequestPathHandler.IsWopiRequest(System.Web.HttpRequest)'.
    Source Error:
    An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
    Stack Trace:
    [MissingMethodException: Method not found: 'Boolean Microsoft.Exchange.Net.Wopi.WopiRequestPathHandler.IsWopiRequest(System.Web.HttpRequest)'.]
    Microsoft.Exchange.HttpProxy.ProxyModule.AllowAnonymousRequest(HttpRequest httpRequest) +0
    Microsoft.Exchange.HttpProxy.ProxyModule.OnAuthenticateInternal(HttpApplication httpApplication) +51
    Microsoft.Exchange.HttpProxy.<>c__DisplayClass5.<OnAuthenticateRequest>b__4() +447
    Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(TryDelegate tryDelegate, FilterDelegate filterDelegate, CatchDelegate catchDelegate) +40
    Microsoft.Exchange.HttpProxy.Diagnostics.SendWatsonReportOnUnhandledException(MethodDelegate methodDelegate) +408
    System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +92
    System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +165
    Which is almost meaningless...  but maybe someone out there has some idea?
    Unfortunately this is very urgent for me a these are production servers and currently there is no email for my company.
    So Please please please can someone help.
    I have tried many many many things from various sites, and so far nothing has worked.
    Thanks,
    -Tim

    Hi Tim,
    We can do the following steps to have a try:
    1. Check Application settings in IIS Application under Exchange Back End web site for BinSearchFolders value.
    a. Open IIS Manager. Expand Sites > Exchange Back End.
    b. Click ecp. Open Application Settings in /ecp Home.
    c. Please check whether the value for “BinSearchFolders” is changed to an invalid value.
    2. Verify Authentication settings for OWA and ECP.
    a. In IIS manager > Default Web Site, make sure Anonymous Authentication is Enabled in Authentication.
    b. Confirm that "Require SSL" is checked on the root of the default website.
    c. Make sure the Basic and Forms authentications are enabled in Default Web Site and Ntlm, WindowsIntegrated authentication methods are enabled in Exchange Back End for both OWA and ECP.
    Regards,
    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected]
    Winnie Liang
    TechNet Community Support

  • Windows 8.1 Mail app and Exchange Autodiscover

    An organisation Im currently supporting has exchange 2010 and autodiscover setup. I've used nslookup to verify autodiscover settings and everything seems ok. When I launch the Windows 8.1 Mail metro app, autodiscover is not working. I have to enter all the
    required fields to get email working.
    Is this anything additionally for Windows Mail autodiscover to work that is different from autodiscover for the Outlook client that needs to be in place?
    Is it a requirement for Exchange Active sync to be enabled? I've been told they are using a 3rd party tool, possibly Sophos,
    thanks
    glen_cni

    Hi,
    As far as I know, Mail APP doesn't have autodiscover ability to identify the confirguation of Exchange. While, in my opinion, it would be better to contact the Mail APP support for further assistance:
    http://answers.microsoft.com/en-us/windows/forum/windows8_1_pr-ecoms
    Roger Lu
    TechNet Community Support

  • ActiveSync autodiscover not working for iPhone but for Android and Windows Phone

    Hi
    We have setup an Exchange 2013 hosted environment, where different mail domains are running on it.
    The main domain is mydomain.com. One of the client domains is customer.com.
    Autodiscover for customer.com has a cname which points to autodiscover.mydomain.com, on our firewall this url is redirected to autodiscover-s.mydomain.com, where our public certificate for mydomain.com is applied. Autodiscover for all
    our customers finally ends at autodiscover-s.mydomain.com.
    Outlook WebApp, Outlook Anywhere and ActiveSync for all customers is reachable through mail.mydomain.com.
    Everything works fine, except of autodiscover for iPhones. I always have to enter the server name mail.mydomain.com manually. After that ActiveSync works on iPhones as well.
    The Problem doesn’t exist on Androids and Windows Phones.
    Any suggestion?
    Regards
    Peter

    Yes, Interestingly same configuration is working in my home lab, but not working at customer. The version is 10.5
    Cannot say wireless issue as jabber for windows is working from wireless

  • Autodiscover is ok with selfssl but problem in outlook exchange 2013

    hi,
    Finally i can setup autodiscover service with self ssl, here is the result 
     Submit  
    Connectivity Test Successful
    Test Details
    The Microsoft Connectivity Analyzer is attempting to test Autodiscover for [email protected].
    Autodiscover was tested successfully.
    Additional Details
    Elapsed Time: 18255 ms.
    Test Steps
    Attempting each method of contacting the Autodiscover service.
    The Autodiscover service was tested successfully.
    Additional Details
    Elapsed Time: 18255 ms.
    Test Steps
    Attempting to test potential Autodiscover URL https://mail.tulisoft.co.in/AutoDiscover/AutoDiscover.xml
    Testing of the Autodiscover URL was successful.
    Additional Details
    Elapsed Time: 18252 ms.
    Test Steps
    Attempting to resolve the host name mail.tulisoft.co.in in DNS.
    The host name resolved successfully.
    Additional Details
    IP addresses returned: 138.91.34.29
    Elapsed Time: 146 ms.
    Testing TCP port 443 on host mail.tulisoft.co.in to ensure it's listening and open.
    The port was opened successfully.
    Additional Details
    Elapsed Time: 260 ms.
    Testing the SSL certificate to make sure it's valid.
    The certificate passed all validation requirements.
    Additional Details
    Elapsed Time: 661 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server mail.tulisoft.co.in on port 443.
    The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
    Additional Details
    Remote Certificate Subject: CN=mail.mail.tulisoft.co.in, Issuer: CN=mail.mail.tulisoft.co.in.
    Elapsed Time: 638 ms.
    Validating the certificate name.
    The certificate name was validated successfully.
    Additional Details
    Host name mail.tulisoft.co.in was found in the Certificate Subject Alternative Name entry.
    Elapsed Time: 0 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 = 5/5/2014 7:18:25 AM, NotAfter = 5/5/2019 7:18:25 AM
    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: 953 ms.
    Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
    The Microsoft Connectivity Analyzer successfully retrieved Autodiscover settings by sending an Autodiscover POST.
    Additional Details
    Elapsed Time: 16229 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://mail.tulisoft.co.in/AutoDiscover/AutoDiscover.xml for user [email protected].
    The Autodiscover XML response was successfully retrieved.
    Additional Details
    Autodiscover Account Settings
    XML response:
    <?xml version="1.0"?>
    <Autodiscover xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <User>
    <DisplayName>mailadmin</DisplayName>
    <LegacyDN>/o=Tulisoft/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=594a81cd32dc4d488dbf698230a8a5bf-mailadmin</LegacyDN>
    <DeploymentId>e2467991-8c60-4245-91b9-1518067363a0</DeploymentId>
    </User>
    <Account>
    <AccountType>email</AccountType>
    <Action>settings</Action>
    <Protocol>
    <Type>EXCH</Type>
    <Server>[email protected]</Server>
    <ServerDN>/o=Tulisoft/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/[email protected]</ServerDN>
    <ServerVersion>73C08204</ServerVersion>
    <MdbDN>/o=Tulisoft/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/[email protected]/cn=Microsoft Private MDB</MdbDN>
    <ASUrl>https://mail.mail.tulisoft.co.in/EWS/Exchange.asmx</ASUrl>
    <OOFUrl>https://mail.mail.tulisoft.co.in/EWS/Exchange.asmx</OOFUrl>
    <OABUrl>https://mail.mail.tulisoft.co.in/OAB/22012d7f-80de-41bb-b2bf-4a52355ffdec/</OABUrl>
    <UMUrl>https://mail.mail.tulisoft.co.in/EWS/UM2007Legacy.asmx</UMUrl>
    <Port>0</Port>
    <DirectoryPort>0</DirectoryPort>
    <ReferralPort>0</ReferralPort>
    <PublicFolderServer>mail.mail.tulisoft.co.in</PublicFolderServer>
    <AD>mail.mail.tulisoft.co.in</AD>
    <EwsUrl>https://mail.mail.tulisoft.co.in/EWS/Exchange.asmx</EwsUrl>
    <EmwsUrl>https://mail.mail.tulisoft.co.in/EWS/Exchange.asmx</EmwsUrl>
    <EcpUrl>https://mail.mail.tulisoft.co.in/ecp/</EcpUrl>
    <EcpUrl-um>?rfr=olk&amp;p=customize/voicemail.aspx&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-um>
    <EcpUrl-aggr>?rfr=olk&amp;p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-aggr>
    <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?rfr=olk&amp;exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;&amp;realm=mail.tulisoft.co.in</EcpUrl-mt>
    <EcpUrl-ret>?rfr=olk&amp;p=organize/retentionpolicytags.slab&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-ret>
    <EcpUrl-sms>?rfr=olk&amp;p=sms/textmessaging.slab&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-sms>
    <EcpUrl-publish>customize/calendarpublishing.slab?rfr=olk&amp;exsvurl=1&amp;FldID=&lt;FldID&gt;&amp;realm=mail.tulisoft.co.in</EcpUrl-publish>
    <EcpUrl-photo>PersonalSettings/EditAccount.aspx?rfr=olk&amp;chgPhoto=1&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-photo>
    <EcpUrl-tm>?rfr=olk&amp;ftr=TeamMailbox&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-tm>
    <EcpUrl-tmCreating>?rfr=olk&amp;ftr=TeamMailboxCreating&amp;SPUrl=&lt;SPUrl&gt;&amp;Title=&lt;Title&gt;&amp;SPTMAppUrl=&lt;SPTMAppUrl&gt;&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-tmCreating>
    <EcpUrl-tmEditing>?rfr=olk&amp;ftr=TeamMailboxEditing&amp;Id=&lt;Id&gt;&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-tmEditing>
    <EcpUrl-extinstall>Extension/InstalledExtensions.slab?rfr=olk&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-extinstall>
    <ServerExclusiveConnect>off</ServerExclusiveConnect>
    </Protocol>
    <Protocol>
    <Type>EXPR</Type>
    <Server>mail.mail.tulisoft.co.in</Server>
    <ASUrl>https://mail.tulisoft.co.in/ews/exchange.asmx</ASUrl>
    <OOFUrl>https://mail.tulisoft.co.in/ews/exchange.asmx</OOFUrl>
    <OABUrl>https://mail.tulisoft.co.in/OAB/22012d7f-80de-41bb-b2bf-4a52355ffdec/</OABUrl>
    <UMUrl>https://mail.tulisoft.co.in/ews/UM2007Legacy.asmx</UMUrl>
    <Port>0</Port>
    <DirectoryPort>0</DirectoryPort>
    <ReferralPort>0</ReferralPort>
    <SSL>On</SSL>
    <AuthPackage>Ntlm</AuthPackage>
    <EwsUrl>https://mail.tulisoft.co.in/ews/exchange.asmx</EwsUrl>
    <EmwsUrl>https://mail.tulisoft.co.in/ews/exchange.asmx</EmwsUrl>
    <EcpUrl>https://mail.tulisoft.co.in/ecp/</EcpUrl>
    <EcpUrl-um>?rfr=olk&amp;p=customize/voicemail.aspx&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-um>
    <EcpUrl-aggr>?rfr=olk&amp;p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-aggr>
    <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?rfr=olk&amp;exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;&amp;realm=mail.tulisoft.co.in</EcpUrl-mt>
    <EcpUrl-ret>?rfr=olk&amp;p=organize/retentionpolicytags.slab&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-ret>
    <EcpUrl-sms>?rfr=olk&amp;p=sms/textmessaging.slab&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-sms>
    <EcpUrl-publish>customize/calendarpublishing.slab?rfr=olk&amp;exsvurl=1&amp;FldID=&lt;FldID&gt;&amp;realm=mail.tulisoft.co.in</EcpUrl-publish>
    <EcpUrl-photo>PersonalSettings/EditAccount.aspx?rfr=olk&amp;chgPhoto=1&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-photo>
    <EcpUrl-tm>?rfr=olk&amp;ftr=TeamMailbox&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-tm>
    <EcpUrl-tmCreating>?rfr=olk&amp;ftr=TeamMailboxCreating&amp;SPUrl=&lt;SPUrl&gt;&amp;Title=&lt;Title&gt;&amp;SPTMAppUrl=&lt;SPTMAppUrl&gt;&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-tmCreating>
    <EcpUrl-tmEditing>?rfr=olk&amp;ftr=TeamMailboxEditing&amp;Id=&lt;Id&gt;&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-tmEditing>
    <EcpUrl-extinstall>Extension/InstalledExtensions.slab?rfr=olk&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-extinstall>
    <ServerExclusiveConnect>on</ServerExclusiveConnect>
    <EwsPartnerUrl>https://mail.tulisoft.co.in/ews/exchange.asmx</EwsPartnerUrl>
    </Protocol>
    <Protocol>
    <Type>WEB</Type>
    <Port>0</Port>
    <DirectoryPort>0</DirectoryPort>
    <ReferralPort>0</ReferralPort>
    <Internal>
    <OWAUrl AuthenticationMethod="Basic, Fba">https://mail.mail.tulisoft.co.in/owa/</OWAUrl>
    <Protocol>
    <Type>EXCH</Type>
    <ASUrl>https://mail.mail.tulisoft.co.in/EWS/Exchange.asmx</ASUrl>
    </Protocol>
    </Internal>
    <External>
    <OWAUrl AuthenticationMethod="Fba">https://mail.tulisoft.co.in/owa/</OWAUrl>
    <Protocol>
    <Type>EXPR</Type>
    <ASUrl>https://mail.tulisoft.co.in/ews/exchange.asmx</ASUrl>
    </Protocol>
    </External>
    </Protocol>
    <Protocol>
    <Type>EXHTTP</Type>
    <Server>mail.mail.tulisoft.co.in</Server>
    <ASUrl>https://mail.mail.tulisoft.co.in/EWS/Exchange.asmx</ASUrl>
    <OOFUrl>https://mail.mail.tulisoft.co.in/EWS/Exchange.asmx</OOFUrl>
    <OABUrl>https://mail.mail.tulisoft.co.in/OAB/22012d7f-80de-41bb-b2bf-4a52355ffdec/</OABUrl>
    <UMUrl>https://mail.mail.tulisoft.co.in/EWS/UM2007Legacy.asmx</UMUrl>
    <Port>0</Port>
    <DirectoryPort>0</DirectoryPort>
    <ReferralPort>0</ReferralPort>
    <SSL>On</SSL>
    <AuthPackage>Ntlm</AuthPackage>
    <EwsUrl>https://mail.mail.tulisoft.co.in/EWS/Exchange.asmx</EwsUrl>
    <EmwsUrl>https://mail.mail.tulisoft.co.in/EWS/Exchange.asmx</EmwsUrl>
    <EcpUrl>https://mail.mail.tulisoft.co.in/ecp/</EcpUrl>
    <EcpUrl-um>?rfr=olk&amp;p=customize/voicemail.aspx&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-um>
    <EcpUrl-aggr>?rfr=olk&amp;p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-aggr>
    <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?rfr=olk&amp;exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;&amp;realm=mail.tulisoft.co.in</EcpUrl-mt>
    <EcpUrl-ret>?rfr=olk&amp;p=organize/retentionpolicytags.slab&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-ret>
    <EcpUrl-sms>?rfr=olk&amp;p=sms/textmessaging.slab&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-sms>
    <EcpUrl-publish>customize/calendarpublishing.slab?rfr=olk&amp;exsvurl=1&amp;FldID=&lt;FldID&gt;&amp;realm=mail.tulisoft.co.in</EcpUrl-publish>
    <EcpUrl-photo>PersonalSettings/EditAccount.aspx?rfr=olk&amp;chgPhoto=1&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-photo>
    <EcpUrl-tm>?rfr=olk&amp;ftr=TeamMailbox&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-tm>
    <EcpUrl-tmCreating>?rfr=olk&amp;ftr=TeamMailboxCreating&amp;SPUrl=&lt;SPUrl&gt;&amp;Title=&lt;Title&gt;&amp;SPTMAppUrl=&lt;SPTMAppUrl&gt;&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-tmCreating>
    <EcpUrl-tmEditing>?rfr=olk&amp;ftr=TeamMailboxEditing&amp;Id=&lt;Id&gt;&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-tmEditing>
    <EcpUrl-extinstall>Extension/InstalledExtensions.slab?rfr=olk&amp;exsvurl=1&amp;realm=mail.tulisoft.co.in</EcpUrl-extinstall>
    <ServerExclusiveConnect>On</ServerExclusiveConnect>
    </Protocol>
    </Account>
    </Response>
    </Autodiscover>
    HTTP Response Headers:
    request-id: cdaeb3ce-1849-4e7e-8b84-16f43f2507a0
    X-TargetBEServer: mail.mail.tulisoft.co.in
    X-DiagInfo: MAIL
    Persistent-Auth: true
    X-FEServer: MAIL
    Content-Length: 9094
    Cache-Control: private
    Content-Type: text/xml; charset=utf-8
    Date: Tue, 06 May 2014 15:21:59 GMT
    Set-Cookie: X-BackEndCookie=S-1-5-21-1925192757-1526100558-3211384720-500=u56Lnp2ejJqBzM3Ix8qanJzSmZqbx9LLnpnI0sbKmc3Syc7Oys+azsbJyJ7KgYHK0MnQzc/Oy9/MxczOxcrG36+y; expires=Tue, 06-May-2014 15:31:59 GMT; path=/AutoDiscover; secure; HttpOnly
    Server: Microsoft-IIS/8.5
    X-AspNet-Version: 4.0.30319
    X-Powered-By: ASP.NET
    Elapsed Time: 16229 ms.
    © 2013 Microsoft | Version 3.2 | Feedback | Privacy | Terms of Use
    now when going to setup outlook 2013 its saying
    "An Encrypted connection to your mail server   not available "
     and its not configuring anyway please help.. 

    Hi,
    Firstly, I’d like to explain, in Exchange 2013, all Outlook use Outlook Anywhere connect to Exchange server. Autodiscover service just help to get all information that Outlook client needs.
    Thus, for the failure of configuring account, I recommend you the following troubleshooting:
    1. Try to manually configure the account: please note the server name option should be filled with the user mailbox GUID:
    [email protected]
    To confirm it, you can run : get-mailbox name |fl exchangeGUID
    2. Check if all users cannot be added in all Outlook clients.
    3. Check the Outlook Anywhere configuration and certificate:
    Get-outlookanywhere |fl
    Get-exchangecertificate |fl
    If you have any question, please feel free to let me know.
    Thanks,
    Angela Shi
    TechNet Community Support

  • 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?

  • Exchange 2013 Autodiscover and Webservices virtual directories with wrong address

    Hey people,
    I have 3 2013 Servers
    Server 1 CAS
    Server 2 & 3 MBX
    having a bit of trouble here - everything was working fine after migration (about 6months ago), and now mac users can't access e-mail.
     If I try to access EWS page (https://webmail.domain.co.ao/EWS/exchange.asmx) , i get
    Service
    You have created a service.
    To test this service, you will need to create a client and use it to call the service. You can do this using the svcutil.exe tool from the command line with the following syntax:
    svcutil.exe https://SERVER2.domain.int:444/EWS/Services.wsdl
    If I try to access the autodiscover webpage, i get
    <?xml version="1.0" encoding="UTF-8"?>
    -<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">-<Response>-<Error Id="1286627925" Time="17:58:59.7730521"><ErrorCode>600</ErrorCode><Message>Invalid Request</Message><DebugData/></Error></Response></Autodiscover>
    When testing outlook web services, i get the following error
    [PS] C:\Windows\system32>Test-OutlookWebServices
    Source ServiceEndpoint Scenario Result Latency
    (MS)
    SERVER2.domain.int webmail.domain.co.ao Autodiscover: Outlook Provider Failure 64
    SERVER2.domain.int Exchange Web Services Skipped 0
    SERVER2.domain.int Availability Service Skipped 0
    SERVER2.domain.int Offline Address Book Skipped 0
    if i run
    [PS] C:\Windows\system32>Get-AutodiscoverVirtualDirectory | fl
    Creating a new session for implicit remoting of "Get-AutodiscoverVirtualDirectory" command...
    RunspaceId : 9f23dad1-7806-42a6-8545-89b66847a359
    Name : Autodiscover (Default Web Site)
    InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}
    ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}
    LiveIdNegotiateAuthentication : False
    WSSecurityAuthentication : True
    LiveIdBasicAuthentication : False
    BasicAuthentication : True
    DigestAuthentication : False
    WindowsAuthentication : True
    OAuthAuthentication : True
    AdfsAuthentication : False
    MetabasePath : IIS://SERVER1.domain.int/W3SVC/1/ROOT/Autodiscover
    Path : C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\Autodiscover
    ExtendedProtectionTokenChecking : None
    ExtendedProtectionFlags : {}
    ExtendedProtectionSPNList : {}
    AdminDisplayVersion : Version 15.0 (Build 775.38)
    Server : SERVER1
    InternalUrl : https://webmail.domain.co.ao/autodiscover/autodiscover.xml
    ExternalUrl : https://webmail.domain.co.ao/autodiscover/autodiscover.xml
    AdminDisplayName :
    ExchangeVersion : 0.10 (14.0.100.0)
    DistinguishedName : CN=Autodiscover (Default Web
    Site),CN=HTTP,CN=Protocols,CN=SERVER1A,CN=Servers,CN=Exchange Administrative
    Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=DOMAIN,CN=Microsoft
    Exchange,CN=Services,CN=Configuration,DC=domain,DC=int
    Identity : SERVERONE\Autodiscover (Default Web Site)
    Guid : fbed978f-7442-46ac-bb3c-53d9d7995507
    ObjectCategory : domain.int/Configuration/Schema/ms-Exch-Auto-Discover-Virtual-Directory
    ObjectClass : {top, msExchVirtualDirectory, msExchAutoDiscoverVirtualDirectory}
    WhenChanged : 12/19/2013 10:30:26 AM
    WhenCreated : 12/19/2013 10:30:26 AM
    WhenChangedUTC : 12/19/2013 9:30:26 AM
    WhenCreatedUTC : 12/19/2013 9:30:26 AM
    OrganizationId :
    OriginatingServer : DC2.domain.int
    IsValid : True
    ObjectState : Changed
    and run
    [PS] C:\Windows\system32>Get-WebServicesVirtualDirectory | fl
    RunspaceId : 9f23dad1-7806-42a6-8545-89b66847a359
    CertificateAuthentication :
    InternalNLBBypassUrl :
    GzipLevel : High
    MRSProxyEnabled : False
    Name : EWS (Default Web Site)
    InternalAuthenticationMethods : {Basic, Digest}
    ExternalAuthenticationMethods : {Basic, Digest}
    LiveIdNegotiateAuthentication :
    WSSecurityAuthentication : False
    LiveIdBasicAuthentication : False
    BasicAuthentication : True
    DigestAuthentication : True
    WindowsAuthentication : False
    OAuthAuthentication : False
    AdfsAuthentication : False
    MetabasePath : IIS://SERVER1.domain.int/W3SVC/1/ROOT/EWS
    Path : C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\EWS
    ExtendedProtectionTokenChecking : None
    ExtendedProtectionFlags : {}
    ExtendedProtectionSPNList : {}
    AdminDisplayVersion : Version 15.0 (Build 775.38)
    Server : SERVER1
    InternalUrl : https://webmail.domain.co.ao/EWS/exchange.asmx
    ExternalUrl : https://webmail.domain.co.ao/EWS/exchange.asmx
    AdminDisplayName :
    ExchangeVersion : 0.10 (14.0.100.0)
    DistinguishedName : CN=EWS (Default Web Site),CN=HTTP,CN=Protocols,CN=SERVRE1,CN=Servers,CN=Exchange
    Administrative Group (FYDIBOHF23SPDLT),CN=Administrative
    Groups,CN=DOMAINL,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domainl,DC=int
    Identity : SERVER1\EWS (Default Web Site)
    Guid : cbdd447b-54f8-4bba-9834-6c28b807711e
    ObjectCategory : domain.int/Configuration/Schema/ms-Exch-Web-Services-Virtual-Directory
    ObjectClass : {top, msExchVirtualDirectory, msExchWebServicesVirtualDirectory}
    WhenChanged : 12/19/2013 9:31:11 AM
    WhenCreated : 12/19/2013 9:31:11 AM
    WhenChangedUTC : 12/19/2013 8:31:11 AM
    WhenCreatedUTC : 12/19/2013 8:31:11 AM
    OrganizationId :
    OriginatingServer : DC2.domain.int
    IsValid : True
    ObjectState : Changed
    Summarizing:
    webmail.domain.co.ao maps to server1
    Autodiscover and exchange web services point out to server1 (CAS), but when openning the respective webpages, the result is an error.
    I have already deleted and recreated the autodiscover and EWS virtual directories but with no success.
    Help anyone?
    Many thanks,
    Andrey

    Hi Andrey,
    Exchange Web Service in Exchange server configuration is working for all users in your Exchange environment, not just for one specific user. If you want to double make sure the EWS service in client side, we can directly access the EWS URL in IE of your
    Windows machine, and see whether a proper XML file is returned. If so, then we can safely ignore the web service test result.
    As for automatic signature application, do you mean
    Add a signature automatically to every message? Please try to remove the signature and reset it again to check whether the issue persists.
    Thanks,
    Winnie Liang
    TechNet Community Support

  • .local domain and autodiscover issues

    I want to preface this by saying I am a new administrator.
    Our SSL cert recently expired, and since .local domains can no longer be on certs, were registered a CA cert with autodiscover.domain.com and mail.domain.com. This new cert was successfully applied, but whenever someones opens their e-mail they get a warning
    about the name on the server not matching the cert. I
    I'm pretty sure this is juts a few DNS records I need to update but I don't know which ones and really need some guidance.
    Thanks for your time.

    So what you are saying is that his current DNS for company.com (which his internal users use for external access) needs to be duplicated internally, then modified to support his internal email access?  I've set up many systems where internal DNS and
    external DNS hosted the same name, and it is far from simple as "a new zone takes less than a minute to create".  How do you handle internal access to external sites (which is currently working just fine with his external DNS)?
    To answer your question, my recommendation is that his internal clients use AutoDiscover to gain their internal settings. Keep in mind that while the Exchange server may be in the .local domain, the SMTP domain they host is a .com domain. And since his servers
    are in a domain, any domain-attached Outlook client will be able to access the mailbox successfully.
    Just create a new DNS record pointing to the external host.  Or get a new domain name that doesn't have external websites, then create a new DNS zone for that.
    Alright, so with your recommendation - he updates his clients to use Autodiscover, which they are likely already using, to gain internal settings.  And then what do you configure the internal URLs as?  
    For example - Autodiscover.
    You set the AutoDiscoverServiceInternalURI to servername.domain.local -> he still gets a cert prompt every time he opens Outlook.
    You set the AutoDiscoverServiceInternalURI to mail.domain.com to match the certificate -> Now ALL autodiscover requests from all clients are going out to the internet, then back into the Public VIP.  
    Same with EWS.  And this is assuming he's using RPC/TCP rather than HTTP.  So then he's either going to get prompts for cert every time he opens outlook and checks OOF or mailtips, or all internal clients are going to use the external VIP for Autodiscover
    and EWS. 

  • Autodiscover, domain controllers, and certificate errors

    I have just deployed and Exchange 2013 server in one of my sites. I'm having tons of issues with it, but one issue I'm having trouble thinking through goes like this:
    All users have email addresses that are [email protected] Domain.com is our internal domain name and also a public domain. Now, in a Windows environment, if you were to nslookup domain.com within our network it
    will resolve to any one of the domain controllers. On our infrastructure master DC there is an IIS website, with SSL, that handles certificate services for our internal CA.
    Here's my problem: When a user opens Outlook and autodiscover attempts to find their Exchange connection info it first tries to reach the site
    https://domain.com/autodiscover/autodiscover.xml. If that PC happens to resolve domain.com to the DC that has our certificate services website on it then the Outlook client sends a certificate error.
    If the client is prior to Outlook 2013, the mailbox configuration just halts and throws an error.
    What do I do to prevent this?

    Hi,
    Yes, we can have the following “switchers”
    PreferLocalXML
    ExcludeHttpRedirect
    ExcludeHttpsAutoDiscoverDomain
    ExcludeHttpsRootDomain
    ExcludeScpLookup
    ExcludeSrvRecord
    ExcludeLastKnownGoodUR
    Thanks,
    Simon Wu
    TechNet Community Support

  • Exchange AutoDiscover not working correctly in 2010/2013 environment

    Here's my setup:
    Mixed environment transitioning:
    Exchange 2010 running on Server 2008 in a VM
    Exchange 2013 running on Server 2012 in a VM
    I have split dns so that autodiscover.domain.com points to my 2013 server internally and my 2010 server externally.  When setting up new profiles in outlook internally, autodiscover seems to work fine.  However, when I try moving the public autodiscover.domain.com
    DNS record over to the 2013, things stop working (like auto profile setup). 
    I know that the 2013 server is reachable from the outside because mail.domain.com will to go owa and ecp without a problem.  I can log in to both without an issue.
    If I point public DNS back to my 2010 server, then all is well again with outlook anywhere and mobile connectivity.
    I'm not really sure what needs to be tweaked for the 2013 server to be ready to take over the day to day communications so that I can decommission my 2010 server.
    Here are the results of the connectivity analyzer:
    The Microsoft Connectivity Analyzer is attempting to test Autodiscover for me.
    Testing Autodiscover failed.
    Additional Details
    Elapsed Time: 1774 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: 1773 ms.
    Test Steps
    Attempting to test potential Autodiscover URL https://domain.com:443/Autodiscover/Autodiscover.xml
    Testing of this potential Autodiscover URL failed.
    Additional Details
    Elapsed Time: 489 ms.
    Test Steps
    Attempting to resolve the host name domain.com in DNS.
    The host name resolved successfully.
    Additional Details
    IP addresses returned: 98.129.228.152
    Elapsed Time: 165 ms.
    Testing TCP port 443 on host domain.com to ensure it's listening and open.
    The port was opened successfully.
    Additional Details
    Elapsed Time: 97 ms.
    Testing the SSL certificate to make sure it's valid.
    The SSL certificate failed one or more certificate validation checks.
    Additional Details
    Elapsed Time: 225 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server domain.com on port 443.
    The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
    Additional Details
    Remote Certificate Subject: CN=www.domain.com, OU=Domain Control Validated - RapidSSL(R), OU=See www.rapidssl.com/resources/cps (c)09, OU=2150198723, O=www.domain.com, C=US, Issuer: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US.
    Elapsed Time: 170 ms.
    Validating the certificate name.
    Certificate name validation failed.
    Tell me more about this issue and how to resolve it
    Additional Details
    Host name domain.com doesn't match any name found on the server certificate CN=www.domain.com, OU=Domain Control Validated - RapidSSL(R), OU=See www.rapidssl.com/resources/cps (c)09, OU=2150198723, O=www.domain.com, C=US.
    Elapsed Time: 1 ms.
    Attempting to test potential Autodiscover URL https://autodiscover.domain.com:443/Autodiscover/Autodiscover.xml
    Testing of this potential Autodiscover URL failed.
    Additional Details
    Elapsed Time: 1009 ms.
    Test Steps
    Attempting to resolve the host name autodiscover.domain.com in DNS.
    The host name resolved successfully.
    Additional Details
    IP addresses returned: x.x.x.x
    Elapsed Time: 70 ms.
    Testing TCP port 443 on host autodiscover.domain.com to ensure it's listening and open.
    The port was opened successfully.
    Additional Details
    Elapsed Time: 189 ms.
    Testing the SSL certificate to make sure it's valid.
    The certificate passed all validation requirements.
    Additional Details
    Elapsed Time: 300 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server autodiscover.domain.com on port 443.
    The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
    Additional Details
    Remote Certificate Subject: CN=mail.domain.com, OU=PositiveSSL Multi-Domain, OU=Domain Control Validated, Issuer: CN=PositiveSSL CA 2, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB.
    Elapsed Time: 220 ms.
    Validating the certificate name.
    The certificate name was validated successfully.
    Additional Details
    Host name autodiscover.domain.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=mail.domain.com, OU=PositiveSSL Multi-Domain, 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=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE.
    Elapsed Time: 34 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 = 5/19/2014 12:00:00 AM, NotAfter = 5/18/2016 11:59:59 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: 276 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: 172 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.domain.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 Unknown.HTTP Response Headers:
    Connection: close
    Content-Length: 315
    Content-Type: text/html; charset=us-ascii
    Date: Sat, 19 Jul 2014 03:44:42 GMT
    Server: Microsoft-HTTPAPI/2.0
    Elapsed Time: 171 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: 207 ms.
    Test Steps
    Attempting to resolve the host name autodiscover.domain.com in DNS.
    The host name resolved successfully.
    Additional Details
    IP addresses returned: x.x.x.x
    Elapsed Time: 15 ms.
    Testing TCP port 80 on host autodiscover.domain.com to ensure it's listening and open.
    The port was opened successfully.
    Additional Details
    Elapsed Time: 76 ms.
    The Microsoft Connectivity Analyzer is checking the host autodiscover.domain.com for an HTTP redirect to the Autodiscover service.
    The Microsoft Connectivity Analyzer failed to get an HTTP redirect response for Autodiscover.
    Additional Details
    An HTTP 403 forbidden response was received. The response appears to have come from Unknown. Body of the response: HTTP Response Headers:
    X-FEServer: SMSE2013
    Content-Length: 0
    Date: Sat, 19 Jul 2014 03:44:42 GMT
    Server: Microsoft-IIS/8.0
    X-Powered-By: ASP.NET
    Elapsed Time: 115 ms.
    Attempting to contact the Autodiscover service using the DNS SRV redirect method.
    The Microsoft Connectivity Analyzer failed to contact the Autodiscover service using the DNS SRV redirect method.
    Additional Details
    Elapsed Time: 39 ms.
    Test Steps
    Attempting to locate SRV record _autodiscover._tcp.domain.com in DNS.
    The Autodiscover SRV record wasn't found in DNS.
    Tell me more about this issue and how to resolve it
    Additional Details
    Elapsed Time: 39 ms.
    Checking if there is an autodiscover CNAME record in DNS for your domain 'domain.com' for Office 365.
    Failed to validate autodiscover CNAME record in DNS. If your mailbox isn't in Office 365, you can ignore this warning.
    Tell me more about this issue and how to resolve it
    Additional Details
    There is no Autodiscover CNAME record for your domain 'domain.com'.
    Elapsed Time: 28 ms.
    I just double checked my SSL cert and it has the three typical entries:
    DNS Name=mail.domain.com
    DNS Name=AutoDiscover.domian.com
    DNS Name=domain.com
    I have assembled the output for the following commands
    HERE
    Get-OutlookProvider | fl
    Get-OutlookAnywhere | fl
    Get-ActiveSyncVirtualDirectory | fl
    Get-AutodiscoverVirtualDirectory | fl
    Get-EcpVirtualDirectory | fl
    Get-OabVirtualDirectory | fl
    Get-OwaVirtualDirectory | fl
    Get-PowerShellVirtualDirectory | fl
    Get-WebServicesVirtualDirectory | fl
    Text
    I have gone through the Exchange Server Deployment Assistant.  Almost everything was as it should have been.  I made some changes in the "Enable and configure Outlook Anywhere" and "Configure
    service connection point."
    I have switched external DNS over to my 2013 server, and the connectivity test is still failing.  It is also not proxying the 2010 mailboxes through 2013 as it should (according to the Deployment Assistant).
    I have a 2010 test account and a 2013 test account.  Both work fine in their respective WebMail's, but the 2010 mailbox will not pull up through the 2013 WebMail.
    Just for the heck of it, I have checked my SonicWall and it is configured the same for the 2010 host and the 2013 host.  I knew that ports 80 and 443 were passing on both hosts anyway because the port 80 redirect works and https webmail works
    on both hosts.
    If I try to access the xml file directly on both hosts:
    https://mail.domain.com/Autodiscover/Autodiscover.xml (2013)
    https://webmail.domain.com/Autodiscover/Autodiscover.xml
    (2010)
    I do get an xml response from both of them after authenticating like this:
    <Autodiscover>
    <Response>
    <Error Time="18:17:41.0173284" Id="2526055628">
    ErrorCode>600</ErrorCode>
    <Message>Invalid Request</Message>
    <DebugData/>
    </Error>
    </Response>
    </Autodiscover>
    Sooo...I'm stuck.

    Update since my last post.
    I have all mailboxes migrated off of 2010 and onto 2013.  I'm ready to turn 2010 off as soon as I can figure out this autodiscover problem and get mail flow going in and out of the 2013 server instead of the 2010 one.
    Brian, I had a http redirect enabled in 2013.  I disabled that redirect and checked for any others.  There is currently no redirect in place anywhere under the default web site (the root site now goes to an IIS 8 page).  AutoDiscover is still
    failing according to the Exchange Connectivity site.
    When I switch autodiscover.domain.com over to the 2013 server I still get failures:
    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: 146 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.domain.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 Unknown.HTTP Response Headers:
    Connection: close
    Content-Length: 315
    Content-Type: text/html; charset=us-ascii
    Date: Mon, 11 Aug 2014 16:50:27 GMT
    Server: Microsoft-HTTPAPI/2.0
    Elapsed Time: 145 ms.
    If I try to hit the xml manually, I get the expected 600 error after providing a username and password.  Should IIS be prompting for credentials when hitting the path for AutoDiscover.xml directly?
    <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    <Response>
    <Error Time="10:53:38.3228589" Id="36607859">
    <ErrorCode>600</ErrorCode>
    <Message>Invalid
    Request</Message>
    <DebugData/>
    </Error>
    </Response>
    </Autodiscover>
    If I switch autodiscover.domain.com back over to my 2010 server the test passes:
    Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
    The Microsoft Connectivity Analyzer successfully retrieved Autodiscover settings by sending an Autodiscover POST.
    Additional Details
    Elapsed Time: 444 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.domain.com:443/Autodiscover/Autodiscover.xml for user [email protected].
    The Autodiscover XML response was successfully retrieved.
    Additional Details
    Autodiscover Account Settings
    XML response:
    <?xml version="1.0"?>
    <Autodiscover xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/mobilesync/responseschema/2006">
    <Culture>en:us</Culture>
    <User>
    <DisplayName>Exchange 2013. Test</DisplayName>
    <EMailAddress>[email protected]</EMailAddress>
    </User>
    <Action>
    <Settings>
    <Server>
    <Type>MobileSync</Type>
    <Name>https://mail.domain.com/Microsoft-Server-ActiveSync</Name>
    </Server>
    </Settings>
    </Action>
    </Response>
    </Autodiscover>HTTP Response Headers:
    Persistent-Auth: true
    Content-Length: 736
    Cache-Control: private
    Content-Type: text/xml; charset=utf-8
    Date: Mon, 11 Aug 2014 17:08:12 GMT
    Server: Microsoft-IIS/7.5
    X-AspNet-Version: 2.0.50727
    X-Powered-By: ASP.NET
    Elapsed Time: 444 ms.
    One interesting thing to note, is that <Url>https://mail.domain.com/Microsoft-Server-ActiveSync</Url>
    is my 2013 server, not my 2010 server

  • Exchange 2013 autodiscover not working from Externally

    Hi 
    i have exchange 2010 sp3(2Mb, 2hub/cas). I installed exchange 2013 servers(2MB, 2CAS). For coexistence i generated new certifcate with new cas from third party. I installed that certificate in that cas and assigned all services. i changed all my virtual
    directories service url. I didnt import the new certificate to exchange 2010 cas server and i didnt change url to legacy link.But still iam able to check exchange 2010 user mailbox owa, activesync and autodiscover without any certificate error. 
    If i try to browse owa, its going to 2013 server, if user is exchange 2010 user and its redirecting to exchange 2010 owa with same link.
    But i dont know how above things is working without importing to new certificate...
    Main problem is i am not able to configure exchange 2013 users outlookanywhere, Autodiscover from externally...
    So in tmg i pointed the outlook anywhere ip address new cas server, now both exchange 2010 and exchange 2013 users while OA from external, its keep on asking password... Not accepting it...
    Please help me to fix this issue..

    Hi ,
    On TMG please have the outlook anywhere rule like below and check the status.
    Step
    1 :
    On the TMG rule - >authentication delegation ---> select the option "no delegation users can authenticate directly"
    Step
    2 :
    on the users tab in the TMG rule - just add "all users" group on that rule.
    By having the above settings we have avoided the issues in your environment.
    Note : Based on the above setting's , Each and everyone in exchange will have a access to the outlook anywhere from external world , because there would not be having any restriction on the TMG rules.
    Please have a look in to the below link , it will give you some ideas which is related to TMG
    http://blogs.technet.com/b/exchange/archive/2012/11/21/publishing-exchange-server-2013-using-tmg.aspx
    Thanks & Regards S.Nithyanandham

  • Error Code 600 Autodiscover

    I am using Exchange server 2007 i am facing issue activesync,
    my users are not able to emails from their smartphones
    https://autodiscover.mydomain.com/autodiscover/autodiscover.xml
    <?xml version="1.0" encoding="utf-8" ?> 
    - <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    - <Response>
    - <Error Time="12:31:17.3655146" Id="2053059689">
      <ErrorCode>600</ErrorCode> 
      <Message>Invalid Request</Message> 
      <DebugData /> 
      </Error>
      </Response>
      </Autodiscover>
    https://mail.mydomain.com/autodiscover/autodiscover.xml
     <?xml version="1.0" encoding="utf-8" ?> 
    - <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    - <Response>
    - <Error Time="12:31:19.5627343" Id="2053059689">
      <ErrorCode>600</ErrorCode> 
      <Message>Invalid Request</Message> 
      <DebugData /> 
      </Error>
      </Response>
      </Autodiscover>
    [PS] C:\Users\Administrator.Mydomain\Desktop>Test-OutlookWebServices | fl
    Id      : 1003
    Type    : Information
    Message : About to test AutoDiscover with the e-mail address Administrator@mydomain.
    Id      : 1007
    Type    : Information
    Message : Testing server MAIL.mydomain with the published name https://mail.mydomain/EWS/Exchange.asmx & .
    Id      : 1019
    Type    : Information
    Message : Found a valid AutoDiscover service connection point. The AutoDiscover URL on this object is https://mail.mydomain/autodiscover/autodiscover.xml.
    Id      : 1006
    Type    : Information
    Message : The Autodiscover service was contacted at https://mail.mydomain/autodiscover/autodiscover.xml.
    Id      : 1016
    Type    : Success
    Message : [EXCH]-Successfully contacted the AS service at https://mail.mydomain/EWS/Exchange.asmx. The elapsed time was 609 milliseconds.
    Id      : 1015
    Type    : Information
    Message : [EXCH]-The OAB is not configured for this user.
    Id      : 1014
    Type    : Success
    Message : [EXCH]-Successfully contacted the UM service at https://mail.mydomain/UnifiedMessaging/Service.asmx. The elapsed time was 181 milliseconds.
    Id      : 1016
    Type    : Information
    Message : [EXPR]-The AS is not configured for this user.
    Id      : 1015
    Type    : Information
    Message : [EXPR]-The OAB is not configured for this user.
    Id      : 1014
    Type    : Information
    Message : [EXPR]-The UM is not configured for this user.
    Id      : 1017
    Type    : Success
    Message : [EXPR]-Successfully contacted the RPC/HTTP service at https://mail.mydomain/Rpc. The elapsed time was 16 milliseconds.
    Id      : 1006
    Type    : Success
    Message : The Autodiscover service was tested successfully.

    Hi
    Error code 600 is an expected result. that means the Autodiscover directory is working fine.
    What error is exchange logging in the application event log regarding users trying to sync phones? Are they domain admins at all? Inheritable permissions ticket?

Maybe you are looking for