Just another Microsoft MVPs site

Category: 564 (page 2 of 5)

SharePoint v3, Updates and 404 Errors

I think I figured out how I blew up my SharePoint on my test box a couple weeks ago.  I mentioned in my previous post that I blew up SharePoint while testing an upgrade scenario.  Of course, being a typical tech working on a test box, I was guilty of changing too many things at once – including changing the SharePoint config and applying patches.  I know, I know – whip me, beat me, and send me to my room . . .

I’m doing a little server consolidation here getting ready to move our servers in to a data center.  So I did a clean install of Windows Server 2003 R2 on what is destined to be my new web server.  I proceeded to get SharePoint, SQL, and all of my other stuff installed, then updated the box via Microsoft Update.  About 50 updates (including Win2k3 SP2 – yes, I am a glutton for punishment) and a few reboots later, the server was fully patched and humming right along.  I opened SharePoint 3.0 Central Administration and after a few seconds was presented with a nice 404 Page Not Found error.


I verified my services were running, then went to check out the Event Viewer.  In the Application Event Logs, I saw a slew of SharePoint errors with Event ID 5586 with details about being unable to connect to the database.  Looking up this error on EventID.net, there wasn’t much there – and I wasn’t particularly keen on running psconfig -cmd upgrade -force and then uninstalling / reinstalling SharePoint.

Googling on “SharePoint event id 5586” wasn’t very helpful either.  I encountered a number of threads that all referenced the hotfix from KB 932091 not installing correctly, and recommending extracting the update and manually running it again.  I had tried this a couple weeks ago on my test box to no avail, and found several others in the threads that this didn’t work for.  Just to be safe, I tried it again on this box, but it still didn’t work.

One difference with this server is that I am actually running full SQL 2005 (instead of SSEE on the test box), so I could access my database via the SQL Management Studio.  When I opened the Management Studio and attempted to connect to my database instance, after a long pause the Management Studio threw an error that it wasn’t able to connect to the database instance – I discovered I received the error whether I was trying to connect via Windows or SQL Authentication, which was an interesting tidbit of information I hadn’t found when troubleshooting the issue on the test box with SSEE.

On a whim, I decided to check the SQL Client Configuration – since I remembered seeing something similar in the past with Microsoft Retail Management System when it couldn’t connect to the database.  I went to Start | Run and   cliconfg  

This is what your cliconfg should show:


This is what cliconfg showed on this server:


I enabled TCP/IP and Named Pipes, then selected “Enable shared memory protocol.”  After clicking OK and rebooting – Voila!  SharePoint is back in business and SQL Management Studio can connect to my database instance via both Windows and SQL Authentication.

I’m not sure which update broke this, but considering in the course of 3 reboots I MU’d approximately 50 updates (including SQL2k5 SP1, 932091, and Win2k3 SP2) – it’s hard to know exactly what disabled my SQL client protocols.  But it was an easy fix, and it’s working now – so I’m happy  smile_regular

Moving a WSS 3.0 site to a new farm

If you haven’t heard already, I am going to be at Jeff Middleton’s SMB Disaster Recovery Conference in New Orleans at the end of this month, and at some point during the weekend I will be discussing Windows SharePoint Services in the context of Disaster Recovery – not only how to recover from a SharePoint disaster, but how SharePoint can be a valuable technology in the face of a true catastrophic disaster.

Well, it just so happens that I have had my own little SharePoint disaster on my hands.  A little over a week a go, I was testing a SharePoint upgrade scenario on my web server and proceded to blow up WSS 3.0 on that box.  The good news was that I had a disaster to fine-tune my recovery skills.  The bad news?  Being a bit lazy I actually had a production SharePoint site on that server (oops smile_embaressed  )   Luckily, the production site was non-critical (just the site for my family – and while they’re used to me blowing things up, I really didn’t want to have to mess with recreating that site and it’s 20GB of data).  And I’ll also admit that I was slightly behind on my SharePoint-based backups for that site as well – far enough behind that I really didn’t want to have to go that far back if I didn’t have to.

