Office 365 Autodiscover Lookup Process

This is a post for reference purposes.  The intent is to look at how Outlook will locate the correct Autodiscover endpoint in a hybrid environment.  This Exchange 2010 SP3 lab has a hybrid configuration with Office 365.  The tenant is called TailspinToysCanada.  Our test mailbox was moved successfully to Office 365.  They are logging onto a domain joined machine which is located on the corporate network, using their credentials.


Autodiscover Configuration

The Autodiscover namespace in this lab is  This is the URL that users will leverage to get the XML response from Exchange.  How do they discover this URL?  See this post for the full details.

In short the Exchange 2010 CAS server has the AutoDiscoverServiceInternalURI set to the namespace.  This is shown below.

Get-ClientAccessServer | Select Name, *URI | Format-Table -AutoSize

Autodiscover Namespace Set On Exchange 2010 CAS

Note that we are NOT setting URLs on the Autodiscover VirtualDirectory.  Please review the myth busting post for the background on this urban legend.  Setting the AutodiscoverServiceInternalURI is the value which will be returned to Outlook when it does a SCP query.  That is great for internal domain joined machines, what about external or workgroup machines?

For external clients, Autodiscover is configured as a standard A record in the external DNS zone.  This is for and points to the external firewall interface which is configured to pass the traffic to the Exchange 2010 CAS server.

Note that in a hybrid configuration the external Autodiscover namespace must point back to the on-premises Exchange infrastructure and not to Office 365.  This is a common configuration issue as the Office 365 portal complains about missing DNS records.  Ignore the GUI, and check the status of the custom domain using Get-MSOLDomain using PowerShell. The newer portal has addressed this, maybe I’ll add a post with details.  Leave a comment and let me know your thoughts please.

Now that we know the infrastructure, let’s see what Outlook does.


Testing Outlook Autodiscover Lookup Process

This is the Outlook 2013 ProPlus client, version 15.0.4693.1000.  We are using the Test E-Mail AutoConfiguration tool to review the Autodiscover process.

Guesssmart and Secure Guesssmart are for POP and IMAP clients so they are cleared to remove unwanted fluff from the results.

The below screen shot shows the steps Outlook has gone through to locate the correct Autodiscover endpoint for this Office 365 mailbox.  This has been edited to show the following:

  • User SMTP address is highlighted
  • Currently viewing the Log tab
  • Each response line has been manually numbered
  • Since the dialog cannot be resized the bottom portion was overlaid so all results were in a single image for readability purposes


Initial Autodiscover Process For Hybrid Mailbox

Line Number Comment
1 Autodiscover endpoint located using SCP query
2 Client attempts first URL
3 Authentication successful to Autodiscover web service using logged on credentials
4 Autodiscover unable to answer query as mailbox in O365. 0x800C8205,  Redirect to TargetAddress
5 Start from beginning using new SMTP address:
6 Autodiscover starts over. Endpoint located using SCP query
7 Client attempts first URL
8 Authentication successful to Autodiscover web service using logged on credentials
9 Autodiscover unable to answer query as mailbox in O365.  Status code:  0x800C8205
10 DNS lookup process starts: root domain lookup
11 Root domain lookup fails with status: 12007
12 Root domain lookup fails with status: 0x8004005
13 DNS lookup process continues to next namespace:
14 Lookup fails with status: 12029
15 Lookup fails with status: 0x800C8203
16 Local XML file lookup
17 Local XML file lookup fails with status: 0x8004010F
18 HTTP Redirect check to:
19 Client redirected to shared autodiscover namespace:
20 Client submits Autodiscover request
21 Authentication needed – 401 response

At this point we are at the shared Outlook Autodiscover service.  We need to authenticate to Office 365 Autodiscover so that it knows who we are, and where to then redirect us.  This is shown in the second section below.  It picks up where the section left off:

Final Autodiscover Process For Hybrid Mailbox

Line Number Comment
22 HTTP 302 redirect
23 Autodiscover failed with status: 0x800C8204 – redirect was received to a more accurate location
24 Autodiscover sent to accurate location
25 Autodiscover request issued to
26 Authentication needed – 401 response
27 Authentication successfully provided
28 Autodiscover request submitted
29 Autodiscover XML data successfully received


At this point our Outlook client has received the Autodiscover XML response.  This took a few hops, but users do not see this background process so this does not really impact them.

