How Outlook 2016 utilizes Exchange Server 2016 FAST Search
Published Mar 21 2019 01:22 PM 174K Views
Microsoft

 

FAST Search

The term FAST Search may not be entirely new to you if you managed SharePoint sites anytime during the last decade. With Microsoft Exchange Server 2016, the FAST search architecture is introduced to Exchange. With FAST search, various new features are made available to Exchange 2016 mailbox users, including Search suggestions and People suggestions. These suggestions are dynamically computed based on your previous searches and the names of people that you frequently communicate with. The new feature set is readily available when using Outlook on the Web to connect to a mailbox on Exchange Server 2016 or Exchange Online.* Additionally, the newer Outlook 2016 desktop client also takes advantage of the new FAST search when connecting to these same mailboxes.

 

Note Exchange Online on Microsoft 365 is migrating search features from FAST to Microsoft Search. However, on-premises Exchange Server will continue to use FAST search. For more information about the migration of Exchange Online search features to Microsoft Search, see How Outlook for Windows connected to Exchange Online utilizes Microsoft Search

 

The evolution of Search in Outlook

As far back as in Outlook 2007, Outlook has utilized Windows Desktop Search (WDS) to index Outlook Data (.pst) and Offline Outlook Data (.ost) files. These indexes are created on the local disk. At the same time, Outlook uses the same WDS architecture to search these local indexes when you initiate a search. The use of WDS in Outlook is sometimes referred to as Instant Search.

 

Let us focus strictly on searching Exchange mailbox content... Exchange content is indexed by WDS when Outlook is configured to connect to the Exchange mailbox using Cached Exchange Mode. When an Exchange email account is in Cached Exchange Mode, the mailbox contents are synchronized to the local .ost file. It is this local file that is indexed by WDS. WDS does not index the mailbox store directly. Why am I still talking about WDS? Because it is still relevant, even when using the latest and greatest versions of Outlook and Exchange.

 

Search in Outlook 2016 and later versions

In Cached Exchange Mode, Outlook 2016, Outlook 2019, and Outlook for Office 365 still query WDS desktop search indexes... and they query Exchange 2016 and Exchange 2019 using FAST Search.

 

Assuming FAST Search is not disabled by policy, Outlook initially submits a query to Exchange on-premises using FAST Search. If FAST Search results are returned in a timely manner (about 5 seconds), these are displayed. But, if the FAST Search timeout is reached before a server response, then a message indicating that We're having trouble fetching results from the server..., along with the link "Let's look on your computer instead." If you click this link, then WDS search results are displayed.

 

Note Outlook also assesses the performance of the network connection and if it determines there is latency, it may default to displaying WDS search results.

 

But wait, there's more! Some search scopes set search criteria that cannot be processed by FAST. If you set the scope to All Outlook Items, Subfolders, or All Mailboxes Outlook defaults to WDS results. The search scope is set next to the Search text box, as shown here:

 

WDS forced by selection.png

 

Additionally, if you type search criteria that is not supported by FAST, Outlook returns WDS results (of course, assuming WDS supports the criteria). For example, Outlook supports the use of natural language queries, such as received:this year. However, Outlook FAST search does not. Therefore, if you submit received:this year, Outlook automatically displays WDS search results. To use FAST search for a similar query, you would need to submit the following criteria: received>12/31/2016.

 

