Configure App Volumes Settings (UEM 9.3)

[JohnTwilley]

The Latest version of UEM (9.3) adds support for App Volumes.  It is very limited at the moment, but it's a start.

After looking through the documentation, I was still a little confused.

https://docs.vmware.com/en/VMware-User-Environment-Manager/9.3/com.vmware.user.environment.manager-a...

Older Method: Managing OST Files with App Volumes & User Environment Manager

In the past, you needed to customize a ADMX for Office to redirect the OST to "C:\SnapVolumesTemp\Writable"

Is this no longer necessary?  The documentation never mentions an ADMX configuration...so I'm assuming it is no longer needed.

Also...can/should we set a Customization looking for this path? C:\SnapVolumesTemp\Writable

Has anyone using UEM 9.3 & App Volumes tried this yet?

Please let us know what you found!

John

[DEMdev]

Hi JohnTwilley,

Indeed, those manual steps of configuring the Office Group Policy setting by importing the ADMX template into UEM are no longer necessary – the new feature in UEM 9.3 gives you the exact same thing by just checking a box.

Also...can/should we set a Customization looking for this path? C:\SnapVolumesTemp\Writable

Not sure whether I understand the question. If you mean whether you should change the default paths in that Advanced Settings dialog: not unless you have a very good reason. Basically, if you have to ask, you don't need to change it 🙂

[JohnTwilley]

Also...can/should we set a Customization looking for this path? C:\SnapVolumesTemp\Writable

What I meant to ask was, should we create a Rule to look for the path "C:\SnapVolumesTemp\Writable" and apply the policy if found.

I was not sure which is processed first.. UEM OR the App Volumes mount point.

I'm just beginning to play around with App Volumes in the lab, so I'm trying to determine a Best Practice.

John

[DEMdev]

Ah, I see. App Volumes attaches the writable volume before UEM runs, so there's no need to check for that path yourself.

Also, in case UEM runs on a system on which App Volumes is not installed, or for a user for whom no writable volume is configured, everything will still work fine. You'll see informational log messages like App Volumes service is not installed -- skipping writable folder configuration for Offline Outlook Data File (.ost) or Folder 'C:\SnapVolumesTemp\Writable' not found -- skipping writable folder configuration for Offline Outlook Data File (.ost).

[LarryBlanco2]

Hmm.. I don't seem to be having the desired effect and/or expected behavior.   I set up according to the documentation here: Configure App Volumes Settings and it's still placing the OST file at it's default location of 'C:\Users\someuser\AppData\Local\Microsoft\Outlook\someuser@domain.com.ost

UEM did create the folder structure of: 'C:\snapvolumestemp\writable\UEM\OST'

2018-02-07 16:01:22.316 [INFO ] Collected App Volumes settings to apply for Offline Outlook Data File (.ost) ('Outlook OST redirection.xml')

2018-02-07 16:01:22.378 [INFO ] Applied App Volumes settings

and then further down

2018-02-07 16:01:24.488 [DEBUG] Conditions: Evaluating condition set 'Microsoft Office 2016.xml'

2018-02-07 16:01:24.566 [DEBUG] Conditions: Check for path 'C:\Program Files (x86)\Microsoft Office\Office16' = false

I understand the condition set because UEM is likely running b4 the Office App Vol is attached.   That is another question I have, How can I rerun UEM condition sets in the allvolattached.bat file.   I currently have 'CMD.EXE /C "C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe" -DirectFlexRefresh' but that doesn't seem to do the trick 4 me.

I'm running Office 2016 Stardard on this AppStack.  All the latest updates have been applied to office.

Any and all help is greatly appreciated.

Larry

[DEMdev]

Hi LarryBlanco2,

UEM uses the standard Outlook Group Policy setting to specify the location of the OST file, but Outlook only picks that up at first launch. Could you try this with a user for whom Outlook hasn't been configured yet?

2018-02-07 16:01:24.566 [DEBUG] Conditions: Check for path 'C:\Program Files (x86)\Microsoft Office\Office16' = false

