|Professional Services||Second Signal||Presentations||Andrew's Blog||Support|
I probably make as big an effort at keeping up with new versions of the Domino server and Notes client software as almost any admin, but with the increasingly rapid pace of change it's getting somewhat more difficult all the time. Many of us have wished for some better automatic update capability for a long time. It's starting to get important enough to demand attention. With 8.5.2 due fairly soon, we'll have had several fairly important updates all within the space of a few months -- 8.5.1, 8.5.1 fp1, 8.5.1 fp2, and 8.5.2 in fairly rapid succession.
Sure, the pace of change is in part due to IBM's desire to get new features out faster and to more quickly address any serious issues with those new features as quickly as possible -- but it does leave administrators scrambling to keep up. What follows is my preference for how IBM could drastically improve this process.
Improvement does not (and should not) mean automatic upgrades without administration planing or management. That's inappropriate for enterprise infrastructure software. IBM can still address many of the major pain points without putting environments at risk.
Key Pain Points:
Pain Point #1 is knowing the update is available, and what it fixes. If you don't follow the community very closely it can be very hard to know if and when you need to perform the updates.
Pain Point #2 is finding, selecting, downloading, and preparing the upgrade software. The download process from IBM is painful and time consuming. It's very easy to find the wrong package or to download some, but not all the versions you need for the number of serves and clients in the environment.
Pain Point #3 is getting the updates prepared for installation -- moving them to the servers, unpacking them, preparing scripts on some servers, and setting up the upgrade packages for workstation roll out through policies.
What Should IBM Do:
1. Allow the Domino servers to automatically download the upgrade packages. This should be configurable on a per-server basis -- so that each server can be designated as an upgrade download point for the Domain. This should be either a single server or multiple servers depending on the environment. Let the admin decide which servers will be configured to download which sets of upgrades.
2. Notify the Admin when new packages have been downloaded.
3. For Client side upgrades, provide a very simple action button that turns a downloaded package into a prepared update to be rolled out through the policy based upgrade system. Once the server has the files, the admin should not have to spend more than a couple of minutes to schedule its roll out to users. The upgrade process already exists, but getting the upgrades into it properly is too painful.
4. For Server side upgrades, provide a very simple action button that turns a downloaded package into a "ready to upgrade" server. The result should be that the upgrade package is moved to the selected servers, unpacked to a specified path, and is ready for upgrade. Once done, the administrator gets a notification indicating the steps necessary to complete the upgrade.
I believe these small steps (small compared to a true automatic patch system -- that I am at this time not in favor of) will drastically improve the adoption of point level updates. Better adoption means better served IT customers and end users. License maintenance will also improve under a system like this.
Please wait while your document is saved.
deployed, Smart Upgrade needs to be able to upgrade that deployment.
The Notes client can be deployed as a multi-user install; has been for years.
Smart Upgrade has never been able to work in that instance thus requiring a
visit to the user to manually upgrade them.