Sysprep and rights...?

[meister]

Ok I created my master image. I have everything I want, tweaked, tested and working. I have a legacy app that Users on the local workstation need to have full rights to the folder, and that's set. Works perfectly. I take an image of it. If I take that image and put it on another machine, run Newsid and rename it, reboot, then add it to Active Directory, everything is fine and the app works great.

If instead I take that image and sysprep -reseal and shut it down, image it, then apply it to a machine, add it to Active Directory I get this very strange issue:

that legacy app I have stops working. But, as the local admin, if I go into the Advanced Security settings for that folder, click Users, and select the "Replace Permission Entries....." and essentially just reapply what's already there, it starts to work.

Am I wrong in thinking this is a rights issue and perhaps GPO just isn't updating fast enough? I'm in the middle of letting a machine sit overnight just to rule out it being timing, but I can't think of anything else, except that maybe rights aren't coming down from the domain controllers like they should..

Any thoughts from the guru's out there?

Thank you!

[Mordac85]

On your image master, did you originally set the permissions on the top level folder and use the check box to propagate them down to the children or just set it at the top and let inheritance pick up the child permissions? Also, where is the top level of the legacy app folder located, off the root, Program Files, etc?

I've never run into an issue where I've had permission issues after sysprep -reseal, so this is an odd one.

[Tripredacus]

Yes, the Administrator account has ownership and permissions for your application. When you run sysprep, you then create a new user. You are using a different account than the Administrator account. Ideally you should install your program after sysprep.

[Mordac85]

I think he's setting folder perms for the Users group to have full control on the app folder, but it's somehow not working after a sysprep -reseal. Do the permissions on the folder appear different between these two imaging processes?

[meister]

Sorry it took so long to get back to this.

All of my Windows installs for the organization start with the same unattended install of Windows. This app I'm having problems with is installed as part of the RunOnceEX setup where we're installing a lot of other apps. It's a mainframe console application that's just installed to the root of C:. The first thing you always need to do once Windows is installed is browse to the dir on C and give Users and Power Users full rights, to folder subfolder and files (it was just never updated in the unattended install and since we have so few different images, it's never a problem)

Oh, this issue has never been seen on any other image I've created from this unattended install.

In this case I needed an image for a specific project. So I started the same way, unattended install of Windows. The PC was sitting in a workgroup, and I changed the rights on this app folder. Everything was fine. I installed another app I needed for this project, then took an image as is. Used ghost 8.3 to capture the image. I started it back up, then sysprepped it. This gave me two images, sysprepped and non sysprepped.

This is how I always do my images, always 2 copies to start. So if I put the non sysprepped image on a machine, run newsid and add it to the domain everything is fine. If I use the sysprepped image, it looks ok, but it's not. When I look at the security tab of the legacy app folder on C, Users and Power Users have full control, but only after I go into advanced and check off Replace permission entries on all child entries.... and apply it, does the app start working again.

Thanks for any thoughts...

[TheReasonIFail]

Compre the "Inherit from parent the permission entries.." check box for the files in that folder for your syspreped and non-syspreped image.

Before running sysprep I always verify/reapply security settings on any thing installed in C:\ exluding the Program Files, Windows and Users/Docs and Settings folder since the days of 2000. That's the way I was taught and I still do it to this day.

Edited November 20, 2008 by TheReasonIFail

[Mordac85]

Before you run sysprep, I would recommend going into the Advanced security settings, check the 'Replace permissions on all child objects...' and hit apply. That should push the permission changes down to the subfolders/files and correct whichever one may not be picking them up through inheritance.

If you want to know what's causing the problem you can either step through each file & folder checking the perms like TheReasonIFail recommends or run filemon on your failed unit to see what file/folder can't be accessed.

[meister]

The "fix" so far, had been what Mordac85 says to do, go into advanced and apply "Replace permission entries...."

I've just been doing it post sysprep. It's just striking me odd that it's happening on this one image, and only after it's sysprepped...

It's a feature I think :-)

[Mordac85]

But did you do this before you sysprepped the system?

Edited November 24, 2008 by Mordac85