Skip to main content

OS Deployment Troubleshooting Guide

This guide covers the most common issues encountered across every stage of OS Deployment in ServiceOps: setup, image capture, image registration, deployment task creation, target machine execution, and golden machine preparation.

Quick Diagnostic Checklist​

Run through this checklist before investigating a specific issue. Most OS Deployment failures trace back to one of these root causes.

CheckHow to Verify
tftpd64.exe is running as AdministratorCheck Task Manager on the MotadataPXE host. Restart it as Administrator if not running.
bootx64.efi exists in the TFTP base directoryBrowse to C:\Program Files (x86)\Motadata\PXE and confirm the file is present.
DHCP Option 66 is the correct MotadataPXE or TFTP host IPOpen your DHCP server and verify Option 66 on the target scope. If the MotadataPXE or TFTP host machine is connected to both LAN and Wi-Fi, use the LAN IP address in Option 66, not the Wi-Fi IP.
DHCP Option 67 is exactly bootx64.efiVerify no trailing spaces or incorrect path separators.
Only one DHCP server is active on the target subnetRunning the built-in tftpd64 DHCP and a network DHCP server simultaneously causes IP conflicts.
Target machine is on a wired connectionMotadataPXE boot does not work over Wi-Fi. Connect the target machine via LAN, then press F10 or F12 (varies by hardware) during startup to open the boot menu and select Network Boot.
Image storage share has Read/Write permissionsRight-click the shared folder and confirm the Poller service account has full access.
Poller service is runningConfirm from Admin > Discovery and Agents that the Poller status is active.
OS Deployment license is activeCheck Admin > Organization > License Details.

MotadataPXE Boot Issues​

Issues where the target machine fails to boot from the network or does not reach the OSDApp.

Target machine will not network boot

Cause: The machine BIOS boot order does not prioritize network boot, or DHCP is not returning MotadataPXE options to the machine.

Fix:

  1. Enter BIOS/UEFI on the target machine and move the network adapter to first in the boot order. Save and restart.
  2. On restart, press F12 (or the hardware-specific boot menu key) and explicitly select Network Boot or MotadataPXE Boot.
  3. If the machine still does not receive a MotadataPXE response, verify DHCP Options 66 and 67 are configured on the correct scope. See Setup.
  4. Confirm tftpd64.exe is running as Administrator on the MotadataPXE host and that the MotadataPXE host is reachable from the target machine's subnet.
OSDApp does not appear after MotadataPXE boot

Cause: tftpd64.exe is not running as Administrator, bootx64.efi is missing from the TFTP base directory, or the base directory path is incorrect.

Fix:

  1. On the MotadataPXE host, right-click tftpd64.exe and select Run as administrator. A non-elevated instance does not serve boot files correctly.
  2. Open the TFTP tab in tftpd64 and confirm the Base Directory is set to C:\Program Files (x86)\Motadata\PXE.
  3. Browse to that folder and verify bootx64.efi is present. If missing, reinstall the MotadataPXE Utility.
  4. Restart tftpd64.exe after making any changes.
Machine boots but shows a blank screen or loading error instead of OSDApp

Cause: The WinPE environment loaded but cannot connect to the ServiceOps server.

Fix:

  1. Confirm the target machine received a valid IP address. Check the network configuration screen if it appears before the error.
  2. Verify that the ServiceOps server is reachable from the target subnet. Ping the server IP from another machine on the same subnet.
  3. Check firewall rules between the target subnet and the ServiceOps server. Port 443 must be open.

TFTP and DHCP Configuration Issues​

Issues with the TFTP server or DHCP option configuration.

Two DHCP servers are conflicting on the same subnet

Cause: Both the built-in DHCP in tftpd64.exe and an existing network DHCP server are active on the same subnet. This causes IP conflicts and unpredictable MotadataPXE responses.

Fix: Use only one DHCP source. Either:

  • Uncheck DHCP Server in the tftpd64.exe Global tab and configure Options 66 and 67 on your existing network DHCP server, or
  • Disable DHCP on the network DHCP server scope for the target subnet and use the built-in tftpd64 DHCP.

