Troubleshooting Imaging

• Authentication Credentials Error
• Re-enroll an Imaging Virtual Server (IVS)
• Image creation or deployment hangs on "calling subprocess.Popen"
• Imaging Issue After Upgrading FileWave and Using Self-Signed SSL Certificate
• RAM listing 0-15 Error
• Sysprep not able to validate Windows installation
• Windows Imaging in FileWave: Secure Imaging Option (15.5+)
• Modifying IVS Init.gz for testing purposes
• Troubleshooting BitLocker Activation Issues on Windows 11 Post-Imaging
• Imaging Speed Test for IVS Performance Verification

Authentication Credentials Error

What

Use this article when a Windows imaging deployment fails on the IVS with this message:

“IVS request for URL: https:<your.IVS.IP.address:20044/imagingwindows/boot/get_image_info/ failed with code: 403 Authentication credentials were not provided.”

The error blocks Windows image deployment because the IVS and FileWave Server need to re-establish their secure connection.

When/Why

This error usually means the IVS shared key no longer matches the key trusted by the FileWave Server. Regenerate the key, then verify that the last four characters changed so you know the IVS is using a new shared key.

How

1. Navigate to FileWave Central (native admin)

2. Open the Imaging tab

3. Highlight and double-click on your IVS

4. Check the box to “Generate new key on Save”

5. Press OK to save

6. Click Monitor while still viewing the Imaging tab preferences

7. Click on Verify to have the IVS check-in

After the IVS verifies successfully, try the image deployment again. Confirm that the image association is set to True before PXE booting the target machine.

Re-enroll an Imaging Virtual Server (IVS)

What this procedure does

Re-enrolling an Imaging Virtual Server (IVS) requires more than deleting its FileWave Central record. Remove the IVS Client configuration and IVS Admin preferences first, then remove the IVS from FileWave Central, restart it, and enroll it again.

When to use it

Use this reset when an IVS no longer connects or images after routine connectivity and service checks. The procedure deletes local IVS configuration, so record the current server address and enrollment details before starting.

Reset and re-enroll the IVS

1. Remove the IVS Client configuration
   1. Connect to the IVS over SSH and run the following commands:
      
      

      $ sudo killall fwcld
      $ rm -rf /etc/xdg/FileWave/Client.conf

      
      
2. Remove the IVS Admin preferences
   1. In a browser, open the IVS Admin address at https://<IVS-IP-address>:20444
      
      
      
      
   2. Select Sign in and enter the IVS administrator credentials. An appliance that still has its initial credentials uses:
      
      

      username: fwadmin
      password: filewave

      
      
   3. Open Admin > Preferences. Select the checkbox beside Preference to select every row, then choose Delete selected Preferences from the Action menu.
      
      
      
      
   4. Select Go, then confirm with Yes. Verify that the page reports 0 Preferences.
      
      
      
      
3. Remove the IVS from FileWave Central
   1. In FileWave Central, open Preferences > Imaging. Select the IVS, select the minus button, and choose OK. Reopen Preferences > Imaging and confirm that the IVS does not reappear.
4. Restart the IVS. In the SSH session, run:
   
   

   $ sudo shutdown -r now

   
   
5. Enroll the IVS again. After it restarts, follow Setting up the IVS (Imaging Virtual Server).

Related content

• Setting up the IVS (Imaging Virtual Server)

Image creation or deployment hangs on "calling subprocess.Popen"

Problem

During Windows image capture or deployment, the IVS can hang at the message "Calling subprocess.Popen with: parted -m /dev/sda print".

Solution

This usually points to a bad or unreadable partition table on the target device. To clear it, enable the IVS debug prompt, boot the affected device, and run the partition cleanup command on the correct disk.

The sgdisk --zap command clears partition data on the selected disk. Verify the drive name before running it; the screenshot shows /dev/sda, but your device may use a different disk name.

1. Make a note of the partition that appears stuck. In the screenshot it is "/dev/sda". Your drive may have a different name.

2. After you know the drive name, turn off the machine that is stuck capturing or deploying the image.

3. Connect to your IVS and run the below command.
   
   

   touch /etc/fw_master_debug

