Share via


Machines not running logon scripts after update to Windows 10 1903 + current updates

Question

Tuesday, August 20, 2019 8:52 PM

We've been encountering a number of machines that after updating to Windows 10 1903 and installing all current updates the machines no longer are running their logon script when logging into the network. It's a variety of machine makes and models with different wired and wireless networking chipsets that are affected, so I don't believe it's strictly a driver issue (drivers have been updated).

We have a Windows 2012 R2 Active Directory domain. Logon scripts are .bat files defined in the user object and are located in the standard \domain.local\netlogon share. User objects also have a home directory mapping defined in the user object (drive H:).

On affected machines the user's logon script doesn't run, but their H: drive gets mapped normally (indicating that during the logon process their user object was accessed). In previous versions of Windows I've seen this happen when the user logged in before the networking had fully initialized, and just having them log off and back on (not rebooting) would remedy it. This isn't doing the trick here, though. I'm going to take an affected machine and set the GPO object to always wait for network before logon just to take a stab at it, but I'm not optimistic.

Has anyone seen anything regarding an issue with logon scripts running in a recent Windows update? I'm looking around and not finding anything specifically about this issue. Thanks.

All replies (17)

Tuesday, October 29, 2019 1:19 PM ✅Answered

You know, your mention of 2008 servers is interesting. As mentioned above, I have one remaining 2008 R2 domain controller (with the rest of our DCs 2012 R2), so our domain/forest functional level is currently Windows 2008 R2.

I know that Windows has switched from FRS replication to DFSR for AD purposes. I wonder if the core issue is that Windows 10 is having issues accessing the Netlogon share if it's been mounted by FRS instead of DFSR? You say you've had the problem with all versions of Windows 10 and (presumably) have a domain functional level of Windows Server 2008. I've only had problems with 1903 release of Windows 10, but I have a slightly higher functional level (2008 R2). Or it could be something else related to the functional level. It could also very well be neither of these things--again, leaving/rejoining the domain resolves the issue on all machines so far.

I'm currently in the process of migrating my AD from FRS to DFSR so I can decommission the old 2008 R2 DC and I wonder if this will positively affect these clients.


Wednesday, August 21, 2019 7:43 AM

Hi,

Thanks for your posting here.

Based on my knowledge, I would suggest that you can try to run your logon scripts in powershell on Windows 10 1903 manually to see if it is successful.

Appreciate your cooperation.

Best regards,

Abby

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact [email protected].


Friday, August 23, 2019 8:35 AM

Hi,

Just checking to see if the information provided was helpful.

Please let us know if you need further assistance.

Best regards,

Abby

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact [email protected].


Wednesday, August 28, 2019 10:05 AM

Hi,

Was your issue resolved?

 

If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.

If no, please reply and tell us the current situation in order to provide further help.

Best regards,

Abby

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact [email protected].


Thursday, September 19, 2019 1:30 PM



I've not tried running it in powershell, but running it from the command prompt (just manually running the .bat file) works fine. I'll try doing it from powershell instead to see if there's any difference.

We've been having this happen on a LOT of machines since posting this, and all since the 1903 update. Many machines have been updating recently as they had delayed feature releases for 6 months.


Tuesday, September 24, 2019 8:15 PM

I can confirm that the login script runs fine from both Command Prompt and Powershell prompts. It just isn't running when logging in.


Wednesday, October 23, 2019 2:27 PM

Any further advice? I continue to have this problem, and it's getting worse. Over the last month we've had a large number of machines that had delayed the 1903 feature update that are now applying them, and almost universally they are not running the logon scripts at boot. We can manually run them (either by copying the .bat file form \domain\netlogon to their local machine and double-clicking them, or running them from powershell) but it isn't taking place during the logon process. 

These are all different models of computers as well, using manually installed copies of Windows 10 from our VL media (not using the copy from the OEM).


Wednesday, October 23, 2019 6:57 PM

I also have witnessed this same issue.  I am in the process of upgrading about 80 machines to Windows 10 1903 version on our Windows Active Directory domain (2008 functional level).  We have a mixture of Windows Server 2008 R2 and 2012 R2 servers, and once we have upgraded all clients we will be removing the 2008 servers.  We have our login.bat scripts configured to run in Site GPOs, we have 2 locations, each has a subnet / site GPO which configures user settings to run the logon.bat script depending upon which location they are at.  

I can confirm that the machines upgraded to Windows 10 1903 will not run the script at login.  I followed the following article regarding Windows 8.1 and 10 clients and a new 5 minute login script delay setting, the "Configure Logon Script Delay" policy, and created a new GPO that was applied to all 8.1 and 10 computers to configure this setting to "disabled" to remove the delay.  This had no effect. 

https://support.microsoft.com/en-us/help/2895815/logon-scripts-do-not-run-for-five-minutes-after-a-user-logs-on-to-a-wi

