Since almost everyone wanted to upgrade TFS V1 to use WSS 3.0, Microsoft added two guides to MSDN in which they explain how to update. In this guide I'll explain how to update your WSS 2.0 sites to use the newly delivered WSS 3.0 templates. This guide can also be used for people and companies who updated their TFS 2005 to a TFS 2008 / WSS 3.0 environment.


Take advantage of new WSS 3.0 functionality.
In order to best take advantage of new WSS 3.0 functionality on the new version of your team project portal sites you may wish to reset the site look and feel of your migrated sites to surface WSS 3.0 features. This step will optionally need to be performed on existing team project portal sites you have migrated from WSS 2.0, but will not need to be performed on new team project portal sites you create moving forward.

  1. Open the WSS 3.0 team project portal you would like to upgrade. (e.g. http:// myATserver:81/sites/MyTeamProject)

  2. Click Site Settings.

  3. On the Site Settings page, click Reset to site definition under the Look and Feel column.
  4. On the Reset Page to Site Definition Version page, you can choose to either reset an individual page within the site collection or to reset all of the pages within a site collection. Once you have made your decision, click Reset then click OK in the confirmation dialog.
    Note: As you will note in the warning dialogs, certain customizations to your team project portal will be lost after performing this reset. Therefore it is recommended that you take care to understand what functionality you need to retain in your team project portal prior to performing this optional reset.
  5. On the Site Settings page, click Top link bar under the Look and Feel column.
    Delete all links
  6. On the Site Settings page, click Quick Launch under the Look and Feel column.
    Remove all headings and links except those from documents
    Add The following headings and links
      • Heading -> Process Guidance
      • Heading -> Reports
      • Link -> Bug Rates
      • Link -> Builds
      • Link -> Quality Indicators
      • Link -> Project Velocity
      • Link -> Issues List
        _layouts/tfsredirect.aspx?IsReport=1&ReportName=Work+Items&rs:toolbar=true&rs:Command=Render&IssueParam=[Work Item].[Microsoft_VSTS_Common_Issue].[Yes]
      • Link -> Exit Criteria Status
        _layouts/tfsredirect.aspx?IsReport=1&ReportName=Work+Items&rs:toolbar=true&rs:Command=Render&IssueParam=[Work Item]. [Microsoft_VSTS_Common_ExitCriteria].[Yes]
  7. On the Site Settings page, click Master Pages under the Galleries column.
    Obtain the default.master (included with this release)
    Click Upload and browse for default.master
    Make sure you check Add as a new version to existing files.
  8. Replace the current CORE.CSS
      • Obtain the CORE.CSS (included with this release).
      • Open the uploaded default.master from SharePoint Designer and edit one of the CSS Properties. The confirmed customizations are reflected in the new local version of the style sheet, which is stored in a new folder named _styles that is created automatically in the Folder List of your site.

        MasterPage Editing

      • Overwrite the CORE.CSS in /_styles/ using SharePoint Designer.
  9. Add additional images
      • Obtain the VSTS images (included with this release)
      • Copy header_agile.gif, header_formal.gif, header_vsts_logo.gif and header-bg.jpg to  /_styles/. This can also be done using SharePoint Designer.
  10. As you can see in the picture below both the default.master as the core.css are unghosted and modified only for this site. These changes will result in a new look and feel for your TFS Sites.

    SharePoint Designer 

As many of you I updated my TFS sites to WSS 3.0. My newly created sites got a different look than the one I created before the upgrade. This is by design. MS will leave your previously created sites untouched and keeps the look and feel. With this guide you can change this behavior.



Stefan Goßner posted a great series of posts about the Content Migration API (formerly known as PRIME) for SharePoint (WSS 3.0 and MOSS 2007). In just 5 post he explains everything about this API and where SharePoint uses it. It's an excellent start point for many SharePoint administrators and developers out there. I also refer to this post in my training's about SharePoint as well.

If you want some other great info about migration check Replication and High Availability from Joel Oleson.



More and more people are migrating their Report Server environment to SharePoint. This migration will give you the ability to open your reports in SharePoint instead of just another UI. For a complete explanation on this migration check a previous blog of my at SQL Server 2005 Service Pack 2 (Integration between Reporting Services and SharePoint 2007). Before you can integrate between Reporting Services and SharePoint you have to decide if you'll setup a separate Application Tier. Almost all my customers have a similar setup as pointed out below.

SERVER 1 - Data Tier

.NET Framework 2.0

SQL Server 2005 SP2 (Database)

SERVER 2 - Application Tier

Internet Information Server 6.0

.NET Framework 2.0 & 3.0

Windows SharePoint Services 3.0

SQL Server 2005 SP2 (Reporting Services)

Reporting Services Add-in for Microsoft SharePoint Technologies

It's also possible to install all these products on one machine, but it isn't advisable. Reporting Services installs some Web Services and a Web manager (will be replaced by the Reporting Services Add-in for Microsoft SharePoint Technologies). After installation you can find all files at the Program FilesSQL ServerMSSQL.#Reporting ServicesReportServer directory. If you've installed al of the above products and updated it with the latest service packs and updates you can start the Reporting Services Configuration Manager. This tool can  be started for the Start menu at All Programs - SQL Server 2005 - Configuration Tools - Reporting Services Configuration. Depending on the choice of installation you will see a similar screen like this.


If some of the above sections displays a red cross mark fulfill these steps.

  • The Report Server virtual Directory should point to the web site where you installed and configured SharePoint.
  • The Report Manager Virtual Directory will become obsolete, so it isn't necessary to implement this step.
  • The Windows Service Identity is used under which the Report Server Windows service runs. The Report Server Windows service performs initialization, reversible encryption, database maintenance tasks, and all scheduling and delivery. The service runs in the background. It performs end-to-end processing for reports that run on a schedule (specifically, it creates report snapshots and runs subscription reports).
    Because it performs all encryption operations, the Report Server Windows service must be running whenever you specify or use encrypted values. Specifying stored credentials, running a report that uses stored credentials, and publishing a report to a report server (data source information is encrypted) are all operations that require the Report Server Windows service.
  • The Web Service Identity creates or uses a application pool under which the identity runs in IIS.

Now all steps are completed and Reporting Services is initialized you can start completing the last step to complete SharePoint Integration. Click on the Database Setup section and Change the Server Mode from Native to SharePoint Integration. After hitting the change button fill out the following screen and make sure the Create the report server database in SharePoint Integrated mode is selected. 


Type in new Database Name (e.g ReportServerWSS). Note. Don't start to create a database which starts with WSS because in some cases the connection will fail. After creating the database the SharePoint integration is completed.


Although it isn't hard to install and configure the add-in, it will give you a lot of steps to fulfill. First of all you have to make a decision about your server topology. Secondly you must setup Reporting Services to use you're data tier (remote or local). Third upgrade your database, so all content will be added to SharePoint and the rendering and caching stays in SSRS. In my next blog I'll explain how Activating SharePoint for Reporting Services works.


I wasn't blogging for a long time, but now I'm back with a strong rhyme.
Look, near the camera, snap my picture. I'll sign my name on it, then I get richer.
Like LL said don't call it a comeback and face the fact Jack I'm all that.

The last couple of months I spend a lot of time developing and giving courses. Like a few of my colleagues already posted on their blogs, I spent a lot of time on our Summer Classes . Check Update summer classes 2007 at and Summer Classes 2007 at for the details. My part in these classes was the developing an teaching the BI part. I had lots of fun with all my students and they appreciated my experiences as well. By the way these classes will be held again in January or February of 2008. See Class-A Summer Classes become Winter Classes at for full details.

Besides the BI part, I also developed a couple of our SharePoint modules. SharePoint is the reason why I was unable to post blogs for a long time. Our SharePoint courses SHAREPOINT 2007 DEVELOPMENT UNLEASHEDSHAREPOINT 2007 BI and SHARPOINT INSTALLING & CONFIGURING are almost every week sold out. I'm not surprised because SharePoint is HOT and other course provides can't deliver a training because the MOC (Microsoft Official Curriculum) material isn't available yet.

Here is some info about my next posts. More and more people are migrating their Report Server environment to SharePoint. I already received a couple of emails how to setup such an environment, but I never had the time to create a post. Today I received another mail requesting me to explain this. So my next posts will be about this subject. I'll divide this subject in three post.

  1. Post: Installing & Configuring the Integration between Reporting Services and SharePoint
  2. Post: Activating SharePoint for Reporting Services
  3. Post: Developing Reports for Reporting Services under SharePoint

I'll keep you posted.



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.


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.



This blog describes how you can setup your SharePoint Services environment using a FQDN. For a full explanation about what a FQDN is, you can read my previous post about Hosting Reporting Services on a fully qualified domain name (FQDN).

For this example I will modify the host file to use as a FQDN. On Windows-based computers, this file can be found in the systemrootSystem32DriversEtc folder. Trough Microsoft Internet Information Services (IIS) you configure the Default Web Site, so it's only accessible through This can be done by changing the default identification and adding the FQDN as a host header value.

After doing so, I open the my SharePoint Services sites using the FQDN. All WSS V2 sites works like a charm, but the WSS V3 sites gives me all kinds of errors.

SharePoint WSS V2 can run in host header mode. After installing WSS but before doing anything in the Administration pages, go to the command prompt and navigate to the Program Files/Common Files/Microsoft Shared/web server extensions/60/bin folder. Run the stsadm.exe tool to create the database using this syntax:

stsadm.exe -o setconfigdb -ds <database server name> -dn <database name> -hh

Once the configuration database has been created, you can then create the sites. Make sure the server's hosts file is updated to specify the domain names you would like.

stsadm.exe -o createsite -url -ownerlogin <domain><username> -owneremail <email address>

In this example I'm not interested in host header mode and a normal installation of WSS does not require this to run. This way its possible to approach all your sites on a IIS web site using a FQDN, after configuring the host header value in IIS.

Host header mode in SharePoint V3, allows you to create multiple domain-named sites in a single Web application. In Windows SharePoint Services version 2, when scalable hosting mode was enabled, you could extend only one Microsoft Internet Information Services (IIS) Web site. Now, with host header mode, you can have host header-based site collections on multiple Web applications, so you're no longer limited to extending just one IIS Web site. In fact, you can have a mix of path-based and host header-based site collections in the same Web application. In addition, you do not need to specify whether you want to use host header site collections when creating the configuration database. Instead, you can now specify whether site collections should be host header-based or path-based when creating the site collection.

stsadm.exe -o createsite -url -ownerlogin <domain><username> -owneremail <email address> -hhurl

This allows you to then host both host header sites and normal corporate mode sites on the same web application and same farm.

In this example I'm not interested in host header mode, but a normal installation of WSS does require some configuration steps to run. This way its not immediately possible to approach all your sites on a IIS web site using a FQDN, after configuring the host header value in IIS.

When I open in Internet Explorer and profiling my SQL Server, WSS V3 executes the following statement.

exec dbo.proc_getSiteIdOfHostHeaderSite @HostHeader=N''

This stored proc will give a result of 0, because SharePoint isn't configured to use this FQDN. To do so, open your Central Administration web site and change the Alternate Access Mappings of your Web Application. This option can be found under operations.

You can change the default URL to notify WSS or add an additional URL to the list.

When you finished doing the previous steps, SharePoint Services will function with a FQDN.

As you can see it's not that hard to use a FQDN with SharePoint Services, but you gotta know how.





I've just finished my guide about upgrading TFS V1 to WSS 3.0 and Microsoft immediately releases Service Pack 1 for TFS V1. This is good thing and I knew it was planned for half December, but I now have to write a second guide about extending your TFS V1 with SP1, while you already upgraded it to WSS 3.0. In the last blog I quoted Brian Harry who commented in my Blog "The last remaining issue that you may hit is when you try to upgrade to a future version of TFS. You may find yourself trying to hack your way through that too.". He was absolutely right, I had to do some stunts again. Most of the stunts are just faking your WSS 3.0 Team Site is a WSS 2.0 Team Site. The easiest way is to install SP1 before you upgrade to WSS 3.0. If so, my previous post still stands, otherwise read the steps below to continue your upgrade. Before you start upgrading your TFS its important to create a good planning for Backup and Restore. Just read this article about "Planning for Backup and Restore" on MSDN. This upgrade works for single- and dual server installments.


Visual Studio 2005 Service Pack 1 was released last Thursday.  Here are the direct download links.

and the two for TFS

If you want to slipstream those packs check the blog post of Heath Stewart on How to slipstream Visual Studio 2005 Service Pack 1. For Detecting Visual Studio 2005 Service Pack 1 and Uninstall Visual Studio 2005 Service Pack 1 Beta before Installing the Release he also got some interesting articles.

If you want to read about all bug fixes solved in TFS SP1, read the following blogs Bug fixes in TFS SP1 and Update on Bug fixes in TFS SP1 of Brian Harry

Workgroup Edition Error

Before showing you the way the go, I like to mention if you're upgrading your TFS with SP1 (which you should) and you're using the Workgroup Edition, there are some problems if the server already is using 5 Licensed Users. The error which will certainly strike is 28002 Error Unknown when installing the KB919156 (Quiescing GDR) fix.

To prevent this error, you will have to remove one of the users, upgrade your server and add the user back in the list. In this fix and SP1, MS tries to add the installing user to the Licensed Users list, even if the installing user is already a member of the list. Marcel de Vries, who already blogged about this error in TFS SP1 Beta1, asked if this error will be fixed in the final release of the service pack. But is seems to be an issue for the RTM of the Service Pack as well.

How to fake a WSS 2.0 on WSS 3.0 server

I've created 4 sections in which I describe the changes compared to a normal install. Both installers (Feature- and Service Pack) are checking if TFS is configured correctly on WSS. When all steps are done it will finally install the updates for TFS.

To retrieve the STS_Content database, it using the proc_getDatabasesWithServer stored proc of the STS_Config_TFS database which is obsolete in WSS 3.0. Run the the SQL statement below, and this check won't fail anymore.


CREATE PROCEDURE [dbo].[proc_getDatabasesWithServer]
      @DatabaseServiceId uniqueidentifier = null, 
      @VirtualServerId uniqueidentifier = null
) AS
      INNER JOIN Services ON 
            Databases.DatabaseServiceId = Services.ServiceId
      INNER JOIN Servers ON
            Services.ServerId = Servers.ServerId
            Databases.VirtualServerId = @VirtualServerId AND
            Databases.SiteCountLimit >= 0     

      IF @@ROWCOUNT = 0
            RETURN 0

            INNER JOIN Services ON 
                  Databases.DatabaseServiceId = Services.ServiceId
            INNER JOIN Servers ON
                  Services.ServerId = Servers.ServerId
            Databases.VirtualServerId = @VirtualServerId AND
            Databases.SiteCountLimit >= 0  
      RETURN 0

