Jump to content
Welcome to our new Citrix community!
  • 0

How to handle the various Windows 10 profiles


Nick Panaccio

Question

How is everyone handling the various Windows 10 profiles, given that 1507/1511 uses v5 and 1607 through 1709 uses v6 (no idea about 1803)? We're using "!CTX_OSNAME!!CTX_OSBITNESS!" in our profile path, and right now have separate profiles for 1703 (Win10RS2x64) and 1709 (Win10RS3x64). I realize that I could change the path to something like "Win10!CTX_PROFILEVER!!CTX_OSBITNESS!" (Win10v6x64) so that all Win10 VDIs are pointing to the same folder, but has anyone actually used something similar and upgraded from 1703 to 1709 using the same profile? I worry about corruption, especially after seeing how often Microsoft changes things around (see the Start tile location changes over the last few years).

 

If you're not keeping one "Win10" profile that applies to them all (assuming they're the same version), are you actually migrating these profiles? If so, how? Ideally, I'd love to just keep our current settings and let users customize their VDI desktop when we do version upgrades, but that may be a tall ask if we do 2-3 feature updates every year.

Link to comment

6 answers to this question

Recommended Posts

To update this, I started some initial, basic testing.

 

Test 1 - UPM Settings:

  • Path to user store: \\Domain\Share\#SAMAccountName#\Win10!CTX_PROFILEVER!!CTX_OSBITNESS!
  • Files to synchronize: AppData\Local\Microsoft\Windows\UsrClass.dat*
  • Already sync'd natively (in the registry): Software\Microsoft\Windows\CurrentVersion\CloudStore

Test 1 Steps:

  1. Login to the 1703 VDI and customize the Start tiles and FTA
  2. Login to the 1703 VDI again and verify that the Start tile and FTA customizations remain. Pass
  3. Login to the 1709 VDI and verify that the Start tile and FTA customizations remain. Fail. FTA customizations work, but the Start menu crashes (see image) and never opens

-------------------------------------------------------

 

Test 2 - UPM Settings:

  • Path to user store: \\Domain\Share\#SAMAccountName#\Win10!CTX_PROFILEVER!!CTX_OSBITNESS!
  • Files to synchronize: AppData\Local\Microsoft\Windows\UsrClass.dat*
  • Exclusion list (registry): Software\Microsoft\Windows\CurrentVersion\CloudStore

Test 2 Steps:

  1. Login to the 1703 VDI and customize the Start tiles and FTA
  2. Login to the 1703 VDI again and verify that the Start tile customizations are lost, but FTA customizations remain. Pass
  3. Login to the 1709 VDI and verify that the Start tile customizations are lost, but FTA customizations remain. Pass. FTA customizations work, and the Start menu opens

-------------------------------------------------------

 

Test 3 - UPM Settings:

  • Path to user store: \\Domain\Share\#SAMAccountName#\Win10!CTX_PROFILEVER!!CTX_OSBITNESS!
  • Exclusion list - files: AppData\Local\Microsoft\Windows\UsrClass.dat*
  • Already sync'd natively (in the registry): Software\Microsoft\Windows\CurrentVersion\CloudStore

Test 3 Steps:

  1. Login to the 1703 VDI and customize the Start tiles and FTA
  2. Login to the 1703 VDI again and verify that the Start tile customizations remain, but FTA customizations are lost. Pass
  3. Login to the 1709 VDI and verify that the Start tile customizations remain, but FTA customizations are lost . Pass. The Start menu customizations work, and FTA customizations are not retained

-------------------------------------------------------

 

So, long story short, I appear to be able to either roam the Start menu between 1703 and 1709, or roam FTA (using UsrClass.dat; I know that I can export/import HKCU\SOFTWARE\Classes\Applications via script to handle FTA). Still, I wonder if this is going to be an acceptable risk in the future or not, because I don't know if anything else will break as a result of having Citrix Profile Manager use the same directory for all Windows 10 VDIs [on the same version]. I don't intend to run multiple Windows 10 builds at the same time, so my testing is basically a one time jump from one build to the next; there will be no moving back and forth between the two.

 

Still, I'd love to hear how others are handling this.

Start menu error.jpg

Link to comment

I realize that I'm talking to myself at this point, but now in my 1709 image and profile, the only way to prevent the Start menu from crashing with the error posted above is to exclude  AppData\Local\Microsoft\Windows\UsrClass.dat* from UPM. That wasn't the case in 1703 for me. So much fun.

Link to comment

I haven't tested that upgrade yet, no. We basically settled on using Win10!CTX_PROFILEVER! for our Profile Management path string so that we didn't have to worry about a newer version profile corrupting it. By all accounts that I've read - and there weren't many - we should be okay to use the same profile when we upgrade from 1709 to 1803, etc. provided that the profile version is identical.

 

We'll be going to 1809 next, as well, so once we're closer I'll be going down that path. I'll certainly add my findings back to this thread.

Link to comment

We have already a large number of profiles in place that used the old naming "!CTX_OSNAME!\!CXT_PROVILEVER!" so its not so easy for us to migrate.

To get higher compatibility, I changed the path to "Win10RS2!CTX_PROFILEVER!".

Thats how I saved my users Profiles after upgrading UPM to 7.15 CU3 because it keeps the Path "Win10RS2" at logon.

 

 

I will do some testing when 1809 is stable and report. I hope they don't increase the Profile Version to V7 ...

 

 

Link to comment

Hi,

Very interested to know how people proceeded with this piece. I have a customer right now who we are migrating from 1703 > 1709 and then will be proceeding to 1809 in the summer. At present with 1703 this sits in a different folder structure share to 1709 and I want to keep profiles seperate as a best practice having done this previously in various other projects. 

 

To date I have not had much luck with migrating a Windows 10 device that has a UPM Profile stored on the device and have needed to delete the local profile which in turn removes the possibility for this to be upgraded locally and then uploaded. By doing this means once it arrives inthe 1709 environment its a clean RS3 profile at logon and has now resemblence to the RS2 profile previous.

 

Did you make any positive progress?

 

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...