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.

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

Yesterday morning, instead of starting to do what I had to do, I began fixing a couple of problems which were annoying me from a lot of weeks.
One of the main concerns I solved was the need to enter the same credential each time an external user gains access to a web site published by my array of ISA servers.
In effect, ISA 2006 come with the SSO Web Listener functionality, but when I last worked on it, I had more urgent tasks to accomplish, so I did not find the time for testing and bringing it in the production environment.

My first impression in a test environment was good, so I spent some hours (obviously after midnight) to activate this function on the production servers. Some troubles, mostly due to the Outlook Web Access application configuration, but at the end I reached the goal: now you are requested for credential one time only, and the user experience in accessing the Phoibos online services has been dramatically improved (have a try with it at http://mailhost.valsania.it/)… thanks you one more time, ISA! 😉

Last week I noticed that HTTP/S connections to my primary ISP public address were randomly dropped for short times. Since this little trouble was affecting the user experience of the Phoibos services customers, I worked a couple of days to find a solution.
The cause of the problem revealed to reside in the Web Listener component of ISA Server 2004 Standard Edition: in effect, the configuration of my firewall (that I deployed to workaround my ISPs low reliability) with two external NIC targeted to different gateways and some other tricks, was something complex and obviously unsupported by MSFT… 😉

The best solution was to deploy an array of ISA Servers (only possible with the Enterprise edition) to have them working as a load-balanced gateways both to access the Internet and to publish my servers on the Internet.  Furthermore the bi-directional affinity functionality granted by the new NLB services on Windows Server 2003 was also the best solution to publish the same service simultaneously on both public IP addresses, which was what I needed.

The migration from my old ISA 2004 single-server deployment to the new ISA 2006 array has been a little more complex than I thougth, mainly because the fact that all the ISA machines I wanted to deploy were hosted on two physical Virtual Server 2005 R2 hosts (if you have ever had to configure NLB clusters in a virtualized infrastructure you know what I mean…). After some troubles I decided to setup the NLB services out of the control of ISA services to be able to make NLB working in multicast mode (that’s the best option if you must have virtual guests by different virtual host “converged” in the same Virtual IP).

At the time I’m writing the new solution has been deployed by some hours, and all seems to work very well and, obviously, in a more available and secure way. I think there are a few adjustments I still have to make… hoping to have as few troubles as possible! 😀