Monthly Archives: April 2007


Since Brian Keller and Brian Harry requested me to test Configuring Visual Studio 2005 Team Foundation Server with Windows SharePoint Services 3.0, I came up with the following testing strategies to test all kind of options and see if it's still serviceable.

  • Team Foundation Server -> Upgrade WSS 3.0 -> Service Pack 1 -> Repair option Add/Remove
  • Team Foundation Server SP 1-> Upgrade WSS 3.0 -> Repair
  • Team Foundation Server SP 1 / SSL-> Upgrade WSS 3.0 -> Repair
  • Team Foundation Server SP 1 / FQDN -> Upgrade WSS 3.0 -> Repair

For the latter I wanted to use my own blog posts, but other people referred to me to use the FQDN post of Buck Hodges. Buck explains in just three points, for answering the question "Is there a way to configure TFS to use fully-qualified domain names (FQDN, e.g., for TFS, WSS, and Reporting Services?"  I asked myself the question "Could it be so simple?". The answer to this is NO. By the way I know the original answer was provided by Bill Essary (Software Architect for Team Foundation Server), so I don't blame you Buck 😉

I shall explain in this post why I like to request Microsoft to create a How To on MSDN. Maybe another great project for Brian and his team ;-). 
The post starts in the middle of setting up your server, because before you can use a FQDN you have to create one. To setup a FQDN and use this on a Web Site read my first post about FQDN. See

The post describes to use TFSAdminUtil for registering a FQDN. Although TFSAdminUtil is a great utility, it misses some parameters for ActivateAT. Microsoft thinks when you setup a FQDN, you will use this hostname for all three Web Sites (SharePoint, SharePoint Admin, Team Foundation Server). Personally I think you separate SharePoint and TFS and probably the Admin site as well (e.g., What does ActivateAT do and how can you use it. Mainly it changes everything below to be used for a single FQDN. I added some remarks to it. This way I want to show it is advisable to add some additional parameters to the TFSAdminUtil. (Suggested parameters: TFSAT, WSSAT, SSRSAT, WSSAAT.) I divided the tool in which actions it does to update TFS.

  1. Changes all address rows in the tbl_subcription table of the TFSIntegration database to use the new application server name. (All address rows uses links to the TFS web site)
  2. Changes all type 3 & 4 url rows in the tbl_service_interface table of the TFSIntegration database to use the new application server name. 

        A) ReportsService (SharePoint web site or separated Report Server web site)
        B) BaseReportUrl (SharePoint web site or separated Report Server web site)
        C) DataSourceServer (Why does MS changes this?, It would be better to use the NetBIOSName)
        D) WssAdminService (SharePoint Admin web site)
        E) BaseServerUrl (SharePoint web site)
        F) BaseSiteUrl (SharePoint web site)
        G) BaseSiteUnc (UNC path, so use NetBIOSName as well)

  3. Changes the value rows in the tbl_registration_extended_attributes of the TFSIntegration database to use the new application server name. 

        A) ATMachineName
        B) ATNetBIOSName

    These registration attributes are used by the TFSAdminUtil to determine if the user gets a question to change its Application Server.

  4. Restart IIS

The post continued to mention "After using the TFSAdminUtil you must update the registry for ReportServer and *.config of the Web Services and NT Services."

What are we missing here.

  1. As seen in my post you have to enable Reporting Services again to be used as a standalone server ( See
  2. If you upgraded to WSS 3.0 and I bet you did if your read Brian's blog, you must change the Alternate Access Mappings. See
  3. For some extra info about the Registry update and the *.config check some other blog posts:
    Hosting Team Foundation Server on a fully qualified domain name (FQDN)
    Hosting Team Foundation Server on a fully qualified domain name (FQDN) Part II
    Automatic Logon in fully qualified domain name (FQDN) environment

I hope I explained why it's so important to have a proper guide about how to setup TFS for a FDQN. Besides this Microsoft is delivering some tools which are great to use for a single FQDN, but since most of my customers want to use a separated FQDN for each Web Site, I'm not happy with it. Luckily most of the configuration are stored in the database, config's, and the registry so it isn't hard to find corresponding keys. I know Microsoft like to refer to TFSReg, but since I'm a data dude and the given connections configuration XML file on MSDN contains some rubbish (http://DTMachineName/ReportServer/ReportService.asmx [I prefer to use the ATMachineName], RosettaService/ReportService.asmx [doesn't exist], http://ATMACHINE:4554/_vti_adm/admin.asmx [wrong port number, talking about serviceable]) I update directly in the database.

Maybe it's a good moment to poll if people are interested in FQDN for TFS guide. Maybe you can post a comment, for requesting one.


Technorati tags: , ,