Never run both simultaneously on the same subnet.

DHCP assigns an IP address but no MotadataPXE boot file is delivered

Cause: Options 66 and 67 are configured at the server level instead of the scope level, or they contain incorrect values.

Fix:

  1. Open your DHCP server and navigate to the scope that covers the target subnet.
  2. Confirm Option 66 is set to the IP address of the MotadataPXE or TFTP host (not a hostname).
  3. Confirm Option 67 is set to exactly bootx64.efi with no extra characters, slashes, or spaces.
  4. Apply the options at the scope level, not the server level, to ensure only the target subnet receives MotadataPXE boot options.
tftpd64.exe closes or crashes during deployment

Cause: The application was launched without Administrator rights, or another process is using the same port.

Fix:

  1. Close all instances of tftpd64.exe.
  2. Right-click tftpd64.exe and select Run as administrator.
  3. If the port is in use, identify and stop the conflicting service using netstat -ano in Command Prompt, then restart tftpd64.exe.

Image Capture Issues​

Issues that occur when running Image Creator (OSDApp) on the golden machine.

Image capture is taking too long or appears stuck

Cause: Image size and network speed determine capture time. A large drive over a slow network can take several hours. The progress bar may appear stalled on large files.

Fix:

  1. Do not close the OSDApp window or restart the machine. Let the process run.
  2. Monitor network activity on the MotadataPXE host to confirm data is still transferring.
  3. If the process is genuinely stuck (no network activity for more than 30 minutes), cancel the capture, check network stability, and restart the process.
install.wim does not appear in the output folder after capture

Cause: The output folder path is incorrect, the share does not have Write permissions, or the capture was interrupted.

Fix:

  1. Confirm the output folder path in OSDApp is correct. Use UNC format for network paths, for example \\hostname\sharename.
  2. Right-click the shared folder and verify the golden machine has Write access.
  3. Check available disk space on the output destination. The free space must be at least equal to the total size of the drives selected for capture in OSDApp, as the captured image can be as large as the source drive.
  4. If the capture was interrupted, delete any partial files and restart the capture.
Network share path is not accessible from OSDApp

Cause: The UNC path format is incorrect, or the golden machine does not have credentials to access the share.

Fix:

  1. Open Windows Explorer on the golden machine and paste the UNC path directly into the address bar to test access.
  2. If prompted for credentials, enter them. OSDApp uses the same network access as the logged-in user.
  3. Ensure the path uses double backslashes: \\hostname\sharename. Do not use mapped drive letters in OSDApp.

Image Registration Issues​

Issues that occur when adding a captured image in ServiceOps.

Storage path not reachable when adding the image in ServiceOps

Cause: The shared folder does not have Read/Write permissions for the Poller service account, the UNC path is incorrect, or the Poller cannot reach the file server.

Fix:

  1. Verify the UNC path format: \\hostname\sharename. Confirm there is no trailing backslash.
  2. On the file server, right-click the shared folder and confirm the Poller service account (or Everyone) has Read/Write access.
  3. From the machine running the ServiceOps Poller, open Windows Explorer and paste the UNC path to confirm it is accessible.
  4. Check that the Poller is running and active in Admin > Discovery and Agents > Discovery Poller.
Image does not appear in the deployment task image list

Cause: The image was not saved successfully in ServiceOps, or the Poller failed to validate the storage path during registration.

Fix:

  1. Navigate to Admin > OS Deployment > Image and confirm the image appears in the list with a valid storage path.
  2. If the image is listed but the path shows an error, delete and re-register the image with the correct UNC path.
  3. Confirm the Poller selected during registration is active and can reach the storage path.

Deployment Task Issues​

Issues when creating or managing deployment tasks.

Passcode authentication fails on the target machine

Cause: The deployment task is not yet active, the expiry date has passed, or the passcode was entered incorrectly.