Because the WSS v2 site isn't active anymore you want the SharePoint Administration Tool to return the info about your WSS v3 site. This can be established by putting the SharePoint Administration Tool in the WSS v2 directory.

Open the Windows Explorer to copy the WSS v3 Administration Tool to the WSS v2 directory.

Open C:Program FilesCommon FilesMicrosoft Sharedweb server extensions60BIN
Rename stsadm.exe -> stsadm.exe.old
Open C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12BIN
Copy stsadm.exe to C:Program FilesCommon FilesMicrosoft Sharedweb server extensions60BIN

The next part I'll explain in the following section.

Open the Windows Explorer to create a dummy root folder for the Dummy Web Site.

Open C:Inetpub
Create a dummyroot folder

When installing the Feature- and Service Pack the web server is also requested to deliver some information to the installers. The first checks if the WSS v2 administration site is installed on the server, and if it's configured for port 17012. During my previous guide I reconfigured the WSS v2 admin site to use 9999 and the WSS v3 admin site to use 17012. Luckily the installers don't check if the server is actually running, so you can change it without stopping the WSS v3 admin site. The other check checks if the Default Web Site is running and if it can be extended. This last check isn't possible with our current Default Web Site, because this site is already extended to WSS v3. This is the part where my dummy site comes in.

Add a Dummy Web Site

