Just like they did with SharePoint Services 2.0, Microsoft has released application templates for SharePoint Services 3.0, which can be found here.  And while you’re there, take a minute to read through the list of Server Admin Templates that are coming soon . . .  there’s several things in there that I can’t wait to get my hands on.

So far, the most exciting of the offerings is the GroupBoard template:

This single template has standard many of the most popular functionality requests that I’ve had from clients and end users over the last couple years, including:

*   In/Out Board

*   “While You Were Out” messaging

*   Resource Grouping / Organization Chart

*   Timesheets

Definitely worth taking a look at.

Ever since I blogged about my batch file to simplify the task of getting a PDF icon to display in SharePoint 2.0 document libraries back in October of 2004, it has been the single-most popular post on my blog (with almost 60,000 hits to date).  Well, ever since Windows SharePoint Services 3.0 was released, I knew that I needed to update my batch file, it just wasn’t quite at the top of the to-do list.  But now the wait is over – I have posted an updated package here. 

Here’s the details and caveats regarding these files:

*    The package (pdficon.zip) contains four files:  pdf.png (the pdf icon), docicon_v2.xml (the updated docicon.xml file for WSS 2.0), docicon_v3 (the updated docicon.xml file for WSS 3.0) and  pdficon.vbs  (the VBScript that makes our lives easier  )

*     pdf.png  is an updated PDF icon that is a little more current (basically, it doesn’t remind you of Acrobat 4.0 like the last one did)

*     This is one of my first VBScripts, and as such I didn’t get some of the functionality in there that I would have liked to.  Mainly, the script makes the assumption that your SharePoint installations were in the default locations (in C:\Program Files\…).  Secondly, it is not localized – it’s specific to an English installation.  If I actually get the time to learn some scripting, then maybe I can tackle those shortcomings.

*     What the script DOES do is install the PDF icon for both SharePoint 2.0 and SharePoint 3.0.  Basically, it looks to see if you have a docicon.xml file in the default WSS 2.0 directory.  If so, it assumes that WSS 2.0 is installed, it renames your existing docicon.xml file to docicon.old, copies the docicon_v2.xml file as docicon.xml to the WSS 2.0 XML directory, and copies the pdf.png file to the WSS 2.0 images directory.  It then does the same for WSS 3.0 – checks for the existence of docicon.xml in the default WSS 3.0 XML directory and if so, completes the required file operations.  If it doesn’t find the docicon.xml file in either location, it doesn’t do anything.  Finally, if it did find either WSS 2.0 or 3.0, it finishes up by doing an iisreset.

*     The script will notify you with a message box when it completes, and it also writes a log file to C:\pdficon.log

a.k.a.  –  Living on the Edge.  Just remember, there’s a reason it’s called the bleeding edge . . .    Here’s your warning:  In this post I am going to explain configuration changes I made to my own internal production environment to get http://companyweb to point to a new WSS v3 site.  This configuration is not supported by Microsoft or myself.  If you decide to try to replicate these settings in your environment, you are doing so at your own risk.

OK, let’s recap.  We’ve talked about the benefits of Sharepoint v3? Check.  We’ve talked about planning what we’re going to move, how we’re going to move it, and what we’re going to have to clean up after the move?  Check.  We’ve talked about prepping our environment so that WSS v3 search works?  Check.  We’ve talked about installing WSS v3 and accessing it via a common name?  Check.  Chad has warned everyone that just because he’s crazy enough to implement a non-supported configuration doesn’t me he’s recommending it or supporting it?  Check. 

First, it’s important to discuss why having http://companyweb point to your new WSS v3 web site is not supported.  As we all know, there is a decent amount of integration between the SBS wizards and our WSS v2 companyweb site.  Additionally, that integration is heavily dependent on DNS resolution to companyweb.  However, the key issue is with the integrated SBS setup.  If you find yourself in a position where you need to re-run SBS Integrated Setup and touch the Intranet piece, it’s going to try to access your WSS v3 site, and with the differences between WSS v2 and v3 – well, let’s just say it’s not going to be pretty and will break more than it fixes.

It’s important to note that I installed and configured my new WSS v3 site using the process I outlined in my previous post, and migrated all of my content over to my new WSS v3 site prior to making the changes mentioned below. 

