Frequently Asked Questions | OS Deployer
This page provides answers to frequently asked questions (FAQs) related to OS Deployer.
General
OS Deployment
- OEM license: If the Windows OS version of the image is the same as the OEM license, then the license will be automatically activated.
- Volume-based license: Let us assume you've created an image by imaging a machine with a volume-based license. Depending on the availability of the license, if you deploy it to another machine the license will be automatically activated.
To resolve the “Insufficient space for creating image” issue, please increase the available free space in the existing image repository. Alternatively, you can create a new image repository at a different location with sufficient free space and use that repository to create the new image.
- Navigate to the server installed directory: Server Installed Directory\webapps\DesktopCentral\agent
- Locate the zip file named "USMTComponents.zip". If the size of the file is 1kb, it indicates that its empty.
- Delete the USMTComponents.zip file and initiate USMT again. The zip must be recreated with required files.
- Download the target machine's model specific rapid storage driver. Extract the driver files and add them to your driver repository.
- Once drivers were added, do a scan for the driver repository and try deployment.
- Alternatively access the BIOS settings of one of the target machines affected by the BSOD.
- Change the SATA configuration to AHCI or AHCI to RAID mode vice versa and attempt to boot the machine into Windows.
- Verify whether the system successfully boots into Windows.
If the issue persists, kindly contact support.
Windows 10/Windows 11 Imaging
PXE Boot Server
- Enter BIOS setup using F2.
- Navigate to the Boot Menu.
- Uncheck Boot Network Devices Last.
- Enable UEFI PXE & iSCSI.
- Select Ethernet1 Boot or Ethernet2 Boot.
- Press F12 during POST to boot from LAN.
Boot Windows via USB Media
The following operating systems are supported for booting Windows from USB using OS Deployer:
- Windows 10
- Windows 8.1
- Windows 8
- Windows 7
- Windows Vista
- Windows XP
The following Windows Server operating systems can be booted using the Windows bootable USB:
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
- Windows Server 2008
- Windows Server 2003 R2
- Windows Server 2003
- Windows PE 10.0 Media - Windows 10, Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012
- Windows PE 5.0 Media - Windows 10, Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012
- Windows PE 4.0 Media - Windows 10, Windows 8, Windows Server 2012, Windows 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008
- Windows PE 3.0 Media - Windows 7, Windows Server 2008 R2, Windows Vista, and Windows Server 2008
- Windows PE 2.0 Media - Windows Vista, Windows Server 2008, Windows XP, Windows Server 2003
Boot Windows via ISO Media
- Create a new ISO bootable media.
- Download the generated ISO file.
- Use any third-party software to burn or copy the ISO file onto a DVD.
- Once the media files are successfully written to the DVD, the customer can boot the machine using the DVD.
Windows ISO Download and Creation
Microsoft Windows Deployment Toolkit
Service Tag Based Target Identification
Your existing OSD licenses are MAC Address-based. After this update, the system will automatically create a Service Tag association for each MAC license using details from the last successful deployment. No manual action is required — existing licenses remain valid.
Yes. Going forward, each license will be identified by the deployed machine's Service Tag. MAC Address will only be used in cases where the Service Tag is found to be invalid.
Previously, deployment targets could only be added using a MAC Address. This update introduces a field that accepts either a MAC Address or a Service Tag, giving you more flexibility when configuring deployment targets.
Yes. Existing deployment task targets are not modified by this update and will continue to function as before. You do not need to reconfigure them.
Previously, MAC Address was mandatory when adding a target in a Standalone Task, while the Service Tag was optional. With this update, the form now accepts either a Service Tag or a MAC Address — MAC Address is no longer mandatory. We recommend providing the Service Tag as the primary target identifier, since modern machines often do not have a built-in Ethernet MAC address.
Existing targets will remain in place and continue to work. However, the behavior depends on how the target was originally configured:
- Target configured with a Service Tag: After the update, the Service Tag will be prioritized and only the Service Tag will be displayed for that target.
- Target configured without a Service Tag: No change occurs. The MAC Address-based target will still be shown and function as intended.
Previously, MAC Address was mandatory when adding computer settings, while the Service Tag was optional. With this update, the form now accepts either a Service Tag or a MAC Address — MAC Address is no longer mandatory.
We recommend providing the Service Tag, as modern machines often do not have a built-in Ethernet MAC address.
Yes. Existing computer settings will remain in place and continue to work. However, the behavior depends on how the setting was originally configured:
- Computer Setting configured with a Service Tag: After the update, the Service Tag will be prioritized over the MAC Address and only the Service Tag will be shown for that Computer Setting.
- Computer Setting configured without a Service Tag: No change occurs. The MAC Address-based Computer Setting will still be shown and function as intended.
Previously, the hyperlink for accessing deployment details was only available for MAC Address entries. After this update, the hyperlink will also be shown for Serial Number (Service Tag) entries, making it easier to navigate to deployment details for machines identified by Service Tag.
In the UEM/Security edition, OSD licensing is integrated with the Endpoint Central. Previously, the overlap between OSD and EC was determined by MAC addresses, which frequently caused licensing inconsistencies when external network adapters were linked to multiple managed agents.
This issue has been resolved by switching to Service Tag verification. A machine that is both Deployed and Managed will now be counted as a single license, regardless of its MAC address associations.
Previously, the common device count for DC and OSD was verified using MAC addresses. In environments where a single external adapter or docking station was used across multiple machines during OS deployment, this method could result in inaccurate license counts. Consequently, the reported license usage was often lower than the actual consumption.
With this upgrade, the common count verification will instead rely on device serial numbers. This change is expected to address the limitations associated with MAC address—based identification and should provide a more accurate representation of license usage.
If the Service Tag is found to be invalid, the system will automatically revert to MAC address-based verification to ensure the machine is still accounted for correctly.
Build Number and Versions FAQ
Click the profile icon at the top-right of the console. Your build number appears in the panel that opens — for example, Build: 11.5.2605.01. Click the build number itself to open the Version Details panel, which shows the individual version installed for each component: Central Server, Distribution Server, and each agent type (Windows, Mac, and Linux).
Click the profile icon at the top-right of the console. If a newer build is available, an upgrade prompt appears in that same panel alongside your current build number. For a broader view to plan the upgrade ahead, the ManageEngine's OS Deployer lists the latest released build and the recommended upgrade sequence for your version but rather wait for the in-console upgrade notification.
A Service Pack is a cumulative release that consolidates all fixes from prior builds into a single new baseline. Every customer upgrading beyond it must pass through it — there is no way to skip it. In the build string, the SP level is the second digit: in 11.5.2605.01, the 5 denotes SP5. An SP release also significantly reduces the size of subsequent PPM files, because older patch-handling code gets cleaned up during consolidation.
A Hotfix is smaller and targeted — it addresses specific bugs found after the last SP and applies on top of it. Hotfixes can be applied incrementally and are lighter than a full Service Pack.
The practical rule: install the SP first to establish the baseline, then apply hotfix builds on top as they are released.
This is a custom fix or specialised hotfix build — not a general release. ManageEngine engineers assign a version number at the time a custom fix is compiled, which can produce a service-pack segment (2534) that appears numerically higher than the current public GA release (2528). This does not mean your environment has a "newer" or superior build — it means it's on a non-standard release branch.
Implications for upgrades:
- Standard PPM files for the GA release path (
2528.x) will likely be rejected by your Update Manager, because the installer detects a higher version number already installed. - Standard in-product upgrade notifications may not appear, since the server knows it deviates from the GA release path.
- You must not attempt to downgrade or apply a lower-versioned PPM without Support guidance.
Recommended action: Contact ManageEngine Support and provide:
- Your current build number as shown in the console
- The contents of
<UEMS_CentralServer>\conf\fixes_id.properties
Support will confirm your correct upgrade path — typically a custom-to-GA consolidation PPM — and whether the fix from your custom build has been merged into the current GA release.
Internet access alone does not guarantee that the upgrade notification will appear. There are four distinct causes, each requiring a different resolution. Work through the table below to identify which applies to your environment before resorting to a manual PPM download.
| Cause | How to Identify | Resolution |
|---|---|---|
| Customised or Hotfix Build Installed | Console build number ends in an unusual patch suffix (e.g., .12 on a build not listed on ME's official website). The server knows it deviates from the standard release path and suppresses standard notifications. | Contact ManageEngine Support with your current build number. They will confirm the correct next step and whether a standard notification will appear once you return to the standard build path. |
| AMS (Annual Maintenance & Support) Subscription Expired | Navigate to Admin → License. If the AMS expiry date is in the past, notifications for builds released after that date are suppressed. | Renew your AMS subscription via your ManageEngine account manager. Notifications will resume once the subscription is active and the console re-contacts the update server. |
| Proxy or Firewall Blocking Update Server | From the server, try to reach autoupgrade.manageengine.com on port 443 using a browser or curl/telnet. If the connection times out, outbound traffic is being blocked despite general internet access being available. | Whitelist autoupgrade.manageengine.com and downloads.manageengine.com on port 443 in your firewall or proxy. After whitelisting, click "Check for updates" again in the console. |
| In-Product Notification Setting Disabled | Navigate to Profile Icon → Build Version → Settings. Check whether "Display in-product notifications about updates" is disabled. | Enable the notification setting and save. The notification will appear at the next update-check interval (typically within a few minutes). |
If none of the above causes apply and notifications are still missing, download the PPM manually from ME's official website using the build number shown in your console and apply it via UpdateManager.bat. Refer to the Downloading the PPM section for instructions.
The position and digit count of each segment tells you the upgrade type required:
| Segment | Position | Example | Upgrade Type Required |
|---|---|---|---|
| Service Pack | 3rd (4 digits) | 2528 | Manual PPM download + planned downtime required |
| Minor Patch | 4th (2 digits) | 21 | Auto Upgrade eligible — no PPM download or downtime needed |
Side-by-side comparison examples:
11.4.2528.19→11.4.2528.21— only Segment 4 changed → Minor Version → Auto Upgrade eligible11.4.2516.39→11.4.2528.21— Segment 3 changed → Service Pack → manual PPM required11.4.2528.21→11.5.2528.21— Segment 2 changed → Major version upgrade → check ME's upgrade path guide first
Practical rule: Compare builds left-to-right. If only the last two digits changed, it's a minor patch. If the 4-digit segment changed, plan a maintenance window. If Segment 1 or 2 changed, verify the full upgrade path on ME's official website before proceeding.
PPM Upgradation
A Service Pack (SP) is a major cumulative release that consolidates all fixes and changes up to that point into a single unified build. It is introduced primarily for code maintenance and to establish a common baseline across all customers. Any customer wishing to upgrade to a build beyond the SP must pass through the SP first — it cannot be skipped. In the build number format, the Service Pack level is indicated by the second digit (for example, in 11.5.2605.01, the 5 denotes the Service Pack). An SP release also significantly reduces the PPM file size and the time taken to apply it, since all prior patch-handling code is consolidated and cleaned up.
A Hotfix is a smaller, targeted release that addresses specific bugs or issues identified after the last SP. Hotfixes can be applied incrementally on top of the SP baseline and are lighter in size compared to a Service Pack.
In summary: Apply the SP first to establish the baseline, then apply hotfix builds on top to stay current.
Backup FAQs
No. Scheduled backup is an online backup — the OS Deployer server stays fully operational while the backup runs in the background.
The backup will not run. There is no retry — it will only attempt again at the next scheduled time. Make sure the EC service is running.
At least 2—2.5× the current database size of free space on both the local drive and your backup destination. For example, if your DB is 10 GB, keep at least 20—25 GB free.
Yes. Ensure the OS Deployer service account has write access to the network folder. For MSSQL, the SQL Server service account also needs write access. Test the connection before relying on it.
It depends on your database size and storage speed. Network backups are slower than local ones. For Remote PostgreSQL, the backup runs over the network — speed depends on bandwidth between the EC server and the remote DB server. Schedule backups during off-peak hours to minimize impact.
Every 45 days, a recovery key is emailed to all administrators. This key lets you restore a backup even if you forget your custom password. Do not delete these emails.
No. Backups are never automatically disabled. If 3+ consecutive failures occur, a dashboard warning appears, but backups continue to run on schedule. Fix the underlying issue (disk space, permissions, or network access) and the next run should succeed.
It is not recommended. VM snapshots and SQL-only backups do not cover application files . We recommend keeping OS Deployer's built-in backup enabled for complete protection.
Yes. The system automatically creates a pre-upgrade backup before every update or patch.
No, it is not safe to delete files in the ScheduledDBBackup folder manually. It is recommended to have atleast 7 days of backup files in the folder. The system automatically manages the backup files based on the retention count you set in the Admin → Database Settings → Database Backup section. Deleting files manually can lead to loss of critical backup data and may affect your ability to restore in case of an issue.
Restore FAQs
No. The backup must be from the exact same build number. If you need to restore on a newer build, install the matching version first, restore, then upgrade.
Yes, always. The restore will not proceed if the service is running. Stop the service via Windows Services before starting the restore.
Yes. Restoring replaces all current data with the backup data. Any changes made after the backup date will be lost.
Use the recovery key emailed to all administrators every 45 days. Check your email archive for a message from OS Deployer containing the key. If you can't find it, contact ManageEngine Support.
Only if you're restoring on a new server. On the same server, just stop the service and run the restore utility — no reinstallation needed.
Yes, if the server hostname and IP address remain the same. Agents reconnect automatically within few minutes.
No. Cross-type restore is not supported. The backup must match the exact database type of your installation (e.g., you cannot restore a Remote PostgreSQL or MSSQL backup on a Bundled PostgreSQL setup).
Yes. Install the exact same version on the new server, copy the backup file, and restore. The build number, database type, and architecture (32-bit/64-bit) must all match.
VM snapshot restore not recommended, in OS Deployer files and database should be in sync so restoring either files or database alone separately using VM snapshot might lead to inconsistency, so always use the Backup-Restore Utility instead of VM snapshots.
Contact support with your backup file details. They can help you locate the exact build installer matching your backup so you can install it on the new server and restore.
Go to Admin → Database Settings → Database Backup → Backup Protection. The new password applies only to future backups. For existing backups, use the original password or the recovery key.
Go to Admin → Database Settings → Database Backup. You can change the backup time, retention count, and destination path. After saving, new backups use the updated settings. Existing backups at the old location are not moved automatically.
Go to Admin → Database Settings → Database Backup. Update the email addresses under the failure notification section. A working mail server must be configured in Admin → Mail Server Settings.
<Install Dir>\UEMS_CentralServer\ScheduledDBBackup\. We strongly recommend changing this to a different drive or network share.
Go to Admin → Database Settings. The database type (Bundled PostgreSQL, Remote PostgreSQL, or Microsoft SQL Server) is displayed on this page.
Backups should always be performed on the primary server. The Failover Server does not run independent backups. After restoring on the primary, run SyncSecondary.bat Restore from the primary server's bin folder to sync the secondary server.
Mail Server Settings
Yes No