none
Logon Script Not Running

    Question

  • Hi There,

    I've set up a logon script in group policy but it doesn't run on SOME XP clients. The script is a VB script and it has another file as a parameter. I've tried setting group policy to run logon scripts synchronously and disabled fast logon optimisation but neither helped. If I run the script locally from the command prompt it works fine.

    Problem clients are XP SP3 and DC is Win server 2003. We also have Vista clients but they don't seem to be having this issue.

    Any ideas?

    Monday, October 11, 2010 11:00 PM

All replies

  • Hello,

    Did you take error in Eventviewer? the users are in local administrator groups ?

    Best Regards.

    Fatih

    Tuesday, October 12, 2010 12:07 PM
  • Nothing in the event viewer. No, the users are not in admin group but they don't need to be for a logon script to work. I'm using the same user account to test on multiple PCs and on some machines the script runs and on others it doesn't. All machines are in the same AD site with LAN conectivity so there are no speed issues either. I can't explain it.
    Tuesday, October 12, 2010 8:07 PM
  • How do you know that the script isn't running? Is it possible that the script is running but the actions in it are failing?

     

    We would need to narrow down the problem:

    First, use gpresult and rsop.msc to make sure that the GPO is applied correctly to problem machines and the script is assigned.

    Second, use simple statements in the script (like echo to a local file) to see if the script itself is running.

    Third, review the specific commands in the script to see why they might be failing.

     

    Thanks,

    Guy

    Tuesday, October 12, 2010 8:19 PM
  • How do you know that the script isn't running? Is it possible that the script is running but the actions in it are failing?

     

    We would need to narrow down the problem:

    First, use gpresult and rsop.msc to make sure that the GPO is applied correctly to problem machines and the script is assigned.

    Second, use simple statements in the script (like echo to a local file) to see if the script itself is running.

    Third, review the specific commands in the script to see why they might be failing.

     

    Thanks,

    Guy


    Hi There,

    For testing purposes I've set the script to show pop-up messages as it runs. On the problem machines this is not happening.

    Also in RSOP i can see there is nothing in the "Last Run" field.

    Finally, if I run the script locally it does what it's supposed to do (add printers) but under group policy no printers are added.

    All of the above tell me the script is not being run.

    Tuesday, October 12, 2010 8:28 PM
  • Update - RSoP is now showing a "Last Run" date and time for the script on the problem PCs which would suggest the script is being run. However no printers are actually being added (as they are on the good clients) and I'm not seeing the "Windows Script Host" pop-up window appearing as the script echoes stuff out - this would obviously suggest the script isn't being run at all. I'm more confused than ever.
    Wednesday, October 13, 2010 1:10 AM
  • If a I call the VB script from within the logon script as set in the users profile in AD it works but not when run from group policy. However I don't want the script called from the AD logon script as I only want it run for specific users.

    I thought I had the solution  - I noticed that on at least one of the problem PCs the application associated with VBS files was notepad so I changed it to cscript.exe but this didn't work either. This si driving me crazy.

    Thursday, October 14, 2010 1:43 AM
  • Hello Broonster27,

    Please enable userenv debug logging and restart the problematic computer, then upload userenv log and  gpresult /v file to the SkyDrive or our workspace for further research.

    How to enable user environment debug logging in retail builds of Windows
    http://support.microsoft.com/kb/221833

    How to collect an MPS report:

    a)       Download the proper MPS Report tool from the website below. Microsoft Product Support Reports http://www.microsoft.com/downloads/details.aspx?FamilyID=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0&displaylang=en

    b)      Double-click to run it. If the requirement is not met, please follow the wizard to download and install them. After that, click Next, when the "Select the diagnostics you want to run" page appears, select General; Internet and Networking; Business Network; Server Components; click Next.

    c)       After collecting all log files, choose "Save the results". Choose a folder to save the <Computername> MPSReports.cab file.

    For your convenience, I have created a workspace for you.  You can upload the information files to the following link.  (Please choose "Send Files to Microsoft")

    Workspace URL: (https://sftasia.one.microsoft.com/ChooseTransfer.aspx?key=e328cab0-cad0-4490-aaef-e115f0531b59)

    Password: 6#pMuccrvZ

    Brent
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Thursday, October 14, 2010 6:50 AM
  • Broonster,

    Its sounds like you have a GP issue not a login script issue.  And based on the fact it runs on random ones its, ill go out on a limb and say that you have a FRS issue between your domain controllers.  Checked your FRS event logs out yet?

    Another way to check is browse to the policy:

    \\domainname\sysvol\domainname\policies

    then:

    \\domaincontroller1\sysvol\dominname\policies

    then:

    \\domaincontroller2\sysvol\domainname\policies

    and compare the folders my guess is they wont match.  If not you need to correct your FRS errors.  The FRS event log will help you determine whats wrong.

    Thursday, October 14, 2010 4:53 PM
  • It looks like a permissions issue on some machines but I'm not sure what permissions. If I logon as admin the script runs, if i logon as a standard user it doesn't. However, if I look at the permissions for localmachine \Users group on C:\windows for a good and bad machine they are exactly the same - they were set through group policy so they should be the same.

    I then gave the localmachine \users group full control of c:\windows (just for testing) but the script still didn't run as a standard user. What other permissions should I be looking at? I've look at the permissions on the registry hives and they are the same too.

    BTW - the script definitely runs as the same standard user on some machines and all PC AD objects are in the same OU.

    Thursday, October 14, 2010 9:29 PM
  • Broonster,

    Its sounds like you have a GP issue not a login script issue.  And based on the fact it runs on random ones its, ill go out on a limb and say that you have a FRS issue between your domain controllers.  Checked your FRS event logs out yet?

    Another way to check is browse to the policy:

    \\domainname\sysvol\domainname\policies

    then:

    \\domaincontroller1\sysvol\dominname\policies

    then:

    \\domaincontroller2\sysvol\domainname\policies

    and compare the folders my guess is they wont match.  If not you need to correct your FRS errors.  The FRS event log will help you determine whats wrong.


    It's not FRS. All the machines use the same DC as there is only one in the site.
    Thursday, October 14, 2010 9:34 PM
  • Hello Broonster27,

    Please enable userenv debug logging and restart the problematic computer, then upload userenv log and  gpresult /v file to the SkyDrive or our workspace for further research.

    How to enable user environment debug logging in retail builds of Windows
    http://support.microsoft.com/kb/221833

    How to collect an MPS report:

    a)        Download the proper MPS Report tool from the website below. Microsoft Product Support Reports http://www.microsoft.com/downloads/details.aspx?FamilyID=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0&displaylang=en

    b)       Double-click to run it. If the requirement is not met, please follow the wizard to download and install them. After that, click Next, when the "Select the diagnostics you want to run" page appears, select General; Internet and Networking; Business Network; Server Components; click Next.

    c)        After collecting all log files, choose "Save the results". Choose a folder to save the <Computername> MPSReports.cab file.

    For your convenience, I have created a workspace for you.  You can upload the information files to the following link.  (Please choose "Send Files to Microsoft")

    Workspace URL: (https://sftasia.one.microsoft.com/ChooseTransfer.aspx?key=e328cab0-cad0-4490-aaef-e115f0531b59 )

    Password: 6#pMuccrvZ

    Brent
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    If you read my other post below you'll see that the script works for a domain admin user but not for a standard user so I've uploaded two userenv files - one for the admin user and the other for the non-admin user.  The gpresult /v output and MPS stuff is there too.

    I though it might have been a permissions thing but now that I've tested giving standard users full access to c:\windows and that still didn't work I'm not sure it is permissions at all. It might be a user profile thing maybe? We don't use roaming profiles BTW.

    Thursday, October 14, 2010 11:37 PM
  • It sounds like you may have the logon script call another script (the file as a parameter). Perhaps the first logon script checks group membership (or user names) and only calls the second script for certain users. Could it be that some users do not have permissions to read the second script? Is the second script in c:\Windows or c:\Winnt? Maybe we need to know how the first script starts the second, or details about what is happening.

    Richard Mueller


    MVP ADSI
    Friday, October 15, 2010 12:39 AM
  • It sounds like you may have the logon script call another script (the file as a parameter). Perhaps the first logon script checks group membership (or user names) and only calls the second script for certain users. Could it be that some users do not have permissions to read the second script? Is the second script in c:\Windows or c:\Winnt? Maybe we need to know how the first script starts the second, or details about what is happening.

    Richard Mueller


    MVP ADSI
    Logon script does no checking for group membership - it simply adds print queues. I'm using the same standard user account to test the script on multiple machines. On some PCs it works on others it doesn't - it therefore doesn't have anything to do with group membership. The logon script and it's parameter (which is the other file) are not local they both reside in the usual place for scripts in group policy.
    Friday, October 15, 2010 1:09 AM
  • Hello Broonster27,

    Please try to rename the cache user profile on the local computer, then you try to log on to the computer again.

    If the problem persists, you need to use the Microsoft Group Policy Diagnostic Best Practice Analyzer (GPDBPA) tool to collect and to analyze data on the client computer.

    Group Policy Best Practice Analyzer
    http://blogs.technet.com/b/askds/archive/2008/04/11/group-policy-best-practice-analyzer.aspx

    Brent
    --------------------------------------------------------------------------------
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    Monday, October 18, 2010 8:59 AM
  • Hello Broonster27,

    Please try to rename the cache user profile on the local computer, then you try to log on to the computer again.

    If the problem persists, you need to use the Microsoft Group Policy Diagnostic Best Practice Analyzer (GPDBPA) tool to collect and to analyze data on the client computer.

    Group Policy Best Practice Analyzer
    http://blogs.technet.com/b/askds/archive/2008/04/11/group-policy-best-practice-analyzer.aspx

    Brent
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    I've done that already - I know as I can see the old re-named profile. HOWEVER, I did it again and this time it worked, the script ran! The problem now is to determine what is wrong with the profiles of the users on these problem PCs. I can't go around giving all these users completely new profiles so I need to find out what specifically is wrong and rectify it. Any ideas?
    Monday, October 18, 2010 9:59 PM
  • Hello Broonster27,

    There is no any clue in userenv log that can troubleshoot a corrupted user profile, however, you can try to rename the following files in %systemdrive%\Documents and Settings\%username% instead of rename user profile, and then check if the logon script is able to run.

    • Ntuser.dat
    • Ntuser.dat.log
    • Ntuser.ini

    Brent


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    Tuesday, October 19, 2010 2:42 AM
  • Hello Broonster27,

    There is no any clue in userenv log that can troubleshoot a corrupted user profile, however, you can try to rename the following files in %systemdrive%\Documents and Settings\%username% instead of rename user profile, and then check if the logon script is able to run.

    • Ntuser.dat
    • Ntuser.dat.log
    • Ntuser.ini

    Brent


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

     

    I'll give it a go but I'm not sure if the profiles are corrupt as such as there are quite a few users experiencing the same thing and it would be a bit of a coincidence that they all suffered the same corruption. I'm thinking it's more something to do with the settings of the user profiles and how they handle file types or something like that.
    Tuesday, October 19, 2010 3:01 AM
  • Hello Broonster27,

    The most direct way is to consider comparing programs which are installed on working computer and problematic computer, then check whether it was caused by a specific 3rd-party software. 

    Brent


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    Tuesday, October 19, 2010 6:52 AM
  • I think I've got it.Hello Broonster27,

    The most direct way is to consider comparing programs which are installed on working computer and problematic computer, then check whether it was caused by a specific 3rd-party software. 

    Brent


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

     

    I think I've got it. It's the file types. On the problem machines the default action for the .VBS file extension is to EDIT with NOTEPAD. If I change to the default action to OPEN with WSCRIPT.exe all is well. Only thing is I now can't see how to set that value for the problem machines as there isn't a group policy setting for changing file type stuff.
    Tuesday, October 19, 2010 11:02 PM
  • Hello Broonster27,

    If only you have at least one Windows Vista or later version in the domain, I think you can configure a file type with GP Preferences. Please follow the steps below:


    1. Enable RSAT on Windows Vista/7 computer.

    http://www.microsoft.com/downloads/en/details.aspx?FamilyId=9FF6E897-23CE-4A36-B7FC-D52065DE9960&displaylang=en

    http://blogs.msdn.com/b/nickmac/archive/2009/08/12/remote-server-administration-tools-rsat-for-windows-7-released.aspx

    http://www.grouppolicy.biz/2010/03/how-to-download-and-install-the-group-policy-management-console-gpmc/

    2. Create a GPO and create a new File Type preference item under Preferences\Control Panel Settings by using GPMC tool.
    http://technet.microsoft.com/en-us/library/cc754587.aspx

    3.To ensure that preferences are applied to clients, make sure that clients have the CSEs and XMLLite installed
    http://blogs.technet.com/b/grouppolicy/archive/2009/03/27/group-policy-preferences-not-applying-on-some-clients-client-side-extension-xmllite.aspx

    Brent


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    • Marked as answer by broonster27 Wednesday, October 20, 2010 2:51 AM
    • Unmarked as answer by broonster27 Wednesday, October 20, 2010 2:52 AM
    Wednesday, October 20, 2010 1:38 AM
  • Hello Broonster27,

    If only you have at least one Windows Vista or later version in the domain, I think you can configure a file type with GP Preferences. Please follow the steps below:


    1. Enable RSAT on Windows Vista/7 computer.

    http://www.microsoft.com/downloads/en/details.aspx?FamilyId=9FF6E897-23CE-4A36-B7FC-D52065DE9960&displaylang=en

    http://blogs.msdn.com/b/nickmac/archive/2009/08/12/remote-server-administration-tools-rsat-for-windows-7-released.aspx

    http://www.grouppolicy.biz/2010/03/how-to-download-and-install-the-group-policy-management-console-gpmc/

    2. Create a GPO and create a new File Type preference item under Preferences\Control Panel Settings by using GPMC tool.
    http://technet.microsoft.com/en-us/library/cc754587.aspx

    3.To ensure that preferences are applied to clients, make sure that clients have the CSEs and XMLLite installed
    http://blogs.technet.com/b/grouppolicy/archive/2009/03/27/group-policy-preferences-not-applying-on-some-clients-client-side-extension-xmllite.aspx

    Brent


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

     


    I run the preference and it successfully changes the associated application to WSCRIPT.exe but the script is still not run at logon. If, however,  I manually go into file types, click on advanced , select Open (which is set to use WSCRIPT.exe) from the actions list, click on Set Default then log off and on the script runs fine.

     

    Confused!

    Wednesday, October 20, 2010 2:58 AM
  • Hello,

    Check whether GPP was applied on the computer?

    If so, it is possible that the script was ran before the file associated that was applied on the computer.

    I think we need to apply GP preference first, and make sure associated program is setting default on the problematic computer, and then to apply script by GPO.

    Brent
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Wednesday, October 20, 2010 7:12 AM
  • Hello,

    Check whether GPP was applied on the computer?

    If so, it is possible that the script was ran before the file associated that was applied on the computer.

    I think we need to apply GP preference first, and make sure associated program is setting default on the problematic computer, and then to apply script by GPO.

    Brent
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    GPP is definitely being run because the preference setting is in the same policy as the script and the preference has been successfully applied. The preference will have been applied after the first logon and that will be permanent but I have logged onto the PC several times and the script is still not being run.
    Wednesday, October 20, 2010 7:57 PM
  • Hello Broonster27,

    >You mentioned that "If I change to the default action to OPEN with WSCRIPT.exe all is well."
    Do you mean that the script was ran by GPO only when file associations was changed manually instead of preferences?

    Dose standard user able to run the script directly on the windows XP?
    Does this issue exist on all Windows XP clients or just some of them?
    Does standard user able to access folder where the script is located from problematic computer?
     \\DC\SYSVOL\domain_name\Policies\{Unique ID}\USER\Scripts\Logon
    Do you find any further error log in event viewer?

    According to the gpresult log, I found the following GPOs were applied under User settings, which GPO was configured as logon script setting?

    Applied Group Policy Objects
    --------------------------------
            Folders & Permissions
            Outlook Link on User Profile
            Safe Senders List
            Software Installation
            printers
            Local Group Policy
    --------------------------------

    Please make a simple script as follow and do a test on Windows XP computer.

    Paste the following code to notepad, and save as test.vbs.

    wscript.echo "Test"

    1. Double-Click test.vbs file on the Windows XP computer, check whether the script is ran properly.
    2. If ok, create a test GPO and link to OU where test user is located, then configure the test.vbs as logon script.
    3. Run gpupdate /force on the client, then log off and on, check if the script is ran.

    Brent


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    Thursday, October 21, 2010 3:45 AM

  • Hello Broonster27,

    >You mentioned that "If I change to the default action to OPEN with WSCRIPT.exe all is well."
    Do you mean that the script was ran by GPO only when file associations was changed manually instead of preferences?

    Dose standard user able to run the script directly on the windows XP?
    Does this issue exist on all Windows XP clients or just some of them?
    Does standard user able to access folder where the script is located from problematic computer?
     \\DC\SYSVOL\domain_name\Policies\{Unique ID}\USER\Scripts\Logon
    Do you find any further error log in event viewer?

    According to the gpresult log, I found the following GPOs were applied under User settings, which GPO was configured as logon script setting?

    Applied Group Policy Objects
    --------------------------------
            Folders & Permissions
            Outlook Link on User Profile
            Safe Senders List
            Software Installation
            printers
            Local Group Policy
    --------------------------------

    Please make a simple script as follow and do a test on Windows XP computer.

    Paste the following code to notepad, and save as test.vbs.

    wscript.echo "Test"

    1. Double-Click test.vbs file on the Windows XP computer, check whether the script is ran properly.
    2. If ok, create a test GPO and link to OU where test user is located, then configure the test.vbs as logon script.
    3. Run gpupdate /force on the client, then log off and on, check if the script is ran.

    Brent


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

     


    1. Yes, that exactly ehat I mean. I go in to file types and manually set the default action to "Open" with Wscript and it works. If I set file types with preferences the script does not work. I've tried setting the file types via preferences using both computer and user GP settings. No luck.
    2. Standard user can run script directly on XP machine, yes.
    3. Only some XP machines.
    4. Standard user can access that file, yes.
    5. No events.
    6. "printers" is the GPO.
    7. The simple wscript.echo "test" works fine as a standard user run both directly and through group policy  (although the preference for the VBS file extension MUST be set)


    One way it does work using group policy however is if I place the script and it's parameter file in \\servername\netlogon so I might just do that instead. The problem with that is that all the clients will connect to the same DC to run the script and we have a very wide WAN.

    Tuesday, October 26, 2010 10:49 PM
  • Hello Broonster27,

    >The problem with that is that all the clients will connect to the same DC to run the script and we have a very wide WAN.

    No, any changes to the %systemroot%\SYSVOL folder on any DC are replicated to the other DCs in the domain. Replication is RPC based.

    NETLOGON vs SYSVOL
    http://www.windowsnetworking.com/kbase/WindowsTips/Windows2000/AdminTips/Miscellaneous/NETLOGONvsSYSVOL.html

    Logon Script FAQ
    http://www.rlmueller.net/LogonScriptFAQ.htm

    Brent


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Wednesday, October 27, 2010 2:53 AM
  • Hello Broonster27,

    >The problem with that is that all the clients will connect to the same DC to run the script and we have a very wide WAN.

    No, any changes to the %systemroot%\SYSVOL folder on any DC are replicated to the other DCs in the domain. Replication is RPC based.

    NETLOGON vs SYSVOL
    http://www.windowsnetworking.com/kbase/WindowsTips/Windows2000/AdminTips/Miscellaneous/NETLOGONvsSYSVOL.html

    Logon Script FAQ
    http://www.rlmueller.net/LogonScriptFAQ.htm

    Brent


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    I realise the SYSVOL/NETLOGON folder is replicated but my group policy points specifically to an absolute path i.e. \\servername\share. I might try %LOGONSERVER% though and see if that works.
    Wednesday, October 27, 2010 7:33 PM
  • Hello Broonster27,

    So you don't have to points an absolute path, you can use FQDN path instead.

    i.e \\contoso.com\NETLOGON 

    If the place where parameter file is located as same with script file, I think you can try to use parameter file without path.

    Brent


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    • Marked as answer by Brent HuModerator Monday, November 01, 2010 2:28 AM
    • Unmarked as answer by broonster27 Monday, November 01, 2010 9:06 PM
    Thursday, October 28, 2010 2:43 AM
  • Yeah, I'll go with that. It still really bugs me that the script doesn't work when run from Group Policy's folder but hey-ho.

    Thanks for your help though. It's been emotional ;-)


    Hibs Ya Bass!
    Thursday, October 28, 2010 2:54 AM
  • If you have any update, please let us know. Thanks.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Thursday, October 28, 2010 7:43 AM
  • Brent,

    You marked this as an answer and it isn't really. I actually just created a work around myself by putting the script in the netlogon folder. I wouldn't want users coming on this very helpful site to see this at the top of the post as an answer to this issue when it clearly isn't.

    Regards,

    C


    Hibs Ya Bass!
    Monday, November 01, 2010 9:10 PM