Remote Desktop Services could not apply a user desktop for a user account with a SID of <GUID>. A temporary profile was enforced for the user. Verify that the user profile disk settings are correct. The error code is 0x800700AA.0
I tried disabling and re-enabling User Profile Disk so RDS would verify that it had the correct permission to create the disk, as well as deleting the related User Profile Disk itself. All to no avail.
Eventually, I started looking around the profile settings in Windows and the registry and I found an entry in the Profile List (HKLMSOFTWAREMicrosoftWindows NTCurrentVersionProfileList) that matched the problem SID and noticed it referenced an invalid “ProfileImagePath.”
Your Welcome! Happy to help!
Very cool. Needle in a haystack. Hope this is resolved in R2, I’ve had to do it for 3 out of 51 profiles.
Hi,
We are usually getting temporary profile in our servers every other day. It is kind of random. How often are you getting temporary profiles?
Hi,
I had a similar problem and temp profiles would keep happening. I was able to workaround using above. To stop this problem happening again I added the RDS server active directory computer account to be a member of “Windows Authorization Access Group”. This completely solved the problem and we no longer have any issues with temporary profiles.
Take a look at this – https://social.technet.microsoft.com/Forums/en-US/7f88b1a2-6e0d-4cdb-b598-cce696ce3255/server-2012-rds-user-profile-disks-errors-during-logoff
Hello Bob event 140 and 50 are known MS issues, asw of today no known fix. There is a Hotfix for the Temporary USer Profile disk. MS hotfix 461155.
We are also having the same problem. I did fond out that when using Session Broker, the VHDX is beeing mounted on the first server the user is connecting to, and if Session Broker transfer the user to another server that server also tries to mount The VHDX, and thai fails because the file is locked. If you turn of NLA and connect you will be prompted twice to enter credentials (if you are beeing transfered to another server) and you wait a few seconds before loging in again, and the first server will hade time to release the VHDX (takes just a few seconds).
We will contact Microsoft and report this as a bug.
Hey Lucas
We have a user who keeps getting a temp profile everytime she logs on. I have tried all the previous manners of resolving the issue before , not working with this client.
Did MS ever get back to you?
Heya,
I too had a problem with temperary profile folders on the session host. I tried deleting the registry keys for the profile list/guids,
deleted the temp folders, looking for permissions errors on the User Profile Disks, or on the shared folder I stored them on. But coulnd’t find
any problems there. Until I realised something.
User profile disks are exactly what they are named for, disks that are mounted onto the host. So when a profile disk is mounted, you should be
able to see them in ‘Disk Management’ on the host you are connected to. Usually you set a User Profile Disk folder as a shared folder, where the
session host can retrieve the disk from. Be sure the permissions are set correctly, so you should see the session host server (computer) having
full rights on that folder.
So the problem was, that I had been mounting the User Profile Disks of several users on our Fileserver. I was in the middle of migrating personal
data to their User Profile Disks. I unmounted the disks after that, but in disk management, they were still attached. Which was causing the
temperary profile folder messages on my session hosts.
After detaching the disks on my Fileserver, the User Profile Disks were working again without a hitch.
Okay after all sorts of investigating, I finally got the approval to get the Microsoft support. The MS support told me that the Temporary User Profile disk can be caused by the SID not being released by the users previous vdi session. He recommended a Hotfix number 469155 to be applied on server 2012 and stated that this issue had been completely resolved in server 2012R2.
Well no, it hasn’t. And there is still no hotfix for R2 as far as i know 🙁
We had exactly this issue on 2012R2 RDS session hosts, using Wyse thin clients and also RDP. But only occasionally – and, like a poster said above, it wasn’t all the time – only sometimes.
We had followed the advice that related to 2008 farms and put a DNS round robin on containing the IPs of the session hosts, and were connecting the clients to that, instead of the broker directly.
After working with Microsoft for a couple of weeks we discovered that this was actually causing the issue. We reconfigured the VDIBroker parameter in our wnos.ini files to point to the broker, rather than set up a direct RDP connection to the session host farm name, and then got it to autoconnect to the name of the session collection rather than a server.
Bingo, problem solved. Hope this helps someone.
Cheers
Hi Tor,
Hope everything is great in Odense. I have a customer that have the same problem. 🙂
/Peter
CE – How exactly did you accomplish this? I am unable to find the ini file you mentioned. I’m starting to get desperate, which is never a good thing.