To recap, Outlook uses FAST search and/or returns results using FAST, except if any one of the following conditions are true:

  • You are connected to a mailbox on Exchange Server 2013 or earlier
  • Outlook is connected to the mailbox in online mode
  • The FAST search feature is disabled via policy or local user registry setting (more on administering the feature below)
  • The FAST search query results are not returned in a timely manner (about 5 seconds)
  • Outlook assesses the performance of the network connection and determines there is latency
  • You are searching a secondary mailbox (there's an exception to this exception, as explained later)
  • The search scope is set to All Outlook Items, Subfolders, or All Mailboxes
  • The search criteria are not supported by FAST search

 

Am I seeing WDS or FAST results?

To determine which results Outlook is displaying, you can focus on some small user interfaces cues.

 

If the results displayed are those generated by FAST, the bottom of your message list will display the following cue:

 

FAST search complete.png

 

If there are more than 75 results from FAST, the bottom of your message list may display the following message until reaching the service or client limit, whichever is smaller:

 

FAST search 75 items paging.png

 

As mentioned earlier, if the service times out or is unavailable, the message list will display the link “Let’s look on your computer instead.

 

FAST search service slow unavail v2.png

 

If you click Let’s look on your computer instead, the results displayed are those generated by WDS. Of course, this is assuming that your local copy of the .ost cache contains items that match your serach criteria. The items that you are searching for may not be locally cached if a limited time window is specified for the Mail to keep offline setting. When this occurs, no local WDS results are returned, but you are given the option to check the Exchange mailbox by clicking Find more on the server:

 

not found locally FAST v2.png

 

Just as earlier Outlook 2016 client versions did, clicking More sends a non-FAST query to Exchange. This is because the client has already determined that FAST search to the service is not available… no need to go back and try that again.

 

WDS more.png

 

And yes, Exchange Server 2016 supports both FAST and legacy Exchange Search functionality. The latter is still required for backward compatibility with Outlook 2013 and earlier versions.

 

Secondary mailboxes

When Outlook 2016 released, the plan was to only support FAST search on your primary mailbox. However, starting in the Fall of 2017, Microsoft 365 Apps (formerly known as Office 365 ProPlus) in Current Channel and Enterprise Channels, and the latest Office 2019 version, now fully support FAST Search for any Exchange email accounts added through File | Account Settings (also known as MultiEx or multiple Exchange accounts). This does not apply to Outlook 2016 installed with the Office 2016 suite that uses Windows Installer (MSI) installation technology.

 

If you are limited to using an older build of Outlook 2016 or one installed using the MSI installation technology, searching in a MultiEx mailbox may submit the FAST query in the context of the logged on user (you). This causes the search results to be pulled from your own mailbox, not the secondary mailbox that currently has the focus in your Outlook client. If you are unable to upgrade your Outlook 2016 client to the November 2017 Monthly Channel Build, you can temporarily work around this limitation by using one of the following options:

  • Change the search scope to All Outlook Items, Subfolders, or All Mailboxes
  • Disable Outlook 2016's use of FAST search via policy or local user registry setting (see the next section)

Note Other types of secondary stores, such as those added via Open these additional mailboxes or those that are automatically configured via AutoMapping, are still limited to WDS.

 

Number of results returned

Currently, the service limits the results to 1000 results. However, Outlook can further limit the results to 250 if the File, Options, Search group, Improve search speed by limiting the number of results shown checkbox is enabled.

 

SearchLimit.png

 

Administer FAST Search in Outlook

To disable FAST search (server assisted search) and revert back to using WDS, an administrator can apply a group policy or implement the DisableServerAssistedSearch and DisableServerAssistedSuggestions user registry values. These are documented in the following table, along with other registry values to allow you to control additional FAST search functionality.


Note The 16.0 registry subkey name is valid for both Outlook 2016 and Outlook 2019.

 

Disable Server Assisted Search

Group Policy registry path:
HKEY_CURRENT_USER\software\policies\Microsoft\office\16.0\outlook\search
DWORD: DisableServerAssistedSearch


OCT registry path:
HKEY_CURRENT_USER\software\microsoft\office\16.0\outlook\search
DWORD DisableServerAssistedSearch

Disables Outlook from requesting and using Search results from Exchange for cached and non-cached mailbox items. Instead, it will use search results from Windows search service. Set to 1 to enforce.

Disable Server Assisted Suggestions

Group Policy registry path:
HKEY_CURRENT_USER\software\policies\microsoft\office\16.0\outlook\search
DWORD: DisableServerAssistedSuggestions


OCT registry path:
HKEY_CURRENT_USER\software\microsoft\office\16.0\outlook\search
DWORD: DisableServerAssistedSuggestions

Disables Outlook from requesting search suggestions from Exchange. Set to 1 to enforce.

Default Server Latency Limit 

Group Policy registry path:
HKEY_CURRENT_USER\software\policies\microsoft\office\16.0\outlook\search
DWORD: DefaultServerLatencyLimit


OCT registry path:
HKEY_CURRENT_USER\software\microsoft\office\16.0\outlook\search
DWORD: DefaultServerLatencyLimit

If the connection to Exchange is slower than DefaultServerLatencyLimit in milliseconds, then do not issue an Exchange Server Assisted search (will only use local search).

Server Assisted Search Timeout

Group Policy registry path:
HKEY_CURRENT_USER\software\policies\microsoft\office\16.0\outlook\search
DWORD: ServerAssistedSearchTimeout


OCT registry path:
HKEY_CURRENT_USER\software\microsoft\office\16.0\outlook\search
DWORD: ServerAssistedSearchTimeout

Timeout in milliseconds that Outlook should wait for Exchange to provide search results before falling back to use local search.

Search Suggestion Keyword Max Display

Group Policy registry path:
HKEY_CURRENT_USER\software\policies\microsoft\office\16.0\outlook\search
DWORD: SearchSuggestionKeywordMaxDisplay


OCT registry path:
HKEY_CURRENT_USER\software\microsoft\office\16.0\outlook\search
DWORD: SearchSuggestionKeywordMaxDisplay

Maximum number of keyword suggestions displayed in Search textbox.

Search Suggestion People Max Display

Group Policy registry path:
HKEY_CURRENT_USER\software\policies\microsoft\office\16.0\outlook\search
DWORD: SearchSuggestionPeopleMaxDisplay


OCT registry path:
HKEY_CURRENT_USER\software\microsoft\office\16.0\outlook\ search
DWORD: SearchSuggestionPeopleMaxDisplay

Maximum number of people suggestions displayed in Search textbox.

Search Suggestion Total Max Display

Group Policy registry path:
HKEY_CURRENT_USER\software\policies\microsoft\office\16.0\outlook\search
DWORD: SearchSuggestionTotalMaxDisplay


OCT registry path:
HKEY_CURRENT_USER\software\microsoft\office\16.0\outlook\search
DWORD: SearchSuggestionTotalMaxDisplay

Maximum total number of suggestions displayed in Search textbox.

Wordwheel Time Out Exchange Search

Group Policy registry path:
HKEY_CURRENT_USER\software\policies\microsoft\office\16.0\outlook\search
DWORD: WordwheelTimeOutExchangeSearch


OCT registry path:
HKEY_CURRENT_USER\software\microsoft\office\16.0\outlook\search
DWORD: WordwheelTimeOutExchangeSearch

The number of milliseconds that Outlook will wait after text changes in the Search textbox before executing a Search using the Instant Search (FAST) API.

Search Suggestion Time Out 

Group Policy registry path:
HKEY_CURRENT_USER\software\policies\microsoft\office\16.0\outlook\search
DWORD: SearchSuggestionTimeOut


OCT registry path:
HKEY_CURRENT_USER\software\microsoft\office\16.0\outlook\search
DWORD: SearchSuggestionTimeOut

The number of milliseconds that Outlook will wait after text changes in the Search textbox before issuing a query to FAST for suggestions.

 

Special thanks to Paul Slaathaug for reminding me to get this blog wrapped up and for providing additional topics to cover.

181 Comments
Brass Contributor

Are there some technical details for that search? While in Office network it works great, but for some users (not all) the FAST search does not work when being connected over SSL VPN to our network (rest is working fine, just server search not). So I assume some ports need to be open or some specific Win services must be allowed over SSL VPN?

Copper Contributor

HKEY_CURRENT_USER\software\microsoft\office\16.0\outlook\search

i don't have this above path in my registry kindly advise for the further

Microsoft

@shahul251  - some of the shown subkeys need to be created manually. I hope this helps.

Copper Contributor

@abdias_ruiz,

 

Maybe there's nothing you can do about this... but...

https://community.spiceworks.com/topic/2271628-outlook-2019-search-something-went-wrong

 

A whole bunch of people are reporting the Something Went Wrong error in Outlook Search. It broke today. Today.

 

You have two options:

  1. Click the search my computer link every time.
  2. Employ the DisableServerAssistedSearch key entry which, of course, stops Outlook from being able to search Exchange live.

Just making you aware! Happy searching!

 

 

Copper Contributor

I started hearing about this issue yesterday.  How do you troubleshoot FAST search issues on the server.  Is there a service that can be restarted? 
Server is Exchange 2013, affecting Outlook 2016 and 2019 clients.

Microsoft

@mwhalenhtc @RDWILD - it seems some are reporting earlier builds are not affected, so it may not be service specific. If someone can open a case with Outlook Commercial support, we can work to better track this internally, along with troubleshooting using logging. Otherwise, I'll continue working with the another group that reported this and post back here with updates.

Copper Contributor

@abdias_ruiz I don’t know how to open a case there. Any tips are welcome. 

Someone over on the Spiceworks thread found a way to force a downgrade to a version in which search worked and then temporarily disabling updates.

 

From an elevated command prompt:

 

"%programfiles%\Common Files\Microsoft Shared\ClickToRun\officec2rclient.exe" /update user updatetoversion=16.0.12624.20466

 

Anything else you can find out is greatly appreciated!!

Copper Contributor

As of 5/6/20 I have had users report that the search function fails while in cached mode. If you search in cached mode, they get an error "Something went wrong and your search couldn't be completed." Then below that it says, "It looks like there's a problem with your network connection." This is happening to all the Outlook clients regardless how they are connecting and what version they are on. It works fine in OWA though. Also, I notice that if you search ALL Outlook Items, it gives same error but it does search and finds items anyway.

 

I have posted this in the MS community board. Waiting for a clue.

 

Thanks

Microsoft

Can everyone advise if this is only occurring against Exchange Server on-premises mailboxes?

Copper Contributor

In my case, it is on premise Exchange server 2016 on Windows Server 2016. A total of 18 clients mixed between Outlook 2013, 2016 & 2019. 

Iron Contributor

@abdias_ruiz No, we have numerous clients on o365, hosted exchange via intermedia with the issue. This appears to have started with the outlook update that has started rolling out this week.

Copper Contributor

@abdias_ruiz, I am using a hosted Exchange service at Intermedia. We are on Exchange 2016 there.

 

We haven't had many reports from our user base yet. I suspect they haven't received the update or they haven't noticed the problem because they don't do a lot of searching in general.

 

I encourage you to look at the link I posted here earlier. The folks there have found a "workaround" of sorts which involves downgrading to a version previous to the build that brings the problem in and then disabling updates for the time being.

 

Here's how I wrote it up internally:

 

1. If Office to set to download and install Insider builds, disable that and restart Outlook.

 

2. Check for an update. Apply it if there is one. (Note: I had to do this because I was on Insider and checking once you disabling forces installation of the latest blessed release.)

 

3. From an elevated command prompt, use this command to downgrade Office to a build before the problem.
"%programfiles%\Common Files\Microsoft Shared\ClickToRun\officec2rclient.exe" /update user updatetoversion=16.0.12624.20466

 

4. Reboot the computer. (You _must_ reboot.)

 

5. Launch Outlook and check to see if Search works. If so, disable checking for updates.

 

After that, we just wait for an official fix.

 

 

Copper Contributor

@Travis_78Can you confirm that you do or do not have clients on O365 with the same issue? We're almost exclusively Intermedia.

 

Edit: Sorry, I understand your message now. You do have clients on O365 with the issue.

Iron Contributor

I will check around, we are also very Intermedia heavy, I want to make sure I'm also not mistaking those using office 365 software, but not on exchange using o365.

Copper Contributor

@abdias_ruiz, I don't see my original reply so I'll try again.

 

We are on Intermedia hosted Exchange (2016). We've had a couple of end-user reports about this but they're all on Intermedia. I suspect the others either haven't gotten the update or haven't noticed.

 

I should also note that I have talked to another admin who is running Exchange 2013.

Copper Contributor

We have a large number of users across several domains reporting search issues within outlook. See my Microsoft Answers post here: 

https://answers.microsoft.com/en-us/msoffice/forum/msoffice_outlook-mso_win10-mso_o365b/outlook-sear...

Iron Contributor

Checking in @abdias_ruiz have you had any forward movement on this one? 

Microsoft

Service telemetry pointed to the possible cause, resulting in additional resources assigned to resolve the issue. Will post updates here.

Iron Contributor

Is this related? Saw this in our office 365 admin center

Travis_78_0-1589234898235.png

 

Microsoft

Yes, that's it. Thank you all for getting this on our radar last week.

Copper Contributor

Just to further inform some remote users connecting via outlook anywhere had this issue as well, kindly consider them.

 

Thanks.

Brass Contributor

Hello,

 

Same issue here, we are hosting provider with on-premises Exchange 2016.

Copper Contributor

@abdias_ruiz 

 

I am concerned that Microsoft is going in the wrong direction.

 

I am not on Office 365 as many others have noted here as well. So, why would a telemetry issue related to Office 365 have any effect on my clients who are almost all on Intermedia? Why would it affect @null null who is running an on-premises Exchange server?

 

Of course, if Microsoft is capturing data for other purposes, not necessarily nefarious in nature, then maybe that could explain it.

 

Can you please make sure the Powers The Be know this is not just affecting Office 365 users?

Copper Contributor

This is interesting...

 

combined_search_use

Used for monitoring possible negative impact on your ability to perform key search functionality such as searching for mail, contacts, or events.

The following fields are collected:

  • account_switcher_action_type - This action type tracks if the user used the account switcher either in simply discovery or if they decided to switch the account

  • action - the type of action that was performed for search. This identifies if a search has been started, in occurring, or ended and what actions were happening during the search, I.e. was the mic used. This is instrumental in ensuring accurate and helpful searches.

Emphasis mine.

 

This is listed under required "Required Diagnostic Data for Office."

 

 

Brass Contributor

We just tell our customers having the issue to use the DisableServerAssistedSearch and it's OK now...

Copper Contributor

@null null

 

Yes, I believe I understand you.

 

My concern is as follows:

 

1. @abdias_ruiz reports it's possible a "service telemetry" issue.

2. @Travis_78 shows an image evidently published to an Office 365 service related site.

3. @abdias_ruiz confirms that's the issue.

 

If Microsoft believes that this is an Office 365 issue, then why are others who aren't using Office 365 affected? And if Microsoft believes it's an Office 365 issue, are they inclined to not feel it's an issue affecting Office no matter where installed and to ignore that evidence? Or do they even know about that evidence. That line I quoted from the webpage--although I can certainly have misunderstood it--indicates that it's a part of the Office 365 (application subscription, NOT Exchange Online subscription) and that it follows under Required Diagnostic Data. This all makes me want to look at outbound connections from Office that don't go to Intermedia.

 

That's my concern. :)

Microsoft

@mwhalenhtc  - as shown in Travis' post, they are pointing out that this affects on-premises mailbox users. The issue is that the client attempts to use an O365 search endpoint, which is expected to fail for non-Exchange Online clients.

Copper Contributor

@abdias_ruiz 

 

Thank you. I was reviewing the image on my phone and didn't read it fully. I'm glad to know that my reasons for being concerned were just nonsense.

Copper Contributor

@abdias_ruiz  we are having the same search issus even when using search criteria like received:this year. Shouldn't this skip FAST like you described? Switching to "All Mailboxes" works, as expected.

Microsoft

@ManuelBerfelde  - can you provide additional details such as the error or unexpected behavior that you see, in addition to your environment, such as whether you are connected to an on-premises or Exchange Online mailbox? Thank you!

Copper Contributor

Temporary fix, until a official one is published:

 

For on premise Exchange

Key: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Search

Value name: DisableServerAssistedSearch

Value type: REG_DWORD

Value: 1

 

For Exchange Online (365)

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\Search

Value name: DisableServerAssistedSearch

Value type: REG_DWORDValue: 1

Iron Contributor

Any general forward movement or ETA on this one?

Copper Contributor

@abdias_ruiz 

 

We have Exchange 2016 and Outlook clients as part of an MS 365 Enterprise plan. Our smtp domain is not registered in O365 and there is not AAD-connect in place. But I have seen the same issue for other environments with on-prem Exchange (using Ex2010, Ex2013, Ex 2019) too.

 

We are experiencing the same FAST search related issues as others in the comments.

It started with one of latest Office updates - not sure which one excactly.

 

Search just returns:

"Something went wrong and your search couldn't be completed."

"It looks like there's a problem with your network connection."

 

I leave this one here again: https://community.spiceworks.com/topic/2271628-outlook-2019-search-something-went-wrong?page=1

Copper Contributor
Microsoft

@ManuelBerfelde, correct, if you're seeing the Something went wrong errors, that update is expected today.

Copper Contributor

Does someone knows if the fix has been released ?  is this a separate KB you need to install manually ?   

we have a customer that runs Exchange 2019 on-prem + outlook 2019 

Also a on-prem exchange 2010 with outlook 2013/16/19 is reporting this issue
we also have a customer who is having search issues with outlook 2019  in combination with IMAP , but i think this is a other problem. 

Copper Contributor

Hey,

use AutoDiscovery paramter ExcludeExplicitO365Endpoint.
Either via GPO (newest admx templates) -> User Template Outlook 2016 -> Account -> Exchange -> Disable Autodiscover (Subtype O365 Autodiscovery)
Or Registry:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover or
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
DWORD:ExcludeExplicitO365Endpoint = 1

This also resolve the the acutal search problem since Version 2004 ;)

 

