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

How to identify unexpected growth in User Layers?


Darin McClain

Question

We have about 400 active VHDs (user layers) on a single share with 13TBs of space. User layers are the only things stored on it and are set to grow to a max of 50GB. I did not expect most to go past 20GB, and a few to max out the 50 and need extending to 100GB from past UniDesk experience. (currently 244 are 25GB or larger, only 85 are under 15GB)  We're down to about 1TB of space left as (I feel, can't prove) some recent new growth has started even though we've stayed steady at 400ish users for the last 1-2 years. For instance, we had 10GB of growth between a Saturday and Sunday evening when almost no one uses their VMs. About 140 sessions active though, with likely applications like Outlook left open I'm sure. By Tuesday morning, it had grown 28GB, and we're on winter break, with most users not working at all. About a month ago I had my team start putting all new hires on a 2nd share, and I even moved a dozen or so users off the Primary share to the 2nd share yet we're still growing on the Primary share! I also kept an eye on the size of the 20 largest of the VHDs, none of them grew in the last few days.

 

The only thing that comes to mind in regards to changes in our environment recently, is that we turned off Cached Exchange mode for all users via GP around 10-15-22. I thought this would actually slow growth at the time we did it. I can't be for sure though that this is the cause. I don't see any good data from my storage appliance that shows when increased growth actually started to occur. Can't find a way to look at historical free space via the Windows servers hosting the share either. I wish I could look at how much free space we had say, 10-1-22, and how many VHDs, to compare to say 8-1-22 and 12-1-22.

 

Thoughts? Suggestions? Pretty please and thank you!

Link to comment

6 answers to this question

Recommended Posts

  • 0

Probably the first thing you should do is to remove deleted space from the vhd files.  You can use my user layer repair utility to do this or something lime Jim Moyles FSLogix shrink script.

https://www.citrix.com/blogs/2021/07/07/revamping-the-user-layer-repair-utility/

https://www.citrix.com/blogs/2020/01/09/the-user-layer-repair-utility-makes-it-easier-to-clean-out-user-layers/

https://github.com/FSLogix/Invoke-FslShrinkDisk

 

Read the blogs or jims help thoroughly and test a subset first before doing them all.  They cant be in use for either of these scripts to work.

To figure out whats going on you would want to mount one of the user layers from a non app layering machine in read only mode and try to figure out what is taking up the space.  If you disabled cache mode i dont think that will delete the ost files so you would probably want to script that and after deleting them run the shrink utilities.

  • Like 1
Link to comment
  • 0

No that's not normal.  Are you running the script "as administrator".  To Troubleshoot go into the compress script and at line 72 add a sleep 120 so that the script will pause for 2 minutes after it creates the  diskpart txt files.  Then make sure those files are created when you run the script.  The error makes it seem like the sizedisk.txt is not there.  But it coudl also be that the text you are getting back from the command does not match what i expected,

 

How big is the disk you are using and what OS is it?

Link to comment
  • 0

I was on a Windows 11 VM w/user layer running it on Windows 11 users layer VHDs.

 

I switched to a Windows 10 machine outside of app layering and it ran successfully on the same 3 VHDs. 

 

I ran it on 2 live users to test with, and only shrunk one from 67GB to 65GB, and the other 89GB to 86GB. So I'll look into adding a delete .ost into the script like you said.

 

Thanks! Gives me something promising to work on in January.

Link to comment
  • 0

Just a follow up, I discovered in my user layers approaching the 40+GB range in size, that some had anywhere from 5-30GBs worth of older MS Edge versions still stored in Program Files. Either MS updates isn't cleaning them up, or the user layer is keeping them as changes made when the system deletes them. Having my guys stop defaulting to extending the disks when calls come in with regards to full C drives now, and instead, clearing out this folder, along with the usual temp folders and downloads folder too.

 

I also like the utility above to shrink disks. After some extensive testing to build trust in it, I eventually ran it on every VHD on a weekend to reclaim some space. Maybe a 15-20% gain, nothing crazy, but it's helping.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...