I have just completed the upgrade of my production systems to the latest revision of Windows SharePoint Services. After about two weeks spent in planning, testing and development, I choose the content database migration process: it has required some more steps and added complexity during the upgrading phase, but the final result is definitely the best one among all the approach suggested in the deployment guide.
More specifically, that upgrade approach allowed me to:
- migrate contents basing on the real needs, instead of forcing me to upgrade all sites and collections in one big step;
- obtain the highest levels of reliability, security and compliance, by running a new SharePoint 3.0 farm without porting settings from the old release;
- redraw the authentication model by using new several service accounts, and reducing Application Pools by 50%.
During the SharePoint upgrade I took the chance to upgrade also my Community Server platform to the 2.1 SP2 release, which is publishing my corporate blogs collection.
Now, I wish to work to redraw several applications which are based on the SharePoint platform (first of all, the Extranet access system) to better serve my customers by leveraging the new features of this exciting release.
Useless post: just migrated the Phoibos blog hosting collection to the new WP 2.1.2 platform. Seamless upgrade process, nothing to remark. 🙂
After a long period of deferring, I have finally get the time to start the activities for upgrading my corporate application platform, based on the Windows SharePoint Services, to the latest version from Microsoft.
The first step was to learn about the supported upgrade procedures, on the WSS 3.0 Technical Library. Then I spent some hours to build a SharePoint web farm “cloned” from that which is running on my production systems, to be used for testing all procedures.
As specified on TechNet, I accomplished all the pre-upgrade steps on that development environment, thus operating the simplest approach (in-place upgrade), because my WSS farm has not undergone so many customizations, and I have no strong downtime limits to comply with.
By following a quite simple step-by-step procedure, I was able to see the fist results in a couple of hours: all virtual servers, application pools and site collections were upgraded in a seamless manner by running the SharePoint Products and Technologies Configuration Wizard, after I installed .NET Framework 3.0, SharePoint 3.0 and the new language packs.
A few additional steps were required to finalize the upgrade from the Central Administration web interface.
The only actions I had to do to address some issues:
After that, I was able to uninstall the old language packs and WSS 2.0 from my development systems.
One important thing to remember is the large amount of space needed to maintain WSS diagnostic log files: you may need to dedicate a VHD to it, if you want logging.
By any other point of view, the new SharePoint version is somewhat of exciting! I finally get convinced to convince some professional developers to spend the necessary time in trying to extend all the applications I currently use and to build new solution on this wonderful platform. 😉
On Friday, 23th February my primary Internet connection link has gone because of the usual incompetence of my provider. Since I noticed the trouble as soon it raised, my customers did not suffer any service break.
The problem was to obtain dynamically what was told to be a static IP in the contract, which did later revealed to be a DHCP reservation. Of course, only if I opened a support service ticket, I’m still waiting for an answer. During the whole day I tried to obtain my IP, by bringing offline and online the dialer and the ATM interfaces on my Cisco router, but only after near 25 hours I was able to come back online.
Thanking one more time my double-connected network infrastructure design, I restored the original RR in my DNS zone, and I went back at work. 🙂