Seems to be an Office365 autodiscover redirect error to on-premise installations

Copper Contributor

Nice article! I have run across several issues in the past and this article explained the fixes in detail. Nice Job!

Copper Contributor

 

@dztek79 ,  excluding O365endpoint trough registry is not a solution in our cases...  i'm still getting this "oops something went wrong" error message

 

we noticed that when we disable the outlook cache mode, the customer is able to search again. 

 

when i enable the outlook cache again, the customer cannot search . When I set the reg-key below, the customer can search again.

Key: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Search

Value name: DisableServerAssistedSearch

Value type: REG_DWORD

Value: 1

 

so, for the time beeing i set this reg-key at the customers who are having this search issue. 

Copper Contributor

I updated my office 2016 on May 14 2020 at 9:30AM EST and this did not fix the search problem.

I search for that registry entry and there is not one available. 

Microsoft

@SpecterM280zx , try the one that @dztek79  pointed out. You'll need to create the subkey and/or DWORD value if it does not exist.

 

Path: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover

DWORD: ExcludeExplicitO365Endpoint

Value: 1

Copper Contributor

I found this video and performed the steps.  https://www.youtube.com/watch?v=csd4rfGkUiQ

 

The Office update did not work. this did.

Copper Contributor

Thanx for the great Article!!

