VMware Horizon Community
aterrell04
Contributor
Contributor
Jump to solution

Does DEM 2111 no longer support hidden token paths?

We have two Horizon environments running with DEM. One is an older 7 deployment with DEM 9.11.0.932 while the new environment uses DEM 2111. On the older environment we have DEM preserve a few custom paths using <programdata>\Common Files\AppVendor\App and <programdata>\AppVendor\SecureString it worked marvelously and each user could persist their activation and license across the desktop pool and rdsh pool. I'm in the process of redesigning and rebuilding based off the same concepts on the latest Horizon build including DEM 2111 but it seems the token paths don't work anymore. The DEM policy is applying as it captures and stores <LocalAppData>\AppVendor just fine in the same config file but it seems to be actively ignoring the hidden paths for <programdata>. Is this feature no longer available? 

The screenshot shows the config as it appears on both the old 9.11 and 2111 DEM consoles. 

Reply
0 Kudos
1 Solution

Accepted Solutions
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi @aterrell04,

Folder tokens are treated case-sensitively in the Management Console. Can you try <ProgramData> with capital 'P' and 'D'?

DEMdev_0-1650307371380.png

The agent does not care, though, so your lower-case <programdata>\Common Files\AppVendor\App should work just fine at run-time. Are you seeing something different in the log?

View solution in original post

Reply
0 Kudos
14 Replies
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi @aterrell04,

Folder tokens are treated case-sensitively in the Management Console. Can you try <ProgramData> with capital 'P' and 'D'?

DEMdev_0-1650307371380.png

The agent does not care, though, so your lower-case <programdata>\Common Files\AppVendor\App should work just fine at run-time. Are you seeing something different in the log?

Reply
0 Kudos
aterrell04
Contributor
Contributor
Jump to solution

Thanks for the tip! I ended up solving through the use of DirectFlex and forcing import at launch which seemed odd as the previous version did not need this. I went back and tried to change the path with Case Sensitivity and voila! Now the path isn't showing with the red intellisense. I haven't tried to disable DirectFlex to test, but my guess is that was the cause. 

 

aterrell04_0-1650639131402.png

 

Thank you again for the guidance and I hope this helps save someone the pain in the future! 

aterrell04
Contributor
Contributor
Jump to solution

I may have spoken too soon. I noticed it is running just fine and everything appears okay, but I can't inject the user's personalization file or license data even with DirectFlex. It launches with the default license and contents but attempting to even manually inject the files after attaching fails (it auto-reverts to the default ones on app launch). I looked at the FlexEngine Log and noticed access denied errors. I think I've got permissions right (they mirror our working previous DEM environment) so I'm not sure what I'm missing now. Any more ideas?  

 

2022-04-26 15:04:01.536 [ERROR] ImportFiles::ImportFile: Access denied on 'ProgramData/Common Files/folder/appfolder/filename.file

Are there other logs I can look at to find out what is going on? I have basically global "allow" permissions on the share \\domain.local\dem\dem_config\ so I'm not sure what I'm missing. 

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

@aterrell04,

DEM's secret/hidden tokens only allow you to reference paths outside the user profile; file system permissions apply as usual.

That access denied error is related to permissions on the ProgramData folder (or one of its subfolders, or the file itself.) You will have to "open up" the ACL(s) to make that work.

Reply
0 Kudos
aterrell04
Contributor
Contributor
Jump to solution

So I did make changes to the subfolder as needed and now I can at least see it copying the base version of the file into the profile archives. I made a 0Kb "dummy" file in the directory on the golden image and when the user logs in it is present even after the AppVolume attaches. Previously the AppVolume version of the file would overwrite whatever was in the path. I then tried to overwrite the file with one containing valid data for the user. And like on the old version of DEM it works. I can run the app and everything seems peachy. When I go to log the user out Flexengine debug log says it sees the files in the path and indicates it captures them as intended. 

When I look in the archive (after the user has fully logged off and the changes have been written) the path is present as is the file. It just happens to be the 0Kb dummy file I made on the golden image not the one I imported manually for the user. I've been going crosseyed looking for differences in the two platforms and only one major one comes to mind.

On the old golden image and old DEM environment, I have an older copy of the app installed. If you try to run the app from the golden image without the right license file it launches but gives a license error. In the old environment, when a user logs on they get a desktop based off the golden image, the AppVolume attaches with the correct version of the app, and for only the first time, I drag/drop the correct license file into the path for the user. They can then work without issue.

When they log off the process reverses but DEM captures the license file I dropped in not the one from the AppVolume or the one from the golden image. 