So when I was looking at deploying WSS v3 and deciding if I wanted to tackle having http://companyweb resolve to a new v3 site, I decided that if I were to do this, I needed to leave myself a backdoor so that I could point companyweb to the original companyweb site in the event that I found myself needing to re-run SBS Integrated Setup and touch various intranet components.  Additionally, I wanted to be able to access the original companyweb site if need be after migrating everyone to a new v3 site. 

Here’s what I came up with.  First – I needed to configure the original companyweb so that I could access it using another name.  For my environment, I chose to use  http://companywebold  

1)   I started with adding the entry to our internal DNS so that companyebold resolved to the internal IP of our SBS.

2)   I flushed the DNS cache and verified that my SBS responded when I pinged  companywebold

3)   I opened Sharepoint Central Administration (v2) and clicked the link to Configure Virtual Server Settings

4)   I clicked to select the companyweb virtual server, then clicked to Remove Windows SharePoint Services from virtual server.

5)   I verified that the Remove without deleting content databases option was selected and clicked OK.

6)   I opened IIS Manager, and opened the Properties page for the companyweb web site.

7)   I added two new host headers to the companyweb site – companywebold   and  companywebold.domain.local    Both host headers were bound to port 80 on the internal IP of the SBS (not all unassigned).  DO NOT REMOVE the companyweb host headers at this point!

8)   I closed the Properties pages of the companyweb site and returned to Sharepoint Central Administration (v2).

9)   I clicked on the Extend or Upgrade virtual server link, then clicked to extend the companyweb virtual server.

10)  I clicked the option to Extend and Map to Another virtual server.

11)  I verified that the companyweb site was being mapped, and that the option to Use an existing application pool was selected.

12)  I verified that the DefaultAppPool was selected, then clicked OK.

At this point, I verified that both  http://companyweb  and  http://companywebold  resolve to the original WSS v2 companyweb.  The key piece to understand with SharePoint, is that the SharePoint configuration database has to know about the host headers that you’re using to access your Sharepoint sites.  You can’t just add another host header to a site in IIS and expect to get to your SharePoint site using the new host header.  That is why I removed WSS from the companyweb site, then added the new host header values (companywebold), then re-extended WSS to the companyweb site.  By doing so, the SharePoint configuration database picks up the host headers already defined for that site, and we are now able to get to the original companyweb site using either of our two host headers.  It is important that WSS v2 configuration database knows about both host headers.

Now, I was ready to make the switch so that my http://companyweb pointed to the new WSS v3 site – both internally AND externally     The key point to remember is that with WSS v3 we can have multiple web sites pointing to the same SharePoint application.  The first thing we need to do is change the Properties of the existing companyweb site.  

1)   I opened IIS Manager, expanded [servername], expanded [web sites], right-clicked on companyweb and selected Properties.

2)   On the General tab, I removed 444 from the SSL port, then clicked the Advanced button to edit the host headers. 

3)   I removed two host headers:   companyweb   and   companyweb.domain.local   then clicked OK to close the Advanced window, then clicked OK to close the companyweb properties page.

4)   At this point I closed IIS Manager.

This leaves the original companyweb in-tact, however right now I can only access it via the alternate http://companywebold URL I created earlier.  Now I was able configure http://companyweb to pull up the new WSS v3 web application:

1)   I opened SharePoint 3.0 Central Administration, and on the Application Management tab, I clicked on Create or extend Web application.

2)   I then clicked on Extend an existing web application

3)   Under Web application, I clicked Change web application then selected my WSS v3 web app (Sharepoint – 80)

4)   Under the IIS Web Site section, I selected the option to Create a new IIS web site, and entered companyweb new for the description

5)    I entered 80 for the port, and  companyweb  for the host header, then clicked OK.

At this point, I opened Internet Explorer and verified that http://companyweb opened the new WSS v3 site – yay!   But I still wanted to enable SSL so that I could access the Sharepoint v3 application externally:

1)   I opened SharePoint 3.0 Central Administration and on the Application Management tab, I clicked on Create or extend Web application.

2)   I then clicked on Extend an existing web application

3)   Under Web application, I clicked Change web application then selected my WSS v3 web app

4)   Under the IIS Web Site section, I selected the option to Create a new IIS web site, and entered companyweb – SSL for the description

5)   I entered 444 for the port, and my public FQDN for the host header (mail.mobitech.biz)

6)   Under the Security Configuration section, I clicked the option to Use Secure Sockets Layer (SSL), then clicked OK.

