×
×
×
×

Installing Service Pack

Last Updated On: 21 May 2026|
25 minutes read |

Best Practices for Upgrading OS Deployer

Follow these recommendations to ensure a smooth upgrade every time.

Before Every Upgrade

  • Verify the Target Build: Always check the official service pack website before starting an upgrade to confirm your applicable upgrade version. For more details, refer your current build number and upgrade notifications.
  • Backup: Ensure a full backup is in place before proceeding. The method depends on your deployment type:
    • OS Deployer built-in backup: Use the Backup-Restore Utility (backuprestore.bat) or a recent scheduled backup as your primary supported backup. This captures both the application files and the database together in a single restorable archive.
    • VM snapshot: A VM snapshot can be used as an additional safety measure, especially when OS Deployer and the bundled PostgreSQL database are on the same server. However, it should be treated as supplementary protection rather than a replacement for the built-in backup.
    • External database: If you are using MSSQL or Remote PostgreSQL, a VM snapshot of the OS Deployer server does not cover the remote database server. Coordinate with your DBA to take an independent database backup (for example, an MSSQL full backup or a PostgreSQL dump) before proceeding.
    • Do not rely on file-only or DB-only rollback: The application files and database must remain in sync. Restoring only a VM snapshot of the application server or only a native database backup can leave the installation in an unusable state.
  • No active OS Deployer processes: Stop the OS Deployer service and verify no wrapper.exe or java.exe processes remain running before launching the Update Manager. File locks from lingering processes are a leading cause of upgrade failure.

Timing, Maintenance Windows and Downtime

Schedule upgrades during low-activity periods (i.e. during non-business hours) to minimise impact on end users and provide sufficient time for post-upgrade validation.

Choosing Your Window

Always schedule a maintenance window larger than your estimated upgrade time. The upgrade itself has two phases: a backup phase where the Update Manager compresses and saves the existing installation, followed by an installation phase where the new build is applied. Both phases run sequentially without user interaction.

For smaller environments the total downtime is typically under an hour. Larger environments with significant patch history take longer — primarily due to the backup phase. It is normal for the Update Manager progress bar to appear stalled at around 40% ("Backing up significant files") for an extended period during this phase; this does not indicate failure.

Upgrade Path Involving Multiple PPMs

If your upgrade path requires multiple PPM steps (intermediate builds followed by the final target), there is no need to halt operations between stages. Once Stage 1 completes and the "Installation Successful" screen appears, simply close the existing Update Manager wizard and invoke a fresh updatemanager.bat to begin Stage 2. All stages can be completed within the same maintenance window.

Warning
Do not open the console while the Update Manager is running. Wait for the "Installation Successful" confirmation before accessing the console or restarting the service.
Note
If processes remain locked after stopping the service: wait a few minutes and verify in Task Manager that wrapper.exe and java.exe have exited before launching the Update Manager. If they continue running unexpectedly, resolve the service state first and then retry the upgrade.

Pre-requisites for PPM upgradation

  1. Confirm a recent OS Deployer backup is available
    Verify that a recent backup created through the built-in backup process is available. Use a scheduled backup or create one manually with backuprestore.bat before the upgrade so you have a complete application-and-database backup in a single archive.
  2. Take a VM snapshot only as an additional safeguard
    If the server is virtualized, you may take a VM snapshot for extra rollback protection. This is most useful when OS Deployer and the bundled PostgreSQL database are on the same server, but it should not replace the built-in backup.
  3. Coordinate a separate backup for remote databases
    If OS Deployer uses MSSQL or Remote PostgreSQL, arrange an independent database backup with your DBA before the upgrade. A VM snapshot of only the OS Deployer server does not cover the remote database server.
  4. Download and validate the PPM file
    Save the PPM to a local drive and verify its checksum.For more details, refer Checksum Validation
  5. Stop the OS Deployer Server service
    Open services.msc → locate OS Deployer Service → click Stop. Wait for the status to show Stopped.
  6. Verify no OS Deployer processes remain running
    After stopping the service, check Task Manager for any remaining wrapper.exe or java.exe processes. Wait a few minutes for them to exit naturally before launching the Update Manager.
  7. Verify free disk space
    Ensure free disk space of at least 1.5× the size of the <Installed_Dir>/OSDeployer_Server folder on the installation drive.
  8. Confirm you are logged in with Domain Administrator credentials.

Steps for Upgradation

  1. Stop the Server. Open services.msc and stop the OS Deployer Service.
  2. Start the Update Manager by executing the script UpdateManager.bat located in the <Installed_Dir>/OSDeployer_Server/bin directory.
  3. Click Browse and select the Service Pack file (.ppm) to be installed. You can view the Readme file by clicking Readme.
  4. Click Install to start the installation.
  5. Restart the OS Deployer Server service after successful PPM installation.
  6. Verify the new build number.

Post-requisites for PPM Upgradation

  1. Distribution Servers will upgrade automatically at their next scheduled replication cycle as defined in the Replication Policy.
  2. Successful communication between the Distribution Server and the OS Deployer Server is mandatory for the Distribution Server upgrade.
  3. Avoid scheduling any patching activities until the Distribution Server upgrade is completed, as it may delay the process.
  4. Ensure that the machine where the OS Deployer Server is installed has sufficient upload/download speed to distribute upgrade files to the Distribution Server.

Distribution Server Status

How Upgrades Propagate After the Central Server is Updated
  • Distribution Servers — Once the Central Server is upgraded, each Distribution Server will initiate the upgrade at its next scheduled replication cycle, as defined in the Replication Policy.
Warning
Important: Upgrade will be triggered on the Distribution Server only when a version change is detected. If the Central Server is updated to a build that carries the same Distribution Server version as already installed, no upgrade will be initiated — the existing Distribution Server version will continue to function with full compatibility.