Accepted Solutions
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 @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.