Now that I had created a separate web site for remote access, I just needed to add my SSL cert to the site.

1)   I opened IIS Manager, expanded [servername] and [web sites].

2)   I right-clicked on companyweb – SSL and selected Properties.

3)   On the Directory Security tab, I clicked the Server Certificate button.

4)   I clicked Next to start the IIS Certificate Wizard.

5)   On the next page, I clicked the option to Assign an existing certificate and clicked Next.

6)   I selected my SSL certificate, then finished the wizard.  (I had to check the SSL cert on my old companyweb to make sure I got the right cert)

At this point, I opened my web browser on a remote system and verified that I could access the new WSS v3 site via the public URL (https://mail.mobitech.biz:444) . . .   and then just to test, I also logged in to RWW and verified that I could access the new WSS v3 site by clicking on the Use my company’s internal web site link . . .   YAY!

Now – I have my new WSS v3 site accessible remotely via the normal companyweb URLs both internally & externally.  I can get to my original WSS v2 site via http://companywebold, and I can also get to the new WSS v3 site via http://intranet as well. 

The key here is that http://companyweb is registered in both the WSS v2 and v3 configuration databases.  So – if I find myself in a position where I need to recover my SBS server or some task that requires running a wizard that touches the Intranet portion, before I do so, all I have to do is stop two of my new WSS v3 sites (companyweb new and companyweb – SSL), then update the original companyweb site to include the original host headers (companyweb and companyweb.domain.local), and add 444 back in as the SSL port.  As a result, the SBS wizards will touch the original companyweb site (that they can work with), instead of the new WSS v3 site that the wizards can’t work with.  And if necessary, users can still access the new site internally via http://intranet.  When the wizards are done, I can reverse the process and be back to using the new WSS v3 site as my companyweb.

So far, the upgrade to WSS v3 has been well worth the effort – every day we’re finding new functionality and my users are liking it more and more.

Having said that, I want to reiterate that the configuration outlined in this post IS NOT SUPPORTED.  If you opt to duplicate this configuration in your environment, you are doing so at your own risk and realize that you will not get support from either Microsoft or myself 

Regardless, if you opt to deploy WSS v3 in your SBS environment either in a supported configuration (the first 4 parts of this series), or in an unsupported configuration as outlined here, some of your SBS integration is not going to work with WSS v3.  The big piece you’ll notice eventually is the Add User Wizard – when you add new users to your SBS, they will not be automatically added to your WSS v3 site – you will have to manually add your new users to the new site.

It’s time to actually install WSS v3 . . .   YAY!   So, if you haven’t done so already download the Microsoft document here and follow that step-by-step to install WSS v3 in parallel to v2 on your SBS.  Just do me a favor and stop after Step 3 (that’s right – forget about steps 4 & 5)

Here’s the deal – when the Sharepoint configuration completes, you have a new Sharepoint site set up that is bound to port 80 with no host header.  But this stops your default web site so the Sharepoint site can run.  The Microsoft document has you create a new Sharepoint application that uses a funky URL like http://servername:9971/sites/sitename – which isn’t exactly user-friendly.  So go ahead and follow the document through Step 3 and we’ll get this worked out so you have a user-friendly Sharepoint site co-existing with your default web site.

(insert cheesy on hold music . . . )

Ok, so now that you have WSS v3 installed according to Microsoft’s instructions (through Step 3), we want to be able to re-start the default web site (so things like OWA and RWW work), and be able to get to the new Sharepoint site easily.  For the purpose of this post, I’m going to use intranet to access the new Sharepoint site (although you can use anything you want (besides companyweb ).  The first thing you want to do is make sure that you can get DNS resolution to work for intranet.  So open your DNS MMC, expand <servername>, and expand Forward Lookup Zones.  Right-click on your internal domain name, and select New Host (A).  Create a new A record for ‘intranet’ that points to the internal IP of your SBS, then click Add Host:

Click Done then close the DNS MMC.  Open a command prompt and flush your DNS cache by running  ipconfig /flushdns  then ping intranet and verify that you receive replies from the internal IP of your SBS.

Next, we want to create a new web site that responds to the http://intranet host header and points to the existing Sharepoint v3 application you have already created.  Luckily, we can do this in one place – Sharepoint v3 Central Administration (Start | Administrative Tools | SharePoint 3.0 Central Administration). 

1)  Open SharePoint 3.0 Central Administration, and click on the Application Management tab. 

2)  Under the SharePoint Web Application Management section, click on Create or extend Web application.

