Painting Happy Little VIPs: FSLogix ObjectSpecific settings.
- Edwin de Bruin
- 21 jul
- 3 minuten om te lezen
You know, most VDI environments run like a well painted canvas. The default FSLogix GPO covers most users with smooth even strokes. They are happy users, their profiles load fast, and the picture looks just right.
But then there are the VIPs, those special users with bold bright colors. The users with massive OST caches that need a bigger space, or the sales crew whose Teams data just keeps growing like a happy little forest.

This is when the ObjectSpecific keys step in, like a delicate brushstroke just for those VIPs.
It lets you configure FSLogix settings exactly where you need them without disturbing the rest of your master painting.
Profiles or ODFC, it is all about adding those happy little details
What is ObjectSpecific?
It’s a registry branch where you can paint unique settings for individual users or groups by their SID.
Drop their SID under the ObjectSpecific key, and FSLogix will say, “Ah, this one gets a special touch.” It overrides the global settings just for those users or groups, letting you customize profile or ODFC container behavior without messing with the whole picture.
Most FSLogix configs live under:
HKLM\SOFTWARE\FSLogix\Profiles
HKLM\SOFTWARE\FSLogix\ODFC
These keys apply globally. But what if your finance team needs a 20 GB OST cache, while everyone else cruises along with 5 GB? Or one group needs Cloud Cache enabled? Or you have multiple locations to store the containers depending on group membership?
That’s where ObjectSpecific comes in.
You drop a user or group SID under an ObjectSpecific branch, configure the alternative settings and FSLogix says, “Oh, you’re special, here’s your override.”
It’s that simple.
But did you say SID? Correct you must use the SID, not names, no, the SID!
to make it a bit easier for you here's how to get a specific SID.
Get-ADGroup "GroupName" | Select-Object SID
or for a specific user
Get-ADuser "Username" | Select-Object SID
A Quick Example
HKLM\SOFTWARE\FSLogix\Profiles\ObjectSpecific\<SID>
For example:
HKLM\SOFTWARE\FSLogix\Profiles\ObjectSpecific\S-1-5-21-1234567890-1122334455-667788990-1001
Stick your FSLogix settings here (e.g., VHDLocations, SizeInMBs or CCDLocations).
In this example I will overrule the default CCDLocations with a GPO preference, so the container gets stored on another location.

On login, this user’s gets these settings, bypassing the defaults.
Groups, Not Just Users
You could use user SID's, but to keep it flexible, use User groups. You don’t want to track every single user SID.
Everyone in that group gets the override without extra effort.
What Wins?
ObjectSpecific beats global settings.
Multiple group matches? FSLogix takes the first one it finds (order isn’t guaranteed).
No match? You fall back to global defaults.
In practice, this gives you a simple hierarchy without messy GPO juggling.
My Notes & Lessons Learned
Keep a lean and clean global FSLogix config that applies for the majority
Always test SIDs. A typo in the SID or path and FSLogix will quietly ignore the settings. (and apply the Global of settings).
For non-persistent environments, ObjectSpecific is refreshingly dynamic, no rebuilds needed.
GPO preference is a very flexible way of implementing this.
Get your administration in order. When using a lot of exceptions with many groups, it can give you quite a headache to reverse lookup all the SIDS back to group names. For example, use the description fields.
Make sure only one Group applies.
Wrapping Up
ObjectSpecific is one of those hidden FSLogix gems, both Profiles and ODFC support it, so adding flexibility when needed for anyone running or juggling mixed user requirements,
It’s simple, effective, and fits perfectly with how I like to keep things: lean, predictable, and easy to debug with one point of attention: the SIDS
Another example of flexibility: I've used this setting at a customer with multiple file servers/storage locations. Created a script to divide the users over the file shares based on number of group members (simply count groupmembers and add to group with the least number of users) and embedded this as part of the automated user creation flow.
Worked like a masterpiece.
Happy painting!