What they all have in common (well, at least those I’ve looked at) is that they eventually come down to using a standard VHD “compact” operation, generally either DiskPart’s COMPACT VDISK command or PowerShell’s Optimize-VHD cmdlet (which requires the Hyper-V module). This has given rise to a brisk cottage industry of scripts designed to shrink VHDs in place, either individually or, in the more ambitious cases (for example Jim Moyle’s), in bulk and at scale. It’s not at all unusual for a multi-GB VHD to be 4 or 5 times larger than the “in use” profile data it actually contains. They grow as files are written to them during active use, but when files are modified, relocated, or deleted over multiple sessions, the virtual disk blocks that are freed in the process remain physically present in the VHDs. But (isn’t there always a “but”?) there’s a small rub that many FSLogix implementations quickly discover: ever-growing storage requirements! The reason is simple: the individual VHD/VHDX virtual disk files into which user profiles are captured (I’ll just call them VHDs going forward), despite starting small and being thin-provisioned (aka dynamically expanding), never shrink on their own. It also doesn’t hurt that it’s an elegantly engineered product that “just works”. This is the FSLogix Magic Hammer You Didn’t Know You Had!Īs you probably know, as a result of the Microsoft acquisition and of the generous licensing terms that followed, FSLogix Apps has quickly become the go-to profile management technology in many enterprises, especially for VDI and cloud deployments.
0 kommentar(er)
