GPU Settings Unavailable After Domain Join on Windows Server? Here's Why.
This article addresses a common problem encountered by system administrators and IT professionals: the unavailability of physical GPU settings after a Windows Server 2012 Remote Desktop Virtualization Host is joined to a domain. Specifically, this issue manifests when the default domain policy is applied, leading to the option for selecting a physical GPU for RemoteFX within Hyper-V settings becoming inaccessible. This situation can significantly hinder the performance and functionality of virtualized environments relying on GPU acceleration.
Symptoms¶
The primary symptom of this issue is the disappearance of the physical GPU selection option within the Hyper-V settings interface after joining a Windows Server 2012 Remote Desktop Virtualization Host to a domain. This occurs when the default domain policy, or a similar policy, is enforced. Administrators attempting to configure RemoteFX for virtual machines will find themselves unable to allocate a physical GPU to these virtual environments.
Even in scenarios where the option to select a physical GPU appears to be available within Hyper-V settings, a secondary symptom may arise. Users might find themselves unable to add the RemoteFX 3D Adapter to virtual machines provisioned on the host server. This means that even if the configuration interface seems to allow GPU selection, the underlying system is preventing the actual assignment and utilization of the physical GPU for RemoteFX capabilities. This can lead to confusion and frustration as the expected GPU acceleration for virtual desktops and applications fails to materialize. The inability to add the RemoteFX 3D Adapter effectively disables the intended graphical enhancements for virtual machines, impacting user experience, especially in graphically demanding applications.
These symptoms collectively point to a policy-related access restriction affecting the Remote Desktop Virtualization Host’s ability to utilize physical GPUs after domain integration. Troubleshooting efforts should therefore focus on examining group policy configurations and user rights assignments to identify and rectify the underlying cause.
Cause¶
The root cause of this issue lies in the configuration of user rights assignments within the domain policy. Specifically, the problem arises if the Default Domain Policy, or any other applied Group Policy Object (GPO), has inadvertently or intentionally removed the “Users” group from the “Allow log on locally” policy. This seemingly minor change has significant repercussions for the RemoteFX functionality on the server.
The RemoteFX feature, responsible for enabling GPU virtualization and acceleration, relies on a system account named ‘RDV Graphics Service’. This service account is crucial for the proper operation of RemoteFX and its ability to interact with the physical GPU. Critically, the ‘RDV Graphics Service’ account is a member of the local ‘Users’ group on the Remote Desktop Virtualization Host server.
When the “Users” group is removed from the “Allow log on locally” policy, it effectively denies logon permissions to all members of this group when attempting to log on locally to the server. Consequently, the ‘RDV Graphics Service’ account, being a member of the ‘Users’ group, is also denied the necessary permissions to log on locally.
Without the ability for the ‘RDV Graphics Service’ to log on locally, the RemoteFX feature cannot initialize correctly and access the physical GPU. This results in the observed symptoms: the GPU settings becoming unavailable in Hyper-V Manager and the inability to add the RemoteFX 3D Adapter to virtual machines. Essentially, the system is prevented from properly leveraging the physical GPU for virtualization due to the restricted logon rights of a critical service account. This highlights the importance of carefully managing user rights assignments in domain policies, especially concerning system services that require local logon permissions to function correctly. The seemingly innocuous change to the “Allow log on locally” policy has a cascading effect, disabling a key feature of the Remote Desktop Virtualization Host environment.
Resolution¶
To resolve the issue of unavailable physical GPU settings after domain join, the key is to reinstate the “Users” group’s ability to log on locally to the affected Windows Server 2012 Remote Desktop Virtualization Host. This involves modifying the “Allow log on locally” policy through the Group Policy editor. The following steps outline the procedure to restore the necessary permissions:
-
Access Group Policy Editor: Begin by launching the Local Group Policy Editor on the Windows Server 2012 Remote Desktop Virtualization Host. Click the Start button, then type
gpedit.mscin the search bar. Press ENTER to open the Group Policy Editor console. -
Navigate to User Rights Assignment: Within the Group Policy Editor console, navigate to the relevant policy settings. Expand the following branches in the console tree:
- Computer Configuration
- Policies
- Windows Settings
- Security Settings
- Local Policies
- Select User Rights Assignment.
-
Open “Allow Logon Locally” Policy: In the details pane on the right side, locate and double-click the policy named Allow Logon Locally. This will open the properties dialog box for this policy, allowing you to view and modify the list of users and groups permitted to log on locally.
-
Verify and Add “Users” Group: In the “Allow log on locally Properties” dialog box, review the list of users and groups that are currently allowed to log on locally. If the Users group is missing from this list, you need to add it back. Click the Add User or Group… button to proceed.
-
Select “Users” Group: The “Select Users, Computers, or Groups” dialog box will appear. In the “Enter the object names to select” field, type USERS. Alternatively, if you are unsure of the exact name or want to browse, you can click the Browse… button to locate and select the “Users” group from the directory. Once you have entered or selected “USERS”, click OK.
-
Confirm and Apply Changes: After adding the “Users” group, it should now appear in the list of allowed accounts in the “Allow log on locally Properties” dialog box. Click OK in the “Add User or Group” dialog box, and then click OK again in the “Allow log on locally Properties” dialog box to save the changes.
After completing these steps, the “Users” group should be reinstated in the “Allow log on locally” policy. This will grant the ‘RDV Graphics Service’ account the necessary permissions to log on locally, enabling the RemoteFX feature to function correctly and allowing you to configure physical GPU settings in Hyper-V.
In addition to ensuring the “Users” group is present in the “Allow log on locally” policy, it is also crucial to verify that the “Users” group is not explicitly denied logon locally through the “Deny Logon Locally” policy. An explicit denial will override the “Allow log on locally” setting and continue to prevent the RemoteFX feature from working. Follow these steps to check the “Deny Logon Locally” policy:
-
Access Group Policy Editor: If you have closed it, relaunch the Local Group Policy Editor (gpedit.msc).
-
Navigate to User Rights Assignment: As before, navigate to:
- Computer Configuration
- Policies
- Windows Settings
- Security Settings
- Local Policies
- Select User Rights Assignment.
-
Open “Deny Logon Locally” Policy: In the details pane, double-click the policy named Deny Logon Locally.
-
Verify “Users” Group is Not Listed: In the “Deny log on locally Properties” dialog box, carefully examine the list of users and groups that are explicitly denied logon locally. Ensure that the USERS group is not present in this list. If the “USERS” group is listed here, it is the source of the problem and needs to be removed. Select the “USERS” group and click the Remove button.
-
Confirm Changes: Click OK in the “Deny log on locally Properties” dialog box to save any changes.
By ensuring that the “Users” group is allowed to log on locally and is not denied logon locally, you effectively restore the necessary permissions for the ‘RDV Graphics Service’ account. This should resolve the issue of unavailable physical GPU settings and enable the proper functioning of RemoteFX in your Windows Server 2012 Remote Desktop Virtualization Host environment. After making these policy changes, it is advisable to restart the server or force a Group Policy update (gpupdate /force in an elevated command prompt) to ensure the new policy settings are applied immediately.
More Information¶
It is important to note that this specific issue regarding GPU settings and domain join is resolved in later versions of Windows Server, specifically starting with Windows Server 2012 R2. Microsoft addressed this behavior in subsequent releases, eliminating the dependency on the “Users” group for the ‘RDV Graphics Service’ account’s local logon rights in the context of RemoteFX functionality.
Therefore, if you are running Windows Server 2012 R2 or a later version, you should not encounter this problem. However, this information remains relevant for administrators managing environments that still include Windows Server 2012 or for those troubleshooting similar issues related to service account permissions and group policy configurations in other contexts.
For environments where upgrading to Windows Server 2012 R2 or a newer version is feasible, it is the recommended long-term solution to avoid this and potentially other compatibility or feature limitations present in older operating systems. Upgrading to the latest supported server operating system ensures access to the latest features, security updates, and performance improvements, in addition to resolving known issues like the one described in this article.
While the resolution provided focuses on adjusting the “Allow log on locally” and “Deny logon locally” policies, it is always best practice to thoroughly review and understand the implications of any Group Policy changes within your organization’s domain environment. Carefully consider the security implications of modifying user rights assignments and ensure that any changes are aligned with your organization’s security policies and best practices. Testing policy changes in a non-production environment before implementing them in production is highly recommended to prevent unintended consequences.
If you continue to experience issues after implementing these resolutions, further troubleshooting steps may be necessary. This could involve examining event logs for related errors, verifying the proper installation and configuration of RemoteFX roles and features, and ensuring that the physical GPU hardware is compatible and correctly installed on the server. Consulting Microsoft’s official documentation and support resources may also provide additional guidance for complex or persistent issues.
We hope this article has provided a clear understanding of the cause and resolution for the “Physical GPU settings unavailable post domain join” issue in Windows Server 2012. By carefully managing user rights assignments within your domain policies, you can ensure the proper functioning of RemoteFX and effectively utilize physical GPUs for enhanced virtualization performance.
Feel free to leave a comment below if you have any questions or further insights on this topic!
Post a Comment