I’ll admit that I’m not making much progress with repairing the WSS installation on the web server – I’ve tried just about everything, and it looks like I’m going to break down and call PSS to get it working again, assuming I don’t just re-install.  Naturally, the only thing holding me back was this one site that I really wanted to salvage.  Well I’m happy to say that after some trial & error (and the help of Google), I have the site up and running on a separate SharePoint farm – and it was actually quite painless.

First – for the sake of clarity, I’m going to talk about this process in terms of moving a site to a different SharePoint farm, for the simple fact that we can have multiple front-end servers running SharePoint in a single farm, and moving a site to different servers in a single farm is a separate process.  Most SBSers are going to be running a single server farm, and as such will often talk about moving a site between servers, when they’re really talking about moving between farms. 

So to accomplish this task, here’s what I did:

1)  On the database server for the current farm, I performed an offline backup of the content database for the site I wanted to move.  (Easiest way to accomplish this is to stop your SharePoint database service and copy your .mdf & .ldf files).

2)  I restored the .mdf & .ldf files for the content database to the SQL data directory on the database server for the new farm.

3)  I attached the restored database to the SQL instance for the new farm.

4)  On the new farm, I opened SharePoint Central Administration.

5)  On the Application Management tab, I created a new SharePoint Application.  In doing so, I created a new web site that used the same port and host header the site on the original farm used.

6)  When the application creation process completed, I did not run the Site Collection Creation Wizard.

7)  Within SharePoint Central Administration Application Management tab, I clicked on Content Databases.

8)  I verified the Web Application, then clicked on the content database (which should be an empty content database created during the Web Application creation process)

9)  On the Content Database Settings page, I changed the database status from Ready to Offline, clicked to select the option to Remove Content Database and clicked OK.

10) Back on the Manage Content Databases page, I verified the web application then clicked Add a content database.

11) On the Add Content Database page, I entered the name of my SQL server where I attached my restored database, as well as the database name.  I verified Windows Authentication was selected, selected the appropriate Search Server, and clicked OK.

12)  Once that process finished, I was returned to the Manage Content Databases tab and could see that the restored content database was now associated with the web application I had created minutes earlier.

13)  I edited my local hosts file so the URL of my site would resolve to the local server

14)  I opened a command prompt and ran an iisreset, then ran an  ipconfig /flushdns, then pinged my site URL to verify it resolved to the local server.

15)  I opened Internet Explorer and browsed to my site – and voila! there it was smile_regular

So in the big picture, what is the big deal here?  The significance is that with WSS 3.0, you can actually restore one or more SharePoint web applications to a new farm with nothing besides a file-level backup of your content database.  And if you ever tried accomplishing the same feat with WSS 2.0, you can appreciate just how significant this functionality is.  Don’t get me wrong – this isn’t going to be the preferred method (I still recommend you take a look at native backup/restore functionality either from within SharePoint Central Administration or via the command line using stsadm.

New York, New York!

Ok gang – just a quick heads up that due to a twist of fate, I am going to be presenting on SharePoint at SMB Nation East this weekend.  There’s still room if you haven’t signed up yet.  I’ll be doing a deep dive on SharePoint 3.0 – and this will not be death by PowerPoint – but live demos.

Did you know that for all of our customers who have upgraded to Office 2007, SharePoint 3.0 has been the driving force and single greatest factor in selling those upgrades?  I’ll show you why – this Friday at 1:30pm smile_regular

You do know about GroupBoard?

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.

PDF Icon Update

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 smile_regular )

*     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

Companyweb & Sharepoint v3 – Part 5


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  smile_regular   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  smile_regular

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.

Companyweb & Sharepoint v3 – Part 4

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 smile_regular).  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 . . .

Companyweb & Sharepoint v3 – Part 3

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 smile_regular

(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 smile_regular.  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.

Companyweb & Sharepoint v3 – Part 2

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).

