SBS 2003 Companyweb migration – Part 5

This is Part 5 in a series of migrating SharePoint from SBS 2003 to SBS 2011. Series posts are:

Introduction – Overview

Part 1 – Caveats and Considerations

Part 2 – Preparation steps on v2

Part 3 – Upgrading v2 database to WSS v3

Part 4 – Attaching upgraded database to WSS v3

Part 5 – Check WSSv3 for migration to Foundation 2010

Part 6 – Move database to SBS 2011

Part 7 – Post migration steps and considerations

In this part we are going to run a check to ensure that our original SBS 2003 Companyweb site (now in Windows SharePoint Services v3) will migrate to SharePoint Foundation 2010.

Prior to any upgrade from WSS v3 it is recommended that you run the stsadm –preupgradecheck from the command line.

To do this go to the command prompt as an administrator on the WSS v3 server. Change to the directory c:\program files\common files\microsoft shared\web server extensions\12\bin. At this location type the following command and press ENTER.

stsadm –o preupgradecheck

You should now see a number of checks being run on your system like so:

When the process is complete you will then see a HTML summary page displayed like so:

Scroll to the bottom of the page to see any errors like shown here:

It is recommended that you read the report carefully and note any warnings and errors as they may prevent successful migration.

Some errors may not be relevant. For example in screen shot above you will note that the error indicates that the system is not running on a 64 bit operating system. This will not apply in the situation where a migration to new hardware is being undertaken.

The –preupgradecheck option is only available on WSS v3 installations that have WSS v3 Service Pack 2 installed.

If everything looks good then you are ready to forklift the WSS v3 databases onto SBS 2011 and attach them to SharePoint Foundation 2010 which I’ll cover in the next part.

SBS 2003 Companyweb migration – Part 4

This is Part 4 in a series of migrating SharePoint from SBS 2003 to SBS 2011. Series posts are:

Introduction – Overview

Part 1 – Caveats and Considerations

Part 2 – Preparation steps on v2

Part 3 – Upgrading v2 database to WSS v3

Part 4 – Attaching upgraded database to WSS v3

Part 5 – Check WSSv3 for migration to Foundation 2010

Part 6 – Move database to SBS 2011

Part 7 – Post migration steps and considerations

In this part we are going to attach the migrated databases we attached to SQL to our staging Windows SharePoint Services v3 (WSS v3).

Adding database to WSS v3

Once the old SharePoint v2 databases have been attached to SQL Server the next step is to connect these databases to WSS v3.

Open a DOS prompt on the WSS v3 server via Start | Run | Cmd. Change directory to c:\program files\common files\Microsoft shared\web server extensions\12\bin and execute the following command to remove the existing WSS v3 database.

stsadm –o deletecontentdb –url http:// -databaseserver -databasename

for example:

stsadm –o deletecontentdb –url http://sharepoint3 -databaseserver VMSBS2003P -databasename WSS_CONTENT

