Writable disk to redirect Windows search (Index of Outlook only)

[cH1LL1]

Hi Guys,

In our non-persistent environment (Delete on log off)

we have Office 2016 installed in the base image - Office 365. (OST files are sitting on the SAN on a Cifs share via a drive mapping.)

The one obstacle we have is that users have a very poor searching experience, because the Window search service is disabled.

I want to do the following:

1. Create a custom Writable disk so I can redirect this Search content to a persistant location ( Cannont be a UNC path! )

2. Enable the Windows Search Service - this will require a recompose

3. Configure GPO for Indexing and redirect

Questions:

has anyone done this ?

What template do I use?

how do i make the Adjustments to the template config files to only Redirect "C:\ProgramData\Microsoft\Search".

Has anyone got a better idea ?

ManyThanks

[pchapman]

I was playing with this last week.  I think I've got it working, but haven't tested it a whole lot, and there may be better ways of doing things.  It uses the standard AppVolumes writable template.  I've combined this with the guide on VMware about how to redirect the OST: Managing OST Files with App Volumes & User Environment Manager - VMware Blogs

1. Leave Windows Search service disabled in parent image.
2. Create a GPO, link to the virtual desktop OU with the following settings:
   1. Computer Configuration -> Policies -> Windows Settings -> Security Settings ->Local Policies/User Rights Assignment
      1. Create Symbolic Links
         1. Specify a group that the users of the virtual desktops belong to, in the lab I just used Domain Users
   2. Computer Configuration -> Policies -> Windows Settings -> Security Settings -> System Services
      1. Windows Search
         1. Startup Mode: Disabled
         2. Permissions: Domain Users / Full Control
   3. Computer Configuration -> Policies -> Windows Settings -> Security Settings -> File System
      1. Grant Domain Users full Control to the following folders (You probably don't need all of these, but I was running into some weird issues so I included them all)
         1. %AllUsersProfile%\Microsoft
         2. %AllUsersProfile%\Microsoft\Search
         3. %AllUsersProfile%\Microsoft\Search\Data
         4. %AllUsersProfile%\Microsoft\Search\Data\Applications
         5. %AllUsersProfile%\Microsoft\Search\Data\Applications\Windows
   4. Computer Configuration -> Administrative Templates -> System/Group Policy
      1. Configure user Group Policy loopback processing mode
         1. Enabled, Merge
      2. This is needed to run the user-based logon/logoff scripts.  You can apply them in a different OU if you'd like, and leave this setting out.
   5. User Configuration -> Policies -> Windows Settings -> Scripts -> Logon
      1. logon.bat (below)
   6. User Configuration -> Policies -> Windows Settings -> Scripts -> Logoff
      1. logoff.bat (below) - Not sure if this is even needed.

Here are the logon / logoff scripts:

REM Logon Script

@echo off

rmdir /s /q C:\ProgramData\Microsoft\Search >> C:\Support\wsearch.log 2>&1

mkdir C:\SnapVolumesTemp\Writable\Search >> C:\Support\wsearch.log 2>&1

mklink /d C:\ProgramData\Microsoft\Search C:\SnapVolumesTemp\Writable\Search >> C:\Support\wsearch.log 2>&1

sc config wsearch start= demand >> C:\Support\wsearch.log 2>&1

sc start wsearch >> C:\Support\wsearch.log 2>&1

REM Logoff Script

@echo off

sc config wsearch start= disabled >> c:\support\wsearch.log 2>&1

sc stop wsearch >> c:\support\wsearch.log 2>&1

[BBurn]

So I agree that this does indeed turn on the indexing and capture it to the writable.  However....  in my testing so far, it appears that the system is still rebuilding the index on each login.  does this not defeat the purpose of capturing the indexing in the first place....

Or is there a crucial part of this that I am missing.  the cost to processing power may not be worth the effort, and that is what I am trying to determine.

Thanks!  I am really appreciative that you have shared what you learned so far.

Also, our OST is being captured in the writable already without UEM, not sure what the benefit of adding all that would be....at this moment.  if they have some fancy way to relink the index without making it rebuild it...  that would be epic.

Cheers!

[cH1LL1]

We implimented FSLogix  to solve this problem -  it took 20 minutes to install, and 2 minutes to get approval to go live.

Office 365 Containers - FSLogix Apps 2.8 - Documentation

[TTC-Seth]

I'm curious, (still learning VDI myself) Why did you opt to place the OST files on a share rather than simply put them on a user's writable volume?