One thing you may be wondering is the TargetAddress mentioned above.  If we look at the attributes defined on an AD user object whose mailbox was migrated to Office 365, we can see the TargetAddress attribute is present on those migrated accounts.

Attributes On Object User-1 - Note The TargetAddress

This is what allows Exchange to shim in the different SMTP address.  Exchange will NOT use as the ultimate delivery address, rather the TargetAddress is used.  In this case it is:

This is provided to the Outlook client when it initially contacted the on-premises Exchange server.  Outlook then uses this to chase down the correct location to send the Autodiscover request. 


DNS Records We Met Along The Way

<Tenuous link to Bob Marley>

We looked for the following DNS records in our journey so far:

  5. (this is where my tenant exists, yours will likely be different)

The is used twice.  Once with HTTPS and then for the HTTP redirect.

Some of these names do not exist in DNS, whilst others have some additional aliases.  We can use Nslookup to query for records.  The DNS server in the internal DC which is then performs recursion on behalf of the resolver.

Nslookup Showing DNS Records Used With Autodiscover

(Click to zoom in to the image)


Outlook 2010 And Outlook Autodiscover 2013 Differences

Outlook 2013 changed its Autodiscover behaviour slightly.  In short it does the SCP lookup but also chases down DNS entries simultaneously so that should the SCP lookup fail, the DNS records are already cached.  It does not really show you this in the Test E-Mail AutoConfiguration tool, but Netmon never lies!  In addition Outlook 2013 also introduced the feature of caching the last successful URL.

The below is an example of Outlook 2010 running on the same machine, as the user above.  Note that with Outlook 2010 there is a single HTTP redirect query which consists of a question and answer.  The destination IP is an external IPv4 address 157.244.217.  This IP is shown in the Nslookup results above.

Outlook 2010 Network Monitor HTTP Traffic

Outlook 2013 has two separate queries. 

Note that you can see Outlook 2013 querying for an HTTP redirect to an internal IP in this example which is the IP of the CAS.  Then 5 seconds later it does the same external HTTP redirect check that Outlook 2010 performed above.  The HTTP 302 redirect is also highlighted in the bottom section

Outlook 2013 Network Monitor HTTP Traffic


To filter out unwanted junk, the following Netmon filter was used to filter out two unwanted process from the results leaving the remaining HTTP traffic displayed:

HTTP and  !(ProcessName == "WaAppAgent.exe") and !(ProcessName == "WindowsAzureGuestAgent.exe")

Netmon Filter Used To Filter Out Multiple Process


Outlook Diagnostic Logging Reference

It is also possible to see the Autodiscover flow through Outlook diagnostic logging.  To apply the change, Outlook must be restarted.  The logs are kept in the %TEMP% folder, and we are interested in the olkdisc.log file.  I use the %TEMP% variable as that removes having to consider where that user’s temp location is.  On the above test machine it is currently C:\Users\User-1\AppData\Local\Temp\3.  Using %TEMP% is way easier!

An excerpt from this test account shows:

  Autodiscover to Failed (0x800C8205)
  Autodiscover to starting
  AutoDiscover doing Pre-Auth with saved data.
  AutoDiscover PRE-AUTH pcreds->dwAuthScheme:
  GetLastError=12007; httpStatus=0.
  Autodiscover to Failed (0x800C8203)
  Autodiscover to starting
  AutoDiscover doing Pre-Auth with saved data.
  AutoDiscover PRE-AUTH pcreds->dwAuthScheme:
  GetLastError=12029; httpStatus=0.
  Autodiscover to Failed (0x800C8203)
  Local autodiscover for starting
  Local autodiscover for Failed (0x8004010F)
  Redirect check to starting
    Autodiscover URL redirection to
    Autodiscover to starting
    AutoDiscover doing Pre-Auth with saved data.
    AutoDiscover PRE-AUTH pcreds->dwAuthScheme:
    GetLastError=0; httpStatus=401.
    GetLastError=0; httpStatus=401.
    AutoDiscover disabled auth schemes:
    AutoDiscover supported auth schemes:
    AutoDiscover attempting Exchange Credentials.
    AutoDiscover USING pcreds->dwAuthScheme:
    GetLastError=0; httpStatus=302.
    Autodiscover to Failed (0x800C8204)
      Autodiscover URL redirection to
      Autodiscover to starting
      AutoDiscover doing Pre-Auth with saved data.
      AutoDiscover PRE-AUTH pcreds->dwAuthScheme:
      GetLastError=0; httpStatus=200.
      Autodiscover XML Received


