The curious case of Group Policy Event ID 1129

-
I recently worked on setting up a startup script GPO policy for installing ConfigMgr agent and almost immediately I started noticing issues with it. This seemed a bit odd as I had used the same script and the setup in another environment and there were no issues. It was time to do a deep dive and after checking for the relevant permissions for the script and the network share, I moved my focus to the event logs. I noticed event ids 1129 followed by 1130.


Event id 1129 translates to - The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has successfully processed. If you do not see a success message for several hours, then contact your administrator.

What can cause this error?

According to Microsoft, the error can be caused due to the following reasons - 

1. The Netlogon service starts before the network is ready. The network stack and adapter initialization often start at about the same time. Some network adapters and switches have link arbitration and MAC address uniqueness checks that take longer to complete than the wait time that is set for Netlogon to detect network connectivity.

2. Solutions that verify the health of the new network member delay the network connection and your ability to access domain controllers. If you have an automatic Direct Access channel connection enabled, it may also require more time to do than Netlogon allows.

3. The 802.1X authentication process delays connections to the domain controllers.

4. The client experiences a delay to retrieve an IP address from the DHCP server. It delays the display of the network interface.

What is the fix?

Group Policy applies during computer startup and user logon. Afterward, Group Policy applies every 90 to 120 minutes. Since my requirement is to get a startup script to work, I need to implement a fix to address this.

Luckily there are multiple ways to fix the issue. However, in my case, I chose to implement the registry that will delay the processing of the Group policies by 60 seconds.

1. Open the Group Policy Management and navigate to the Group Policy Objects. 
2. Right click and select New. Provide the name and hit edit.
3. Navigate to Computer Configuration -> Preferences -> Windows Settings -> Registry.
4. Set action to Update.
5. Locate and select the following subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

6. Set value as GpNetworkStartTimeoutPolicyValue.
7. Set value type as REG_DWORD.
8. Set value data as 60.
9. Set Base as Decimal.

It should look something like below -

10. Wait for the policy to replicate across DCs (if there are more than 1 DC) and once complete, run gpupdate /force.

After the policy applies, the registry is configured.



Reboot and the startup scripts through GPO should apply just fine. In my case the startup script ran as expected and the ConfigMgr agent installed successfully. Just make sure that the registry gets applied before any startup scripts run on next reboot.

Until next time..

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){                 $KPID=$KP.KeyProtectorId                 break;             }         }        $o
Read more

Intune: Configure Printers for Non-Administrative Users

-
Image
Configuring printers for end users or giving them the ability to do it themselves is a normal requirement for organizations. Now if your users are Administrators, then the configuration can be straight forward, but in case of Non-Administrators there are additional steps required as Non-Administrators will not be able to add a driver in the driver store despite being able to install a printer. In this blog, I will cover the steps that I took to address this requirement using Intune. The setup involves 2 steps -  1. Setup registries. 2. Install the driver and configure the printer Setting up registries – The registries that need to be configured are actually part of a GPO setting – Allow non-administrators to install drivers for these device setup classes It can be found under: Computer Configuration -> Policies -> Administrative Templates -> System -> Driver Installation I used a Powershell script to set the values and wrapped it in a Win32 application. $Path1
Read more

Prevent users from running certain programs or applications on Windows endpoints using Intune

-
Image
  When it comes to blocking or preventing users from running an application on Windows devices, one normally uses App locker policy, Windows Defender Application Control and not so new but pretty useful method called Defender Vulnerability management within Microsoft 365 Defender Portal. A recent question on the Tech Community Microsoft forum prompted me to look for all possible alternatives. I started reminiscing over the legacy GPO policies and that is when I stumbled upon the policy  Don’t run specified Windows applications  located under User Administrative Templates - The policy setting does come with its own caveat - " This policy setting only prevents users from running programs that are started by the File Explorer process. It does not prevent users from running programs, such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting does not prevent them from starting pr
Read more