Troubleshooting Windows Server: Fixing 'Roles' Error in Server Manager

Table of Contents

Managing server roles and features is a cornerstone of Windows Server administration, allowing IT professionals to tailor a server’s functionality to specific organizational needs. Server Manager serves as the central console for these critical operations, providing a streamlined interface for deploying, configuring, and monitoring server roles. However, encountering errors within this essential tool can significantly impede server management, leading to operational delays and potential service disruptions. This article delves into a specific and persistent issue where selecting “Roles” in Server Manager results in an error message, preventing the proper installation or management of server components.

The focus here is on understanding the root causes of this error and providing a comprehensive, step-by-step resolution. This common problem manifests through distinct error messages and event log entries, pointing towards underlying system component corruption. By systematically addressing the identified causes, administrators can restore full functionality to Server Manager and ensure their Windows Server environment operates efficiently and reliably. This guide aims to equip you with the knowledge and steps necessary to diagnose and rectify this particular issue, ensuring smooth server role management moving forward.

Understanding the Criticality of Server Manager¶

Server Manager is more than just a dashboard; it’s the primary administrative console for Windows Server. Through this interface, administrators can add or remove roles and features, manage local servers, connect to remote servers, and perform a variety of diagnostic tasks. Roles, such as Active Directory Domain Services, DNS Server, or Web Server (IIS), define the core functions a server performs within an IT infrastructure. Features, like .NET Framework or Group Policy Management, provide additional capabilities to support these roles or other system functions.

The seamless operation of Server Manager is paramount for maintaining a healthy and functional server environment. Any disruption to its ability to display or manage roles can halt critical deployment processes, prevent necessary updates, and ultimately impact the availability and performance of services hosted on the server. When Server Manager fails to load roles or throws an error, it indicates a fundamental communication breakdown within the server’s operating system components, requiring immediate attention.

Identifying the Symptoms: Error Messages and Event Logs¶

When this particular issue arises, administrators will typically encounter an error message shortly after attempting to access the “Roles” section within Server Manager. The immediate indication is that the user profile, for some reason, fails to load correctly, leading to the reported error. Clicking on Error Details reveals a more specific and critical message that points directly to the underlying problem.

The primary error message displayed to the user is:

Server Manager:
Unexpected error refreshing Server Manager; cannot open an anonymous level security token. (Exception from HRESULT: 0x80070543)
For more information, see the event log: Diagnostics, Event Viewer, Applications and Services Logs, Microsoft, Windows, Server Manager, Operational.

This message is highly indicative, highlighting the inability to open an “anonymous level security token,” which is crucial for internal communication between system components. An HRESULT value of 0x80070543 specifically translates to ERROR_DS_UNWILLING_TO_PERFORM, often associated with security or permission-related issues when trying to perform directory service operations, or in this context, system component operations that require specific security contexts.

To gain a deeper understanding and confirm the diagnosis, further investigation into the Event Viewer is essential. The specified path, Applications and Services Logs\Microsoft\Windows\ServerManager\Operational, as well as related logs, will contain more granular error entries that corroborate the Server Manager message. Administrators should navigate to Applications and Services Logs\Microsoft\Windows\ServerManager-DeploymentProvider\Operational and Applications and Services Logs\Microsoft\Windows\ServerManager-MultiMachine\Operational for detailed insights.

Here are the specific event log entries commonly observed:

Log Name	Source	Event ID	Task Category	Description Summary
Microsoft-Windows-ServerManager-DeploymentProvider/Operational	Microsoft-Windows-ServerManager-DeploymentProvider	403	GetAlterationState method call.	GetAlterationState method returned Failed. Error: The request to add or remove features on the specified server failed. Installation of one or more roles, role services, or features failed. Cannot open an anonymous level security token. Error: 0x80070543
Microsoft-Windows-ServerManager-DeploymentProvider/Operational	Microsoft-Windows-ServerManager-DeploymentProvider	1315	GetServerComponent request on a separate thread.	Exception Detected: Installation of one or more roles, role services, or features failed. Cannot open an anonymous level security token. Error: 0x80070543 ErrorID: DISMAPI_Error__Failed_To_Enable_Updates
Microsoft-Windows-ServerManager-MultiMachine/Operational	Microsoft-Windows-ServerManager-MultiMachine	4002	Add-_InternalWindowsRole task.	Add-_InternalWindowsRole workflow reported an error installing or removing the requested component(s), TargetComputer:, RequestState:2, RebootRequired: false, ErrorMessage: The request to add or remove features on the specified server failed. Installation of one or more roles, role services, or features failed. Cannot open an anonymous level security token. Error: 0x80070543 , ErrorId: DISMAPI_Error__Failed_To_Enable_Updates, ErrorCategory: 7, Warning:

These event IDs consistently point to a failure in accessing or enabling updates for server components, explicitly mentioning the inability to open an “anonymous level security token.” This repetitive message across different logs strongly indicates a fundamental issue with how the server’s internal components communicate and authenticate, setting the stage for the underlying cause.

The Root Cause: Component-Based Servicing Subsystem Corruption¶

The core of this problem lies within the Component-Based Servicing (CBS) subsystem of the Windows operating system. The CBS is a critical framework responsible for installing, configuring, updating, and managing all Windows components. It handles the low-level operations of system files and registry settings, ensuring that all components are correctly registered and their dependencies met. When this subsystem becomes corrupted, it can lead to a wide array of system instabilities and functional errors, including the one observed in Server Manager.

Corruption in the CBS subsystem often stems from incorrect permissions. These permission issues can be introduced through various means, such as manual modifications by users or administrators, third-party software installations that alter system file permissions, or even malicious attacks. When the CBS subsystem’s integrity is compromised due to these incorrect permissions, it struggles to perform its essential tasks securely. Specifically, it might fail to properly authenticate internal processes, leading to the “cannot open an anonymous level security token” error.

This security token error signifies that the system’s Distributed Component Object Model (DCOM) – which facilitates communication between software components on different computers or within the same computer – cannot establish a sufficiently trusted connection. The DCOM settings, particularly concerning authentication and impersonation levels, dictate how components verify each other’s identity and permissions. If these settings are misconfigured, or if the underlying CBS components are corrupt, the necessary security token cannot be generated or utilized, blocking Server Manager from interacting with the role installation services.

Comprehensive Resolution Steps¶

Resolving this issue involves correcting specific DCOM security settings that are critical for internal system communication. These settings ensure that various Windows components, including Server Manager and the Component-Based Servicing subsystem, can securely interact and perform their functions. Follow these steps meticulously to rectify the problem:

1. Access DCOM Configuration:
   Click Start, then select Run. In the Run dialog box, type dcomcnfg.exe and press OK. This command launches the Component Services console, which is the administrative tool for configuring DCOM applications and services on your system.

2. User Account Control (UAC) Prompt:
   If prompted by User Account Control (UAC), click OK or Yes to grant administrative permission to open the Component Services console. This is a standard security measure to ensure that changes to system-level configurations are authorized.

3. Navigate to My Computer Properties:
   In the console tree on the left pane, expand Component Services, and then expand Computers. You will see My Computer listed. Right-click on My Computer and then select Properties from the context menu. This action opens the “My Computer Properties” dialog box, where you can configure system-wide DCOM settings.

4. Access Default Properties:
   Within the “My Computer Properties” dialog box, navigate to the Default Properties tab. This tab contains global DCOM settings that affect how distributed components interact across the entire system.

5. Configure Default Authentication Level:
   Locate the Default Authentication Level dropdown list. From this list, click and select Connect.

   • Important Note: If the Default Authentication Level is not set to None (e.g., it’s already set to Connect, Call, or Packet), do not change it. An administrator might have explicitly configured this setting for specific security reasons, and altering it could inadvertently affect other system services or applications. The primary goal here is to ensure it is not set to “None” if it shouldn’t be, or to correctly set it to “Connect” if it was improperly set. The “Connect” authentication level ensures that the identity of the client is authenticated only when a connection is established, providing a baseline level of security for component interactions.

6. Configure Default Impersonation Level:
   Next, locate the Default Impersonation Level dropdown list. From this list, click and select Identify.

   • The “Identify” impersonation level allows the server (the component receiving the call) to determine the identity of the client (the component making the call). However, the server cannot use the client’s identity to access other resources. This level is crucial for security because it permits identification without granting excessive privileges, ensuring that operations like retrieving server roles are performed under the correct, identified security context.

7. Apply and Confirm Changes:
   Click OK to apply the changes to the DCOM settings. A confirmation dialog box might appear asking you to confirm the selection. Click Yes to proceed. These changes require the system to update its DCOM configuration, which is a significant, system-wide adjustment.

8. Close Component Services Console:
   After confirming the changes, close the Component Services console. The modifications should take effect immediately, although sometimes a reboot might be beneficial, especially if other services were heavily reliant on the old DCOM settings.

These steps collectively re-establish the proper DCOM communication parameters, allowing the Component-Based Servicing subsystem and Server Manager to securely interact. By ensuring components can correctly identify and authenticate each other, the “anonymous level security token” error is resolved, restoring Server Manager’s functionality.

Verifying the Fix¶

After diligently following the resolution steps, it is crucial to verify that the fix has been successfully applied and that Server Manager is operating as expected. This verification process confirms that the DCOM settings have been correctly configured and have resolved the underlying communication issues.