Does 2111 process logging users off differently where it might cause this to not work? Any ideas as to what I'm missing?

Regardless, thank you for the help thus far I really do appreciate it! 

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

@aterrell04,

> Does 2111 process logging users off differently

As of DEM 2111, DEM runs a tiny bit later in the overall logoff (compared to the logoff-script approach in previous versions; nothing has changed in NoAD mode.)

I can't imagine this to be material, though. Which version of App Volumes are you using?

Reply
0 Kudos
aterrell04
Contributor
Contributor
Jump to solution

We are using APP VOLUMES 4, VERSION 2111 (4.5.1.10) in the new environment. 

The old environment is using VERSION: 4.0.1.35 of AppVolumes and DEM version 9.11.0.932

The VDI desktops are using agent 4.5.1.10R 

 

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

@aterrell04,

There used to be an issue where App Volumes detached the (implicit) writable volume before DEM's export took place (which might result in the behavior you described, i.e. DEM exporting contents from the base image), but I'm pretty sure that was fixed before App Volumes 2111.

No clue then, I'm afraid, so probably best to open an official support ticket for this.

aterrell04
Contributor
Contributor
Jump to solution

Understood. I found a KB that looked similar to what you are describing but wasn't sure how to fix it. I'll open a case and follow up here with what we learn. 

Thanks again for helping and giving some leads! 

Reply
0 Kudos
aterrell04
Contributor
Contributor
Jump to solution

Still waiting to hear back from support officially, but since our rollout is hung up on this I've been poking at it more. I found a work around or maybe a solution?? In addition to the personalization section using <ProgramData> as @DEMdev mentioned with case sensitivity and folder permissions, I created a user environment Logon Task to perform an xcopy of the personalization file asynchronously. I thought this would be a temporary work around, but for some strange reason the file that is brought over by the xcopy procedure into the <ProgramData> path (and where the AppVolume attaches its own settings/files) persists the app launch which is great. To my surprise when I logged the user out, the Profile Archive retained the version of the customization file the xcopy task put in just like the old system (which doesn't have the xcopy task enabled). 

 

It is a completely bizarre behavior and if you asked me what is happening in the background I wouldn't have an answer but maybe this can help someone else. I'll still follow up with what the support reps I'm in contact with find but this has been a wild rollercoaster! 

aterrell04_0-1651255822563.png

 

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

@aterrell04,

Happy to hear this has unblocked your rollout, but it sounds, umm, quite surprising... There's effectively no difference between having DEM personalization (profile archive import) put that file into that folder, or having a DEM logon task do that through xcopy...

Anyway, I'm also interested in hearing what support will tell you 🙂 Do you have an SR# you can share (here or privately)? I'm off for a while, but I might sneak a peek, as I'm curious as to what's going on here.

Reply
0 Kudos
lansti
Hot Shot
Hot Shot
Jump to solution

Hi, I also see that DEM does not export all files from a folder in %programdata%.
I'm running DEM 2209.
[IncludeFolderTrees]
<ProgramData>\Application1

This application1 is running from an Appstack, and i have check that the user have the correct rights on this folder.
DEM is importing one file with Files and Folders, and that file is also exporting back. But, users often do some settings modifications that should follow them, and a new XML files is written to the folder %programdata%\application1. But this file is not exported to the archive.

My logs is telling me that export is successfull:
2023-06-27 08:10:36.023 [DEBUG] ExportFiles: Recursively processing folder '<ProgramData>\application1'
2023-06-27 08:10:36.034 [INFO ] Exported file information successfully

But it is missing the new XML file with modifications.

Best regards
Lansti
Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi @lansti,

That sounds a bit like the scenario I mentioned in my earlier response to this thread. There seems to be a scenario where App Volumes detaches the writable volume before DEM gets to run at logoff.

To validate that assumption, can you test whether it works when you perform the export during the session rather than at logoff? That is, is this something you can do via DirectFlex?

Alternatively/additionally: If you run a batch file from a DEM export task that DIR's that folder and redirects the output to some persistent location, do you see the expected files in that output?

Reply
0 Kudos
lansti
Hot Shot
Hot Shot
Jump to solution

Hi @DEMdev , a little late reply on your reply... 

I tried this, and my isse is that i already have a script, that should import "default config" when a user choose to import the default config. And i see that my configfile is changing, but since i have direct flex configured for the application that uses this config, the profile is importet over my recent importet configfile... and I can not import the config file while application is running, becase the application will still se the old one.. so whatevere i do, i always will import end axport the file that i have in my DEM Profile, and not the new imported one. 

 

Hope you understood this 😄 

Best regards
Lansti
Reply
0 Kudos