Since the time Jan beat me by delivering his Return of the SmartPart, I still get lots of request to complete my initial blog about dynamically loaded User Controls in SharePoint 2007 / ASP.NET 2.0 Portals. Keep in mind SmartPart is a great WebPart, but focuses completely on SharePoint. The WebPart even inherits from Microsoft.SharePoint.WebPartPages.WebPart and isn't what I found able to use enumerators. Besides this I like to complete where I once started and Microsoft is still not delivering an additional component which they once promised. See a blog of Scott Guthrie where he describes some info about whether it will be possible to host Web Parts built as ASP.NET 2.0 User Controls within SharePoint 2007.

The last time I stuck at part V which was al about the WebPart EditorPart, to select a UserControl from the "UserControls" directory. This part of the blog series focuses on discovering the properties of selected UserControl. In this blog I won't be bother you with big code screen but only with three small ones. All other code will be included as attachment, so you can read and investigate it. You can learn a lot of debugging code. Most of the ASP.NET 2.0 portals uses personalization, which can be setup with the aspnet_regsql.exe command. This command can be found at %WINDOWS%Microsoft.NETFrameworkv2.0.50727. After running this all portal users are able to store their settings of the given WebParts. I added the ability to store the properties of UserControl as well. To set and show the properties of a UserControl you can use the [WebBrowsable] and [Personalizable] attribute.

I divided the properties in three categories.

  1. String -> rendered as a TextBox
    private string _textField;
    [WebBrowsable(true), Personalizable(true)]
    public string TextField
            return this._textField;
            this._textField = value;
  2. Boolean -> rendered as a CheckBox
    private bool _boolField;
    [WebBrowsable(true), Personalizable(true)]
    public bool BoolField
            return this._boolField;
            this._boolField = value;
  3. Enumerators -> rendered as a ComboBox
    public enum Days
        Saturday, Sunday, Monday, Tuesday, Wednesday, Thursday, Friday
    private Days _enumField;
    [WebBrowsable(true), Personalizable(true)]
    public Days EnumField
            return this._enumField;
            this._enumField = value;

Most of my classes kept the same signature compared to the initial design. For a complete description of all classes their methods,  you can read the second post of the blog series.

Class Diagram

To use the UserControlWebPart assembly you must register it in your ASP.NET 2.0 portal application or populate it in SharePoint. A good guide to follow for populating the SharePoint WebParts Gallery is of Mart Muller. See It's based on Office SharePoint Server 2007 Beta 1 TR, but still do the job. After this you can use it in any of these apps as a normal WebPart. Your UserControls need to be in the "UserControls" folder of the application. When a UserControl contains a separate assembly file, you must place it in the "bin" folder of the application.

UserControl in ASP.NET 2.0 Portal and SharePoint using my own UserControl WebPart

As you can see in the image, I now have create my an UserControl EditorPart which customizes / personalizes a UserControl.

I did it again. This time it costs me several days instead of hours, because retrieving and storing the properties of user control isn't easy. Maybe somebody can confirm this ;-), it would encourage me to finish the blog series. The next part will focus on setting up connectable user controls by using the consumer / provider model of ASP.NET 2.0. Frankly I don't have a clue when I post this blog because I'm working on setting up TFS to run over SSL and off course about WSS 3.0 the MS way. To give everyone including the SharePoint Team the ability to start using this WebPart I included the sources and DLL in the post as well. If somebody has better ideas (e.g. AJAX) or want to help writing this code, send me an email.


1 Comment

This is one of my many posts about FQDN. Most people who followed the guides about setting up SSRS, WSS and TFS in FQDN environment, complained they have to log on each time when the connect to their sites. These sites are still intranet sites, but IE thinks otherwise. IE qualifies any FQDN as an Internet site. If you want to log on automatically to the Local intranet site, you can add the site to trusted sites of the Local intranet. Keep in mind if you changed the level or deselect the "Automatic logon only in Intranet zone" option this workaround won't work.

Open Intranet Options and select the Security Tab. After doing so select Local intranet and click the Sites button.

When the following display appears, select the Advanced button.