4. PXE boot the machine giving the error again.

5. The machine will go to a prompt where you are able to type the below command. For the example, "/dev/sda", but yours may be different.
   
   

   sgdisk --zap /dev/sda

6. Shut down the machine you are capturing the image from or deploying the image to.

7. Run the below command on your IVS to delete the file you created.
   
   

    rm -rf /etc/fw_master_debug

8. PXE boot the machine again. The image capture or deployment should continue past the previous hang point.

Imaging Issue After Upgrading FileWave and Using Self-Signed SSL Certificate

What

After upgrading FileWave Server, IVS, and clients, imaging may fail when the environment uses a self-signed SSL certificate.

When/Why

Use this workaround when IVS imaging fails after an upgrade and the environment does not use a root-trusted SSL certificate. Add the check to your IVS upgrade process for self-signed certificate deployments.

How

1. Access the IVS via SSH or locally:
   • Connect to the IVS by SSH or local console. Use sudo -s so the following file edit runs as root.
2. Edit the dnsmasq.lua file:
   • Use your preferred command-line editor, such as vi or nano, to edit /imaging/scripts/bin/dnsmasq.lua:
     • vi /imaging/scripts/bin/dnsmasq.lua
     • nano /imaging/scripts/bin/dnsmasq.lua

1. Navigate to line 128:
   • Navigate to line 128.
     
2. Switch to insert mode:
   • In vi, press i to switch to insert mode. In nano, move the cursor to the line and edit directly.
3. Add the following line:
   • req.tls = false
4. Save and exit vi or nano:
   • Press the Esc key to exit insert mode.
   • In vi, type :wq and press Enter to save and exit. In nano, press Ctrl+X and save the file when prompted.
5. Verify functionality:
   • Test imaging again after saving the file.

Related Content

• Self-signed SSL Certificates
• Network Imaging / IVS

RAM listing 0-15 Error

What

Machines using the latest M.2 drives may run into an error listing RAM failures when deploying an image.

When/Why

New machines with M.2 drives may have been set up with a pre-configuration of RAID within the machine’s BIOS. You will want to log into your machine’s BIOS and change the storage controller or SATA configuration from RAID to AHCI.

How

Depending on the manufacturer/brand of BIOS, be sure to review the options and verify the method of logging into the BIOS. Once logged in, perform the following steps:

1. Search the BIOS for storage, controller, or SATA settings

2. Change the storage/SATA mode from RAID to AHCI

3. Confirm the changes and save

4. Exit BIOS and restart the machine

5. Prepare PXE boot to image deployment

After the storage/SATA setting has been changed and saved, please try again to deploy your image. Be sure the image association is set to True before PXE booting the machine.

Third Party Vendors

Each Brand/Manufacturer has their own options to enter BIOS. Below are a few examples to search for:

• HP BIOS

• Dell BIOS

• ASUS BIOS

• Lenovo BIOS

Sysprep not able to validate Windows installation

If Sysprep fails with an Appx validation error, check %WINDIR%\System32\Sysprep\Panther\setuperr.log, identify the package named in the error, remove that app for each affected user, and then run Sysprep again. Sysprep remains mandatory for FileWave Windows disk imaging; Microsoft explains the disk-duplication policy here.

1. Removes computer-specific information from a Windows installation. Duplicated computer-specific information can cause Windows functionality to behave incorrectly across multiple PCs.
   • Generates a new computer SID
   • Sets a new computer name
   • Clears out event logs
   • Runs mini setup to deal with hardware differences
2. Performs a full Windows shutdown when the "/shutdown" switch is specified, which is required on Windows 8 and 10 - Starting with Windows 8, Microsoft added a fast startup feature that helps your PC start up faster after shutdown, even faster than hibernate. Windows does this by saving an image of the Windows kernel and loaded drivers to C:\hiberfil.sys upon shutdown so when you start your PC again, Windows simply loads the C:\hiberfil.sys file into memory to load Windows instead of starting from scratch. When it does this, Windows leaves the main partition hosting Windows in a state that prevents FileWave from properly capturing it. When you sysprep with the "/shutdown" parameter, it performs a full shutdown without generating a hiberfil.sys file and leaves the partition hosting Windows in a state that allows FileWave to capture it.

