How To Fix Outlook 2013 Search Problems

Has your Outlook 2013 search suddenly stopped working? You keep typing different words and phrases, but it does not make a difference. Everything you type in Outlook search comes up with zero results.

You’ll probably see a message that says “We couldn’t find what you were looking for.”  There’s also a chance that you can see very few results, and if you take a look at the indexing status dialog in Outlook, you will possibly see the following message: “Search results may be incomplete because items are still being indexed.”

What Causes Outlook 2013 Search Problems?

When it comes to Outlook 2013 Search not working, you will quickly discover that this is a common issue across the board with Outlook users, so don’t blame yourself. Of course there are some preventative measures you could take to help keep away any Outlook 2013 search problem, but with constant use, there’s a chance something will go wrong down the line. When you rebuild a PST file, add more mailboxes, or even just migrate emails, your search index may not update and that will kick off an Outlook 2013 search problem. Not to worry, there are things you can do to fix those issues.

Step 1: Verify that indexing is working

To verify that indexing in Outlook 2013 is working properly, use the following steps:

• Click in the Search box
• In the Search tab, select Search Tools and then click Indexing Status
• When the indexing status dialog emerges, you might see the following:

If you see this message, it means that the index is complete, and Outlook can’t find your item for some other reason.
If Outlook has not finished indexing all of your items, you’ll see a message that says:

Search results may be incomplete because items are still being indexed.

If you see this message, take note of the number of files remaining to be indexed, wait five to ten minutes and then check again. If you still can’t find your files, try removing then adding your Outlook files to the Windows index.

Step 2: Remove Outlook from the Windows Index:

• Go to File > Options
• In Search settings, click Indexing Options…
• Click Modify
• Un-check Microsoft Outlook from the list of Indexed Locations
• Close Outlook completely and check the Task Manager (ctrl+alt+del) to see if no Outlook processes are running

Step 3: Make Sure Outlook Files can be Indexed

Outlook PST and OST files are indexed by Windows by default, but it may be that something strange happened during an update to either Windows or Outlook that caused this not to be the case. In order for Outlook to be able to search your emails, the contents of those emails must be allowed to be indexed by Windows. Here’s how to check:

• Find the location of your PST or OST files
  • Go to File > Account Settings > Account Settings
  • Click on the Data Files tab
  • Select your Outlook file from the list and click Open File Location…

• Right click on the .pst or .ost file and click Properties
• Click Advanced
• Make sure that the box next to ‘Allow this file to have contents indexed in addition to file’ is checked.
• Click OK

Step 4: Add Outlook to the Windows Index

Follow the steps outlined in step 2. Make sure this time that the box next to Microsoft Outlook is checked.
Give Outlook a little time to check the state of the indexing. It may be that it needs to add new items to the index. After a few minutes, you can try searching again.

Last Resort: Rebuild the Index in Outlook 2013

If you still can’t find the email you’re looking for, there may be a problem with your index. Rebuilding the index in Outlook 2013 isn’t too difficult, only time consuming. Here’s how to rebuild:

• In Outlook 2013 click on the File tab, then click Options > Search
• Click Indexing Options
• You should now see what locations are being indexed. Click Advanced
• Under Troubleshooting, click Rebuild
• Rebuilding will take some time so make sure to leave your PC running for a while, preferably when you don’t need to work with it since indexing can impact the speed of your computer.

Often when you move emails around a lot, or just generally use Outlook for a long time, you’re likely to run into indexing issues. These few steps will help you get Outlook 2013 search back into shape.

Offline Files and Continuous Availability: the monstrous union you should not consecrate

The difference between Windows 8 and Windows 10

Windows 8.1 and Windows 10 support SMB3, allowing them to utilize CA, transparent failover, and Scale-out File Servers. But due to the aforementioned timeout problem that many customers reported, we decided in Windows 10 to fix the glitch.

Starting in Win10, when you connect to a CA-enabled share, there is no longer an option to use offline files. No matter the settings, files will not cache and the user will not run into timeout problems.

When you mark a share as “continuously available” you are essentially committing to the following contract:

1. The SMB server must always be available.
2. Any data written to the server needs durable persistence on disk and must be resilient to disk failures.
3. The network between the client and the server is expected to be fault tolerant and high speed.