Add your portal URL (e.g., or

These simple steps help you to configure your Internet Explorer so you don't have to log on every time you want to access your portal.


1 Comment

Why you should host your TFS on a FQDN, I don't have to explain anymore. If you want to know how to configure this, read the following blog posts very carefully.

  1. Hosting Reporting Services on a fully qualified domain name (FQDN)
  2. Hosting SharePoint on a fully qualified domain name (FQDN)
  3. Hosting Team Foundation Server on a fully qualified domain name (FQDN)

One thing I completely forgot to mention in the last post is the Windows Services of TFS.

These services are very important for Data Warehousing, its reports and for Code Coverage Analysis. If you configured your TFS as I described in the FQDN posts, there is still one thing left.

Check your portal reports and look if the last Warehouse update was recently done. A regular report will contain a sentence like this.

Probably it is out of sync for quiet some time now. Most of the more experienced users of TFS updated their warehouse themselves by using the Warehouse Controller web service, which can be found at http://<SERVER>/Warehouse/v1.0/warehousecontroller.asmx. Just select Run and invoke its method. To get the current status of the web service select GetWareHouseStatus.

Another thing on which you can see your Windows services don't work the way their supposed too, is by starting the Code Coverage Analysis service. When this service is incorrectly configured it will display an error in the event log. The event log window will display an error like below. 

Open the configuration files of the TFS Server Scheduler and Code Coverage Analysis. Both can be found at

%Program Files%Microsoft Visual Studio 2005 Team Foundation ServerTFSServerSchedulerTFSServerScheduler.exe.config
%Program Files%Microsoft Visual Studio 2005 Team Foundation ServerCoverAnCoverAn.exe.config

Replace the URL key of the appsettings (Note: BisDomainURL can be replaced too, because it became obsolete in SP1. Now all configurations of TFS uses TFSNameUrl) .

<add key="TFSNameUrl" value="" />

Restart your services (Code Coverage Analysis, TFSServerScheduler) and at next interval the Data Warehouse will be updated again. The error shown above will also not occur again.

I apologize for leaving this out in my guides in the first place, but I hope all errors left are now solved as well. My next post will be about setting up TFS to run over SSL and off course about WSS 3.0 the MS way.


Technorati tags: ,

Update: My post Upgrade TFS V1 to WSS 3.0 Guide and Upgrade TFS V1 to WSS 3.0 round 2 - TFS SP1 became obsolete, because Microsoft is delivering their own guides on MSDN now. I even reviewed parts of this guides and tested everything on different machines with different settings.

You can find both guides at this link TN1501: Configuring Windows SharePoint Services 3.0 on the Visual Studio 2005 Team Foundation Server Application Tier or TN1502: Configuring Windows SharePoint Services 3.0 on a Remote Server to work with Visual Studio 2005 Team Foundation Server Furthermore you'll need an additional hot fix for your Team Explorer to connect to WSS 3.0 correctly. You can find more info about this at

Last Monday I read a post of Brian Keller about Configuring Visual Studio 2005 Team Foundation Server with Windows SharePoint Services 3.0. I wondered which posts he was referring to by reading "There are even a few posts in the community from people who have demonstrated how to get WSS 3.0 working with Team Foundation Server".

This morning I received a personal email of Brian explaining why he didn't mentioned mine name in the first place. He didn't want me to feel like Microsoft came along and discounted something that somebody in the community did because that's really not their intention at all. They are just trying to come up with a solution which enables WSS 3.0 but lets your TFS deployment remain serviceable.

I experienced myself that TFS is not serviceable anymore after upgrading to WSS v3 using my own guide. When I upgraded our TFS environment to SP1, it took me several hours to complete this job. TFS is really searching for a WSS 2.0 site and can't service a WSS 3.0 site. In another post I described my adventure and how I managed to make WSS 3.0 a bit more serviceable. See

This afternoon Brian Harry added a new post about this issue as well. See Configuring TFS to use Sharepoint 2007. He explicitly thanked me and requested me to give a taught about this solution. I like the idea, so the next coming weeks, when I have some spare time,  I will investigate and test this.

Knowing now that my own post was referenced I feel flattered and hope to help MS to publish their final document on MSDN. Maybe some day my dream about TFS will come true.



When an ASP.NET application is started it processes the web.config file. Doing so it is combined with all web.config files found up in the tree of virtual directories. Suppose I have a website located at and a w00t app like When the application is loaded by the web server the web.config of the root website is read as well. Even when the physical path does not have a tree structure at all. Luckily it reads the highest file in rang first, so if you want to change settings for the app all settings made in the root are overruled. Things get worse when an ASP.NET 1.1 app enters the stage. This will also try to process all files named web.config up in the virtual directory tree, regardless of their intended framework version. The real bad thing is that ASP.NET does not understand an ASP.NET 2.0 config file. The latter happened to me while installing SharePoint 2007 on a production server running several 1.1 apps.

After searching the Net I ran in some strange post of Microsoft. How to: Modify Configuration Settings for an Application to Coexist with Windows SharePoint Services. This post doesn’t work at all and is intended for WSS v2. However this post is released in the WSS v3 documentation. Shame on you MS.

So it was up to me to solve this problem. I changed the ASP.NET configuration settings to use ASP.NET 2.0 as it ASP.NET version. This way all settings in the web.config of SharePoint are now understood by my w00t app.

The only part left to do is add the lower statements to the web.config of the web application

<trust level="Full" originUrl="" />
  <remove name="PublishingHttpModule" /> 
  <add name="Session" 
<pages enableSessionState="true" />

This way the app will be fully trusted, except sessions and resolve a small error which will be added to the eventlog. For complete details about this error, browse to Unable to connect publishing custom string handler for output caching of Steven Van de Craen

Maybe it wasn’t a good idea to install SharePoint on a production machine without testing it, but you must dare to live. By the way, SharePoint and all apps works like a charm.