Windows SharePoint Services


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.



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.



Christmas do come early this year. The SharePoint team in Japan has just finished working on the next version of their popular team productivity application template, GroupBoard Workspace 2007. This is the first of the “Fantastic 40” Application Templates for Windows SharePoint Services 3.0 early next year

The GroupBoard Workspace template creates a space for a group or team to connect and share information in a collaborative environment, improving team efficiency and productivity. The template helps track team member whereabouts and status, and includes a built-in timecard list and organization chart. Meetings can be scheduled with attendees, and meeting rooms and other resources can be reserved. It also enables members to share phone messages and circulate memos.

Check out the following pics for some detailed info.


Time card


I repeat my first sentence by claiming Christmas do come early this year. I can't hardly wait till the other 39 Application Templates will be released.






For users who want to install TFS SP1 after this upgrade an update of this blog is available. In the new blog I explain how to fake a WSS v2 site on a WSS v3 server. For new users, first install TFS SP1 and then follow this guide for upgrading to WSS 3.0.

For users who want to install TFS in a FQDN (Fully Qualified Domain Name) environment I added some blogs how to setup an environment like this.

The last time I wrote an article about upgrading your TFS V1 environment to WSS 3.0, I got a lot of reactions. Some where good, some where not. Most of the complaints where about "Can't you write a simple upgrade guide.". I'm aware that my previous post wasn't clear enough and I didn't use any steps in it. So this is the first thing I gonna set straight in this post. The previous post was also to complex and you had to do to much manual steps (e.g. Don't upgrade, upgrade the content database, reconfigure Reporting Services, e.t.c.). Luckily I found out you can do an upgrade after all. Other complaints I got that I was changing the Process Guidance Templates which isn't the proper way. This part really frustrated me to, so I deep dived into Team Foundation Server and searched for the problem which prevent me for creating a new site from the Team Explorer. The good news is, I found it, and have two solutions for it. One is for all administrators of TFS and the other is for the Microsoft Team. One thing still stands as Brian Harry 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.". I can't do anything about it right now, because I and the most of you don't know which parts Microsoft will patch when they deliver 'Orcas'. Of course its advisable to backup your system and databases before you do any upgrade. Furthermore I recommend you to download the latest MSF Process Guidance. All points which have been carried by Jason Barile are refuted in this blog.