Click Start, click Control Panel, click Administrative Tools, and then click Internet Information Services (IIS) Manager.
Stop the Default Web Site

Right-click on Web Sites and add a new Web Site using the Wizard.

Description: Dummy Web Site
IP Address: All Unassigned
TCP Port: 80
Path: C:Inetpubdummyroot
Permissions: Read, Run scripts (such as ASP)


Change WSS v2 port to 17012

Click Start, click Control Panel, click Administrative Tools, and then click Internet Information Services (IIS) Manager.
Right-click the SharePoint Central Administration folder and then click Properties.
Change the TCP Port to 17012 without starting the site.

Now having configured your server, you can install SP1 for TFS. Be sure al these screen will popup when installing the updates. You can also check your Add/Remove programs if the update succeeded. The update for the build will always succeed, because this update won't use TFS. 


When everything is installed correctly return to original state of you Web Server. So stop the Dummy Web Site and start the Default Web Site. The last thing you should do, is change the ports, so IIS can't make a mistake.

I showed you again, the it's possible to upgrade to WSS 3.0 and even install your Feature- and Service Packs afterwards. This is a good thing, so all you WSS 3.0 sites for TFS out there, keep on running. At my company we are using WSS 3.0 for TFS (dual-server), so we can eat our own Dogfood. This way I guarantee you I'll deliver a guide for upgrading to 'Orcas' as well.