Sysprep can occasionally fail with a validation error when a provisioned Microsoft Store Appx app has been updated for one user but not for all users on the reference system.

Sysprep has an additional provider in Windows 8 and 10 to clean Microsoft Store Appx packages and generalize the image. This provider will fail if an all-user package is updated for one of the users on this reference computer, which Windows will do automatically if it is connected to the internet long enough. To minimize the chance of this happening on the reference system, keep it disconnected from the internet as much as possible until the image is ready.

The error message you'll see in %WINDIR%\System32\Sysprep\Panther\setupact.log, and more importantly in setuperr.log, when sysprep fails under these circumstances is that "an app was installed for a user, but not provisioned for all users".

<Date> <Time>, Error SYSPRP Package <PackageFullName> was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.
<Date> <Time>, Error SYSPRP Failed to remove apps for the current user: 0x80073cf2.
<Date> <Time>, Error SYSPRP Exit code of RemoveAllApps thread was 0x3cf2.
<Date> <Time>, Error [0x0f0082] SYSPRP ActionPlatform::LaunchModule: Failure occurred while executing 'SysprepGeneralize' from C:\Windows\System32\AppxSysprep.dll; dwRet = 0x3cf2
<Date> <Time>, Error SYSPRP ActionPlatform::ExecuteAction: Error in executing action; dwRet = 0x3cf2
<Date> <Time>, Error SYSPRP ActionPlatform::ExecuteActionList: Error in execute actions; dwRet = 0x3cf2
<Date> <Time>, Error SYSPRP SysprepSession::Execute: Error in executing actions from C:\Windows\System32\Sysprep\ActionFiles\Generalize.xml; dwRet = 0x3cf2
<Date> <Time>, Error SYSPRP RunPlatformActions:Failed while executing SysprepSession actions; dwRet = 0x3cf2
<Date> <Time>, Error [0x0f0070] SYSPRP RunExternalDlls:An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = 0x3cf2
<Date> <Time>, Error [0x0f00a8] SYSPRP WinMain:Hit failure while processing sysprep generalize internal providers; hr = 0x80073cf2

Follow the steps below to remove the offending apps causing sysprep to fail before sysprepping again.

1. Check %WINDIR%\System32\Sysprep\Panther\setuperr.log for errors like the ones above and note the <PackageFullName> of the app, for example 9E2F88E3.Twitter_5.4.1.0_x86_wgeqdkkx372wm.

2. Launch PowerShell as an administrator and remove the Microsoft Store Appx app in question. In this example, <PackageName> is Twitter.
   
   

   Remove-AppxPackage *<PackageName>*

3. If sysprep continues to fail because of the same app, it means the app is installed for another user on the system. Log into this other user account and repeat step 2 to remove the app for that user.

4. Sysprep again.

5. Repeat steps 1–4 until Sysprep is successful.

Windows Imaging in FileWave: Secure Imaging Option (15.5+)

What

In FileWave version 15.5.0, significant changes have been made to the Windows Imaging process using the Imaging Virtual Server (IVS). Previously, when imaging or capturing a Windows system, the device would mount NFS (Network File System) volumes directly over TCP/UDP port 2049. Starting with FileWave 15.5, the imaging process has been enhanced for security and reliability by allowing the creation of a VPN tunnel over TCP/UDP port 20490. Over this secure VPN tunnel, the system accesses the NFS mounts, providing a more secure and efficient imaging environment. This secure functionality was initially enabled by default, but from 16.2.0 onward it is disabled by default and can be enabled or disabled via a command.

When/Why

When to Use

Secure imaging is something you want to consider if you frequently capture images of devices that have user data on them. Secure imaging will prevent someone from grabbing an image from the IVS server. If you don't typically do this, and typically use the IVS to simply capture base images and deploy them then there is better performance if Secure Imaging is disabled. If you setup your IVS on version 16.2.0 then it will be disabled by default. If you were running an older IVS you may see it enabled but can easily toggle it off or on in 16.2.0.

How

Enabling Secure Imaging

You can enable it with this command on FileWave 16.2.0 or beyond:

sudo imaging-control enable secure-mount
sudo reboot

Disabling Secure Imaging

You can disable it with this command on FileWave 16.2.0 or beyond:

sudo imaging-control disable secure-mount
sudo reboot

Important Considerations

Firewall Configuration: Make sure that your network’s firewalls allow traffic over the necessary ports:

• Port 20490 for Secure Imaging.
• Port 2049 for Standard Imaging.

Related Content

• Setting up the IVS (Imaging Virtual Server)
• Imaging Speed Test for IVS Performance Verification

Digging Deeper

Secure Imaging Flag File

On FileWave versions older than 16.2.0, you can delete the flag file to enable Secure Imaging:

sudo rm /etc/fw_insecure_nfs_mount
sudo reboot

On FileWave versions older than 16.2.0, you can create the flag file to disable Secure Imaging:

sudo touch /etc/fw_insecure_nfs_mount
sudo ufw allow 2049/tcp
sudo ufw allow 2049/udp
sudo reboot

Modifying IVS Init.gz for testing purposes

What

With the IVS, target devices uses init.gz as the boot image over the network. For troubleshooting purposes, you may want/need to make a change to this image (for instance to change a driver file or to make some workaround). 

When/Why

This is not an activity most FileWave administrators will do but is being documented for cases where it is needed. Usually you will do this with support to test something.

How

Related Content

• Network Imaging / IVS

Troubleshooting BitLocker Activation Issues on Windows 11 Post-Imaging

Overview

Use this targeted repair when BitLocker fails after Windows 11 imaging with the Boot Configuration Data (BCD) path error shown below. The commands correct the device, osdevice, and memory diagnostic device values on systems that match the documented partition layout.

Issue Description

After deploying a Windows 11 image to devices, attempts to enable BitLocker fail with the following error:

"The path specified in the Boot Configuration Data (BCD) for a BitLocker Drive Encryption integrity-protected application is incorrect. Please verify and correct your BCD settings and try again."

The issue was observed on multiple devices after the same FileWave imaging workflow. Confirm the current BCD values on an affected test device before treating this as the cause.

Initial Troubleshooting Attempts

Unattend File Adjustments

One of the first suspected causes was the Windows unattend.xml file used during deployment. Specifically, we considered that the partitioning and wiping directives in the answer file conflicted with FileWave’s imaging and partitioning steps.

To test this theory:

• Removed the entire partitioning section from the unattend file.

• Re-imaged devices using the updated unattend configuration.

Result: This change did not resolve the BitLocker error.

Manual BCD Edits

We experimented with manual edits to the BCD store using bcdedit, in an attempt to update or repair paths that might be misconfigured post-image. However, these attempts did not lead to a consistent fix.

Resolution

The tested workaround below came from a community report on Reddit (source) and was then validated on multiple affected devices.

The issue appears to be related to incorrect device and osdevice settings within the BCD store. BitLocker can initialize successfully by explicitly setting these values to point to the system partition.

Required Commands

Check the partition mapping first. BCDEdit changes can make Windows unbootable. Run bcdedit /enum from an elevated Command Prompt and verify that Windows is on C: and memory diagnostics uses \Device\HarddiskVolume1 before applying this example. Pilot the change on representative hardware before wider deployment.

Run these commands in an elevated Command Prompt only after the values match:

bcdedit /set {current} osdevice partition=C:
bcdedit /set {current} device partition=C:
bcdedit /set {memdiag} device partition=\Device\HarddiskVolume1

Optional: Batch File Version

You may also save the above commands to a .bat file for repeated use. Below is the complete content of the file:

@echo off
bcdedit /set {current} osdevice partition=C:
bcdedit /set {current} device partition=C:
bcdedit /set {memdiag} device partition=\Device\HarddiskVolume1
echo Edit complete.
pause

Post-Fix Behavior

After running the commands (or executing the batch script) and rebooting the device:

• BitLocker can be successfully enabled.

• Verify that the recovery key is escrowed in the directory service configured by your organization.

This workaround resolved the error on multiple test devices in the original report. Treat it as a targeted repair, not a universal post-imaging step. The PowerShell example below applies the same values.

