Updating software on target Domino servers or deployment groups

Updating a single or multiple servers

Updating servers in a deployment group

Server capabilities

Not all Domino servers have the capability to install software (see Enabling AutoUpdate). When a server has only Distribute capability, such as an AIX server, a scheduled deployment will distribute the software, but not install it. The Schedule Deployment dialog displays how many of the selected servers have Install capability and how many are limited to Distribute capability.

Each Domino server determines its own capabilities which it stores in the Capabilities field of its autoupdate.nsf server document. The value indicates the server's maximum capability and will be None, Distribute, or Install. A server listed with Install capability also has Distribute capability.

Scheduling installs

When you schedule installs, additional fields appear in the Schedule Deployment dialog that allow you to select the weekdays, time window, and optionally a start date and end date for the installs. The designated server ensures that the installs will not start until at least the start of that time window. For example, if you select weekdays Saturday and Sunday and scheduled time between 9 am and 1 pm, the earliest the installs can start is Saturday at 9 am. If, for example, a target server is down at that time and does not come up until 2 pm, it will wait until at least 9 am on Sunday to start the install. You can also specify a start date and end date, which can be useful if you want to schedule the installs for more than a week ahead.

Ordering installs

When you schedule a deployment of multiple servers, you can control the order in which the installs execute. You must coordinate this ahead of time, before you schedule a deployment.

Servers will be updated in order from the lowest deployment order to the highest. Servers with a lower deployment order must update completely before any updates on servers with a higher deployment order are initiated. If an update fails on any server, any servers with a higher deployment order will not be updated.

For example, say you schedule a deployment on servers A, B, C, and D and set the deployment order to 1, 2, 2, 3, respectively. Server A will be updated first. If the update is successful, servers B and C will be updated concurrently. If both of those updates succeed, server D will be updated.

Best practices

The designated download server is critical to successful completion of installs because it houses the autoupdate.nsf database that contains the software and keeps track of the status of all target servers. Here are some recommendations.

• When choosing your designated server, pick one that has minimal down time.
• Schedule installs so that the designated server is the last one to update. The target servers need access to the designated server during their updates so that they can update information in autoupdate.nsf. If you schedule all your installs using one deployment group, ensure that the designated server has the highest deployment order. If you use multiple deployment groups, schedule them so that the group containing the designated server is scheduled later than all the others.

Viewing active deployments

After scheduling for software distribution, you can view the progress in the Active Deployments view.

1. Open the autoupdate.nsf, and then the Active Deployments view. Note that once a server is successfully updated, it will no longer appear in this view.
2. Locate the server name or deployment group and use the indicated icon to determine its status:
   • The Pending Distribute icon indicates that the deployment is pending.
   • The Distributed icon indicates software has been distributed.
   • The Pending Install icon indicates that the install is pending.
   • The Installing icon indicates that the install is in progress.
   • The Error icon indicates that the distribution or install ended in an error.
3. Open the History view under Deployment History. This view contains a history document for each completed deployment attempt on each server.
4. Locate the server name and use the indicated icon to determine its status:
   • The green checkmark icon indicates the install completed successfully and the server has restarted.
   • The Error icon indicates the install failed.
5. Open the history document to see details on the install results:
   • Prior version
   • New version
   • Action (Install or Distribute)
   • Unique deployment ID for the Schedule Deployment action that initiated the install
   • Start and end times
   • Run time in seconds
   • Installer reboot request shows the suggested action from the Domino installer when it completes an install, which can be No reboot needed, Recommended, or Required. Note that the actual action taken by AutoUpdate depends on the OS reboot option in the autoupdate.nsf server documents. If that option does not allow the OS reboot, AutoUpdate will not reboot, regardless of the installer suggestion. It will attempt to restart Domino, but if there are pending file operations on any Domino files, Domino will not start.
   • OS reboot status shows whether AutoUpdate rebooted the operating system after successfully installing Domino. The value can be No reboot needed, Rebooted, or Reboot disabled by configuration. See Configuring the Global Configuration Document for reboot configuration options.
   • autoinstall log
   • Domino installation log
6. Open the Servers view under Server Deployments. Here you can quickly determine the status of all your servers:
   • The checkmark icon indicates server is Unscheduled. This is the expected status after a successful update.
   • The Distributed icon indicates software has been distributed.. This is the expected status for servers that do not have install capability.
   • The Error icon icon indicates the install (or distribution) failed.
   • Other icons can indicate work in progress.
