I have set up a Windows Server 2008 R2 terminal server for the sole purpose of running a web-based application that has utterly ridiculous system requirements (IE7, Java 6 update 3, Acrobat 9.5). It's terrible software, but we're stuck with it.
Because of the security implications of running such out-of-date software, the terminal server is isolated from the rest of the network and has a fully locked-down group policy applied to it so that it can only run Internet Explorer, and can only browse to that one URL. This server does not receive any Windows updates whatsoever. The server also reboots itself nightly and purges all user profiles.
For the convenience of our users, I set it up to run IE as a RemoteApp so it just appears to the user as a normal application that they double-click on their desktop. This used to work fine, until one day it just stopped for no reason I can think of.
Here are the symptoms:
- If the user double-clicks the RemoteApp icon from their desktop, IE opens up to a blank page with the correct URL in the address bar. Refreshing the page doesn't do anything, nor does copy/pasting the URL into the address bar.
- If the user signs into the terminal server using a fully interactive desktop session (not via the RemoteApp), then the page works fine.
- After having navigated to the page successfully in full desktop mode, the user can then log off and use the RemoteApp version just fine for the rest of the day.
This obviously has something to do with the user profile. I can break it again on-demand by purging the profile manually. The problem is that I do not want to remove the nightly profile purge because we start running into caching problems later on (this is why the profile purge was implemented in the first place).
The application does not use any custom ActiveX controls. The vendor says that running it in a terminal server environment is an unsupported configuration (because of course they would say that), so they're no help.
Any ideas?
Best Answer
I found the answer. We have a generic IE group policy object that we use on terminal servers, and this particular terminal server has its own lockdown IE GPO (to prevent it from browsing the internet). In AD, the server is in its own container with inheritance blocked.
Someone marked the generic IE policy as enforced, which not only broke through the inheritance blockade, but also made it first in the precedence order. Simply removing the GPO enforcement fixed the issue.
Not really useful for the internet at large. Just posting this as a reminder to check your GPO inheritance when you run into wonky server configs that work one day and then suddenly don't the next.