Thin imaging and policy chaining

Mbentley777
Contributor

Recently attended an admin meeting where folks mentioned that they were using thin imaging (i.e. not nuking the boot volume, but instead using policy to lay down installs and configs).

There were a few things that I was unsure about and was hoping to get input from the forum.

1) How do you ensure that your 'thin image' configs aren't pushed out to computers that are already configured?

I've seen talk of policy chaining, and using a custom trigger. It occurred to me that I might consider making the machine a member of a group, and then scope a self service item to kick off a 'config' trigger. In turn a bunch of packages etc, could be called via this trigger.

Is that the recommended method? Am I reinventing the wheel? Can thin and modular re-imaging co-exist?

2) How do you eliminate the admin that might already exist on the box?

For this one, I thought, "Maybe we could ensure that the admin account is the same for each deployment" but if I'm honest, I'm pretty sure that folks might fat finger account names

I plan to hide our admin account, but would it be worthwhile to kill whatever visible admin is there, and then create a new standard one, as well as the hidden one? If so, how?

3) How do you handle data migration to a new user account if the current user is local, but you want them to login using their AD profile?

This is the big one, as I'd like to ensure that we do a minimum of data transfer - are there any workflows out there that folks prefer?

0 REPLIES 0