Startup script doesn't work correctly

[s***@gmail.com]

I created a new GPO specifically to run a batch file, which copies a few folders to %systemroot% and %systemroot%\system32. The batch file works just fine when manually run, but when I created the GPO, it only creates the new folders, it doesn't copy the files.

- I moved my computer account into the AD container I linked the GPO to.
- I set Security Filtering to Domain Computers
- I added Domain Computers to the root of the folder I'll be copying everything from, and gave it Read permission (and saw it apply permissions to all of the folders and files)
- I verified the GPO is Link Enabled and Enforced
- I verified the GPO is being applied to my computer

When I put the batch file in \\<domain>.com\SysVol\<domain>.com\Policies\{97517B77-24AF-47DB-ABBA-A0EE4E5452A6}\Machine\Scripts\Startup, it creates the folders, but doesn't copy the files.

When I left the batch file in the same folder as everything is being copied from, nothing at all appears to happen.

Does anyone have any ideas as to what I'm doing wrong?

[Therion69]

I created a new GPO specifically to run a batch file, which copies a few fo=
lders to %systemroot% and %systemroot%\system32. The batch file works just =
fine when manually run, but when I created the GPO, it only creates the new=
folders, it doesn't copy the files.=20

I understand that you are using a startup script, so it must be a computer policy. These policies (and scripts) are being run under SYSTEM user credentials. Are you sure that the source-files that you are trying to copy are accessibe by this account? Because normally, files on a netword-share are not accessible this way! SYSTEM is a local account!

Another thing to keep in mind is file-system translation. Trying to access the systen32 folder on a 64-bits machine using 32-bits software (like for example SCCM) recuires you to access the system32 folder as 'SysNative' (even though this folder does not really exist!). Otherwise files will end up in the SysWOW64 folder.

The theory is this: A 64-bits program trying to access system32 will end up in system32, because thats where the 64-bits system files are located. However, 32-bits programs will also look for the system32 folder (they wouldn't know anything else), but Windows detects this and redirects those apps to SysWOW64, where actually all 32-bits system files are stored. Confused? Read this a couple times over,i was very confused first time i had to deal with this problem ;-)

But i think the first thing is more likely to help you solve the problem: startup/shutsown scripts (and computer GPO's) run under SYSTEM, while logon/logoff scripts (and user GPO's) run under the current users credentials! Just keep this in mind while designing scripts and you will do fine.

Greetings, Andreas.


--------------= Posted using GrabIt =----------------
------= Binary Usenet downloading made easy =---------
-= Get GrabIt for free from http://www.shemes.com/ =-

[m***@gmail.com]

It's an old post but nevertheless this may be useful for others searching for the same problem. Try putting the folder to copy from in a location accessible to "Authenticated Users" (which will be the ones logged in) and "Domain Computers". If necessary re-share the folder as a new share called "SoftwareDeployment" or something, with the above two groups having read-only access. Also ensure the two groups have permissions to the folder, not just the share.

We had a similar issue a while back and this sorted it.