##
##.SYNOPSIS Fixes BCD configuration to resolve BitLocker activation issues on Windows 11.
##
##.DESCRIPTION
##  This script sets the correct BCD partition values for osdevice, device, and memdiag using bcdedit.
## Intended for deployment through FileWave as a Fileset or custom script.
##

# Requires elevation
if (-not ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole(`
    [Security.Principal.WindowsBuiltInRole] "Administrator")) {
    Write-Host "This script must be run as Administrator."
    exit 1
}

# Define target values
$osDevice = "partition=C:"
$device = "partition=C:"
$memdiagDevice = "\Device\HarddiskVolume1"

try {
    Write-Host "Applying BCD changes..."

    # Set the current OS device and boot device
    bcdedit /set "{current}" osdevice $osDevice
    bcdedit /set "{current}" device $device
    bcdedit /set "{memdiag}" device $memdiagDevice

    Write-Host "BCD changes applied successfully."

    # Optional: Trigger reboot after applying fix
    # Restart-Computer -Force

} catch {
    Write-Error "An error occurred while editing BCD: $_"
    exit 2
}

exit 0

Optional verification/detection script:

$bcdOutput = bcdedit /enum {current}
if ($bcdOutput -match "osdevice.*partition=C:" -and $bcdOutput -match "device.*partition=C:") {
    Write-Host "BCD is already configured correctly."
    exit 0
} else {
    Write-Host "BCD configuration needs to be fixed."
    exit 1
}

Conclusion

In the reported cases, incorrect device and osdevice values blocked BitLocker activation. If the error text or partition mapping differs, investigate the image, storage layout, and unattended setup instead of forcing these values.

After a successful pilot, you can deploy the repair as a FileWave Fileset or script to devices that report the same BCD error and partition layout.

---

References

• Reddit thread with the original solution: https://www.reddit.com/r/sysadmin/comments/1hh4d4s/comment/m6di6vq/?rdt=42301

• Microsoft: BCDEdit /set

Imaging Speed Test for IVS Performance Verification

What

When imaging Windows devices from a FileWave Image Virtualization Server (IVS), it’s important to ensure that data transfer speeds are optimal. Bottlenecks can occur if the IVS and client devices are on different subnets, or if network links between them are not operating at full capacity.

Two tools—iftop and iperf3—can help diagnose and measure network performance for imaging.

Note that if stunnel is enabled then there is some additional bandwidth used for the encrypted tunnel. You can disable stunnel for better performance. 

When/Why

You might use these tests when:

• Imaging feels slower than expected.

• Clients are located across multiple switches or VLANs.

• You want to validate performance before imaging large batches of devices.

• You need to confirm whether a slowdown is due to the network, the IVS, or client hardware.

How

1. Measuring Real-Time Traffic with iftop

iftop can show live network traffic on the IVS.

Install and run it on the IVS:

Note that in FileWave 16.2.0+ this is already installed on the IVS so you will not need to do the apt install command below.

sudo apt install iftop
sudo iftop

The first column will be the server you are running iftop on. The second column will show you the devices connected so if I was imaging 152.32.183.31 then that would be the last entry on the screen and the first line is traffic TO that host and the second is traffic FROM that host as indicated by the arrows. 

Understanding the three traffic columns in iftop:

• Left column: Average traffic rate over the last 2 seconds.

• Middle column: Average traffic rate over the last 10 seconds.

• Right column: Average traffic rate over the last 40 seconds.

You can use this to see per-client speeds during imaging and spot if a client is receiving data more slowly than others.

---

2. Load Testing with iperf3

iperf3 simulates network traffic to measure throughput between the IVS and a client device.

Install on the IVS:

Note that in FileWave 16.2.0 the IVS already installs iperf3 so you may not need to do the install and systemctl commands below.

The second line below is only needed if you picked "No" to running iperf as a service and will set it to be a service.

sudo apt install iperf3
sudo systemctl enable --now iperf3
sudo ufw allow 5201/tcp

Note that iperf3 listens on TCP 5201 so make sure that from your clients you can reach the IVS on that port and you don't have a firewall blocking that port.

On the client side (macOS, Windows, or Debian):

As of FileWave 16.2.0 the IVS has iperf3 already included in the OS that boots on a client when PXE booting. To test you just need to put the IVS in debug mode and then boot a client to be imaged. In debug mode that client will boot to a unix shell instead of imaging or capturing. From there you can use the following command to test;

1. Enable debug on IVS;

sudo touch /etc/fw_master_debug
sudo reboot

2. Command to type on the PXE booted client when in debug;
Note that in tbe below command the 5 is the number of connections and 30 is the duration to test. This would simulate 5 clients for 30 seconds. You can change the number and duration to do more extensive testing.

network-test 5 30

3. Disable debug on IVS once you are done with testing;

sudo rm -f /etc/fw_master_debug
sudo reboot

Other than testing via a client in debug mode you would need to first install iperf3. This can be found for Windows here: https://iperf.fr/iperf-download.php and for Debian can be installed with "sudo apt install iperf3" and for macOS can be installed via Homebrew with "brew install iperf3". On macOS many admins will already have Homebrew installed, but it can take a few minutes to install it if not.

iperf3 -c <IVS_IP> -P <parallel_streams> -t <seconds>

• <IVS_IP>: IP address of the IVS.

• -P: Number of parallel connections (e.g., 1 for a single client, 20 to simulate 20 machines).

• -t: Duration in seconds for the test.

Example:

iperf3 -c 192.168.1.50 -P 10 -t 30

Tests 10 parallel streams for 30 seconds.

---

3. Bandwidth → MB/s Cheat Sheet

(Real-world speeds will be ~10–15% less due to protocol overhead, duplex negotiation, etc.)

Network Speed	Theoretical MB/s	Real-World MB/s (approx.)
1 Gb	125 MB/s	105-115 MB/s
2.5 Gb	312.5 MB/s	265-285 MB/s
5 Gb	625 MB/s	525-565 MB/s
10 Gb	1250 MB/s	1050-1150 MB/s

---

4. Using Results to Predict Imaging Times

Once you know your average throughput from iperf3, you can estimate imaging time.

Example 1: 1 Gb Network Connection

• Image: 10 GB

• Driver pack: 3 GB

• Total data: 13 GB

• 1 Gb link ≈ 110 MB/s real-world

Calculation:

13 GB ÷ 110 MB/s ≈ 118 seconds (~2 minutes) per machine.
For 10 machines (unicast), ≈ 20 minutes (plus minor overhead).

Example 2: 10 Gb Network Connection

• Image: 10 GB

• Driver pack: 3 GB

• Total data: 13 GB

• 10 Gb link ≈ 1100 MB/s real-world

Calculation:

13 GB ÷ 1100 MB/s ≈ 12 seconds per machine.
For 10 machines (unicast), ≈ 2 minutes total.

---

Expected Imaging Times by Network Speed

(Assumes 13 GB total image + drivers per machine, real-world throughput values, unicast imaging)

Network Speed	Real-World Throughput	1 Machine Time	10 Machines Time	20 Machines Time
1 Gb	~110 MB/s	~2 min	~20 min	~40 min
2.5 Gb	~275 MB/s	~47 sec	~8 min	~16 min
5 Gb	~550 MB/s	~24 sec	~4 min	~8 min
10 Gb	~1100 MB/s	~12 sec	~2 min	~4 min

Additional Notes:

• Always consider the slowest link: client NIC speed, switch port speed, uplinks between switches, and IVS NIC speed.

• Avoid hubs—always use switches.

• Different VLANs and routing hops may reduce performance.

Related Content

• Setting up the IVS (Imaging Virtual Server)

• IVS Control Commands
  

Digging Deeper

• You can combine iftop and iperf3 results: run iperf3 load tests while monitoring iftop to see how the IVS reports real-time speeds.

• For imaging 50+ devices, consider deploying a local IVS in each subnet to avoid bottlenecks.

• Remember that hard drives (HDD vs. SSD) in client devices also impact the perceived imaging speed—network speed is only one part of the chain.

• If speeds are significantly below expected values, investigate:

  • Duplex mismatches on switch ports.

  • Outdated NIC drivers on clients.

  • Oversubscribed uplinks between switches.