For my Organisation it was enough to Set this both >2000 (Milliseconds)

ServerAssistedSearchTimeout

DefaultServerLatencyLimit

No need to disable the Serverassistedsearch

If not working, check if your new DWORDS landed in Search/Catalog

Microsoft

Please note that if you have Exchange Server 2016 on-premises, if you use any of these registry settings:

  • ServerAssistedSearchTimeout
  • DefaultServerLatencyLimit
  • DisableServerAssistedSearch

you are basically disabling FAST search, too.

 

So if you would like to continue benefiting from your on-premises server's FAST search, while avoiding the Autodiscover issue that causes Outlook to try the Exchange Online search service, then use the ExcludeExplicitO365Endpoint registry value option.

Copper Contributor

@bputs After Setting the regkey, restart outlook and wait a few minutes. the autodiscover procedure must run onece, after that, restart outlook again and search will work again....

 

Maybe ctrl+rightclick on outlook tasktray with test autoconfig will speed this up

Copper Contributor

I have Exchange 2013 Standard on premise. Clients are using Office 365 Outlook. 

When this option is off or on. The search results are still limited to 250. What am I missing?

Number of results returned

Currently, the service limits the results to 1000 results. However, Outlook can further limit the results to 250 if the File, Options, Search group, Improve search speed by limiting the number of results shown checkbox is enabled.

 