Fix:

  1. Open the deployment task in Admin > OS Deployment > Deployment and check the Start Date and Expiry Date.
  2. If the start date is in the future (task is in Scheduled state), edit the start date to activate it immediately.
  3. If the task has expired, edit both the start date and expiry date to reactivate it.
  4. Confirm the passcode is being entered correctly on the target machine. The passcode is 6 digits with no letters or special characters.
Cannot edit the start date of an active deployment task

Cause: The task is in Started state. Once the start date has passed, it cannot be changed.

Fix: You can only extend the expiry date of a Started task. If you need to change the start date, create a new deployment task with the correct dates and expire or delete the existing one.

OS Deployment section is not visible in the Admin panel

Cause: The OS Deployment license is not active, or the Discovery and Agents section is disabled in ServiceOps.

Fix:

  1. Go to Admin > Organization > License Details and confirm an OS Deployment license is listed and not expired.
  2. Confirm the Discovery and Agents section is visible and enabled in the Admin panel.
  3. Contact your Motadata account manager if the license is missing or expired.

Image Transfer Issues​

Issues that occur while the image is being applied to the target machine.

Image transfer fails partway through deployment

Cause: Network instability during the image transfer corrupts the WIM file or breaks the connection to the image share.

Fix:

  1. Check network stability between the target machine and the file server hosting the image. Use a wired connection only.
  2. Confirm the image share still has Read/Write permissions during transfer. Some environments revoke permissions on a schedule.
  3. Verify no firewall or switch policy is terminating long-running connections.
  4. Restart the deployment from the beginning. Partially transferred images cannot be resumed.
Deployment completes but the machine boots into an error or recovery mode

Cause: The image was captured from a machine that was powered on after Sysprep, or the capture was incomplete.

Fix:

  1. Verify the golden machine was never powered on after Sysprep ran. See Golden Machine Preparation.
  2. Recapture the image from a freshly Sysprepped golden machine.
  3. Re-register the new image and create a new deployment task.

Golden Machine and Sysprep Issues​

Issues during golden machine preparation and Sysprep generalization.

Sysprep fails with a generic error

Cause: Pending Windows Updates, provisioned Microsoft Store apps, or security software is interfering with Sysprep generalization.

Fix:

  1. Open C:\Windows\System32\Sysprep\Panther\setupact.log and search for the specific failure reason.

  2. Apply all pending Windows Updates and reboot before retrying.

  3. Remove provisioned Microsoft Store apps:

    Get-AppxProvisionedPackage -Online | Remove-AppxProvisionedPackage -Online

  4. Disable or uninstall antivirus or endpoint security software temporarily.

  5. Retry Sysprep after resolving the identified issue.

Sysprep rearm count shows 0

Cause: Sysprep has been run the maximum number of times allowed on this Windows installation (three rearms).

Fix: Rebuild the golden machine from a fresh Windows installation. There is no workaround for an exhausted rearm count.

Deployed machines all show the same computer name or SID

Cause: Sysprep was not run before capture, or the golden machine was powered on after Sysprep and before the image was captured.

Fix:

  1. Rebuild the golden machine and complete all preparation steps. See Golden Machine Preparation.
  2. Run Sysprep with the /generalize /oobe /shutdown flags.
  3. Capture the image immediately after shutdown without booting the machine again.
BitLocker decryption is blocking Sysprep

Cause: One or more drives are partially or fully encrypted with BitLocker. Sysprep cannot run on an encrypted drive.

Fix:

  1. Check the encryption status of all drives:

    manage-bde -status

  2. For every drive that is not fully decrypted, turn off BitLocker (repeat for each drive letter shown as encrypted):

    manage-bde -off C:

  3. Decryption runs in the background and can take a long time depending on drive size and speed. Re-run manage-bde -status to monitor progress.

  4. Retry Sysprep only when every drive shows Percentage Encrypted: 0.0% and Conversion Status: Fully Decrypted. Retrying before decryption is complete will fail again.