Hello,
Thank you for posting question on Microsoft Windows forum!
The followings are the plausible explanation to address your below queries.
1.For the question of How could I make sure whether this red X causes the problem in the applying the Admins policy or not?
- The red X on the "Administrators (Group name)" line, coupled with the "An unknown error occurred when attempting to open the database" error, might suggest that the GPO is not applying the Restricted Groups setting correctly for the Administrators group. Even if you've seen red X's before with successful application.
- To confirm, beyond RSoP, you can:
- Check the local Administrators group directly: Log onto one of the affected servers and open lusrmgr.msc (Local Users and Groups). Manually verify the members of the Administrators group. If the "wrong" accounts are still there after a gpupdate /force and a reboot, the GPO is indeed failing to enforce the membership.
- Event Viewer: On the affected servers, check the System and Security event logs in Event Viewer for any events related to Group Policy (Source: GroupPolicy, SceCli, etc.) Look for warnings or security errors.
- Event Viewer: Specifically, check the Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational log. This log provides more detailed information about Group Policy processing. Look for events with Activity IDs that correspond to the policy application and any errors within that sequence.
- Create/Enable winlogon.log (if not already enabled):
- The winlogon.log file is crucial for debugging security policy application issues. If it's truly missing, you may need to enable detailed logging for the Group Policy Security client-side extension (SCECLI).
- Navigate to **HKEY_**LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions{827D319E-6EAC-11D2-A4EA-00C04F79F83A} (This GUID is for the Security Group Policy Extension).
- Inside this key, you might find a ExtensionDebugLevel DWORD value. If it exists, set its data to
2
(Hexadecimal). If it doesn't exist, create it as a DWORD (32-bit) value and set its data to2
. - After setting this, run gpupdate /force on the affected server and then check C:\Windows\security\logs\winlogon.log. This log should now contain more detailed information about the security policy processing and hopefully, the exact error preventing the Restricted Group from applying. Look for lines containing "Cannot find" or error codes.
2.Regarding the question of I failed to find the solution in resolving the An unknown error occurred when attempting to open the database - what can I do to fix it?
- This error might also indicate corruption in the local security policy database on the server. You can try the following steps.
- Check for Non-Existent Accounts in the GPO:
- The most common cause for "An unknown error occurred when attempting to open the database" with Restricted Groups is that the GPO contains an account or group that no longer exists in Active Directory or is misspelled.
- Carefully review the "Admins" GPO and ensure all specified accounts/groups are valid and exist in your Active Directory. Even a single invalid entry can cause the entire Restricted Groups processing to fail for that group.
- If you enabled winlogon.log (as per Q1), this log often specifically calls out which account it "Cannot find". This is a key piece of information for troubleshooting.
- Verify DNS and Network Connectivity:
- GPO processing heavily relies on proper DNS resolution to locate Domain Controllers and SYSVOL shares.
- Ensure the affected servers are pointing to correct and healthy DNS servers (your Active Directory integrated DNS servers).
- Perform nslookup tests for your domain and for _ldap._tcp.dc._msdcs.<yourdomain> to ensure domain controller location is working.
- Verify that the servers can access the SYSVOL share on your domain controllers like \yourdomain.com\SYSVOL.
- Test with a New GPO (for isolation):
- As a diagnostic step, create a new, simple GPO with only the Restricted Group setting for the Administrators group. Link it to a test OU containing one of the problematic servers.
- Run gpupdate /force and reboot. See if this new, isolated GPO applies correctly. If it does, the issue might be with the original "Admins" GPO itself (e.g., internal corruption, though rare).
Hope the above information is helpful!