1. Reopen Server Manager: Close and then reopen Server Manager. Observe if the initial loading process completes without error.
2. Access Roles and Features: Navigate to the Roles and Features section within Server Manager. This is the primary area where the error previously occurred. The section should now load correctly, displaying the installed roles and offering options to add or remove features.
3. Attempt a Minor Operation (Optional but Recommended): If feasible in your environment, attempt a small, non-disruptive operation, such as starting the “Add Roles and Features Wizard” and progressing through the initial steps (without committing to any installation) or refreshing the current view. This will further confirm that the underlying component communication is functioning properly.

If Server Manager loads without the error message and you can successfully navigate its various sections, particularly “Roles and Features,” then the issue has been resolved. If the problem persists, you may need to re-verify each step of the resolution or consider further diagnostics.

Preventing Future Occurrences¶

While resolving the current issue is paramount, understanding how to prevent similar problems in the future is equally important for maintaining a stable Windows Server environment. Many DCOM and CBS corruption issues stem from misconfigurations or unauthorized changes.

• Adhere to Best Practices for Permissions: Regularly review and enforce strict permission management policies. Avoid making manual changes to system file or registry permissions unless absolutely necessary and thoroughly understood. Always use official administrative tools and methods.
• Cautious Software Installations: Be wary of third-party software that may alter system components or permissions during installation. Always download software from trusted sources and review installation prompts carefully.
• Regular System Health Checks: Implement a routine schedule for checking server health, including reviewing event logs for unusual errors, running system file checker (sfc /scannow), and utilizing DISM commands (DISM /Online /Cleanup-Image /RestoreHealth) to repair component store corruption.
• Controlled Administrative Access: Limit administrative access to servers to only essential personnel. Implement the principle of least privilege, ensuring users and service accounts only have the permissions required to perform their specific tasks.
• System Backups: Maintain regular, reliable system backups. In severe cases of corruption, a clean restore from a known good backup might be the quickest and most effective solution, though it should be a last resort.

By adopting these preventative measures, administrators can significantly reduce the risk of CBS subsystem corruption and DCOM misconfigurations, thereby ensuring the long-term stability and reliability of their Windows Server roles and features management.

Further Diagnostics and Advanced Troubleshooting¶

If the outlined resolution steps do not fully address the “Roles” error in Server Manager, it indicates that the issue might be more complex or that there are other underlying problems affecting your server’s health. In such scenarios, a more in-depth diagnostic approach is warranted.

1. Run System File Checker (SFC):
   Open an elevated Command Prompt and run sfc /scannow. This command scans for corrupted Windows system files and attempts to repair them. A corrupted system file can sometimes interfere with DCOM and CBS operations.

2. Utilize Deployment Imaging and Servicing Management (DISM):
   If SFC reports unfixable issues, or as a general system health check, use DISM commands to repair the Windows component store.

   • DISM /Online /Cleanup-Image /CheckHealth (Checks if an image is repairable)
   • DISM /Online /Cleanup-Image /ScanHealth (Scans for component store corruption)
   • DISM /Online /Cleanup-Image /RestoreHealth (Repairs component store corruption using Windows Update as a source)
     These commands are powerful tools for fixing deeper system integrity issues that might affect component-based servicing.

3. Review Relevant Service Status:
   Ensure that critical services related to Server Manager and component installation are running. These include, but are not limited to, “Windows Modules Installer” (TrustedInstaller) and “DCOM Server Process Launcher.” Access services via services.msc.

4. Check for Pending Windows Updates:
   Sometimes, pending updates or failed updates can leave the system in an inconsistent state, impacting core functionalities. Ensure all necessary Windows updates are installed and the server is rebooted if required.

5. Examine Group Policy Objects (GPOs):
   If the server is part of an Active Directory domain, Group Policies can sometimes override local DCOM settings or impose other restrictions. Review any GPOs that might be affecting security settings, particularly those related to DCOM, Windows services, or user rights. Running gpresult /r in an elevated command prompt can help identify applied GPOs.

6. Test with a Different Administrator Account:
   Create a new administrator account and log in with it to see if the issue persists. This helps to rule out profile-specific corruption or permission issues.

By systematically working through these advanced troubleshooting steps, you can uncover and resolve more persistent or complex issues that might be preventing Server Manager from functioning correctly. Always ensure you have appropriate backups before making significant system changes.

---

Successfully managing Windows Server roles and features is fundamental to maintaining a robust and efficient IT infrastructure. The “Roles” error in Server Manager, while frustrating, is a resolvable issue, often pointing to underlying DCOM or Component-Based Servicing subsystem misconfigurations. By understanding the symptoms, diagnosing the root cause, and applying the detailed resolution steps provided in this guide, administrators can restore full functionality to their Server Manager console. Furthermore, adopting preventative measures and being prepared for advanced troubleshooting will help safeguard your servers against similar issues in the future.

Have you encountered this specific error, or perhaps a similar one with DCOM settings? What steps did you find most effective in resolving it? Share your experiences and insights in the comments below – your contributions can help other administrators facing similar challenges!