Companyweb & Sharepoint v3 – Part 1

This is the first in a short series of running Windows Sharepoint Services v3 on your SBS 2003 / R2 server.

First the caveat:  Upgrading and/or running your companyweb site with Windows Sharepoint Services v3 is not supported – neither by Microsoft nor myself.  Just because I’m blogging about it doesn’t mean I’m supporting it.  Microsoft does support installing WSS v3 in parallel with v2 on your SBS – but only supports the companyweb site running as a WSS v2 site.  Microsoft’s official document on installing Windows Sharepoint Services v3 on SBS can be found here

What’s the fuss?

The first thing to talk about is why you want to move up to WSS v3.  Being a long-time Sharepoint junkie, there are some impressive features in v3 that address many of the complaints and wishes we all had with previous versions.  The key items:

Recycle Bin    All most WSS admins can say is FINALLY!  No more juggling with multiple stsadm or smigrate backups to allow for individual item restores.  And when you need to restore, no more needing to restore those backups to parallel sites.  Granted it worked – but was cumbersome and painful.   WSS v3 gives us a dual-layer Recycle Bin.  Each user gets their own Recycle Bin which allows them to easily recover anything they may have deleted (a document, a photo, or even a list item).  In addition to the individual user recycle bins, there is a site-level recycle bin as well.  So even if your users delete something from the site, and then empty their recycle bin only to come to you the next day to ask if there is any way of getting that item back – well now there is.  The administrator can access the site collection recycle bin and restore items that users have deleted even if they have deleted their recycle bin.  This is configurable so you can specify how long you want to keep deleted items in the recycle bin, so you don’t have to manually empty the site collection recycle bin.

Offline Access to Document Libraries     Yes, you read that right.  So you’re finally getting your users to store their documents on your Sharepoint site – but you’ve still got those roaming users who are keeping files on their laptops so they can have access to them anywhwere, even if they don’t have an internet connection.  Well now you can have the best of both worlds.  With Outlook 2007 and WSS v3, you can now keep a copy of your document libraries within Outlook – so your users can have offline access to their Sharepoint files.

Mobile Access.     Do you have users who are out of the office a lot?  Do they have internet-enabled phones?  WSS v3 includes a mobile page format optimized for web-enabled PDA’s & smart phones – which presents an experience somewhat similar to OMA.  Regardless, you can now access your Sharepoint site, including documents and lists right from your phone.  I only migrated our companyweb a few days ago, and I’m already finding myself taking serious advantage of this mobile access on a regular basis.   

Tighter integration with Office.     WSS v3 and Office 2007 are a match made in heaven.  With WSS v2 & Outlook 2003, we could link Sharepoint calendars and contact lists with Outlook.  However, anyone who used this functionality realized this was a one-way connection:  you could only view the calendars and contacts in Outlook.  Any additions or changes had to be made via the Sharepoint web interface.  Not any more – with WSS v3 and Outlook 2007, you have full two-way integration, allowing you to add/edit appointments or contacts from either the Sharepoint web interface OR from within Outlook.  And an added bonus – if you delete a Sharepoint contact or appointment from within Outlook, it actually gets sent to your Recycle Bin within Sharepoint.

Improved Versioning.     WSS v2 allowed us to keep versions of items stored in document libraries.  WSS v3 allows us to keep track of both major & minor versions within document libraries, and even allows us to keep track of versions of list items.  So you can now see version histories within your lists, and just like with document libraries, restore any previous version at any time.

Improved Security.     WSS v3 gives us true item-level security on documents and even list items.  So for you somewhat Draconian admins out there, you can control what your users can see, change & delete at a granular level.

There’s a lot going on with WSS v3 – both on the surface and under the hood.  So far our migration has met with positive results from our users – it’s cleaner, quicker, and just flat out prettier.  But now that you know why you want to migrate, in the next segment we’ll address how to plan such a migration and what gotchas and pitfalls to avoid. 

Older posts Newer posts