Note, that if you are using the SQL Server 2005 Embedded Edition (SSEE##) that installs with the default standalone installation of WSS v3 you do not need to specify the database server. That is, you should leave out the option –databaseserver

Where http://sharepoint3 is the new WSS v3 created during installation of WSS v3, VMSBS2003P is the name of the WSS v3 Windows Server and WSS_CONTENT is the default name of the WSS v3 content database created during installation of WSS v3. If you have made changes from the default during the installation some of these vales will be different for you.

It is important to remember that this process will remove all the existing content from the WSS v3 site.

You now need to add the migrated SharePoint v2 databases that you have previously attached to SQL Server to the new WSS v3 site. The addcontentdb process will allow you to do this and automatically upgrade your SharePoint v2 data into WSS v3. Execute the following command to add the existing old SharePoint database to the new WSS v3 site.

stsadm –o addcontentdb –url http:// -databaseserver -databasename

for example:

stsadm –o addcontentdb –url http://sharepoint3 -databaseserver VMSBS2003P -databasename STS_VMSBS2003p_1

Note, that if you are using the Microsoft SQL Server 2005 Embedded Edition (SSEE##) that installs with the default standalone installation of WSS v3 you do not need to specify the database server. That is you should leave out the option –databaseserver

The upgrade process will vary on the size of the content databases and speed of your hardware. Eventually, you should receive a message telling you that the process completed successfully.

Once the process is complete, open the default WSS v3 site (typically just the http://server_name) on the WSS v3 staging server and confirm that the data is present and correct. You should see data from from your SBS 2003 Companyweb but now in a WSS v3 format.

In the next part we’ll commence the process to migrate to SharePoint Foundation 2010.

SBS 2003 Companyweb migration – Part 3

This is Part 3 in a series of migrating SharePoint from SBS 2003 to SBS 2011. Series posts are:

Introduction – Overview

Part 1 – Caveats and Considerations

Part 2 – Preparation steps on v2

Part 3 – Upgrading v2 database to WSS v3

Part 4 – Attaching upgraded database to WSS v3

Part 5 – Check WSSv3 for migration to Foundation 2010

Part 6 – Move database to SBS 2011

Part 7 – Post migration steps and considerations

In this part we are going to attach the SharePoint v2 databases we copied across from SBS 2003 to the version of SQL that comes with a standard installation of Windows SharePoint Services v3 (WSS v3).

Part of the migration process of Companyweb from SBS 2003 to SBS 2011 involves migrating to WSS v3 (and eventually to SharePoint Foundation 2010). This means you will have to install WSS v3 somewhere as a staging server. I am not to concerned about this here, as long as you have it running with the default setup you will be able to follow along. However, if was me, I’d be using a Virtual Machine of some form as my staging server for WSS v3 but I am not going to cover any of that. I am going to assume that you already have WSS v3 running in a default installation somewhere.

We need to get the Companyweb databases we copied from SBS 2003 attached to the version of SQL on our WSS v3 server. By default, the WSS v3 databases are stored on the system partition (C: drive) of the server and no graphical management tools are installed. It is however possible to manipulate the databases using the command line but a free graphical management tool is available from:

http://www.microsoft.com/downloads/details.aspx?FamilyID=c243a5ae-4bd1-4e3d-94b8-5a0f62bf7796&DisplayLang=en

It is strongly recommended that you install this application on your server to make working with the Microsoft SQL Server 2005 Express Embedded Edition (SSEE) easier.

Once the management studio has been installed on the server it can be accessed via Start | All Programs | SQL Server Management Studio Express.

Once the management studio is running you will need to connect to the Microsoft SQL Server 2005 Express Embedded Edition (SSEE). To do so use the following string in the server name field:

\\.\pipe\mssql$microsoft##ssee\sql\query

Once the management console has connected you should see an interface similar to that of other SQL 2005 server installations. The databases are located under the database folder.

By default the location of the Microsoft SQL Server 2005 Express Embedded Edition (SSEE) data on the WSS v3 server will be:

c:\windows\sysmsi\ssee\mssql.2005\mssql\data

and this cannot be changed during the installation process. In many cases, as the data held in the databases grows it may cause problems because typically C: is the Windows system partition.

Unlike Microsoft SQL Server 2005 Express Edition the Embedded Edition does not have a limitation on the size of a database, while the non-embedded edition has a maximum database limit of 4GB.

Attaching databases using SQL 2005

Locate the Database folder under the Server name.

Right mouse click the Database folder and select Attach from menu that is displayed.

Press the Add button to locate the SharePoint v2 database that you previously copied.

Navigate to the location on the disk in which you saved the copy of the original SharePoint v2 database. Select the MDF file (here STS_SERVER_1.mdf) and press the OK button.

Check that all the information now displayed is correct and when complete press the OK button to continue.

SQL Server 2005 will now attach the database. You should see the word Executing displayed in the lower left of the screen during this process.

When the process is complete, if you now examine all the databases listed under the Databases folders you should see your SharePoint v2 database (in this case STS_VMSBS2003P_1). Note, that you will also see the WSS v3 database (in this case WSS_content) that was installed during the setup of WSS v3. If you have not already taken note of what the WSS v3 database is you should do it now for later reference.

The next post will cover how to connect this migrated databases to WSS v3.

SBS 2003 Companyweb migration – Part 2

This is Part 2 in a series of migrating SharePoint from SBS 2003 to SBS 2011. Series posts are:

Introduction – Overview

Part 1 – Caveats and Considerations

Part 2 – Preparation steps on v2

Part 3 – Upgrading v2 database to WSS v3

Part 4 – Attaching upgraded database to WSS v3

Part 5 – Check WSSv3 for migration to Foundation 2010

Part 6 – Move database to SBS 2011

Part 7 – Post migration steps and considerations

I am going to assume that you have done your backups and updates on the source SBS 2003 server.

Pre-requisite

If you have enabled full text search on SBS 2003 Companyweb (by migrating the databases to the full version of SQL from MSDE) you will firstly need to disable prior to the migration.

Disabling Full Text Search SBS 2003

The easiest way to tell whether full text indexing has been enabled on WSS v2 is simply to view the WSS v2 site. To do this, simply open a web browser and type http://companyweb into the address. If full text indexing has indeed been enabled you will see the search box in the top right of the window.

Full text indexing on WSS v2 needs to be disabled prior to any migration.

To disable full text indexing on WSS v2 logon to the SBS 2003 server as an administrator and select Start | Administrative Tools | SharePoint Central Administration.

When the Central Administration site appears scroll down to the bottom of the screen.

Under the Component Configuration section select the Configure full-text search link.

You should now see a check box indicating that full-text search is enabled. Simply uncheck this box.

And press the OK button to save the new configuration.

After pressing OK the system will now process you changes and return you to the Central Administration site.

You can now proceed with the WSS v2 migration.

1. Ensure that http://companyweb is operational.

2. Download the prescan.exe utility from:

http://www.microsoft.com/downloads/details.aspx?familyid=e8a00b1f-6f45-42cd-8e56-e62c20feb2f1&displaylang=en&tm

and copy it to your SBS 2003 server.

3. Open a command prompt on the console and run prescan.exe like so:

At the command prompt type prescan /all and press Enter. The scanning tool will examine the existing SharePoint v2 databases and report if there are any issues that may arise when you attempt to migrate. When the process is successful close the DOS prompt. Note, that running prescan does not in any way affect the existing SharePoint v2 database operations, it does however make a minor change to the databases that is required prior to any migration. Thus, you need to run this prescan tool for the migration to succeed. So beware that a small change is made to the databases but this shouldn’t affect their operation in any way.

If there issues they will need to be addressed and resolved before you continue with the migration.

3. The next step is to stop the SharePoint v2 database service so that the existing databases can be copied to a new location. To do this go Start | Administrative Tools | Services.

Locate the service named MSSQL$SBSSHAREPOINT, right mouse click on the service and select Stop from the list that appears.

When this process is complete you should see nothing in the Status column for that service, this indicates that the service is not running. Close the Services window.

4. You now need to locate the original SharePoint v2 databases. Normally these will be located in :\program files\microsoft sql\server\MSSQL$SHAREPOINT. Typically, the files will be named STS__1.mdf and STS__1.log.LDF (in this case STS_VMSBS2003P_1).

Right mouse click on both of these files and select Copy from the menu that appears.

Move to the location where you wish the new databases to be located (on a WSS v3 server typically) and paste the files into that directory.

Once the databases have been copied they need to be attached to the SQL server associated with your installation of WSS v3. I’ll cover this in the next part of the series.

You can now restart the service named MSSQL$SBSSHAREPOINT on the SBS 2003 server so that Companyweb continues to operate. Remember though, if you make changes to the version of Companyweb on the SBS 2003 server AFTER you have copied the databases you’ll need to re-migrate to incorporate these changes.

This will be the last we’ll need from the SBS 2003 server.

SBS 2003 Companyweb migration – Part 1

Series Posts:

Introduction – Overview
Part 1 – Caveats and Considerations
Part 2 – Preparation steps on v2
Part 3 – Upgrading v2 database to WSS v3
Part 4 – Attaching upgraded database to WSS v3
Part 5 – Check WSSv3 for migration to Foundation 2010
Part 6 – Move database to SBS 2011
Part 7 – Post migration steps and considerations

If you are planning to migrate your Companyweb information from SBS 2003 you are going to be taking the long road I’ll tell you now. As I mentioned in a previous post there is not a simple way to move from Companyweb on SBS 2003 (SharePoint v2) to Companyweb on SBS 2011 (SharePoint Foundation 2010). The path you’ll need to follow is firstly a migration to Windows SharePoint V3 and then to SharePoint Foundation 2010.

So, before you even commence this process you should ask yourself whether all the migration effort is really worth it? In many ways simply copying over the data and starting a fresh maybe the most effective solution. You may lose some meta data but there are so many points along the migration path that can cause pain I would really recommend that you honestly ask yourself the question as to whether a migration is really going to worth the trouble? Start by asking yourself exactly what Companyweb on SBS 2003 is being used for.

When you are considering whether a migration is worthwhile you need to consider a few things:

1. If SharePoint is just being used a file storage location, then simply copying those files via Windows Explorer to SharePoint Foundation 2010 is probably a better bet since it effectively avoids the two step migration process.

2. If you have lots of lists and information other than files in your existing SharePoint then the most effective method to shift these is via migration. It is certainly possible to export and import lists to spreadsheets and then back into a newer version of SharePoint but if you have lots of lists then it is probably going to take too long to work through all the items. Conversely, if your site is only relatively small then exporting and importing maybe much easier.

3. If you lots of customizations to your existing SharePoint, by this I mean those done with a HTML editor like FrontPage, then I’d caution that migration will most likely be problematic. Likewise, if you added custom template and web parts then many of these will not survive the migration process and will most likely need to be removed/uninstalled prior to migration. That will al take time and generally break things.

4. If your SharePoint site is large (say >1GB) or is overly complex in its structure (i.e. lots of subsites) then migration is probably going to be more effective. The migration method basically involves detaching, copying and reattaching databases between SharePoint versions. If you have a lot of data then it is probably going to be much easier to do all this via a single file rather than trying to export and copy the data individually. However, beware of the default database limitations of Companyweb on SBS 2011 (10GB) because if your existing SharePoint data is already larger than this you are going to have to take appropriate steps on the destination SBS 2011 server to accommodate your data before you commence any migration process.

5. The migration process from SBS 2003 Companyweb is going to require the installation of a Windows SharePoint Services v3 (WSS v3) server. Where are you going to install this? On the SBS 2003 server? On a stand alone members server? On a virtual PC? To my way of thinking it really doesn’t make much sense to install WSS v3 on the existing SBS 2003 server simply because doing that isn’t straight forward. Do it wrong and you’ll screw up all your existing SBS 2003 wizards. For me the best bet is to use Virtual PC as a staging server to move the content to WSS v3. This provides greater flexibility (roll backs, snap shots, etc) as well as effectively costing nothing (Virtual PC is free to download, you can use a trail license of Windows Server will migrating, etc). It will also leave your source SBS 2003 server more or less untouched providing roll back if required. Whatever you decide you are going to need to install WSS v3 somewhere!

6. Are your backups working? If you plan to migrate part of pre-scanning process will make slight changes to the existing SBS 2003 Companyweb databases. I am yet to see a situation where this caused an issue BUT that doesn’t mean it couldn’t happen. Anytime you plan to make changes to the source during a migration you need to ensure that you can return it to exactly the way it was before you made changes. I’d always recommend you do a stsadm –o backup on your existing Companyweb site on top of whatever else you are doing to backup the database. An stsadm –o backup command gives you a single data file that can easily be restore to a blank SharePoint site which in my experiences provides a huge amount of flexibility.

With all this mind I’ll cover the migration process from SBS 2003 to a temporary WSS v3 server in an upcoming post.

Image: jacqueline-w

SBS Companyweb migration

Series posts:

So SBS 2011 Standard is now available and Microsoft has even released a document on how to go about migrating Companyweb from SBS 2003 and SBS 2008. You’ll find that document here:

http://technet.microsoft.com/en-us/library/gg563792.aspx

Rather than simply re-hash that document I’m going to do a series of blogs posts on general migration to the latest version of SharePoint. That means both SharePoint Foundation 2010 on SBS 2011 and Office365 in the ‘cloud’. So let’s start with a high level overview.

General

1. You can’t simply back up and restore Companyweb web from SBS 2003 to SBS 2008 or SBS 2011 for that matter.

2. Each version requires a conversion process to be run on the databases. Thus, from Windows SharePoint v2 on SBS 2003 to Windows SharePoint Services v3 on SBS 2008 the database requires an upgrade. Likewise, the same applies from Windows SharePoint Services v3 to SharePoint Foundation 2010.

3. If you want to jump from Windows SharePoint v2 to SharePoint Foundation 2010 you are going to have upgrade to Windows SharePoint v3, then upgrade to SharePoint Foundation 2010. There is no direct process. This means you will need a functioning Windows SharePoint Services v3 site somewhere during the migration to SharePoint Foundation 2010.

4. SharePoint Foundation 2010 on SBS 2011 is limited, by default, to a database size of 10GB (because it uses SQL Express 2008 R2). If you have content large than this you need to look at moving SharePoint Foundation 2010 to a commercial version of SQL (i.e. standard).

5. Some of the customizations and templates in each version may not migrate and in some cases may actually prevent migration. The general rule of thumb is that the less modifications you make to SharePoint the easier the migration. You’ll need to test for these customizations prior to migration to determine what changes may be required on the original site prior to the migration.

6. Tools such as SharePoint workspace 2010 will not be of assistance for a migration since they ONLY function with the current version of SharePoint (i.e. 2010).

7. You will need to re-establish things like search indices, PDF indexing, etc in the latest version (which can require very different configurations from the original version).

8. Beware of long filenames, blocked file types and filenames with special characters. They may not all be supported in the version of SharePoint you are moving to.

9. Make sure you have enough disk space on your destination server for the SharePoint databases as in most versions of SBS the default location for SharePoint databases is on the system drive (i.e. C:). Best practice is to relocate the databases before you start populating them.

10. There are a few different paths that can be taken for a migration but at the end of the day you typically want a site that is a combination of the existing blank site and you old content. This will means running a merge, which typically means you need to create an import file of your old data in a SharePoint 2010 format first.

From SBS 2003 to SBS 2011

1. You are going to need to ensure that SharePoint v2 on SBS 2003 is full patched. This means at least SharePoint v2 Service Pack 3 needs to be installed.

2. You’ll need to run the prescan.exe tool on SharePoint v2. This will provide you with any warnings that may prevent migration. Note that prescan.exe also changes the databases so that they can’t be upgraded WITHOUT running this tool.

3. Then you’ll have to install Windows SharePoint Services v3 somewhere (on the SBS 2003 box, another box or a virtual machines) and migrate the v2 databases there.

4. You’ll then need to run the v3 command:

stsadm –o preupgradecheck

and resolve any issues.

5. Finally you can migrate the databases to SharePoint Foundation 2010 on SBS 2011.

From SBS 2008 to SBS 2011

1. Again, you’ll need to ensure that SharePoint it totally up to date. Migration will not work unless certain minimum versions are met.

2. You’ll then need to run the v3 command:

stsadm –o preupgradecheck

and resolve any issues.

3. You can then migrate to SharePoint Foundation on SBS 2011.

To BPOS

1. BPOS is currently equivalent to Windows SharePoint Services v3 (like that on SBS 2008). So if you have anything prior you will need to bring the source content up to that level first.

2. You can’t do a database migration under BPOS so you’ll have to use a number of export and import mechanisms to get the content across. This will mean exporting lists to spreadsheets and databases. It will mean using SharePoint templates to save calendars. It will also means using drive mappings to shift data.

3. At the end of the day it is a very manual process and will most likely result in data loss. There are third party tools available, but in my experience they are not cost effective unless you are doing a lot of SharePoint migrations.

To Office365

1. When BPOS is upgraded to Office365 it will upgrade SharePoint from v3 to 2010 which generally means the content from previous versions (i.e. v3) will not migrate easily. This means that any content will need to be converted into 2010 format before it is imported into a 2010 site. That is why it is a good idea to move your SBS 2008 Companyweb data now into BPOS so when it gets upgraded to SharePoint 2010 your data will as well.

2. You can’t migrate a database straight into Office365 (is my understanding although powershell may allow this), thus you are going to have to use a number of import and export mechanisms to get the content across. This will mean exporting lists to spreadsheets and databases. It will mean using SharePoint templates to save calendars. It will also mean using drive mappings to sift data.

3. At the end of the day it is going to be a very manual process and will most likely result in data loss (from what I can currently see). There are third party tools available, but in my experience they are not cost effective unless you are doing a lot of SharePoint migrations.

Conclusion

There are plenty of issues I have glossed over here but hopefully this gives you some idea of what you may be up for during a SharePoint migration.

I’ll provide more details of each of these migrations over the coming posts.

Image: Kevin Eddy

New SharePoint options for SMB

So SBS 2011 Standard has been released and will soon make its way onto the servers of SMB customers (so they say). SBS 2011 Standard includes an on site version of SharePoint 2010. This version is SharePoint Foundation 2010, which is kind of the upgrade from Windows SharePoint Services 3.0.

Now SharePoint Foundation 2010 is a free download from Microsoft, which you could install on a Windows 2008 server without the need for SBS 2011 Standard. SharePoint Foundation 2010 also has a bigger sibling know as SharePoint Server 2010. SharePoint Server 2010 comes in two flavours, standard and enterprise both of which are really priced out of the market for SMB customers.

SharePoint Server 2010 enterprise has plenty of really great features including Access Services which allows you to host an Access database in SharePoint and using it through a web front end. It includes InfoPath services that allows you to host intelligent forms created with InfoPath on SharePoint without the need to have InfoPath installed on the desktop. Along the same lines you’ll also find Visio and Excel services. SharePoint Server 2010 also includes features like social networking so people can ‘like’ and rate results which improves their relevance to the organization. It includes something known as My Sites that gives each employee their own portal as a way of aggregating information about them and what they are working on. Finally, SharePoint Server 2010 includes a much improved and extended version of search.

Typically all this was out of the reach of smaller customers because SharePoint Server 2010 requires both server and client licensing, thus they settled for the reduced functionality in SharePoint Foundation 2010. But guess what? They don’t have to any more. Why? Because when Microsoft makes it’s latest version of cloud services available via Office365 customers can get access to almost the complete functionality of SharePoint Server 2010 for a few dollars per user per month.

Many of the projects I get engaged with are looking to develop an intranet using their SBS server. That’s great, and for some customers that will work well but when I speak to most customers about the benefits they receive from hosted SharePoint Server 2010 via Office365 combined with the reduction in administration, reduction in licensing complexity and so on, most are choosing to go with the online offering.

Until Office365 officially launches clients need to sign up with BPOS which is currently limited to Windows SharePoint Services 3.0 but they all see the benefits of getting on board sooner rather than later and can’t wait for the upgrade to Office365 to take place. Personally, I can’t either because it is going to give businesses of all sizes access to enterprise software for a few dollars per month per user.

Roll on Office365.

Upgrade or downgrade?

I’ve been testing the limits of SharePoint Designer of late as I work on an automated vacation calendar that I’ll be making available soon. If you didn’t already know, here are some interesting issues I have found with SharePoint Designer so far.

Firstly, you can only use the latest version of SharePoint Designer with the latest version of SharePoint. Thus SharePoint Designer 2007 only works with Windows SharePoint Services 3.0 while SharePoint Designer 2010 only works with SharePoint Foundation 2010. The same applies to the bigger SharePoint Server versions as well. So, if you are like me and need to work with both versions of SharePoint you need both versions of SharePoint designer installed on a machine. Couldn’t have the newer version supported the older version of SharePoint? I know it is completely new technology but….really?

Now, the thing that really has my nickers in a knot is the fact that Microsoft seem to have deprecated (read removed) a feature that I make extensive use of. In SharePoint Designer 2007 you can send an email as part of a workflow. Thus an email like this:

allows you to also embed HTML so that the result looks like:

This allows you a great deal of formatting flexibility to improve the presentation ability to end users.

BUT try exactly the same formatted email using SharePoint Designer 2010 and this is the end result:

that is, HTML is no longer rendered. What the hell? How come this was removed from a NEWER version of SharePoint Designer? I can’t see it being because of the newer SharePoint 2010 technology, because all it is doing is sending an email.

This makes it very difficult to format professional looking emails from SharePoint 2010 now doesn’t it? I find it interesting that Microsoft touts SharePoint Designer 2010 as the tool for creating workflows yet it removes this sort of basic functionality.

There are a few places on the Net where a potential work around is provided for this but that usually requires modifying the web server configuration files on the actual SharePoint server, something not generally possible on hosted SharePoint now eh? What’s the bet that isn’t enabled with the Office365 version of SharePoint when it becomes available either? (Pretty high I reckon).

So, the only solution seems to be to design with Visual Studio but that means I gotta go out and buy, install, and learn how to code before I can do something as simple as format an email!

Surely there has to be an solution to this, surely?