Today started out alright. The night before I had successfully upgraded a customers TFS server from 2005 to 2008 server inside the outage window and with a minimum of fuss. As I am sure most of you know, upgrading TFS is a two step affair where you can optionally also upgrade the WSS 2.0 installation to WSS 3.0 – I opted to do this the following day and wear any minor outages (IISRESETs etc) while everyone was working.
My strategy for WSS 2.0 to WSS 3.0 upgrade was to do an in-place upgrade where I simply install WSS 3.0 over the top and then tell TFS where the new admin service is so that Team Project creation works. I never even got to the point where TFS needed to know about WSS 3.0 – oh no, my tale of woe had begun.
The upgrade process for WSS started smooth enough with the new install getting dropped down onto the machine without too many issues. However, when I went to run the configuration wizard (psconfigui.exe) it bombed out at step 7 (provisioning the central administration web application). The log file produced indicated that something was seriously wrong.
Looking at the log file there were several hints as to what might be the issue:
- Some kerberos issue.
- Some security issue.
- Some IIS issue.
I still don’t know which one it is because I ended up rolling back to WSS 2.0, however that wasn’t before spending about ten hours trying to figure out what was going on using a combination of Google and various debugging tools.
I managed to find this thread featuring Michael Nemtsev which pretty much matched the issue that I was having, however none of the other comments of the thread offered a solution that worked for me (either I wasn’t able to try them or they just didn’t make sense, I followed up with Michael who happens to work for Readify as well and he shared some scripts with me that were informative but didn’t help much. I also learned that not doing the right thing with psconfig.exe can lead to your Default Web Site being deleted (the hard way).
So what was a stressed developer to do? Well, I decided it was time to learn more about the problem and spent a few couple of hours attaching various debuggers (Visual Studio 2005, cordb.exe and mdbg.exe) to the psconfigui.exe process and steping through Microsoft’s code to migure out exactly what data was being passed into FileIOPermission to make the thing fall over. It turns out that the value “adminvs” was being passed in, but that doesn’t really make sense so I left feeling pretty mystified.
I’ve actually pinged a few people to see if they can help me. Hopefully between us we can figure out what the answer is. Before I sign-off I just wanted to make an observation about dependencies…
Dependencies are Evil
Whilst I can appreciate why the TFS team might want to depend on WSS, and on Reporting Services they then need to accept that their product will only be as stable as those products, and that their upgrade processes will only be as good as their upgrade process. When you take a dependency on a complex piece of software, then your software automatically becomes that complex.
This is one of the reasons why I am so excited by SaaS. WSS might be a fantastic collaboration space but from an install experience point of view it sucks, in fact there are lots of products out there whose install experience suck – the majority I would say. In a SaaS world where the vendor hosts their product I wouldn’t care how crappy their install process is because I would never have to do it, I could just use the software and plug my tools into it.
In the future, when I create a team project I hope that I can just point at my hosted SPS2007 infrastructure, or some other site that I’ve already created and just say “use that for collaboration”.