We have made no intentional changes to our cloud environment, domain controllers, Group Policy, or network configuration, but users are now being logged in with temporary Windows profiles. The first login works normally, but after a virtual desktop is rebooted, the next login receives a temporary profile. This is currently affecting every user. The domain controllers are online, the site-to-site tunnel is up, and the desktops can reach the directory directly. The D: user volumes are not full. Event Viewer shows User Profile Service errors such as 1511 and 1515, but nothing obvious explains why profile creation is failing. Where should I look next? Could a Group Policy setting—possibly one that restricts USB device mounting—cause this behavior even if the policy has not recently changed?
3 Answers
Because all users are affected, check the shared profile or SMB path and the server-side logs as well as the individual desktop logs. Confirm that the profile volume is actually mounted and writable during sign-in, and verify DNS resolution, SMB connectivity, and permissions from an affected desktop. A policy change is still possible even without an intentional edit—an updated policy, security baseline, or changed device-control behavior can expose a problem that was previously hidden. Compare `gpresult /h` output between a working first login and a failed post-reboot login if possible.
Start with the affected desktop's Event Viewer rather than the cloud console. Check the Application log for User Profile Service events around the failed sign-in, especially 1511, 1515, 1521, and 1533. Then inspect the user's SID under HKLMSOFTWAREMicrosoftWindows NTCurrentVersionProfileList; a matching .bak key often means Windows considers the normal profile unavailable. Since this affects every user, focus first on something shared: domain name resolution during logon, an unreachable SMB or profile share, a storage mount issue, or a Group Policy that prevents the profile volume from being accessed. A working tunnel and successful ping do not necessarily prove that the required DNS, SMB, and authentication traffic is available at logon time.
It appears to affect every user, and the D: volumes have plenty of free space. We are seeing the 1511 and 1515 events, but nothing else in the logs clearly points to profile creation. The desktops can reach the directory, so I am also testing whether our USB-restriction policy could be involved, even though it has been unchanged for years.
Be careful with recovery actions. Rebuilding the desktop normally resets the system volume while preserving the user volume, whereas restoring it can reset both. Do not restore a machine until you have confirmed where the profile problem is, because that could remove user data while only masking the underlying access or policy issue.
Should the relevant SMB and profile-mount logs be checked on the individual virtual desktop, on the file server, or both? I am currently checking the desktops and comparing the applied policies.