Restricted Groups issue

Hram Admin 170 Reputation points
2025-06-03T10:15:11.5133333+00:00

Hello!

My domain contains the GPO (say named Admins) that defines which user accounts are to be the members of the local Administrators group. This policy was first applied to the Servers OU ~ 10 months ago and I didn't see any issues with it: the accounts not specified in the GPO were removed from local Administrators group (if any) and the new ones were successfully added - so far so good.

Now when running some tests on a couple of servers I noticed that when I add an account to the local Administrators group and apply the policy (or even restart a server) this "wrong" account does not get removed from the local Administrators group. I checked that policy is applied correctly and then checked RSoP on both servers:

02

The result:

  1. Configure Membership for Administrators tab contains exactly the same accounts as it should ( no accounts were either added or removed)
  2. Administrators (Group name) has the red X
  3. The error (An unknown error occurred when attempting to open the database) on the Precedence tab
  4. Winlogon.log does not exist

I've already seen the red X in the RSoP data and nevertheless those gpo settings have been applying successfully so

Q1: How could I make sure whether this red X causes the problem in the applying the Admins policy or not?

Q2: 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?

Regards,
Michael

Windows for business Windows Server User experience Other
{count} votes

Accepted answer
  1. Chen Tran 955 Reputation points Independent Advisor
    2025-06-06T07:44:22.4333333+00:00

    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:
    1. 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.
    2. 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.
    3. 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. User's image
    4. 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 to 2. User's image
    • 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:
    1. 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.
    2. 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.
    3. 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:
    1. GPO processing heavily relies on proper DNS resolution to locate Domain Controllers and SYSVOL shares.
    2. Ensure the affected servers are pointing to correct and healthy DNS servers (your Active Directory integrated DNS servers).
    3. Perform nslookup tests for your domain and for _ldap._tcp.dc._msdcs.<yourdomain> to ensure domain controller location is working.
    4. Verify that the servers can access the SYSVOL share on your domain controllers like \yourdomain.com\SYSVOL.
    • Test with a New GPO (for isolation):
    1. 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.
    2. 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!


0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.