# 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](https://www.manageengine.com/products/os-deployer/service-pack.html) before starting an upgrade to confirm your applicable upgrade version. For more details, refer to [your current build number and upgrade notifications](https://www.manageengine.com/products/os-deployer/help/server/product-build-number-and-upgrade-notifications.html). - **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 to [Checksum Validation](https://www.manageengine.com/products/os-deployer/help/server/checksum-validation.html). 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 `/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 `/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.