Copper Contributor

5/14/20 8:10 AM PST.

I just updated my Outlook 2019 from v2004 build 12730.20250 to v2004 build 12730.20270 and the search function still does not work. Entering the registry d-word back again...fyi We are connecting to on-premise Exchange 2016.

Iron Contributor

I'd rather not be doing workarounds that we have to go back and change later. Any kind of ETA?

Copper Contributor

Thought I would weigh in here. I have been participating in another forum here Outlook 2019 search: Something went wrong I am spicehead-c6dzn over there. I have been tracking this problem since May 6th since one of my clients reported it. They are running Exchange 2013 CU23 on-premises and Windows 10 Pro workstations with retail Office 2019 Click-To-Run. So no Office365 - Microsoft Accounts. Exchange 2013 is also using FAST search and is affected.

 

The following CTR builds are affected 12730.20236 - 12730.20250 - 12730.20270

 

Out of all the workarounds that have been proposed. ExcludeExplicitO365Endpoint mentioned by @dztek79 is in my opinion the best work around for my clients setup. Thanks @dztek79! I like that it can be rolled out using GPO if you have the latest ADMX templates. I like that it also fixes another potential problem with AutoDiscover.

 

However after extensive testing, I have determined that only one of the registry paths works for me. I am not sure why. I applied the registry changes via manually via regedit. I followed @abdias_ruiz advice to apply the change wait and restart Outlook. I also tried logoff/logon and rebooting the machine just to make sure. This is the one that works for me. It would be the one applied via GPO, did not require reboot, logoff starting/restarting Outlook. 

 

Path: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover

DWORD: ExcludeExplicitO365Endpoint

Value: 1

 

@abdias_ruiz thanks for your work on this! I suspected the patched version will be available very soon. I am wondering if the above registry change prevents Telemetry data being sent to Microsoft :smile:. You mentioned earlier that was involved. Not sure what is being transmitted. Perhaps search queries? Please advise.

 

 

Copper Contributor

Just spent quite a bit of time on a post here. I seems to post OK but now it has vanished. Does anyone know how or why this happened?

 

EDIT: Now my previous post is showing up. Not sure what happened.

Co-Authors
Version history
Last update:
‎Sep 27 2022 09:10 AM
Updated by: