We haven't made any changes to AWS, our domain controllers, Group Policy, or the surrounding network, but users are suddenly being logged into temporary Windows profiles. The first login works normally; the problem appears after a WorkSpace is rebooted. The domain controllers are online, the IPsec tunnel is up, and the WorkSpaces can reach Active Directory. D: drives do not appear to be full. Event Viewer shows User Profile Service events such as 1511 and 1515, but nothing obvious points to the cause. What should we check next? Could a Group Policy setting, such as USB storage restrictions, be preventing the profile from mounting or loading?
2 Answers
Start with Event Viewer on an affected WorkSpace and check the Application log for User Profile Service events around the failed logon. Events 1511, 1515, 1521, and 1533 can help identify whether Windows is failing to load, access, or write the profile. Also check HKLMSOFTWAREMicrosoftWindows NTCurrentVersionProfileList for the user’s SID. A .bak entry often means Windows marked the normal profile as unavailable and created a temporary one instead.
Since this appears to affect everyone, investigate shared dependencies rather than only individual profile corruption. Confirm DNS and domain resolution from the WorkSpace itself at logon time; an active tunnel and successful ping do not guarantee that name resolution or SMB access is working correctly. If profiles or related data use a file share, review the SMB server logs and verify that the share is reachable and writable.
The D: volume is also worth checking even if it is not full, since WorkSpaces store user profile data there. Avoid using Restore as a first fix: Rebuild resets C: while preserving D:, whereas Restore resets both and can remove user data.
A mount or access problem is still a strong possibility. Check the logs on the SMB or profile server as well as the local WorkSpace, especially for failed authentication, unavailable shares, permission errors, or connection failures around the time of logon. If every user is affected, compare the current effective Group Policy and test with the suspected USB restriction temporarily excluded for a controlled account or WorkSpace. A policy can begin causing problems after an environmental change even when the policy itself was not edited.
It now appears to affect every user, and the D: volumes have plenty of free space. We’re seeing the profile errors directly on the WorkSpaces, but nothing else in the event details clearly explains the failure. The machines can reach and modify resources on the domain controllers. I’m also testing whether a Group Policy setting is involved, particularly our USB-mount restriction, since this OU is affected by that policy even though it has worked for years.