I'm working on some startup scripts for my AD workstations, so I can run an SSN scanner on them. The script runs a utility that outputs data into text files, and I'm trying to put those files on my file server. Easy enough, right? I thought so too, except that nothing is landing on the server at all.

The utility outputs the files to the local workstation's C: drive, which my script then should copy to the file server. All of this is running as the SYSTEM user on the workstation, since it's a startup script. I've given Domain Computers read/write rights to the file server folder.

I don't think I'm missing anything, but evidently I have.

Any ideas, folks? Thanks!

4/29/2010 9:58:38 AM

I do something relativelty similar -- a VB.NET screensaver that periodically takes screenshots of the screen saver in progress and saves them locally.

Not entirely sure what your script is written in, but I use WebClient to upload the files to our webserver, which then saves them. It's an additional step and probably not the best solution in your case, but it is an option.

4/29/2010 10:07:12 AM

It's honestly just a good ol' batch file. Nothing special about it at all. Basically I'm doing this...

IF EXIST %COMPUTERNAME%.txt COPY %COMPUTERNAME%.txt \\FILESERVER\FOLDER\

I'd think that would be simple enough. By the time the utility completes the SSN scan, it's been several minutes, and the network stack has already loaded, so there's a network connection.

4/29/2010 10:10:04 AM

do a net use to the share first, copy to the share, delete the net use

4/29/2010 3:28:35 PM

SYSTEM isn't a domain account. Create an actual user on the domain, give it access to write to the share, and then set the service/application to run as the domain\user.

4/29/2010 3:37:17 PM

Another thing to check, look at the share permissions (these are different from the file system permissions) and make sure everyone has read/write/modify. Use NTFS file perms to manage permissions.

4/29/2010 3:39:03 PM

Good suggestions. I know the share perms are correct, as other things read from this location. I think you might me right about it being SYSTEM as a non domain user... But I thought if you added Domain Computers with read/write permissions, wouldn't that address things being run in a startup script on a box?

4/29/2010 4:17:18 PM

hmm. Not sure. IDK if system contains the domain creds of the computer or not. re: share permissions, always check the share permissions (folder properties -> share tab -> permissions) and make sure "Everyone" has all perms. Doing this does not override your NTFS perms on the folder. Share perms are a hold out from the fat32 days and you're almost always better off setting share perms to allow full perms for "Everyone" so you dont run into problems later on.

For example, if you added Domain Users into the share perms, and Everyone is set to the default of read only, then a Domain Computer would not have access to write the share, even though they have perms on the NTFS permissions. Share perms are access to the share, NTFS perms are access to the file system. You need write perms in both places in order to successfully write.

Last thing to try would be to give "Everyone" in share perms full access and then give "Everyone" full access in NTFS perms and see if the issue still exists, if not you just need to tighten up the NTFS perms. If the app still cant write you've got something else going on.

4/29/2010 4:24:51 PM

Quote :

"SYSTEM isn't a domain account"

This would be my first guess...

Other guesses are to try 1) pinging the server, then sending the file or 2) use shadow copy (xcopy) instead of straight copy (if the writing program still has the file open it may get mad).

4/29/2010 9:37:24 PM

One other question (I'll reply to the above responses separately)... I can't find any documentation on this point, but can you only assign one logon script? I have two separate GPOs with logon scripts, assigned to users, but I don't think the second one is running.

4/30/2010 11:16:41 AM

IIRC only one policy can own each setting (login scripts being a setting). You can specify multiple scripts inside the login script option for one gpo, but if you have 2 gpos both with their own scripts im pretty sure only the scripts for the winning gpo will run.

You can call scripts from within a script based on current creds so that may be an option if you want to do some funky stuff.

Also, any gpo login scripts are run in addition to a login script specifed in the user's AD account.

I am assuming (so correct me if im wrong) that you have 2 gpos w/ scripts. 1 is probably a global one that everyone gets and 1 is assigned to a lower OU that you want specific users to get. The goal being everyone runs script 1, but only a few people run script 2. if this is what you want it might make more sense to assign the global script as the login script for everyone in ad, and remove it from the global gpo.

Second option, remove second script from the second gpo and add it to the first gpo. Inside the script do a lookup to see if the current user is a member of X group you want to run the script and only run it if you get a match.

First option is much easier, but the second option might be more flexable in the future.

4/30/2010 12:33:31 PM

protip: use group policy management console's report tools to determine exactly what gpos are being assigned to a user/computer, why they're being assigned, and what settings were applied and from which gpo each setting comes from.

4/30/2010 12:36:52 PM

Shaggy: thanks. I've been using the GMPC for a while, working with assigning various other things, mostly apps for computers and standard settings GPOs for users. I'm still running in to issues, but I think I can rule out the login scripts and shares as the source of my troubles at this point. Thanks for your suggestions and help. A++ tech help, would post again.

5/1/2010 10:48:22 AM

We do this at work a lot, and I just add <Domain Name>\<MachineName>$ to have access to the folder you want to copy to.

I couldnt tell by your post if you had done that exact add or not.

5/1/2010 11:16:36 AM

Well, the fileshare is running from a Windows Server 2003 R2 box. The share is also being used for application deployment via GPOs, which has never given me any trouble. I just created a logging directory there for convenience to me.

I think part of the issue I have is that the script is breaking at some point around the time it connects to the fileshare to verify if a file exists (IF EXIST \\share\folder\file.txt GOTO EXIT).

But at this point, I don't think it's the share itself that is causing it anymore. I'm going to put in some traps to test the failure point later today.

5/1/2010 11:46:19 AM

Issue resolved today. GPOs got re-pushed to a bunch of machines, and the script is behaving now. I added a bunch of testing checks to the script, and they all passed. I'm guessing I messed up something along the way, but it's behaving now. thanks for the help guys, it's sincerely appreciated.

Semi-related note... this incident convinced me that I need some better tools for handling updates and shit. SCCM is now on my to-buy list.

5/3/2010 7:18:00 PM

you need to add the computer accounts to the permissions on the folder.

5/3/2010 7:56:10 PM

^ I ended up doing that fairly early on in my troubleshooting. I can clearly see that the accounts have access to the share, because they're successfully returning from IF EXIST statements in my script.

Specifically, I added the Domain Computers security group.

[Edited on May 3, 2010 at 8:26 PM. Reason : clarity]

5/3/2010 7:58:42 PM