Why BisRegEdit is sometimes the reported culprit of a failed install.

  • Article

I've been reading the newsgroup postings setup for Team System. Of particular interest, are those dealing with setup issues as I've spent a fair amount of time working with "setup" to make sure that the pieces work together.

There are two types of installs that we do around here.

  1. Scripted installs using a combination of batch, vbasic, and other "scripts".
  2. Layout install which installs from CABs, uses setup.exe.

I've done a fair amount of work with the first type and am familiar with many of the steps necessary. BTW, we try very hard to make sure that the product of either install are equivalent.

Ok, so how does BisRegEdit fit into the setup process? "BIS" (will be renamed when we RTM), provides infrastructure services. One of those functions is to help the multiple services (Work Item Tracking, Build, Source Code Control, Data Warehouse, etc) locate each other. In this case, it acts as a clearing house. The information that it provides comes from each service registering information with BIS at install time. There are many ways to provide this information. The Source Code Control team chose to provide the registration information through a .ASPX page (dynamically). What this means, which may be subtle, is that the Source Code Control system which was just installed is invoked to provide the data. Thus, if part of the installation has failed, than this step usually (but not always) will highlight a failure elsewhere in the installation process.

OK, I said this would be about why BisRegedit is often listed (wrongly) as the culprit. Let's look at the actual invocation line and pick it apart:
"C:\Program Files\Microsoft Visual Studio 2005 Enterprise Server\BISIISDIR\sdk\bin\bisregedit.exe" "https://TEAMSYS:8080/SCC/public/application/ServiceDefinition.aspx" TEAMSYS.BURTON.COM BisDB

Bisregedit accepts command lines of the form:  <xml-document> <TeamSystem Database Server> <BisDatabase>
where

  • xml-document contains the registration data for the service.
  • TeamSystem Database Server is the name of the data-tier system
  • BisDatabase is the name of the database where the data will be stored.

In the case of the Source Code Control system, the registration data is obtained by invoking the Source Code Control system (just installed!). The page at <InstallDir>/SCC/public/application/ServiceDefinition.aspx provides this information. From a browser (on an installation that's working), you can navigate to the same Url to see the data. E.g., open your favorite browser and enter https://TEAMSYS:8080/SCC/public/application/ServiceDefinition.aspx

When everything is installed properly, the BisRegEdit loads the contents of the document using the following pattern:
    XmlDocument registrationDoc = new XmlDocument();
registrationDocument.Load(string xmlDocument); // in this example, the parameter is the Url listed above but a file can be supplied

When BisRegedit fails, it may be due to a few things; I usually triage failures as follows:

1. Installation log: check for failures earlier in the process. The installation log is on the client system.
2. Event log of mid tier: check for error event log entries (the source will be VSTF * or TFS) in the application log.
3. Make sure that ServiceDefinition.aspx permits anonymous access.
4. Check ASP.NET version  for TF web site (should be 2.x)
5. IIS log for web site looking for 5xx or 403 status codes (generally, 401s are ok if they're followed by a 200).

If there aren't any errors in the install log that are obvious, then the problem may be isolated to the Source Code Control system. I always check the event log first (on the mid/app-tier).  Look for events in the application log with the source VSTF Source Code Control. If there are any, than supplying that data will help us determine what went wrong.

If there are no event log entries sourced by VSTF Source Code Control, check the system log for W3SVC entries around the same time. Even the ones marked information are important.

If there are no relevant event log entries, then make sure that the ServiceDefinition.aspx page permits anonymous access. It's supposed to be set during the installation. Use the inetmgr to view: Start, Run, Inetmgr (or start inetmgr from a command prompt). Open web sites, open VSTFWebSite, open SCC, open public, open application, RMB ServiceDefinition.aspx and look at properties, select the file security tab, select 'edit' on authentication (top-most item). Verify that the anonymous access is enabled.

If anonymous access is enabled for the page, check the properties of the web site using inetmgr.Open Web Sites and RMB on VSTFWebSite (I think that's the name). Check the
ASP.NET tab and make sure the ASP.NET version is 2.x or greater. If it's not 2.x, then the wrong version of ASP.NET is associated with the web site and Team Foundation will not work.

While you're looking at the properties, select the web site tab. Make sure that IIS logging is enabled, and select the 'Advanced' button. Note the log file directory at the bottom. This is the IIS log, if there are errors indicated here, than it's possible that the web service didn't receive the request from IIS. Normally, you'll see a pattern of calls with status 401, 401, then 200 (at the end of each line). Open the log file corresponding to the date of the failed installation (note the format of each file). There should be a line with a 500 that corresponds to the 500 internal server error that you saw earlier. There might be a 403 as well. This information is important to share when posting information about a problem.

There are many of us involved with Team System that also read the newsgroups on a frequent basis. By sharing your post there, others can possibly benefit.

Hope that helps -- let me know if something isn't clear.