1

I have a network of around 100 Windows XP boxes, plus a number of Windows 10 ones, in a Windows Server 2003-hosted Active Directory. There's a tender in process to replace both the clients and the server with current hardware and server software, but until that happens I'm stuck with the shortcomings of this server platform.

In any case my task is to make sure that upon login of a domain user, a specific file is copied from the server to his/her directory. This is trivial task if the server is 2008 or later, but for 2003 it isn't.

For that purpose, I've first uploaded the file to be distributed to a network-accessible share, accessible as //UNC_full_path/file.

I then created a GPO (with computer-options disabled) and configured the user section to contain a single startup script. The script file was named (for the sake of completeness) copyfile.cmd and was placed in the section offered by the GPO (\domainname.local\SYSVOL\domainname.local\Policies{policyid}\User\Scripts|logon). The contents of the file was the following command:

IF NOT EXIST "%USERPROFILE%\file" copy \\UNC_full_path\file "%USERPROFILE%"

I finally removed Authenticated users as the target of the policy and added only domain admins, to make some test runs.

On Windows XP after a gpupdate /force /boot and logging as the administrator, everything works as planned: the file is copied to the user directory, if it does not exist. If it exists, nothing happens, as planned.

Making a test run on Windows 7 was also succesful. However, performing the same feat on Windows 10 does not produce anything at all... In fact, Windows 10 clients seem to be "stubborn", disrespecting all GPOs that utilize some sort of cmd-based commands scripts, as I've tested.

I'm clueless as to how I can proceed to troubleshoot this issue. Any ideas will be welcome.

Again, please do remember we are talking Server 2003, so the usual 2008+ tricks do not apply.

1

From Windows 8.1 on, by default, the logon process delays logon scripts for 5 minutes. There are many poorly written or misbehaving logon scripts out there, the 5 minute delay will ensure that the user's desktop remains responsive during the logon process.

However, this may come as a surprise for many organizations especially since the intent of most logon scripts is to perform some action prior to the user interacting with the desktop.

This script execution delay setting is stored in the following GPO location:

Computer Configuration\Administrative Templates\System\Group Policy

The default value setting for the "Configure Logon Script Delay" policy is "Not Configured", which means "five minutes".

The second thing to check for is usually the source of the script: access to the file has to be possible for the computer account. This account (COMPUTER$) will try to fetch the file before handing it over to the local user logon process.

Try to add "Domain Computers" to your Fileserver/NTFS ACL to be sure it can be read by your target machines.

|improve this answer|||||
  • Thanks for the pointers. I tried the first suggestion: setting the policy to "disabled" policy and setting the delay to zero. Unfortunately, result is the same. As for the other suggestions: please note that the same GPO works fine with XP and 7 clients, so perhaps it would be somewhat strange to have an ACL/security filtering issue. – cosmos Jun 19 '19 at 11:13
  • 2
    Strike my last comment out: contrary to my logic, I did something in-between your suggestions. I added the computer account to the GPO security filtering. That did the trick! I performed various tests, in which I reset the local "Configure Logon Script Delay" back to "Not configured". Still works like a charm! Not sure if I should add this a separate "solution" as per serverfault instructions, since it was your pointers that led me to this. Let me know what I should do, I'd happily accept your post as a solution. Definitely a +1 from me though. – cosmos Jun 19 '19 at 11:54
  • 1
    And one final comment: this issue would not normally appear if I hadn't replaced "Authenticated Users" from the GPO security filtering with a couple of testing user accounts (remember that I was doing limited testing here). I still do not understand why the gpo worked just fine, when the clients were either XP or 7... In any case, setting to "Authenticated Users" fixed even the Windows 10 client case. – cosmos Jun 19 '19 at 12:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.