SharePoint migration from WSS3 to WSS4

Vince

Vince

Vince

Man of Honour
Joined
30 Oct 2003
Posts
13,803
Location
Essex
Hi All,

I am currently in the planning stages of a migration from WSS3 to WSS4, moving from a 2003 32bit server to a 2008 WSS4 64bit farm.

The current environment has custom code compiled for 32bit so I know I will need to recompile my code for 64bit and there are several web parts that will need to be re-writen.

My question though is this, has anybody been through a migration from wss3 to 4? If so are there any major pitfals that I should look out for or any major, or minor issues that you came across that may help while planning my migration?

Thanks in advance.
 
Hi,

What methods are you planning for your upgrade? Inplace or using the DB Attach method? I think you can do a combination of each but there are pros/cons for each.

One of the things to look out for is the new v4 masterpages on your sites. You can choose to keep the older masterpages but v4 is the newer standard. If you haven't done any personalisation then I don't think this makes any odds.

You probably know about the defined migration paths i.e. going from WSS3 32-bit to 64-bit and then to WSS4 64-bit. You cannot migrate directly from 32-bit to 64-bit (v3 - v4).

I haven't done a migration myself but covered some of this in training for the 2010 version.
 
Hey I am going to leave our current site live and take a copy of the content database and migrate that up to wss3 64 bit. Following that I am going to use the db attach method.


As it stands we have some pretty heavy customisations but these are mostly code projects installed to the GAC as DLL's in the guise of event handlers for specific lists, library’s, handling of permissions etc. As for front end personalisation we are pretty standard but do use the corporate logo, dropdowns for navigation which is a code edit to the master page and the rest is a basic re-skin with our corporate colours.


I am familiar with the defined paths for migration so have planned for this, I guess with any migration you can always plan for the known but the unknown is what worries me. Going from wss2 to wss3 caused all kinds of trouble as did a straight move from a WSS3 cloud to a colocation (this was due to all kinds of issues with the differences in config from the cloud to our domain). Needless to say all users etc needed to be remapped with stsadm after we finally got our new environment up and running and more importantly accepting the content database. Anyway I digress, the thing that im not sure on and to be fair it was vague and slightly buggy in WSS3 is FBA.


We use FBA to provide a way for our clients to log into their document library, they log in and a bit of code then works out which sp group they belong to and redirects them to their library. Quite how FBA is implimented in 2010 is still a bit of a mystery to me. This is mainly as I haven't had a whole load of hands on time with it in my test environment or any formal training :S
 
Sounds like you have the whole thing sussed. I don't do much on the development side so might have to call for some help in a day or two writing some authentication provider stuff!
 
No problem, we use seperate authentication providers to divide up our local users (those with auth provided by AD) from our web users who log in via our corporate site and whos auth is provided by FBA. I find that there are plenty advantages but mainly this allows me to give different URL's internally to externally which aids in monitoring, these seperate auth providers also allow much easier management of groups and permissions for those groups.