For more details on Outlook diagnostic logging please see KB 2862843 -- How to enable global and advanced logging for Outlook 2010 and Outlook 2013.




Comments (54)
  1. turbomcp says:

    Thanks a lot
    most comprehensive article I have seen to date

  2. turbomcp says:

    Rhoderick ,
    I got quick question
    from my understanding in hybrid where the on premises is 2010 and the hybrid servers are 2013 the SCP record needs to point to the most updated version of exchange and that is Exchange 2013 correct?
    Thanks in advance
    big time fan

  3. That would be correct. For a single Autodsicover namespace, that should point to the latest version of Exchange.


  4. turbomcp says:

    externally I knew it needs to be the hybrid server ofcourse but internally there aren’t any documentation for this…
    I know theoretically 2010 should be able to answer these requests for internal clients but wasn’t sure what’s the best practice.

  5. Aadi says:

    Apt and perfect article….

  6. Anonymous says:

    Ran into an issue where this Outlook 2010 SP2 client, build 14.0.7113.5000, was throwing up unexpected

  7. Rhoderick, thanks for laying out the process clearly. It’s a great resource to point people to when explaining how things need to be set up.

    I have an environment I’m working on that has an issue with delays. Internal workstations can configure a profile quickly, but external workstations take about 6 minutes to complete a profile configuration or to run test-email autoconfig. When I use ExRCA,
    it takes about 63 seconds. A good 40 seconds are waiting for the query to "" to time out before querying the proper "" record. My "test email autoconfig" process looks a lot like yours, but has
    a full page of additional attempts to "". Do you see a significantly different result when you run your tests from a non-domain-joined system external to the LAN?

  8. Hi Dave,

    To what/where does your DNS resolve to? Is it a website at a hosting provider, a SharePoint site or something like that?


  9. Best thing I like about your blogs is the detailed description. This is simply great. Thanks, I now will simply direct my guys to this article when they have an issue with Autodiscover.

  10. Techno Music says:

    Hi Rhoderick,
    I am aware that there is now a feature when using set-hybridconfiguration a single domain name can be nominated for all autodiscovery lookups in an hybrid infrastructure, therefore no need for additional DNS records and expensive cert. However I fail to see
    the value in this? Wont on-premise users already require autodsiscover records for primary email addresses and these will already be stamped on a public certificate. So where is the savings with this autodiscovery feature?

  11. For an application developer or script writer using the EWS Managed API 2.0, would it be safe to forego some of the discovery and preset the URL to

    In testing, there’s a remarkable difference in duration. The work to discover the enpoint involves a lot of timing out due to bad assumptions (like from a user’s email addres

    The concern is how durable is ""?
    What is the difference between "" and ""?
    Why does the resolved url have the "-s" in the name?


  12. Stefan K says:

    I have noticed autodiscover process slow dramatically after enabling modern authentication for Office 2013 for MFA. But strangely it affect only VPN connections – it may take up to 5 mins for Outlook to start

  13. robsealock says:

    It would be fantastic if you could include in this article how a non-domain joined outlook client is processed and how/when/where authentication to AutoD is achieved.

  14. andrew stevens says:

    Thumping good read

    Well done!

  15. Mitchell Earl says:

    I get an Autodiscover URL redirection from to on our SBS 2011 server. Is this the reason it won’t connect externally? Is there a way to prevent the redirect?

    1. More than likely. I don’t do SBS, but you should be able to set this up using the SRV record option.

      Using the regular may be possible — would be best to look at the SBS TechNet forums for that.


  16. Sachin Arora says:

    Awesome Article Rhoderick!

  17. Tom says:


    very good article!
    But how to configure autodiscover if we have exchange hybrid and also migrating data from Zimbra or Google Mail? These AD users don’t have attributes like targetaddress, exchangeguid, legacyexchangedn and so on…

    Thanks in advance

    1. You need to have those attributes in Hybrid Tom. Do you have Exchange deployed on-premises?

      If not, then that is not Hybrid.


      1. Tom says:

        Hi Rhoderick,

        yes the attributes are available but still empty for users are migrated from Google Apps to O365.
        I think I have to Enable-RemoteMailbox for each user, set the msExchRemoteRecipientType “4” and the targetaddress for routing and autodiscover.

        Thank you!

        1. Hi Tom,

          So in this case the users were migrated straight to 365? I assume that you do have Exchange deployed on-prem. is that the case?


  18. Marc says:

    Hi Rhoderick, I’m migrating from Exchange 2010 to Exchange 2013 running Server 2012 R2. I thought I had everything migrated over to Exchange 2013. As I test, I turned off the Exchange 2010 server and wanted to see what is broken before I uninstall it for good.

    When the Exchange 2010 server is off, all my Outlook 2007 clients receive popup message asking for the credentials. I made sure the Outlook clients have SP3 and the November cumulative update. When I attempt to enter the credentials it doesn’t work. When I perform a Test Auto Email Configuration in Outlook, I get the following errors. FAILED (0x800C8203), httpStatus=401, FAILED (0x80040413), and FAILED (0x8004010F). I tried created split DNS on my local DNS server to resolve the domain name internally, however that didn’t fix the problem. I also tried creating a local SRV record for _autodiscover but that didn’t work either. I was going to uninstall the CAS server role on Exchange 2010 to see if that fixes it, but wasn’t sure if that would break something else. Once I turn the Exchange 2010 server back on, everything is working again. I really appreciate you taking the time to read this and any advice you can give me to resolve my problem.


    1. Hi Marc,

      You have a single Autodiscover namespace internally I assume? The SCP objects were updated, and all point to the Exchange 2013 servers?


  19. Ravi says:

    Hi Rhoderick ,

    I got quick question which could be silly or not very relevant.

    If I have cloud only user in the same tenant with e-mail address matching to that of on prem SMTP address.
    How does autodiscover works in such scenario ?


  20. Mihai D. says:

    excellent article. thank you for your time in writing this. I hope you can give me an idea about a situation i have encountered.
    I manage a hybrid configuration that i did not setup, but i inherited. We have 7 domains, ( is the primary domain) ,, etc. and . I have an issues that i can’t seem to put my finger on it.
    Sometimes, even joined domains machines give a certificate warning connecting to, but is not the autod domain. i have run the HCW to confirm that autodiscover is only for the autod domain. I have checked the on-prem configs, i have checked the DNS entries i do not find anything related to . SCP entries are correct i doubled checked them. I do not find any reason why DOMAIN joined domains are trying to access THis issue is fixed by itself. It appears at random times, sometimes multiple times a day, sometimes not at all. we also have a SRV record for domain.

    Can you give me some pointers on what else to check ?

    Thank you for your time.

  21. Nellybauer says:

    Thanks for the very informative article. We have a hybrid enviornment & have recently migrated all users over to Exchange Online, so are now looking to create new users straight into O365 to save having to create an on-prem mailbox & migrate it. We are creating new users, setting the email address fields appropriately, letting them sync via AADC, then adding an O365 licence to the user once synced. This works great in that the user then has a mailbox created in Exchaneg Online which we can then login to via OWA. The issue is Outlook fails to connect as Autodiscover fails. So, if we force our account creation scripts to add the TargetAddress to be the, should that then mean that Autodiscover starts to work?

    1. Have you looked at enable-remotemailbox cmdlets ?


  22. Nailed it, impressive. I am going to use the way you built that table explaining logs vs. comments in my next posts 🙂

    1. Glad you found it useful 🙂


  23. Karen says:

    Hi Rhoderick,
    This is a great article. (very clear and easy to follow) .

    Do you know if there is a similar article for an environment that is just Office 365? (We have an issue that I suspect is firewall related, and I’m trying to figure out what URLs we should meet along the way. If we can’t access one of the URLs that would explain why auto-discover is failing internally but not externally.)


    1. Hi Karen,

      If there are no Exchange servers on-premises, then this article should apply but ignore the SCP bit since you do not have that

      If you have split DNS, check that the relevant records were also created in the internal zone.


      1. mb96net says:

        All our mailboxes are on O365. We have an Exchange server on-premise only to be used as an SMTP relay for applications on-premise (and apparently to allow AD Connect to sync Exchange Attributes). We don’t really want to manage mailboxes via the on-premise Exchange server and we don’t want any clients to rely on it for AutoDiscover services (or any other services). Can I have autodiscover resolve to O365 internally and externally even though I run the Exchange Hybrid Wizard? When I run the wizard it says my Exchange server needs to have EWS exposed externally, but I assume that’s for O365 to be able to move mailboxes to/from on-premise (which I don’t want to do). I’m not sure how to be as fully migrated to O365 as possible while removing as many dependencies on my on-premise Exchange 2016 server as possible. MS basically seems to suggest that I stay Hybrid forever and use my On-Premise ECP to manage mail recipients in O365, but I would rather manage everything from O365 and not allow any clients to connect to my On-premise exchange.

        1. Did you ever make a decision on moving your autodiscover record? I’m in the same situation as you and this article gave me pause about making the switch. 365 support told me I’m free to move my autodiscover record after all mailboxes have been migrated to 365.

  24. WECAN Login says:

    Hey nice post. I hope it’s alright that I shared it on my Facebook, if not,
    no problem just let me know and I’ll remove it. Regardless keep up the good work.

    1. Linking and sharing is awesome!. Sharing with a preamble and the content intro is also totally fine.

      Please do not copy and paste the entire article though. I will ask for that to be changed.


  25. Thank you for the article Rhoderick.

    There is one thing that bugs me regarding the HTTP redirect method in multi-tenant scenarios: in my multi-tenant environment, when the HTTP redirect occurs, clients are prompted with a certificate warning. I know I can suppress it, that’s not the issue. However, when a similar HTTP redirect occurs to Office 365, no warning is displayed, it just happens.

    How is a multi-tenant HTTP redirect infrastructure configured by me different from that of Office 365? Why is it that O365-hosted mailboxes don’t generate a cert warning when autodiscover is HTTP-redirected?

    Thank you.

    1. Hi Zoltan,

      Are you asking how to suppress the AutoD prompt on the user’s Outlook client?


      1. Hi Rhoderick,

        Thanks for the prompt reply.

        Correct. I know I can suppress it with a Reg hack as per

        Just wondering how it is done for O365 that Outlook trusts it out of the box and doesn’t prompt. I want my clients, inclusive mobile, to connect to their tenant mailbox without being prompted, just like they would to an O365 EOL mailbox.

        Is it hard-coded into Outlook to trust FQDNs?


      2. Found half the answer. After installing Office and running Outlook for the first time, Outlook creates the and Registry values in the RedirectServers key.

        I still don’t know how mobile devices get around the redirect warning.

        1. Yes – that’s correct Zoltan, those entries are written in to suppress the redirect.

          For the mobile clients, that is up to the device how it will deal with the prompt.


  26. Mihai D. says:

    Hi Rhoderick,,

    Excellent article. I hope you can give me an idea about a situation i have encountered.
    We have a hybrid configuration. We have 7 domains, ( is the primary domain) ,, etc. and . I have an issues that i can’t seem to put my finger on it.

    Sometimes, even joined domains machines give a certificate warning connecting to “” instead of the “”, but is not the autod domain. i have run the HCW to confirm that autodiscover is only for the autod domain “”. I have checked the on-prem configs, i have checked the DNS entries i did not find anything related to . SCP entries are correct i doubled checked them. I do not find any reason why outlook from a DOMAIN joined computer is trying to access This issue is fixed by itself. It appears at random times, sometimes multiple times a day, sometimes not at all. we also have a SRV record for domain.
    At the time of this writing, there is one computer that exhibits this behavior every single day.

    Can you give me some pointers on what else i can check to see where this is coming from ?

    Thank you for your time.

    1. Hi Mihai,

      What version of Outlook is this please? Do you see differences between different Outlook versions and/or builds?


      1. Mihai D. says:


        This issue happens on outlook 2013/2016 . But the current issue is on outlook 2016. I haven’t notice any difference on outlook builds, but i will check that as well.

  27. Shiv says:

    Very well explained

  28. Rhoderick,

    Wanted to let you and future readers know about a free tool that can be used to retrieve the AutoDiscover XML result from any server (that supports such).

    Priasoft (of which I represent) has produced this tool for our own support and troubleshooting needs, but found it valuable to most that are faced with tracking down issues with AutoD.

    The tool does not need outlook installed (great for running on a server in a pinch) and has a drop-down for choosing the version of outlook to send to the server (good for getting mapiHTTP info which is version dependent).

    It follows the same auto-resolve pattern as outlook and has all the current overrides (like no SCP or no SRV) in checkboxes so they can easily be turned on/off for testing.

    Hopefully it finds use and helps others as it has for us.

    It can be found here:

  29. Thanks a LOT as usual for all your Posts!

    Question, our Exchange was decommissioned and we’re strictly on Office 365. I have implemented the registry fix on each computer so that it doesn’t look to our old exchange Autodiscover and instead, get the one of Office365 “quickly”.

    In this case, how to change those values that are written inside the AD that points to our old on-prem exchange?

    Thank you in advance!

    1. Curious as to the question. If you have change the Autodiscover keys on the clients, why do you then want to edit the values in AD ?


      1. Thank you for your reply and, Happy New Year!

        Actually, whenever a new computer is setup, i will have to run that registry (or i will need to push it from my side) and i would always prefer to solve the issues from the base instead of doing fixes.

      2. I searched on all places i thought of but got no results. :/

  30. Kevin O says:

    Hello Rhoderick,

    I have an Exchange 2010 environment we are migrating to Office 365. I have installed an Exchange 2016 server and pointed Autodiscover to the 2016 server, internal and external records. Autodiscover tests work fine for Exchange mailboxes. But for mailboxes migrated to Office 365, Autodiscover gives an HTTP 403 error message instead of the redirect URL. Here is the output from ExRCA. Thank you.

    The Microsoft Connectivity Analyzer is checking the host 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: EXCHANGE16
    Content-Length: 0
    Date: Fri, 26 Jan 2018 15:21:09 GMT
    Server: Microsoft-IIS/8.5
    X-Powered-By: ASP.NET
    Elapsed Time: 119 ms.

  31. ChetRichUni says:


    This is a very useful article as I am having a very similar issue. Outlook 2013 will not connect using the address but if I change it to the email address I can configure the profile.

    I noticed when I create a new user on the Hybrid server and check the target address it is pointing to the domain and not the I have a screenshot of the test but cannot post it.

    I have had the O365 Team look into this and they tell me that its an internal network issue.

    All help would be greatly appreciated.



    1. Hi Chet,

      Check how you have published Autodiscover. Something is most likely wrong with that.

      Target address should be set to the namespace when an on-premises mailbox is migrated to Exchange Online.


      1. ChetRichUni says:

        Hi Rhoderick,

        Thanks for getting back to me. I’ll check this and get back to you if I have any further issues.


  32. Naijden says:

    Hi Rhoderik,

    In our hybrid environment we have mixed legacy / modern authentication clients, and also some conditional access rules. At the ADFS level we block legacy from outside known IP addresses (x-ms-forwarded-ip). i.e. When the authentication request comes from a known IP range, we permit it – legacy clients should be able to authenticate, but only from the corporate network).

    We configured ADFS to issue a permit for requests originating from known IPs, and for x-ms-client-application Microsoft.Exchange.Autodiscover

    However – when setting up a mailbox on Outlook 2013 / Outlook 2016 the autodiscover phase failed – basically authentication failed (continuous credential request was shown). We checked ADFS and the incoming x-ms-client-application claim is Microsoft.Exchange.ActiveSync (even though the client is outlook). Some of the claims are below (from our ADFS)

    Outlook/15.0 (15.0.4971.1000; MSI; x86)

    Any idea if this is expected behaviour (i.e. ExO proxies the request as ActiveSync for Autodiscover requests coming from Outlook)?
    Does Microsoft.Exchange.ActiveSync claim need to be enabled in this case to permit autodiscover ? (our Original goal was to allow for specific group members – for which a separate ADFS rule exists)

    An example of our current ADFS policy is below:
    @RuleName = “Allow access Legacy Authentication from corporate network”
    exists([Type == “”, Value=~ “^(?i)False$”])
    && exists([Type ==””,
    Value =~ “Microsoft.Exchange.Autodiscover|Microsoft.Exchange.OfflineAddressBook|Microsoft.Exchange.RPC|Microsoft.Exchange.WebServices|Microsoft.Exchange.Mapi|Microsoft.Exchange.SMTP|Microsoft.Exchange.Pop|Microsoft.Exchange.Imap|Microsoft.Exchange.Powershell”])
    && exists([Type ==””,Value =~ “”])
    && exists([Type ==””,Value == “/adfs/services/trust/2005/usernamemixed”])
    => issue(Type = “”, Value =”true”);

Comments are closed.

Skip to main content