The CA feature tries to hide transient failures at any of the above three interfaces from applications by holding and resuming handles. Remember, it’s for high-throughput, high-availability, high-IO, mission critical server applications like SQL Server and Hyper-V. #3 above directly conflicts with “offline files” – which assumes flakey, slow, and intermittent network connectivity.
Naturally, this decision to change the behavior in Win10 may not make your day, which leads me to:

A variety of alternatives

• Use Work Folders. The future is definitely Work Folders. CSC hasn’t had a feature update since Windows 8, and that should be a strong sign that it probably never will. We have moved into a new phase, where users want to sync their data from PCs, phones, and tablets – and not necessarily all running Windows nor SMB. Work Folders brings all that to the table, and is actively under development and accepting feedback. Heck, Jane the Work Folders PM wrote about it constantly. She never sleeps.

• Just use CA. If you are looking for data consistency and transparent failover for non-mobile users, stop using CSC. Disable it on all your CA shares using Server Manager, Failover Cluster Manager or Set-SmbShare:

• Just use CSC. If you are looking for mobile user and crumbling network support, stop using CA. Disable it on your shares using Server Manager, Failover Cluster Manager, Set-SmbShare, or Explorer:

• Use a two-share combination. If you have a hybrid set of mobile users and desktop users all accessing the same data, nothing is stopping you from creating two shares to the same data – one with CA enabled and one with CSC enabled. Then your users can select the share that matches their needs.

• Use OneDrive for Business & Sharepoint. There’s this whole bizarro world out there that doesn’t use file servers. I don’t truck with it, but you might find them interesting. Check out https://technet.microsoft.com/en-us/library/dn889837.aspx & https://onedrive.live.com/about/en-us/business/. I think some guy named Jose works there now. The traitorous swine.

The future

We heard the Windows 8.1 feedback and changed the behavior in Windows 10 to stop the timeout issue. We then had feedback from Windows 10 customers that wanted it back the old way. So we decided to add this ability back into a future release of Windows 10; look for it here in group policy:


Software\Policies\Microsoft\Windows\LanmanWorkstation\AllowOfflineFilesforCAShares

Split-Brain DNS Deployment Using Windows DNS Server Policies

A DNS deployment is said to be split-brain (or split-horizon) when there are two versions of a single zone, one for the internal users and one for the external users – typically users on the public internet. For Windows DNS server based deployments, such scenarios called for maintaining two different DNS servers, each catering to a different set of the users. If only a few records inside the zone were split brained or both instances of the zone (internal and external) were delegated to same parent domain this became a management conundrum.

Another variant of the split brain deployment is the selective recursion control for DNS name resolution. Sometimes the enterprise DNS servers are expected to perform recursive resolution over internet for the internal users; while they have to act as a pure name servers (authoritative) for external users and block recursion for them. Here we shall see how these two scenarios can be accomplished using DNS policies.

Two versions of the same zone

Suppose the career website of contoso.com is hosted at www.career.contoso.com . The site has two versions, one for the internal users where internal job postings are available and is available on a local IP 10.0.0.39. The public version of the same site is available on public IP 65.55.39.10. In absence of DNS policies, the administrator had to host these two zones on separate Windows DNS servers and manage them separately. Using DNS policies these zones can now be hosted on the same DNS server.

If the nameserver hosting contoso.com zone is listening on two network interfaces; one with a public IP of 208.84.0.53 for external queries and another with a private IP 10.0.0.56 for internal queries then the administrator can follow these steps to achieve this split brain deployment

* All IPs and names are purely representational

  

Create the Scopes of the Zone

Partition the zone contoso.com to create an internal zone scope. A zone scope is a unique instance of the zone. A DNS zone can have multiple zone scopes, with each zone scope containing its own set of DNS records. The same record can be present in multiple scopes, with different IP addresses.

The internal zone scope will be used to keep the internal version of www.career.contoso.com

Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "internal"

Explore Add-DnsServerZoneScope

By default a zone scope exists on the DNS zones. This zone scope has the same name as the zone and legacy DNS operations work on this scope. This default zone scope will host the external version of www.career.contoso.com

Add Records to the Zone Scopes

