DEM folder structure changes under "Personalization"

[curtistcreps]

I've been managing a Horizon environment for about the past three years at my organization. That includes managing DEM. When I first became the primary "VDI guy", I had to build off of what had already been put in place. With that said, DEM (though still needing some work) has been something I've focused in on a lot more lately in trying to better understand / polish up to better fit our organizations needs. It also is a bit unorganized partially due to the last person who managed it. I would like to re-organize some of the items in the "Personalization" section. 

We are using a mix of DirectFlex and rules that are processed at logon and logoff (I would argue 70% DirectFlex). Knowing how the DEM agent on the VM reads the data from the DEM Config location on the DEM server and processes the rules, I decided to do a small test to see if changing the directory structure would affect the export of user data that already had an active session running when I changed the rules. It appears that it did...

For example:

My Adobe Reader configuration is DirectFlex enabled (data is exported at logoff). I want to move it to the "Adobe" folder I created as shown above. I have a test user that is currently logged into a non persistent session at the time I move the configuration for Adobe Reader to that new folder. I open Adobe Reader as the test user, and all of the customizations I set are imported via DirectFlex as expected. After logging off, the data is exported still to the original path above \\DEM_User_Archive_Path\Applications\Standard\Adobe Reader.ini. The problem is, the next time I log on as that test user, since the folder path for the Adobe Reader configuration has been changed, DirectFlex no longer imports from \\DEM_User_Archive_Path\Applications\Standard\Adobe Reader.ini, but rather attempts to import from the new path \\DEM_User_Archive_Path\Applications\Standard\Adobe\Adobe Reader.ini. Since the new path does not contain any of the test users data, it does not import the settings. 

Is this expected behavior of DirectFlex? My thought is that if were to make a configuration change while users were already logged in that once they logged off, the DEM agent would be able to read the changes and export the DirectFlex data to the new location, but it doesn't seem to be the case...It just seems odd that rule changes like that would require the user to log out completely and back in again to process the changes. You can see why this is problematic though. I've got nearly 40 users that use these configurations. It would be a disaster to re-organize the folder structure, only to have users logout and still have DirectFlex export the data to the old paths. Next time they log in, any customizations via DirectFlex would be gone and would have to be moved manually in their Profile Archive. Not to mention it would bombard the helpdesk with calls...

Does anyone know a way to be able to re-organize the folder structure without causing such problems? My only thought is create the folders, duplicate the rules into those folders and wait a few days for users to log in / out to generate the DirectFlex data. Then after several days just retire the old rules. 

Any ideas?

[curtistcreps]

Quick follow up to this:

I ended up doing the exact thing that I mentioned in the article. I ended up creating the new folder structure and duplicating the existing configuration files. Only catch was, I had to disable DirectFlex on the new ones since you can't have the same set of executables enabled for DirectFlex on two configuration files (otherwise when you validate DirectFlex config in DEM it will show conflicts and the rules wont run right). Only drawback doing it this way was that while I waited for about a week for users to log in / out to have the new configuration structure generated in their profiles, the logon times were increased by a fair amount due to the new configuration files importing data at logon. After everyone had generated the new configurations, I changed the new ones back to use DirectFlex and reitred the old ones. 

I still think VMware needs a more streamlined solution to make things like this easier. I reached out to support to inquire if there was a better way of accomplishing this, but they did not know of anyway natively to accomplish this.