Install Procedures:

  1. Update Windows
    Visit Windows Update ( and install all items in the Critical Updates and Service Packs group.

  2. Install Microsoft .NET 3.0
    Install Microsoft .NET Framework version 3.0, which is a prerequisite for WSS 3.0.

  3. Change WSS v2 port
    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 a none existing port number (e.g. 9999).

  4. Install Microsoft Windows SharePoint Services 3.0.
    Select the default upgrade 'Yes, perform an automated in-place upgrade'.
    You should not change the default selections in any other feature areas.
    Click the Install Now button and accept the warning.
    Deselect Run the SharePoint Products and Technologies Configuration Wizard now and click on close.

  5. Pre-upgrade scan your WSS v2 sites
    Run prescan.exe /all from the command prompt.
    prescan.exe is located in C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12BIN.
    You must use the pre-upgrade scan tool to scan all Web sites in your environment to check if any errors exist before you perform an upgrade.

  6. Upgrade WSS v3
    Click Start, click Control Panel, click Administrative Tools, and then click SharePoint Products and Technologies Configuration Wizard.

    On the Configure SharePoint Central Administration Web Application page,
    check Specify port number: 17012 (Default port for TFS SharePoint)
    You should not change the default selections in any other feature areas.

    The wizard will now start 10 tasks to complete the upgrade in WSS.

    Update Fabrício Braz: We can't forget to emphasize that the SQL Server 2005 has to be set up to using both TCP/IP and named pipes for local and remote connections. Otherwise, the step 6 won’t work at all.

  7. Post-upgrade WSS v3
    When you hit Finish button the SharePoint 3.0 Central Administration site is opened and shows an upgrade status page in your browser at http://server:17012/_admin/UpgradeStatus.aspx. Please be very patient, because this post-upgrade could take quite some time. Check Step within the action compared to the Total steps in this action. When the upgrade status shows Finished, click on the Finalize Upgrade link, and click on the Complete Upgrade button.

    When the upgrade is finally finished you may configure your complete SharePoint Server (e.g Email, Search).

    Update Mike B: By default the account used for installing TFS only has permissions for creating new team projects. You can add other accounts by signing in at the http://{myserver}/default.aspx site with this account.

  8. Check your Reporting Server and WSS sites
    Open the reporting site in your browser at http://servername/reports.
    Open one of the team projects in your browser at http://servername/sites/teamproject.

    For sites that were customized in a Windows SharePoint Services-compatible design program in which the server administrator has chosen to keep the customizations during the upgrade, your home page will have the look and feel of the Windows SharePoint Services 2.0 site rather than the Windows SharePoint Services 3.0 site and will not include all of the Windows SharePoint Services 3.0 features. Site owners should consider discarding the customizations by using the Reset to site definition link on the Site Settings pages for those sites. (Caution: By doing this the MSF Agile look and all your report links will be removed.) This will give the customized pages the Windows SharePoint Services 3.0 default and uncustomized version of the page, including all of the Windows SharePoint Services 3.0 features. With e.g. SharePoint Designer, you can customize your Site Template again.

  9. Open Visual Studio Team Explorer to open your project using the new WSS v3 site.

You now have configured all your current project sites to use WSS v3. To create new Team Projects, you have to the following steps. These steps will not change any of your Process Templates and will not harm your TFS server in anyway. These steps will change the behavior of your WSS v3 site so TFS can communicate with it, like it's a WSS v2.

New project procedures:

  1. Add Process Template to the server
    Before you can use the WSS v3 to create a site, the template for the selected Process Template must be upgraded to a WSS v3 template, else you'll get the following error: "TF30267: Windows SharePoint Services version 2 templates are not supported in this version of the product."
    You can download a VSTS_MSFAgile.stp and VSTS_MSFCMMI.stp Template for WSS v3 here or you can create your own by doing the following steps.

    • Go to an upgraded site and save the site as Template by clicking on Site Settings.
    • Click on Save site as template.
    • Give the file and template the exact same name as which it is stored in your Process Template.
      You can find the site template name in the WssTasks.XML which you can open if you download the process from the Process Manager.
      For MSF for Agile Software Development -v4.x its VSTS_MSFAgile.
    • Download the file from site template gallery in the site and store it at C:

    Run stsadm from the command prompt to delete the WSS v2 template and add the WSS v3 template.
    stsadm can be found at C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12BIN

    stsadm syntax: stsadm -o deletetemplate -title <template title>

    For example: stsadm -o deletetemplate -title VSTS_MSFAgile

    stsadm syntax: stsadm -o addtemplate -filename <template file> -title <template title>

    For example: stsadm -o addtemplate -filename C:VSTS_MSFAgile.stp -title VSTS_MSFAgile

    Run iisreset /noforce

  2. Change the WSS Admin Webservice
    As soon as you try to upload a new Process Template or you want to create a new Team Project, you'll get the following error: "TF30162: The language id specified in the process template does not exist on the WSS server".

After a deep and thorough search, I found out the WssSiteCreator class of the ProjectCreationWizard calls a method VerifyLcidOnServer, which checks the LCID's on the WSS Server. This verification is done by using the GetLanguages method of the WSS Admin Webservice. This is where the problem comes in. In SharePoint v2 this method didn't return any XML namespace, so it was really easy to populate and to query with XPath. In SharePoint v3 GetLanguages returns a XML namespace, as it should be, like W3C recommends.

<Languages xmlns="">
Return GetLanguages WSS v2

<Languages xmlns="">
Return GetLanguages WSS v3

XmlNode xml = admin.GetLanguages();
XmlNodeList nodeList = xml.SelectNodes("LCID");
Current code MS Team is using for populating

XmlNode xml = admin.GetLanguages();
XmlDocument xmlDoc = xml.OwnerDocument;
XmlNamespaceManager xmlnsManager = new XmlNamespaceManager(xmlDoc.NameTable);
xmlnsManager.AddNamespace("mike", xml.NamespaceURI);
XmlNodeList nodeList = xml.SelectNodes("//mike:LCID", xmlnsManager);
Code MS Team should use for populating (This works for WSS v2 as for WSS v3) 


Because I don't have the sources of Team Foundation Server or WSS v3, I have to arrange something otherwise. In this code part I'll parse every method to the original Webservice except the GetLanguages method. In this method I'll copy all nodes and remove all the namespaces so the code of the TFS TeamExplorer will understand it. By doing this TFS thinks it's a WSS v2 machine. Maybe this solution isn't the best, but it works for me.

using System;
using System.ComponentModel;
using System.Collections;
using System.Data;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Web;
using System.Xml;
using System.Net;
using System.Security.Permissions;
namespace SharePoint.WebService
    /// <summary>
    /// Summary description for Admin
    /// </summary>
    [WebService(Namespace = "")]
    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    public class Admin  : System.Web.Services.WebService
        public string CreateSite(string Url, string Title, string Description, int Lcid, string WebTemplate, string OwnerLogin, string OwnerName, string OwnerEmail, string PortalUrl, string PortalName)
            AdminProxy.Admin spAdmin = new AdminProxy.Admin();
            spAdmin.Credentials = System.Net.CredentialCache.DefaultCredentials;
            return spAdmin.CreateSite(Url, Title, Description, Lcid, WebTemplate, OwnerLogin, OwnerName, OwnerEmail, PortalUrl, PortalName);
        public void DeleteSite(string Url)
            AdminProxy.Admin spAdmin = new AdminProxy.Admin();
            spAdmin.Credentials = System.Net.CredentialCache.DefaultCredentials;
        public XmlNode GetLanguages()
            AdminProxy.Admin spAdmin = new AdminProxy.Admin();
            spAdmin.Credentials = System.Net.CredentialCache.DefaultCredentials;
            XmlNode xmlNode = spAdmin.GetLanguages();
            XmlDocument xmlDoc = new XmlDocument();
            foreach (XmlNode childNode in xmlNode.ChildNodes)
                XmlNode targetNode = xmlDoc.CreateNode(childNode.NodeType, childNode.Prefix, childNode.Name, "");
                targetNode.InnerXml = childNode.InnerXml;
            return xmlDoc.SelectSingleNode("Languages");
        public void RefreshConfigCache(System.Guid VirtualServerId, bool AdminGroupChanged)
            AdminProxy.Admin spAdmin = new AdminProxy.Admin();
            spAdmin.Credentials = System.Net.CredentialCache.DefaultCredentials;
            spAdmin.RefreshConfigCache(VirtualServerId, AdminGroupChanged);
Code of the new Admin Webservice 


A Compiled SharePoint.Webservice.dll and a new admin.asmx can be found here.

To use these files you must open the Windows Explorer and go to C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12ADMISAPI

Unfortunately you must change the trust level of the SharePoint site to be able to run this Webservice on your machine. Open the Windows Explorer and go to C:InetpubwwwrootwssVirtualDirectories#### (Random number, ShartePoint Central v3 Administration)

    • Edit the web.config in the current directory and change its trust level.
    • <trust level="WSS_Minimal" originUrl="" />
      <trust level="Full" originUrl="" /> (Full with a capital F)

Open the Windows Explorer and go to C:InetpubwwwrootwssVirtualDirectories####bin

    • Copy the downloaded or self compiled SharePoint.Webservice.dll in the directory.

Update Bart Gunneman : You need to change the trust level, because you deploy your new asmx into the bin folder of this website. If you deploy it into the GAC it should not, in theory, be necessary to raise the trust level.

Open the original admin Webservice in your browser at http://localhost:17012/_vti_adm/admin_org.asmx
Open the new admin Webservice in your browser at http://localhost:17012/_vti_adm/admin.asmx

You now have upgraded your TFS configuration to WSS v3. Everything should work now, like it did before. So you can use all all the features in Team Explorer like Show Project Portal..., New Document Library..., Upload Document... and New Folder. But you could also create new Team Projects and down- and upload new Process Templates. The last step in this guide is to cleanup everything which is leftover by the installation of TFS.

Cleanup procedures (Extra, Not Necessary):

  1. Uninstall WSS 2.0
    Click Start, click Control Panel, and then click Add or Remove Programs.
    Microsoft Windows SharePoint Services 2.0

    When the program is removed click Start, click Control Panel, click Administrative Tools, and then click SharePoint 3.0 Central Administration. This will reconfigure your machine.

    Caution: After uninstalling WSS v2: Your security on the root web.config has changed

    Open the Windows Explorer and go to C:Inetpubwwwroot
    Open the security properties of
    Click the Advanced button and select Allow inheritable permissions from parent to propagate to this object and all child objects.

Update: Don't remove WSS v2, you'll need it for updates.

Reboot your system to make sure all changes are made successfully.

I have seen on some machines that after a reboot I also need to change the trust level of the SharePoint site itself, else the documents won't show up in the Team Explorer.

Open the Windows Explorer and go to C:Inetpubwwwroot

    • Edit the web.config in the current directory and change its trust level.
    • <trust level="WSS_Minimal" originUrl="" />
      <trust level="Full" originUrl="" /> (Full with a capital F)

To do a final test you could upload a new Process Template (Just download a template from the Process Manager. e.g MSF for Agile Software Development -v4.x and modify its name in the ProcessTemplate.xml)

My summary of the previous blog still stands and still hopes the MS Team will give us the support as soon as possible. Besides this I hope the most of you will test this Guide and help me to make it more complete. I only tested it on a TFS Single-Server, so maybe someone can test it on TFS Dual-Server as well. Furthermore it will be nice to test it on a clean machine, so TFS will do a full configuration of WSS v3. I'll test this the next coming week. Ok, there are some disadvantages (You must downgrade your trust level and do an upgrade of the Webservice), but compare to the advantages of WSS 3.0, at least give it a try. At my company we will use it too, so we can eat our own Dogfood. This way I guarantee you I'll deliver a guide for upgrading to 'Orcas' as well.

Update: This upgrade works for a single-, as a dual server installment. It's not possible to install TFS on WSS v3 from scratch.