The next step is to add the records representing the web server host into the two zone scopes- internal and default (for external clients). In internal, the record www.career.contoso.com is added with IP address 10.0.0.39, which is a private IP; and in default zone scope the same record (www.career.contoso.com) is added with IP address 65.55.39.10.

Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "65.55.39.10" 

Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "10.0.0.39” -ZoneScope "internal"

Explore Add-DnsServerResourceRecord

Note that no –ZoneScope parameter has been provided when record is being added in default zone scope. This is same as adding records to a vanilla zone.

Create the Policies

Once the server interfaces for external network and internal network have been identified; and the partitions (zone scopes) have been created, the next step is to create policies that connect these two, in a way that when the query is received on private interface, the answer is returned form the internal scope of the zone. No policies are required for mapping default zone scope. 

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW -ServerInterface "eq,10.0.0.56" -ZoneScope "internal,1" -ZoneName contoso.com

* 10.0.0.56 is the IP on the private network interface.

Explore Add-DnsServerQueryResolutionPolicy

How it all works

Now the DNS server has been configured with the required policies. When a name resolution query is incident on the DNS server so configured, each name resolution request is evaluated against the policies on the DNS server. If the server interface on which the query has been received matches any of the policy, the associated zone scope is used to respond to the query. So, in our example, the DNS queries for www.career.contoso.com  that are received on from private IP (10.0.0.56) are responded with an internal IP address; and the DNS queries that are received on the public network interface are responded with the public IP address in the default zone scope (this is same as normal query resolution).  

Selective Recursion Control

In the previous example, the same DNS server is serving both the external and internal clients and respond back with different answers. Certain deployments may require the same DNS server to perform recursive name resolution for the internal clients apart from acting as authoritative nameserver for contoso.com. For this, the recursion has to be enabled on the DNS server. But as the DNS server is also listening to the external queries, the recursion is also enabled for external clients and the DNS server becomes what is known as an open resolver. This makes the server vulnerable to resource exhaustion and can be abused by malicious clients to create reflection attacks. There is no reason why contoso.com’s DNS server should perform recursive name resolution for external clients. Essentially there is a need of recursion control such that the recursion is allowed for internal clients while blocked for external clients.

This can be achieved in following steps

Create Recursion Scopes

Recursion scopes are unique instances of a group of settings that control recursion on a DNS server. A recursion scope contains a list of forwarders and specifies whether recursion is enabled. A DNS server can have many recursion scopes.

The legacy recursion setting and list of forwarders are now referred as the default recursion scope. You cannot add or remove the default recursion scope, identified by the name “.” (Dot).

In this example, the default recursion setting is being disabled, while a new recursion scope for internal clients is being created where recursion is being enabled.

Set-DnsServerRecursionScope -Name . -EnableRecursion $False

Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True 

Explore Add-DnsServerRecursionScope  

Create Recursion Policies

DNS server recursion policies can be created to choose a recursion scope for a set of queries matching certain criteria. If the DNS server is not authoritative for those queries, these policies allow admin to control how to resolve those queries.  Here the internal recursion scope which has recursion enabled is being associated with private network interface

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainRecursionPolicy" -Action ALLOW -ApplyOnRecursion -RecursionScope "InternalClients" -ServerInterfaceIP  "EQ,10.0.0.39"

 Explore Add-DnsServerQueryResolutionPolicy

In both the examples ServerInterface has been taken as a criteria. Sometimes the split-brain may be required to be deployed on the basis of source client subnet. That can also be achieved using the client subnet criteria. (See how to use client subnet for traffic management)

How it all works

If a query for which the DNS server is non-authoritative is received, i.e. say for www.microsoft.com, then the name resolution request is evaluated against the policies on the DNS server. As these queries do not fall under any zone, the zone level policies (as defined in first case above) are not evaluated. The recursion level policies are evaluated and those queries which are received on private interface match the SplitBrainRecursionPolicy which points to a recursion scope where recursion has been enabled. The DNS server then performs recursion to get the answer for www.microsoft.com from internet and caches it locally. On the other hand if the query is received on the external interface, no policies match and default recursion setting (in this case disabled) is applied, preventing the server from acting as open resolver for external clients while it is acting as a caching resolver for internal clients.