Not having an answer is bad enough, but being locked out of the process to discover the answer is ten times worse for me; especially when I know something most others don’t – a way to solve the problem without resorting to ‘bad workarounds’, that will inevitably cause the same amount of problems as not finding the answer to the original question.
It’s not often that I’ll blog about my work – mainly through fear of revealing information that I probably shouldn’t and/or my colleagues reading something that they probably shouldn’t have and the potential for them to take it the wrong way (this is the Internet after all). But I’ll need to refer to the problem at hand in order to make my point here.
We’ve long ran a Citrix Xenapp 5 farm at work, split between two clients and whilst one client works flawlessly, the other runs into problems with their allocated servers, despite the applications being almost identical between the two parties. The troubleshooting process has attempted pretty much everything from re-installing servers, changing hardware components, every registry hack you could possibly ever think of and then a bit more, but nothing has worked.
Having exhausted our troubleshooting repertoire the decision was made to abandon the current farm and build a new one, which after a lot of heart and headaches in trying to find my answer for the failures I was happy to admit defeat in, made especially more easier to swallow given that we have already lost a substantial amount of money trying to diagnose a live system.
The new farm has been built using Microsoft Server 2008 and is now a 64-bit system, as opposed to the Server 2003, 32-bit environment the old one utilises. The servers are speedy and responsive, but there are two problems we can’t seem to diagnose; when launching an Intranet page (which is set up as a published application), we are prompted for credentials and the second is when we log into a specific website and hit search, the page returns to the logon screen.
Two minor issues you may think, but log into the server locally (as opposed to the published application), and they work fine. Log out of the server and then launch the published apps again and they work flawlessly.
This suggests to me that Microsoft have some difference in logon between a local connection and a remote Xenapp session that sets the profile up differently and allows Internet Explorer 8 (and later testing with IE9), to then work. Searching around the Internet has found no matching results and further leads to investigate.....but instead of trying to fix the issue, our installs team have now decided to switch to Firefox, replacing IE – and it appears to have pressed my buttons.
Being a Microsoft die-hard and a user of the SysInternals tools, I’m dying to get my hands on the server and figure out the difference and then attempt to fix based on the information Process Monitor will unearth for us. But having zero access to the server prevents me from doing this and instead a team of server engineers attempt to go looking for a needle in a haystack and provide work arounds using Firefox (which means we can’t control sessions using Group Policy anymore and configuration is an added worry we now need to contend with).
I spent two years learning everything I could about SysInternals tools and how to use them effectively exactly for this reason; to find my answer. What I didn’t envisage was that I wouldn’t be able to use these skills to find answers and that those with elevated privileges would prevent me from working towards solving problems.
“In the words of the philosopher Jagger, you can’t always get what you want”
- Dr. Gregory House, House, M.D.