The Windows 10 machines have the new GPO applied and the delay setting is disabled, but they still do not run the logon.bat script at logon, and in fact they never run the script.  You can go into SYSVOL, open up the policy, find the script, and manually execute it from Command Prompt or powershell and it runs and connects all mapped drives with no issues.  What I have had to is place a copy of the logon.bat script on each user's desktops and instruct them to run it when the mapped drives disappear, which is a very poor workaround.  

This issue has existed since Windows 10 came out on our network.  We only had a few machines running Windows 10 up until this year and they were mostly laptops that were in and out of the building, so it wasn't a huge deal until now.  Most of our machines are Dell OptiPlex models that were purchased with Windows 10 but downgraded to Windows 7 until a critical software package was updated this year to support Windows 10.  

Does someone have a real fix for this?

 


Wednesday, October 23, 2019 8:14 PM

We've only had the issue starting with 1903. We've had Windows 10 running on machines for several years without issue. I personally have 1903 installed and am not having any problems, but my machine was installed with 1903 install media, not a previous version that had the feature update installed. As far as I can tell the only affected machines have been those that updated from a previous version (such as 1809).

I have found that removing the machines from the domain and adding them back seems to work, if that helps identify the issue at all.

As for our domain functional level we're on 2008 R2 until I can replace our oldest DC.


Thursday, October 24, 2019 5:29 PM

Hello,

Not seeing this as a commonly reported error, 

Here are a couple of questions that may help isolate why this could be happening

How the logon script is assigned to the user?

Where is it stored?

What commands do they run?

Do they use the GP to run logon scripts synchronously?

Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.


Thursday, October 24, 2019 6:27 PM

Our login script is assigned via group policy.  There is a site GPO for each of our two locations / subnets that assigns the location specific logon.bat script in User configuration.  The scripts are stored in the corresponding Policy GUID folders located in \DOMAIN.local\sysvol\DOMAIN.local\Policies.  They are simple batch scripts that only run net use commands, and map drive letters to server shares.  

As far as I know, the only group policy settings regarding logon scripts that are configured for the Windows 10 machines are what I outlined above, the "Configure Logon Script Delay" was set to "disabled" to remove the 5 minute delay.  

Windows 7 Pro machines have no issues running the logon.bat script.  Windows 10 Pro machines normally will only have the U: drive mapped, the user share which is assigned via AD Users and Computers properties for each individual user.  The logon.bat will not run at logon.  You can browse to the SYSVOL location and run it manually after logon without issue and it connects all the drives.

Also, after logon on the clients, running RSOP.msc shows all GPO objects applied correctly without error, including the site GPO that assigns the logon.bat script.  The folder redirection policies for documents and desktop folders also works fine after login, so Group Policy appears to be processing just fine, it just never runs the script.  


Wednesday, November 6, 2019 10:26 PM

This is very possible.  We are at 2008 functional level and this will not be changing until we finish migrating all our Windows 7 clients, and then migrate away from the single 2008 and the two 2008 R2 servers.  Let me know what happens once you migrate to DFSR and if your issue is resolved.  I do remember seeing random error messages now about not being able to access the SYSVOL / NETLOGON shares but this does not always happen when the clients do not run the login script.  


Wednesday, December 11, 2019 8:16 PM

Im having the exact same problem suddenly. My script have been running perfectly and suddenly it does not work anymore. It's a powershell script run from the computer configuration from af GPO.

The Script runs fine if I open the script when loged in. And the GPO is applied. When i run it it work fine under the user account.


Wednesday, December 11, 2019 8:17 PM

Have you found a solution for this annoying Win 10 problem.


Tuesday, February 4, 2020 10:50 PM

I thought I was having this issue but it turned out the starting of the script was delayed.


Thursday, March 12, 2020 2:13 PM

I've run into this issue as well. I had a case opened with Microsoft and what we determined was that with windows 10 group policy processing runs under a different account than a user login. For example, an interesting test is to run command line as a regular user then run the net use command to see what drives are mapped. Then launch the command line as an admin (right click and run as admin), run net use again, and verify if your drives are there. In my case they were. So i had to find a way to get the script to run under the user account logging in and not the system account that group policy uses to process the policy. So in my case i created a registry entry (string value that gets deployed through group policy preference) under HKCU\Software\Microsoft\Windows\CurrentVersion\Run that points to a bat file existing in a script share. Its really not ideal but it seems to work. Just mentioning it in case it helps anyone else. I'm actually still researching to see if there is a better way to handle this instead of the workaround. In Microsofts ongoing effort to improve security i feel like they cause more headaches for the admin.


Tuesday, May 26, 2020 2:53 PM

I can report that our issue did in fact go away once I migrated AD from FRS replication to DFSR. I still have the 2008 R2 DC, but since switching to DFSR I've not had any machines experience the issue.