I'm troubleshooting a Windows Server 2025 domain-joined member server that does not have the RDS role, AVD, FSLogix, roaming profiles, or user profile disks installed. Users see a black screen for several minutes after signing in, either at the console or through administrative RDP sessions. Stopping the App Readiness service makes the desktop appear immediately.
This is commonly associated with RDS and multi-user environments, where the App Readiness database can become slow or oversized. However, this server has a relatively small user base and is not being used as an RDS host.
Has anyone seen the same behavior on a plain Server 2025 member server? Could this be a Server 2025 regression, a problem with the App Readiness database, or something triggered by virtualization or OS customization? What would make the service stall in this environment, and is it safe to disable it permanently? I'm also concerned about possible effects on Store or Edge sign-in and Windows Update operations. Finally, is there an official Server 2025 fix, rather than relying on older timeout registry settings intended for Server 2019 or AVD?
3 Answers
The familiar black-screen problem is not limited to large roaming-profile deployments. App Readiness still runs on a normal member server and can wait on per-user application registration, provisioning data, or a damaged app repository. Look in the AppX deployment and App Readiness event logs, compare the behavior with a newly created test account, and check whether the delay began after an update or image change. At present, the available guidance appears to be the existing timeout workarounds rather than a clearly identified Server 2025-specific hotfix.
Check whether the server is running in VMware and whether an OS customization or guest-preparation step was used. There are virtualization-specific cases where that leaves App Readiness waiting during sign-in, even without RDS or profile containers. Reviewing the guest customization history and the App Readiness event logs would be a good next step.
I would not treat disabling App Readiness as a permanent fix. The service can be involved in application provisioning and some update workflows, so disabling it may cause patching or application installation problems. Increasing the relevant App Readiness and first-logon timeouts is generally safer while investigating the cause.
That’s worth checking. This machine is not using AVD or RDS, so a virtualization or image-customization issue may explain why the usual multi-user explanation does not fit.