How To
Summary
Windows Server 2022 is failing to install Remote Desktop Services role and getting error, “Failed: Unable to install the role services for Remote Desktop Services role services”.in addition to displaying EVENTID 7001 with message, “The RemoteApp and Desktop Connection Management service depends on the Windows Internal Database service which failed to start because of the following error: The service did not start due to a logon failure” while the CBS log file is also showing, “InstallRDcmsDatabase Failed with error code 0x80070002. Retrying”.
Objective
According to Microsoft and other sources, the error encountered during the Remote Desktop Services (RDS) role installation on Windows Server 2022 is commonly caused by the Windows Internal Database (WID) service (specifically, the MSSQL$MICROSOFTWID instance) failing to start due to insufficient logon permissions.
This problem triggers Event ID 7001 (service dependency failure for RemoteApp and Desktop Connection Management) and the CBS log entry for `InstallRDcmsDatabase` failing with 0x80070002 ("The system cannot find the file specified"). The database setup can't proceed without the service running.
The root issue is typically a missing "Log on as a service" user right for the service account `NT SERVICE\MSSQL$MICROSOFTWID`, often overridden by a Group Policy Object (GPO) in domain environments somewhere. This is usually the common reason for this issue.
Environment
Windows Server 2022
Steps
To fix the "Logon failure" for the Windows Internal Database (WID) service when installing Remote Desktop Services, you must add the "NT SERVICE\\ALL SERVICES" group and the "NT SERVICE\\MSSQL$MICROSOFTWID" account to the "Log on as a service" security policy using the Local Security Policy editor (secpol.msc or gpedit.msc)
Quick Checks Before Fixing
- Ensure there are no pending reboots (check via `gpupdate /force` and restart if needed).
- Verify the server is domain-joined if using a full RDS deployment (standalone mode may require Windows Admin Center for installation).
- Run a system file check: Open an elevated Command Prompt and execute `sfc /scannow` followed by `DISM /Online /Cleanup-Image /RestoreHealth` to rule out corruption.
Primary Fix: Grant "Log on as a Service" Rights
This resolves the logon failure in most cases. Perform these steps on the server where RDS is being installed.
1. Open Local Security Policy:
- Press `Win + R`, type `secpol.msc`, and press Enter (run as Administrator if prompted).
2. Navigate to User Rights Assignment:
- Expand Local Policies > User Rights Assignment.
- Double-click Log on as a service.
3. Add the Required Account:
- Click Add User or Group.
- In the "Select Users or Groups" dialog, click Locations and ensure the local computer is selected.
- In the "Enter the object names" field, type `NT SERVICE\ALL SERVICES` (this covers the WID service broadly) or specifically `NT SERVICE\MSSQL$MICROSOFTWID`.
- Click Check Names (it should resolve), then OK.
- Click OK to close the policy dialog.
4. Apply Changes:
- Close secpol.msc.
- Open an elevated Command Prompt and run `gpupdate /force`.
- Restart the server.
5. Retry RDS Installation:
- Open Server Manager > Manage > Add Roles and Features.
- Proceed with the RDS role installation (select Connection Broker if that's failing).
- If using the RDS Deployment wizard, restart it post-reboot.
If the server is clustered, repeat steps 1-4 on all nodes using the Cluster service account.
If GPO is Overriding the Policy (Domain Environment)
The local policy change may revert due to a domain GPO.
1. Identify the Overriding GPO:
- Press `Win + R`, type `rsop.msc`, and press Enter.
- Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Log on as a service.
- In the Precedence tab, note the GPO(s) listed (e.g., a default domain policy).
2. Modify or Exclude the GPO (requires domain admin access):
- On a domain controller, open Group Policy Management (`gpmc.msc`).
- Locate the offending GPO (e.g., under Default Domain Policy).
- Edit it: Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Log on as a service.
- Add `NT SERVICE\ALL SERVICES` to the policy.
- Alternatively, create a new GPO linked higher in precedence (e.g., at the OU level for your server) with the same addition, or exclude the server from the overriding GPO.
- Run `gpupdate /force` on the server and reboot.
Alternative Fix:
Reinstall Windows Internal Database (If Logon Rights Don't Resolve)
If the above fails (e.g., persistent file-not-found during DB setup):
1. Uninstall WID:
- In Server Manager > Manage > Remove Roles and Features, deselect Windows Internal Database under Features.
- Complete the removal and reboot.
2. Rename Leftover Folder:
- Open File Explorer as Administrator.
- Navigate to `C:\Windows`.
- Rename the `WID` folder to `WID_old` (if it exists).
3. Reinstall WID and Retry RDS:
- Re-add Windows Internal Database via Server Manager > Add Roles and Features > Features.
- Reboot, then retry the RDS installation.
Verification
- After fixes, check Event Viewer (Windows Logs > System) for no new 7001/7041 errors.
- Manually start the WID service: In `services.msc`, find Windows Internal Database (MSSQL$MICROSOFTWID), set Startup type to Automatic, and start it.
- If RDS installs successfully, configure licensing via Server Manager to avoid grace period issues.
Additional Information
Remember to restart the server after all changes!!
Check Group Policy (if applicable): (If issue still exists after all steps are completed!)
- If the server is part of a domain, check for any domain Group Policies (GPOs) that might be overriding local security settings or removing user rights. You can use rsop.msc to identify the GPO that may be preventing the changes.
Document Location
Worldwide
Was this topic helpful?
Document Information
Modified date:
06 February 2026
UID
ibm17259968