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

After Windows 10 upgrade system files saved on userlayer conflict with os update.


David Kurtz1709159055

Question

We are currently on Windows 10 v1703.  Recently created a new version of the os layer with Windows 10 v1803.  Upgrade seemed to go fine no issues there.  I pushed this out to a few test machines with no issues.  When i updated myself I was getting strange compatibility errors when attempting to open c:\windows\system32\mstsc.exe (remote desktop).  Also c:\program files\internet explodrer\iexplore.exe would not run, I could see it in task manager but it would always go to suspended and never open.  I logged off and noticed that both of these exe's are on my user layer.  So I am assuming they are versions for the previous OS not the new one.  Is there any way to prevent this?  I see a lot of system files saved to my userlayer.  I hate to go through every single userlayer and manually delete system files that shouldn't be there in the first place every time I upgrade Windows 10.  Does anyone else have these issues with upgrading to a new version of Windows 10?  I have also opened a ticket for this just wanted to run this by everyone.

 

Thanks

David

 

Windows 10 v1703 going to v1803

vmware horizon 7.7

ELM 18.12

Vmware ESXI 6.5u1

Link to comment

4 answers to this question

Recommended Posts

We should be automatically doing that at a major Windows update.  We will intentionally go through the User Layer, look for strategic files we have recorded as being "moved" from the boot image (as opposed to newly created in the User Layer) and remove them.  Engineering says specifically your situation should be covered.  The only thing we can think of that our database of moved files (stashed somewhere under C:\Program Files\Unidesk\etc, as I recall) has gotten corrupted so we no longer have a record of what the original state of those files was.  That would be a problem specific to an individual user layer, and not something you'd need to worry about across all of your users.

 

We have no better resolution for a broken move-file database than what you're doing: recreate the User Layer or manually clean it up.  But this rally is supposed to work exactly as you hoped it would.  If you're seeing this on more machines than just you, then there might be a systematic reason why your move-file databases are getting damaged, but it's hard to imagine how unless your machines are crashing all over the place (which does have a way of corrupting individual files).

Link to comment

That makes sense, I did some spot checking on some offline userlayers this morning and i did not see the same issues I had on mine.  It does appear to be isolated to myself.  I have multiple back ups of userlayers, is there any way to check those for corruption?  Are there things that you can recommend I can copy (safely without introducing more corruption) from the existing userlayer to a new one(to save time customizing settings).

 

Thanks
David

Link to comment

I don't have a move-files database verifier, and I wouldn't expect one unless this becomes widespread.  As for what files you can safely copy, pretty much everything but C:\Program Files\Unidesk.  No need to copy that over; everything else, it's your call.  C:\Users would seem obvious to keep in its entirety, C:\Windows might be obvious to leave behind, but maybe there's something there you do want.

 

As for what registry data, there be dragons, I wouldn't try to capture anything there except what automatically comes over with the C:\Users profile data.  That should cover most of your profile customizations.

Link to comment

Archived

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

×
×
  • Create New...