We are currently running XenApp 6.5 on Windows 2008 R2 Standard x64.
So here's a little back story. We had a XenApp 6 environment that did not suffer these issues. Then, our SAN decided to crash and we lose most of our storage repositories that have our old environment in them. We decided to rebuild our entire XenApp environment on a new hypervisor, VMware vSphere 5.1 (ESXi).
At the same time, we had an exisiting XenDesktop environment that was still up and running during the crash. about 80% of our Citrix users were on XenDesktop while the remaining 20% were on our old XenApp environment.
Upon making the decision to rebuild XenApp, we decided to take everyone out of XenDesktop, decommission XenDesktop, and then exclusively run XenApp. We are now running XenApp and we are not running XenDesktop. What this means now is that 80% of our citrix users have never logged into our OLD XenApp environment. Our old XenDesktop and old XenApp environments are now gone.
What we are running into now is that users, including domain admins
that log into our NEW XenApp are having issues downloading things in IE. We traced it down to the file simply not writing into the C:\Users\username\appdata\local\microsoft\windows\temporary internet files\content.ie5\xxxxxxxxxx\ folder.
This could allude to a bigger problem, not just exclusive to IE.
However, we come to find out that users that have accessed our OLD XenApp environment are not having these issues on our NEW XenApp environment.
Here is the sequence to which I've identified the problem.
I logged in as Jenny. She was on our previous XenApp farm before the rebuild. We search for a basic PDF. I click on the first result in google.
The PDF opens fine in the web browser.
I search on the terminal server which Jenny is logged into, the file is found on the path shown below:
I now log in as a test account that had been created after the new environment was stood up and search for the same manual.pdf in google. I open the first link like the first time. Nothing happens.
Searched the C: drive for the same file. Cannot find the file.
This all takes place in the same environment. None of these users have special or elevated permissions set in their AD objects. The only difference was Jenny's account was on our old XenApp environment which did not have this problem, and whatever magical power she had has successfully carried over to the new environment. We do not think it's a permissions issue because not even our domain admins can successfully produce the same results as Jenny's account.