DEMdev's Accepted Solutions

Hi @mbrundage, Does the log file show that DEM still redirects AppData for a user for which this shouldn't happen? What does the AppData value in key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\... See more...
Hi @mbrundage, Does the log file show that DEM still redirects AppData for a user for which this shouldn't happen? What does the AppData value in key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders look like in that case? Is it C:\Users\user name\AppData\Roaming, or does it point to the (old) network location? If the latter: Are you by any chance exporting the Shell Folders key with DEM?
Hi @goran_j, This is an agent setting, which is why you can't find it in the Management Console. If you configure the DEM agent via GPO, you can download the advanced ADMX template from KB 2145286,... See more...
Hi @goran_j, This is an agent setting, which is why you can't find it in the Management Console. If you configure the DEM agent via GPO, you can download the advanced ADMX template from KB 2145286, and then configure the Custom commands as SYSTEM policy setting: If you use NoAD mode, you can configure the equivalent settings your NoAD.xml config file.
What did you configure in DEM? Anything that might conflict with that Group Policy setting?
Hi @TomH201110141, Thank you for the config files. Can you try setting Arguments to "%1", like this: When Windows launches the associated executable, it will replace that %1 with the fully-qua... See more...
Hi @TomH201110141, Thank you for the config files. Can you try setting Arguments to "%1", like this: When Windows launches the associated executable, it will replace that %1 with the fully-qualified path of the file.  
Hi @mathewdsa, We pay a lot of attention to maintaining backwards compatibility, so you're good to go for upgrading from 9.3 to 10.x. Folder structures (both on the agent side and the config share) ... See more...
Hi @mathewdsa, We pay a lot of attention to maintaining backwards compatibility, so you're good to go for upgrading from 9.3 to 10.x. Folder structures (both on the agent side and the config share) have remained the same.
Hi @lvaibhavt, You're running in Workspace ONE UEM Integration mode, where the concept of a config share does not apply. You can change that on the Integration tab of the settings dialog.  
Hi @SebastianK8, I've taken a look at this, and this would indeed require changes on the Horizon agent side. The USB redirection component processes almost all of its configuration before DEM gets t... See more...
Hi @SebastianK8, I've taken a look at this, and this would indeed require changes on the Horizon agent side. The USB redirection component processes almost all of its configuration before DEM gets to perform its logon activities; only the USB redirection enabled/disabled setting that can be applied with DEM Horizon Smart User Policies is picked up afterwards. You can allow specific VIDs/PIDs using Horizon Smart Computer Policies or using an elevated task (which allows targeting based on user/connection conditions), but those settings won't be picked up until a session reconnect. Hardly a user-friendly approach
Hi @tschuegy, That's fine as far as the DEM agent is concerned. Just be aware that depending on where that folder is located (and/or how you have managed ACLs) your end user might be able to add/rem... See more...
Hi @tschuegy, That's fine as far as the DEM agent is concerned. Just be aware that depending on where that folder is located (and/or how you have managed ACLs) your end user might be able to add/remove/change settings, which would allow them to run executables with elevation, circumvent application blocking and Group Policy-based restrictions, et cetera.
@JohnLord, Looks like the corresponding vdm_common.adml file is not valid according to its XML schema: You can fix this by opening that file in Notepad and setting that defaultItem attribute to... See more...
@JohnLord, Looks like the corresponding vdm_common.adml file is not valid according to its XML schema: You can fix this by opening that file in Notepad and setting that defaultItem attribute to "0". We'll make the DEM Management Console a bit less picky w.r.t. this validation – thank you for bringing this to our attention. 
@MaxStr, Looks like you upgraded to the Standard Edition. Just uninstall that, and install the Enterprise Edition, and you should be good to go.
@lansti, FlexEngine.exe -r path\to\profile\archive.zip can be used to import an individual profile archive. If you run this from a DEM logon task, you can add -f name\of\a\separate\logfile.log – the... See more...
@lansti, FlexEngine.exe -r path\to\profile\archive.zip can be used to import an individual profile archive. If you run this from a DEM logon task, you can add -f name\of\a\separate\logfile.log – the main log file will be locked, so the logging of that individual import would end up in FlexEngine-1.log otherwise. Another approach would be to just copy each user's "old" Chrome profile archive into their "new" profile folder (taking care of file system permissions and such), and have DEM just import it as usual when they log on to the new environment for the first time?
Hi @aterrell04, Folder tokens are treated case-sensitively in the Management Console. Can you try <ProgramData> with capital 'P' and 'D'? The agent does not care, though, so your lower-case <pr... See more...
Hi @aterrell04, Folder tokens are treated case-sensitively in the Management Console. Can you try <ProgramData> with capital 'P' and 'D'? 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?
Hi @tschuegy, We've seen that behavior on Citrix with DEM 2111 (and on earlier DEM versions as well, when using NoAD mode), and it seems that Citrix WEM plays a role. Are you using WEM, by any chanc... See more...
Hi @tschuegy, We've seen that behavior on Citrix with DEM 2111 (and on earlier DEM versions as well, when using NoAD mode), and it seems that Citrix WEM plays a role. Are you using WEM, by any chance? The issue is fixed in DEM 2203, which is scheduled for release next month. The workaround for now is to disable multi-session support using the attached advanced ADMX template. You'll still get the "Logon time: <error>" bit in the log, but the path-based export takes place. (Multi-session support is typically not required, but just to make sure: this takes care of RDSH scenarios where users can have multiple concurrent sessions on the same host. In that case, a path-based import should only be performed for the "first" logon of a certain user, and the path-based export should effectively be skipped until the user logs off from their last session. That logic requires getting the user's user name at logoff, so we can determine whether they have any other sessions on the machine, and that's what's failing with that error 1733 on Citrix WEM.)  
Hi @tschuegy, Sure, DEM will undo certain settings at logoff. There's no supported way to prevent that for ADMX-based settings; you could hack something together for this, but that would mean that t... See more...
Hi @tschuegy, Sure, DEM will undo certain settings at logoff. There's no supported way to prevent that for ADMX-based settings; you could hack something together for this, but that would mean that those settings will never be reverted by DEM. Addressing the root cause (i.e. making sure that logon scripts run synchronously) would be a better solution, I think. And, no, as DEM 2111 no longer requires logon/logoff scripts, "Run logon scripts synchronously" is no longer required either.
Hi @burgerking68, That looks like a bug. The When updating drivers for an existing connection dropdown in the Point and Print Restrictions policy setting used to have three options in older versions... See more...
Hi @burgerking68, That looks like a bug. The When updating drivers for an existing connection dropdown in the Point and Print Restrictions policy setting used to have three options in older versions of the Printing ADMX template, but now only has two. I guess your ADMX-based setting was defined using the old templates, with the third option (Do not show warning or elevation prompt) selected, and you have since updated the templates to newer versions. (It seems that Microsoft updated the templates last June.) The Management Console is unable to match the third option as defined in the ADMX-based setting with the options available in the ADMX template. It should handle such a situation in a more robust manner; we'll work on that. Thank you for bringing this to our attention! A quick workaround would be to temporarily go back to the old Printing ADMX template, and edit your ADMX-based setting. Happy to do that for you, if you prefer; just send me the ADMX-based settings configuration file (here or in a private message.)
Hi @TomH201110141, You can call FlexEngine.exe with the arguments -m caption firstMessageLine secondMessageLine ... lastMessageLine To close the message automatically after X seconds, use -mnX ... See more...
Hi @TomH201110141, You can call FlexEngine.exe with the arguments -m caption firstMessageLine secondMessageLine ... lastMessageLine To close the message automatically after X seconds, use -mnX  To allow the user to dismiss the message earlier, use -maX Out of curiosity, what types of tasks would DEM still be performing in the background that would require this?
Hi @cbaptiste, Config files for each settings type are processed in alphabetical order, and the last one wins.
Hi @Hoodsie2018, You could do this by putting conditions on the configuration files. You could check the pool name, for instance: Or, if the pools use different images, you could bake some spe... See more...
Hi @Hoodsie2018, You could do this by putting conditions on the configuration files. You could check the pool name, for instance: Or, if the pools use different images, you could bake some special registry key into the image, and do something like: I would suggest to create one or more condition sets with whatever condition(s) you choose to use, and then reference those condition sets from your configuration files, rather than the conditions themselves. That allows for easier updates in the future, if required. This approach means that you'd have to modify all your personalization config files (or all non-personalization config files, depending on whether you go for a "apply if this condition matches" or "do not apply if this condition matches" approach), which can be a hassle. Instead of putting conditions on your config files, you could consider having DEM perform its personalization logic, but using a non-persistent profile archive folder for some desktop pools. (Given your "Each time they log in, it's a clean slate" statement, I'm assuming these are Instant Clones.) For instance, you could configure a profile archive path of %LOCALAPPDATA%\VMware\DEM for the desktop pools where you do not want DEM to persist settings. If you enable Group Policy loopback processing in merge mode, configure this "non-persistent profile archive" setting, and target it to computer OUs with desktops where you don't want DEM to persist settings, it will override the "normal" profile archive path coming from the "normal" user GPO. This is still somewhat involved, so in a future DEM version we will add an agent configuration setting to disable personalization.
Hi @mvftw, You can indeed install the Management Console on another computer and point it to the same share. Just to make sure, based on your "I don't want to disturb anything" statement: any chang... See more...
Hi @mvftw, You can indeed install the Management Console on another computer and point it to the same share. Just to make sure, based on your "I don't want to disturb anything" statement: any change you'll make through that newly installed Management Console will be picked up by the DEM agents that are configured to that share... So it's not so much about being careful with doing anything to that original Win 7 machine; it's really about the contents of the configuration share. If you want to become acquainted with DEM without any risk of breaking anything currently running in production, I'd suggest to create a small test setup (one VM with the Management Console and file share, and one or two VMs with the DEM agent, for instance.) You can just copy over the contents of your production share to your test share.
Hi @Lieven, Here you go: DEM Standard Edition and DEM Enterprise Edition.