Since using seperate auth providers I also had this idea of creating groups and assigning permissions "on the fly" via code for new clients. This works when we convert a lead to a client, there is a workflow in place which upon running (when a lead status is updated to won) copies the lead details into a new client record. Attached to a client list there is a event handler which fires upon "Item added" the code goes away and sets up a document library based on the client name (using elevated privilages for those that don't have the authority to perform the action) it then loops through and creates default folders in the document library, sets up the librarys versioning settings and assigns permissions for users and a new client group that it creates. All I have to do then is assign FBA users to that group for client login to work. Again I digress but would be happy to help and share code etc.
 
That sounds pretty sweet setup. I have covered some stuff about event handlers on courses etc but would struggle to put something together!

Would be interested to hear back about your progress on the wss3-4 migration.
 
Ill keep you updated I am currently waiting for some new kit to be doployed in the DC, we are updating several bits of kit we have over there as to be honest it is starting to show its age.

Today we are installing a new raid array for the sql databases, Friday evening we will install the new cisco firewall and reconfigure the p2p VPN and domain trust to allow authentication against our AD here in the office.

Following the hardware config we should be getting on with the migration starting next week. The plan dictates that we should finish and go live by late September but this could be as early as the beginning of Sept if everything goes nice and smooth. Ill update this thread from time to time with anything I discover.

To be honest I would also love to be deploying office 2010 at the same time but I currently have 50 laptops out there with biometric devices and for some reason on the machines I have tried I am still unable to configure office (outlook) in cached exchange mode. This has been since release and I still cant make it happen, it just freezes, turn off cached exchange mode and exchange will work. Bizzare....
 
Ok so I thought that I would send out a little update to this... I have now been working on the migration for about a month (on and off) and am just finishing off.

The one thing that is noticable with the change is that the masterpages in 2010 foundations are much more tied down than they were in wss3, for example, in wss3 you could emulate MOSS navigation with a quick change to the "topnavprovider" essentially allowing dynamic dropdown menus with ease. In 2010 the same is not true. It appears that ms are spending more time on differentiating the foundations product from the full server product and making it harder to emulate the look, feel and features of the full Server product in the free foundations product. To do this it appears that they have tied the navigation providers deeper into publishing infrastructure (a feature not available in 2010 foundations), I thought that this was going to be a big problem, that was until I realised that we could probably use ajax to build a new nav menu or just overide the current one with a new nav provider (work in progress here) however for the time being I have reverted back to the WSS3 masterpage and we are going to do our first release on this.

Moving on everything else has been pretty easy, granted I stumbled across changes in the object model that meant my custom code had to be modified to work on the new environment, these changes included moving base events to their own method, changes in the syntax for event firing and the disabling of as well as configuring myself a new deployment method (for some reason my old custom app just doesn't seem to be doing a decent job anymore).

Ok on to FBA, if you are currently running alternate access mapping on WSS3 and are thinking of upgrading then be aware that FBA is a whole new animal in this version. There were no major issues with the configuration but importing the user accounts and passwords from WSS3 into 2010 is not something that I have managed and to be honest it doesn't bother me a whole lot as the passwords were generated and emailed to myself as well as the users in question. This one boils down to re-keying.

So out of the box the upgrade does pretty much work excluding the following items:

- GAC deployed code - for obvious reasons when moving server you will need to re-deploy the code to the GAC, this is after making the subtle modifications required by the new environment.

- Workflows - Need to be re-registered, there was not a single change needed here just linking to a list in designer.

- FBA and other Alternate access mapping.

Finally, and I forgot to mention this... when we first detached the database to take a copy, after the detatch the following things broke in the WSS3 environment (our live environment).

- Search server (application error and failed searches for users)
- Central admin (Application error connecting to the database)
- Alerts (Our old WSS3 server just refuses to send out alerts... This is still not fixed but we are surviving till we decide to go live.


Some resources (books) which I would recommend for anybody playing with 2010 and WSS3 for that matter:

Office SharePoint Server 2007 - Administrators Companion (simply a must have for WSS3 and MOSS)

SharePoint 2010 Administrators Companion (as above)

Finally, and I am still waiting on delivery of this because it was only released today but should help with my butchering and branding of the UI:

Professional SharePoint 2010 Branding and User Interface Design
 
Last edited:
Sounds like you have a pretty sweet setup!

I've always liked SharePoint but my knowledge of it doesn't really extend much further than setting up users, permissions, doc libraries, workflows, basic customisations with SharePoint Designer etc.

Odd that some of your features broke when you detached the database, but I know from speaking to some of the Windows guys here that SharePoint migrations can be a bit of a pain in general.

Maybe one day MS will standardise things properly and have a nice easy migration process!
 
Funny you should say that Eulogy, our SharePoint environment used to be on your firms platform and I would say that some of the problems could well be down to the nature and complexity of a shared platform. I have to say though it served us incredibly well for the early stages of our project and was also priced well. The only limitation seemed to be with gac deployed custom code and any form of alternate access mapping.

I must admit at first I was sceptical about what direction the free SharePoint versions were going. Early versions, those included in SBS 2003 (wss2) were pretty shocking, navigation in particular was horrific and I found that even I would get totally lost as to where in the tree structure I was. I remember creating my own graphics in paint shop and creating clickable links to try and get some form of navigation. If you ever saw it, I am sure you would agree it was pretty ugly looking and not overly effective. It could well be that I wasn't as experienced with the product back then but I didn't much like it or think it was going anywhere special.

wss3 moved things forward for me, they addressed some of the navigation issues and if you didn't mind making a few changes you could pretty much address that globally making for a decent user experience, once I had that down it was time to start building in the business processes I got plenty of them out of the way, then the new problems came in. I wanted to link lists across sites, sharing information from lists on one page to lists in another for things such as inbound and outbound referrals to our contact database (creating a custom crm basically). What I wanted SharePoint to be at that stage was a decent relational database and what it ended up being is a mish mash of event handlers and a few clever self-firing workflows. Eventually and later on down the line I centralised the list database and got over more of the issues but this cost performance.

Anyway it looks like in time I might be able to do something about this in 2010. A quick look seemed to show some pretty extensive list sharing options, in time and once we are out of beta I will be exploring the new potential. Anyway I've gone and written another essay so will stop babbling on, I’ve outlined mostly failings in SharePoint but overall as a product and bearing in mind its price when compared to the licencing model of MOSS or Server 2010, its failings and how much of a nightmare migration can be are a small price to pay for what it can do for document management and business process management.
 
Aye if you want lots of customisations and control shared platform for Sharepoint really isn't the way to go. Dedicated/In house all the way!

From an end user perspective, having used both WSS2 and WSS3, I completely agree. WSS2 served a purpose but is completely overshadowed by WSS3 in all aspects really. I actually like using WSS3 because it has a nice interface and it's very intuitive.

We use MS CRM internally for our CRM/Case logging system, and i'd compare to WSS2, ugly and not all that great. I'm hoping that CRM 5 will improve on the product but we've had to make a lot of form customisations and workflow changes to get where we are with it today.

We also use MOSS internally and as far as I can see it's just a beefed up version of SharePoint 3, but I prefer it to our old WSS2 site so I tend to stick stuff on there instead!

On a slightly unrelated note, MS are really trying to push SharePoint over public folders in Exchange, so much so that in Exchange 2007 Public folders aren't installed by default, and depending what version of Exchange 2010 you run, you may be unable to have public folders at all! As much as I like SharePoint, and it's fairly affordable nature, I think public folders still have their place.
 
You must log in or register to reply here.
Back
Top Bottom