3)  Click to Extend existing web application.

4)  On the page that opens, click on the Web Application field and select Change Web Application. 

5)  On the page that opens, select your SharePoint Web Application. 

6)  In the IIS Web Site section, select the option to create a new web site.

7)  Enter a description for the new site (e.g.  Intranet)

8)  In the Port field, enter 80

9)  In the Host Header field, enter   intranet

10)  Click OK.

Open your web browser and verify that http://intranet opens your new Sharepoint site.  Now we need to remove the web site that Sharepoint setup created. 

1)   Return to the SharePoint 3.0 Central Administration and click on the Application Management tab.

2)   Under the SharePoint Web Application Management section, click on Remve SharePoint from IIS WebSite

3)   In the Web Application section, verify that the web application is http://servername

4)   In the Deletion Options section, verify that the IIS Website is set to SharePoint – 80 (Default)

5)   Select the option to Delete IIS Web sites

6)   Click OK

So now, we have http://intranet resolving to the new Sharepoint site, and we’ve removed the site that SharePoint setup created.  Now all we have to do is start the default web site.  Open IIS Manager, expand servername and expand web sites.  Select the default web site and click the Start button.

Voila!  There you go . . .     In part 5, we’ll discuss the unsupported method of having http://companyweb resolve to this new site, and being able to access it through Remote Web Workplace as well . . .

This post is all about installing WSS v3 in parallel to WSS v2 on your SBS.  Now, the Microsoft provided documentation does a good job of walking you through this, but there a few things they don’t provide solutions to that you need to think about in advance.

First, I’m going to go out on a limb and think that you are probably planning on using the search functionality within WSS v3.  The nice thing about v3 is that you do not need full-blown SQL in order to get full-text search.  The down side is that if you upgraded your companyweb database to a full SQL backend to get search functionality, this breaks the search in WSS v3.  However, we can fix this – but it means that we aren’t going to have search on our WSS v2 sites.  If you’re like me where you’re moving everything to v3, this isn’t a big deal.  However, if you determine you need to keep full-text search on your v2 sites, or if you’re running SBS Std you can go ahead and skip this post 

(Edit:  There’s mixed reviews on just what does break search in WSS 3.0 as Susan mentions here. Short story is that we know search works if you’re running SBS Std.  We know search breaks if you upgraded your companyweb to full SQL 2000 Std.  What we don’t know is if search breaks if you upgraded your companyweb to full SQL 2005 Workgroup.  I’m going to try to find a box to sacrifice and test this scenario.  Until then – let me know what you’ve seen out there)

So here’s the plan:  In order to get full-text search working on WSS v3, we need to effectively downgrade our existing WSS v2 to use WMSDE instead of full SQL.  The high-level overview of this process is that we’re going to backup our WSS v2 site(s), remove the intranet component from SBS, uninstall the SHAREPOINT SQL instance, then re-install the intranet component and restore our WSS v2 sites.  Simple, right?

Step 1:   BACKUP!

I like to be extra safe with this, so I’m suggesting two backups of each site – one with STSADM and one with SMIGRATE.   An stsadm backup is great because it keeps all of our security, etc. in tact.  An smigrate backup is great because it gives us the flexibility of restoring to any machine running WSS v2, not just the machine the backup was taken from.   So, to backup your companyweb create a new directory somewhere on your server, with two sub directories –  stsadm and smigrate.  (On my server the directory I created was D:\wsstemp)

Open a command prompt and change your working directory to C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\bin

Enter the following command:

stsadm -o backup -url http://companyweb -filename D:\wsstemp\stsadm\companyweb.dat -overwrite

Be sure to replace D:\wsstemp\stsadm with your local path.  When that command is finished, you’ll run an smigrate backup from the same working directory:

smigrate -w http://companyweb -f D:\wsstemp\smigrate\backup.fwp -y

Again, be sure to replace  D:\wsstemp\smigrate with your local path.

Repeat this for each WSS v2 site you have.  You can store multiple stsadm backups to the same directory, as each stsadm backup is contained within a single file, just be sure to use a different file name for each site .  However, you will want to save your smigrate backups in a separate folder for each site, as the smigrate backup can be split among multiple files depending on the size of the site being backed up)

Step 2:  Remove intranet component.