That's indeed most probably because the AppStack with Office hasn't attached yet at the time UEM runs. Running "C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe" -DirectFlexRefresh from allvolattached.bat should do the trick, though. Can you post a FlexEngine log file (at log level DEBUG)?

[LarryBlanco2]

So I did manage to get the redirection to work properly with UEM and App volumes.  I think something was not working correctly with GPP's.   After recreating the Group policy it worked.  It was weird.

So the only thing I am left with is running FlexEngine from the allvolattached.bat file.

It runs it initially upon login correctly.  

2018-02-08 16:22:22.342 [INFO ] Starting FlexEngine v9.3.0.804 [IFP#01df79ef-3e7>>]

2018-02-08 16:22:22.342 [INFO ] Running as Group Policy client-side extension

2018-02-08 16:22:22.342 [INFO ] Performing path-based import

A LOT MORE STUFF

2018-02-08 16:22:23.842 [DEBUG] Running as Group Policy client-side extension -- skipping all refresh-related actions

2018-02-08 16:22:24.295 [DEBUG] Started injection

2018-02-08 16:22:24.295 [DEBUG] Launched FlexEngine in DirectFlex mode

2018-02-08 16:22:24.373 [INFO ] Done (2040 ms) [<<IFP#01df79ef-3e7]

AND THEN

2018-02-08 16:23:10.899 [INFO ] Completed DirectFlex import (10 ms) [<<IFP#0296922f-60db2]

But when attempting to run the allvolattached.bat with C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe" -DirectFlexRefresh the event viewer is showing:

EVENT 283,  Immidio Flex+

Invalid Configuration: 'Flex Config Files path' must be configured in Group Policy for DirectFlex refresh.

I do have it configured in there otherwise it would work the first go around.  I can execute the batch file manually from the VM and it runs with no issue.   So All I am left to guess is that it's running under the SYSTEM context?

Larry B.

[DEMdev]

Hi LarryBlanco2,

I think this is related to App Volumes, and I'm afraid I don't know enough about that... What version of App Volumes are you using, and are you using the default snapvol.cfg or did you modify it?

[techguy129]

There is a current issue with App Volumes 2.13 where the C:\SnapVolumesTemp folder is not visible. The file system driver is hiding the folder from the operating system. This might be the cause of your issue. I suggest rolling back to 2.12 as a temp fix. A fix should be coming out in the next update.

AV 2.13.1: Can no longer see C:\SnapVolumesTemp after updating to 2.13.1

[DEMdev]

Hi techguy129,

Good point, but the "OST on writable" feature in UEM is not affected by the invisible C:\SnapVolumesTemp folder.

The "temporarily invisible" policy settings also can't be explained by that, I think.

[LarryBlanco2]

Currently I am using App Volumes v 2.13.2.13

I did modify the snapvol.cfg file according to this KB:  VMware Knowledge Base

I opt'd for the zip file which I uploaded to App Volumes.

Current Zip: 2149799_OutlookIndexConfig.zip uploaded by MyDomain\MyUserAcct on Nov 21 2017(View 4 Files)[16 of 10 updated]

Larry

[DEMdev]

Hi LarryBlanco2,

Good thing I said earlier that "I think this is related to App Volumes, and I'm afraid I don't know enough about that..." 🙂

Your "So All I am left to guess is that it's running under the SYSTEM context?" was right on the money: looking at the App Volumes docs it turns out that up until AV 2.11, allvolattached.bat ran in the user context, but starting with 2.12, it runs as SYSTEM.

There's now an allvolattached_shellstarted.bat, which is run in the user context, so moving your DirectFlex refresh call over to that script should hopefully do the trick.

[LarryBlanco2]

lol.  

I'll give that a try and will report back.  I guess next time I will need to read thru the docs in their entirety.

Larry

[LarryBlanco2]

That did the trick.   It does indeed run under the user context.

Awesome & thanks!

Larry B.