I am now working on preparing the Horizon 8 environment with DEM 2209.
In our previous DEM environment, we only had one environment. In Horizon 8, there will be several DEM environments and therefore a different folder structure than what we have today in production.
We have users using different browsers: Chrome, Firefox and Edge.
In these, users have history, bookmarks, etc., which we want to accompany the users to the new platform.
For Chrome, we have turned on a policy that creates a profile.pb. I have scripted this so that it is copied out to the user's profile area, so that we can import this again when the user logs on to Horizon 8, and thus get the bookmarks at least.
But there are of course several things that I want to include from today's Chrome, to tomorrow's chrome. I can certainly script everything, but I thought I would look at alternatives.
Chrome is currently in Horizon 7's DEM environment under the "Applications" folder, and in Horizon 8 it will be under "Default apps".
I tried to have 2 config files with Chrome in Horizon 8 (test environment), where it imports what we have lying around in the Horizon 7 environment into VDI, and exports it out to both horizon 7 and the horizon 8 environment. This seemed to allow me to migrate the data from Horizon 7 to Horizon 8. I verified that the files located on my profile application/Chrome.zip and "Default apps\chrome.zip" were the same size and that all the files in these zips were identical.
When I then disable the Horizon 7 version, and log in, I was missing several bookmarks(not all) etc, and when I log out, "Default apps\chrome.zip" becomes significantly smaller.
I have read the User Environment Manager Application Migration.pdf, but didn't get very wise.
The config in chrome.ini is the same for Horizon7 and Horizon 8, so I would assume that import and export would be the same for both files, but that is not the case.
This is what chrome.ini looks like:
<AppData>\Google\Chrome\User Data\Profile 1\profile.pb
<AppData>\Google\Chrome\User Data\Profile 2\profile.pb
<AppData>\Google\Chrome\User Data\Profile 3\profile.pb
<AppData>\Google\Chrome\User Data\System Profile\profile.pb
<LocalAppData>\Google\Chrome\User Data\First Run
<LocalAppData>\Google\Chrome\User Data\Last Browser
<LocalAppData>\Google\Chrome\User Data\Local State
<LocalAppData>\Google\Chrome\User Data\Module Info Cache
<LocalAppData>\Google\Chrome\User Data\Default\Extension Cookies
<LocalAppData>\Google\Chrome\User Data\Default\Extension Cookies-journal
<LocalAppData>\Google\Chrome\User Data\Default\Extension State
<LocalAppData>\Google\Chrome\User Data\Default\Local Extension Settings
<LocalAppData>\Google\Chrome\User Data\Default\Local Storage
Does anyone here have experience with taking settings from an old DEM environment to a new DEM environment?
I think I'm missing something, but it reads way more complicated than necessary from my experience We didn't do anything special at all going from DEM 9.9> 10.1 >10.4 and we use the same DEM configurations in two separate environments (test and Prod). All the exported DEM profiles travel between 2012,2016, win11 pools every day. Same DEM profile storage location for everything. Sure, during sanity/validation testing I've cloned out a separate DEM environment. Got a bunch of garbage in your current DEM environment and want to start clean and only import good settings? clone it out the config and use policy to point pools to one DEM environment or the other. The user Appdata in either DEM instance *should* be portable.
For DEM upgrade verify the compatibility matrix (it should be)! Upgrade order is:
Hi, thanks for your reply. Yes i have a bad habbit of doing things complicated for my self sometimes...
But, when we first configured UEM back in the days, it was very messy, where everything was in one environment. It took ages to log on, because we had, no kidding, over 300 shortcuts, depending on your role. Everything was installed into the golden image. Now when we are going to Horizon 8 we wanted to start over with a clean DEM 2209, thin goldens with appvolumes.
Therefore, our DEM environment is divided into 7-8 environments. And where the settings are located in Horizon 7, will not be the same in Horizon 8, so these settings will not be imported. Basically, users will start with completely empty profiles if we do not import settings of today. Because the folderstructure in DEM is totally different. I may be thinking too complicated, so I have tried slightly different approaches.
I get it. We also did recreate our UEM/DEM for 2111 ...mostly. it's still a just a copy of the previous which was built on our first implementation but with less crap, more condition sets, and is faster/better in every way because we are wiser and smarter now 😉 As mentioned the appdata is the same i didn't notice any DEM folder structure difference between 710-2111. whatever was stale was cleaned up with *.zip seach and purged if not modified in the last 6months. The app DEM profiles, say Chrome, really could be the same between the versions unless there is a feature you are using out of the gate, if so, my suggestion is to not do that until all the DEM components are upgraded.
We also started with too many Appvols, which was terrible paid advice that I wouldn't wish on my enemies. I hope 2209 works for you better, but IMO appvols should be used very sparingly only to keep from having to have a separate image and then disabled when not used for that pool/farm.
We are working with non-persistent desktops, and have named the different pools like:
First character indicates Test/Production/somethingElse environment
Second character indicates City
Third, M10 og T4 nvidia card,
Number, just an unique value, that tells our support team what kind of pool the users are logged on.
With appvols we then assign with condition: computers whose name begins with P
We currently have 14 app volumes, of which 3 are default, and the rest are assigned based on role and needs.
Much faster with this config than everything inside the golden, and much better for me when i need to patch these, rather than 11 golden images.