7. Open the server document to see additional details. You can view a record of completed software distributions and installations on the Update history tab. From there, you can select a history document from the embedded view. This is an alternative way to view the history documents from step 5.

On systems that do not have install capability, once distributions are complete, the software must be installed manually. After the Domino server has been manually upgraded to the version of the distributed software, the software will be removed from the Active Deployments view.

Details on the automatic install process

The Domino autoupdate task waits, if necessary, until a target server is within its scheduled deployment window and all servers in the same deployment with a lower deployment order have completed successfully. Then it queues a request to the autoinstall standalone program to perform the install.

autoinstall checks the request, and if it is not valid, rejects it. Otherwise it performs the install, writes a status file and log files with the details of the install, and restarts Domino. In some cases, when Domino restarts, it offers the option to update the design of the Domino directory (autoinstall ensures that there is no prompt for the update and that the directory design is updated automatically).

When Domino comes back up, it evaluates the results of the install, creates a history document, and attaches the log files. It also updates the server status to either Unscheduled if the install was successful or Error if it was not.

Troubleshooting install failures

For any failures, more details can be found in autoupdate.nsf. Open the database on the designated server and check the server document in the Servers view, making sure to also check the latest document under the Update history tab. History documents can also be accessed from the History view.

If the install has not yet been initiated

• If the server status is Scheduled:
  • Check the install schedule in the server document. It could be that the current time is before the scheduled time window.
  • Check the deployment order. If you scheduled other servers as part of the deployment, and they have a lower deployment order, their installs must complete successfully before this server's install can be initiated.
• If the server status is Pending, Domino is downloading the Domino software to the target server. When that completes, the install will be initiated.
• If the server status is Distributed, Domino has distributed the software to the target server. It should update shortly to either the Waiting to Install or Installing status.
• If you selected the option Install now, or if the current time is within the date and time you scheduled, the install should begin shortly and the status will display as Installing.
• If the current time is not within the date and time you scheduled, or if there are other servers in the deployment group with a lower deployment order that have not completed their installs, the status will remain Waiting to Install until the prerequisites are met, at which point the status will display as Installing.
• If the server status is Error, something went wrong prior to the install. Check the history document for details on the failure.

If the install was initiated but Domino is still down on the target system

• Check that the server status is Installing. If it is still Scheduled or Pending, Domino might have been shut down for a different reason, before AutoUpdate attempted the install.

• The install could be taking some time. Check the target server to see if any install process is running. You can also check files in the domino/deploy directory under the Domino data directory. The file autoinstall_<deployID>.txt contains the current status of the autoinstall process orchestrating the install. If it has completed, it will contain a [total] section that indicates success or failure. If it does not contain this data, the install is probably still in progress and you should give it more time.
• The install might have failed and autoinstall could not restart Domino. Check if there is a log file created by the actual installer. It typically has a name like HCL_Domino_Install_<datetime>.log. The log file should indicate what failed. The autoinstall log file, named autoinstall_<deployID>.log, should contain all the details of the work attempted by autoinstall. It makes every attempt to restart Domino after an install attempt, whether it succeeded or failed, but in some rare cases it might not be able to restart Domino successfully. In those cases, you should restart Domino in the standard way you normally do.

If Domino has restarted after the install, but the server document still indicates the install is in progress

• Usually the autoupdate task checks the results shortly after server startup. If the server is taking a long time to fully come up, it could be that the check has not yet happened and you need to give it more time.
• Check if the designated server is down. It could be that the install completed successfully on the target server but it could not update its status on the designated server.

If Domino has been restarted after the install and the server document indicates the install failed

• Check the history document for the install attempt. It contains file attachments that should contain details on the failure.
  • autoinstall_<deployID>.log contains a detailed log of steps taken by autoinstall to orchestrate the Domino install. The start of the log includes the request details from AutoUpdate. The end of the log contains the results of the install attempt in a simple format, broken into sections. Each section contains a line that is either "status=SUCCESS" or "status=FAILED". The [total] section summaries the overall result. There is much more detail in the file that should help you determine why the install failed.
  • HCL_Domino_Install_<datetime>.log is the log file generated by the actual Domino installer. This might contain details of a Domino installer failure. If this file does not exist, it means that autoinstall failed before it could even attempt the Domino install.