Now that you have your WSS v2 site(s) backed up, we can remove the intranet component from SBS.  To do so, go to Add/Remove Programs and locate Windows Small Business Server 2003, and click Change / Remove. 

When the Small Business Server Setup Wizard starts, click Next until you get to the Component Selection screen.  On this screen, click the Action column next to Server Tools and select Maintenance.  Then, click the Action column next to Intranet and select Remove. 

Click Next and finish the SBS Setup wizard. 

Step 3:  Remove the Sharepoint SQL instance:

Once the SBS Setup wizard completes, you will return to the Add/Remove Programs window.  Locate the Microsoft SQL Server 2000 (SHAREPOINT) entry and click Change/Remove.  Follow the wizard to completely remove the Sharepoint SQL instance. 

Once you have successfully removed the Sharepoint SQL instance, close Add/Remove Programs and reboot your server.

Step 4:  Re-install SBS Intranet component.

After your server reboots, you are ready to reinstall the SBS intranet component.  This process is virtually identical to the removal process we went through in step 2.  The only difference is that when you get to the Component Selection screen, you will select to install the Intranet component, the finish the wizard.

Once the wizard has finished, verify that you can navigate to http://companyweb and that you get a new, stock companyweb site.

Step 5:  Restore your existing companyweb site.

At this point, our easiest restore is going to be using our stsadm backup.  Open a command prompt and navigate to C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\bin   then enter the following command:

stsadm -o restore -url http://companyweb -filename D:\wsstemp\stsadm\companyweb.dat -overwrite

Be sure to replace D:\wsstemp\stsadm\companyweb.dat with your local path and filename of your backup.  Once this completes, navigate to http://companyweb and verify that your original site is in-tact.

There you go – you have successfully downgraded your companyweb site from a full SQL backend to a WMSDE backend, which will allow search to function when you get WSS v3 installed.

a.k.a. – the migration planning stage 

You’ll note that the key word above is migration.  If you remember from the Microsoft document here, on SBS you’re going to do a parallel installation of Sharepoint v3, so that you’ll have both Sharepoint v2 and v3 installed.  And since we’re going to be migrating to a new site, we need to figure out what we’re going to move, and how we’re going to move it.

The first step to planning your migration is taking inventory of your current companyweb site.  What type of data is housed there?  If you’re storing files in your document libraries, have you added new columns to track metadata on the documents?  Are you keeping version histories on your documents?  If so, will you need access to those version histories after the migration?  What about custom lists?  Also, do any of your document libraries or lists have lookup fields referring to other lists on your site?  Besides the data itself, what about how the data is presented.  Do you have any 3rd party web parts you’re using?  Have you created any custom web-part pages to display your data?

It’s no surprise that if you’re using any 3rd party web parts in your WSS v2 site, you’ll want to check with the publisher to see if those web parts are compatible with WSS v3.

Next, you need to look at what tools you’re going to use to migrate your data from the old site to the new.  We can use Windows Explorer to move contents of our libraries (documents, photos, etc.).  But what about your lists?  Microsoft Access to the rescue!  You’ll need at least Access 2003 (but 2007 is preferred).  Both Access 2003 and 2007 an open Sharepoint lists so that they appear as an Access table.  If you have Access 2003, you’ll have to create your lists in your new site manually, then build an append query in Access to copy your list contents from your original companyweb site to the new WSS v3 site.   However, if you have Access 2007 you can take advantage of it’s Export to Sharepoint functionality.  Just open your original companyweb list in Access 2007, click on the Export to Sharepoint button (under the External Data ribbon), enter the URL of your new site and Access will create the list with the appropriate fields in your new WSS v3 site and copy the list contents over.

(Edit – Nick ever so graciously gave me a virtual smack up-side the head and mentioned SharePoint Designer 2007 (formerly FrontPage) for use in migrating your data.  DOH! talk about missing the obvious . . .  I’m going to blame it on sleep deprivation.  Anyway – if you have access to SharePoint Designer 2007 it has some very cool features to help with moving your lists & libraries) 

Finally, you need to be aware of what steps you’re going to have to complete manually on the new site – which is basically everything outside of moving your content.  You’ll need to recreate your permissions (adding users to the site, editing list / library permissions if you had done so on your original companyweb, etc.).  You’ll need to recreate any custom views you had created for your lists & libraries, and if you had any custom web part pages, you’ll need to verify those work as intended (especially if you had data view web parts linked together for filtering data).