Now, I don’t know about you, but when I see “God Mode”, I think of running around in some shooter killing all the bad guys/monsters/aliens/whatever without any worry of damage or harm coming to me. Those of you that cut your teeth on some of the old school DOS-based games of yester-century (a la Doom) will know exactly what I’m talking about.

I don’t think of “God Mode” when it comes to an operating system. Unless, perhaps, running everything as admin. Really, though, that’s probably more akin to anti-God Mode if you think about it; you need to be a little more worried about potential damage and hazards since you are running as admin.

But then there’s Windows 7 and we have things like User Account Control to keep you from doing too much harm. So is “God Mode” some super-anti-UAC thingie that makes it like it was in the old days when you could call deltree from the root of your C: drive and it would happily go about doing it? (Note: Yes, I know someone that did this. No, it wasn’t me. And no, I don’t recommend trying it.)

Nope, not at all like the God Mode that I knew and loved from the days of Doom.

So when I saw an article called “Understanding Windows 7's 'GodMode'”, I was intrigued. It’s not the “God Mode” of Doom-yore, but it is interesting nonetheless and I’m kinda liking it. You create a folder and name it “GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}” (no quotes, of course). Then … behold! the icon changes and you have access to a ton of controls and settings for the operating system. It does work on Windows Server 2008 R2 x64, which is what I’m running right now.

It reminds me, in a way, of the Windows 95 Product Team Easter Egg. But simpler to create and a lot more useful.

One of the things that I’m working on as a part of the Team Foundation implementation that I’m working on is to create a series of short (10-15 minute … for me, that’s short) videos on different topics related to working with TFS within the environment. If these were generalized TFS videos, it wouldn’t be an issue but they aren’t – they are highly customized to the specific implementation and the custom template that we’re using. As a part of it, I needed to create a virtualized environment that reproduces the production environment that I could use for the videos (as well as testing). Since I want this to be as close as possible to the actual, working, production environment, I wanted to use the same URLs as we use in production. Setting up and resolving the URLs is easy enough … it’s all a private Hyper-V environment that has its own domain controller, DNS and DHCP. Adding credentials for invisible, integrated authentication was easy as well. Or so I thought … it turned out that it wasn’t as simple as I would have thought.

The URLs were all set up. I used tfsadminutil configureconnections to set the URLs in TFS so that the registration worked correctly. I cleared the TF client cache. Yet … it still didn’t work. I got errors from the client (running on the Hyper-V host system) that basically said “ummm … so sorry, it’s not working”. Looking at the app tier’s event log, I saw a series of errors including the following (this proved to be the important one):

Detailed Message: TF53002: Unable to obtain registration data for application VersionControl.
Web Request Details
    Url: http://apptier.my.testurl.com/VersionControl/v1.0/repository.asmx [method: POST]
    User Agent: Team Foundation (devenv.exe, 9.0.30729.1)
    Headers: Content-Length=319&Content-Type=application%2fsoap%2bxml%3b+charset%3dutf-8&Accept-Encoding=gzip&Accept-Language=en-US&Expect=100-continue&Host=apptier.my.testurl.com&User-Agent=Team+Foundation+(devenv.exe%2c+9.0.30729.1)&X-TFS-Version=1.0.0.0&X-TFS-Session=09b73cf7-6f05-4528-b8d7-2b531d43a409
    Path: /VersionControl/v1.0/repository.asmx
    Local Request: False
    Host Address: 10.5.5.1
    User: TESTDOMAIN\JSawyer [authentication type: NTLM]

Exception Message: TF30063: You are not authorized to access apptier.my.testurl.com.80. (type TeamFoundationServerUnauthorizedException)

I would get this same error regardless of client (VS or TFS Web). The account being used was a domain administrator … so that ruled out that it was really an authorization issue. Besides that, it all worked find until I did all the mucking about with the URLs.

Looking about the Internets, I found a blog entry from Nick Berardi gave the solution (and yes, our current production environment in Win2K3)… I set the TFS URLs in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck registry key, rebooted and voila!! It all worked!