How to Set Up Windows Deployment Services (WDS) on Windows Server 2025

Windows Deployment Services (WDS) enables network-based operating system deployments across your organization without requiring physical media. By combining PXE boot, TFTP, and multicast transmission, WDS allows bare-metal machines and virtual machines to boot from the network and receive a full Windows installation automatically. On Windows Server 2025, WDS is well-suited for mid-sized environments that need reliable, fast OS provisioning with unattended installation support. This guide covers the complete WDS setup — from role installation through PXE configuration, image management, driver injection, unattended answer files, and a comparison with Microsoft Deployment Toolkit for more advanced scenarios.

Prerequisites

  • Windows Server 2025 with at least 4 GB RAM and 100 GB+ free disk space for image storage
  • Active Directory domain environment (WDS requires domain membership)
  • DHCP server running on the network (can be on the same server or a separate server)
  • A Windows Server 2025 ISO or installation media to extract WIM images
  • Network interface that supports PXE boot on client machines
  • Static IP address on the WDS server with proper DNS registration
  • Local administrator rights on the WDS server

Step 1: Install the WDS Role

Install both the Deployment Server and Transport Server role services. The Transport Server handles multicast and unicast transmissions independently; the Deployment Server provides the full image management and PXE boot infrastructure.

# Install WDS role with all sub-features and management tools
Install-WindowsFeature -Name WDS -IncludeManagementTools -IncludeAllSubFeature

# Verify installed features
Get-WindowsFeature -Name WDS* | Select-Object Name, DisplayName, InstallState

After installation completes, confirm that WDS, WDS-Deployment, and WDS-Transport all show as Installed.

Step 2: Configure WDS with the Configuration Wizard

After the role installs, the WDS server must be initialized before it can serve PXE clients. Use PowerShell’s wdsutil wrapper or the graphical console.

# Initialize WDS — store images in D:RemoteInstall
# Integrate with Active Directory, respond to all PXE clients
WDSUTIL /Initialize-Server /RemInst:"D:RemoteInstall" /Authorize:Yes

# Alternative: configure via PowerShell (Windows Server 2025)
Import-Module WDS

# Set WDS to respond to ALL clients (known and unknown)
WDSUTIL /Set-Server /AnswerClients:All

# Configure PXE prompt delay (seconds before auto-boot, 0 = immediate)
WDSUTIL /Set-Server /PxePromptPolicy /New:OptIn /Known:NoPrompt

# Verify server configuration
WDSUTIL /Get-Server /Show:Config

For tighter control in production, set /AnswerClients:Known to only respond to pre-staged computer accounts in Active Directory, preventing unauthorized machines from booting from the network.

Step 3: Add Boot and Install Images

WDS requires two types of WIM images: a boot image (boot.wim — the Windows PE environment) and one or more install images (install.wim — the actual OS). Both come from the Windows Server 2025 installation ISO.

# Mount the Windows Server 2025 ISO
$isoPath = "D:ISOsWinServer2025.iso"
$mount = Mount-DiskImage -ImagePath $isoPath -PassThru
$driveLetter = ($mount | Get-Volume).DriveLetter
Write-Host "ISO mounted at ${driveLetter}:"

# Add the boot image (Windows PE)
$bootWim = "${driveLetter}:sourcesboot.wim"
WDSUTIL /Add-Image /ImageFile:"$bootWim" /ImageType:Boot

# Verify the boot image was added
WDSUTIL /Get-AllImages /ImageType:Boot

# Add install images — Windows Server 2025 has multiple editions in install.wim
$installWim = "${driveLetter}:sourcesinstall.wim"

# List available editions in the WIM
Get-WindowsImage -ImagePath $installWim | Select-Object ImageIndex, ImageName

# Add specific edition (index 1 = Server Standard, 2 = Server Standard Desktop Experience, etc.)
Add-WdsInstallImage -Path $installWim -ImageGroup "WindowsServer2025" -Index 4 `
    -ImageName "Windows Server 2025 Datacenter Desktop Experience"

Add-WdsInstallImage -Path $installWim -ImageGroup "WindowsServer2025" -Index 2 `
    -ImageName "Windows Server 2025 Standard Desktop Experience"

Write-Host "Install images added to WDS."

Step 4: Configure DHCP for PXE Boot

If DHCP and WDS are running on the same server, you must configure DHCP options so that PXE clients are not confused by the DHCP server also handling TFTP boot file references.

# When WDS and DHCP are on the same server, configure WDS to NOT listen on port 67
# This prevents WDS from interfering with DHCP
WDSUTIL /Set-Server /UseDhcpPorts:No /DHCPOption60:Yes

# If DHCP is on a separate server, set DHCP Option 66 (Boot Server) and Option 67 (Boot File)
# on the DHCP server to point PXE clients to the WDS server:
$wdsServerIP = "192.168.1.10"
Set-DhcpServerv4OptionValue -OptionId 66 -Value $wdsServerIP -ScopeId "192.168.1.0"
Set-DhcpServerv4OptionValue -OptionId 67 -Value "bootx64wdsmgfw.efi" -ScopeId "192.168.1.0"

Write-Host "DHCP PXE options configured."

Step 5: Configure Multicast Transmissions

Multicast transmission dramatically reduces network load when deploying to many machines simultaneously. Instead of each client receiving its own unicast stream, a single multicast stream serves all clients in a session.

# Create an auto-cast multicast transmission for an install image
New-WdsMulticastTransmission -FriendlyName "WS2025-Datacenter-Multicast" `
    -ImageGroup "WindowsServer2025" `
    -ImageName "Windows Server 2025 Datacenter Desktop Experience" `
    -TransmissionType AutoCast

# Create a scheduled-cast (starts when client threshold is met or at a time)
New-WdsMulticastTransmission -FriendlyName "WS2025-Standard-ScheduledCast" `
    -ImageGroup "WindowsServer2025" `
    -ImageName "Windows Server 2025 Standard Desktop Experience" `
    -TransmissionType ScheduledCast `
    -StartTime "2026-05-20 02:00:00"

# List active multicast transmissions
Get-WdsMulticastTransmission | Select-Object FriendlyName, ImageName, Status

Step 6: Inject Drivers into Boot Images

If client hardware requires drivers not included in the default Windows PE boot image (e.g., specialized NIC or storage controllers), inject them into the boot.wim before deployment.

# Create a staging directory
New-Item -Path "C:WDSWorkBootMount" -ItemType Directory -Force

# Export boot image from WDS to a working copy
Export-WdsBootImage -DestinationPath "C:WDSWorkboot_temp.wim" `
    -ImageName "Microsoft Windows Setup (x64)"

# Mount the boot image for offline servicing
Mount-WindowsImage -ImagePath "C:WDSWorkboot_temp.wim" -Index 1 `
    -Path "C:WDSWorkBootMount"

# Add driver package (e.g., Intel NIC drivers)
Add-WindowsDriver -Path "C:WDSWorkBootMount" -Driver "D:DriversIntelNICx64" -Recurse

# Commit and unmount
Dismount-WindowsImage -Path "C:WDSWorkBootMount" -Save

# Replace the boot image in WDS with the updated version
Remove-WdsBootImage -ImageName "Microsoft Windows Setup (x64)"
Add-WdsBootImage -Path "C:WDSWorkboot_temp.wim"
Write-Host "Boot image updated with custom drivers."

Step 7: Create an Unattend.xml for Automated Installations

An unattended answer file eliminates interactive prompts during deployment — disk partitioning, product key entry, regional settings, and initial administrator account creation are all handled automatically.

# Associate an unattend.xml file with a specific install image in WDS
# The unattend file is typically created with Windows System Image Manager (Windows SIM)
# Below creates a minimal unattend.xml via PowerShell here-string for testing

$unattendXml = @'


  
    
      en-US
      en-US
      en-US
      en-US
      en-US
    
    
      
        
          0true
          
            1EFI500
            2MSR128
            3Primarytrue
          
        
      
      
        
          false
          03
        
      
    
  
  
    
      
        corp.example.com
        
          svc_domainjoin
          corp.example.com
          P@ssw0rd!
        
      
    
  

'@

$unattendXml | Out-File -FilePath "D:RemoteInstallWdsClientUnattendWS2025Unattend.xml" -Encoding UTF8

# Associate the unattend file with the WDS install image
Set-WdsInstallImage -ImageGroup "WindowsServer2025" `
    -ImageName "Windows Server 2025 Datacenter Desktop Experience" `
    -UnattendPath "D:RemoteInstallWdsClientUnattendWS2025Unattend.xml"

Write-Host "Unattend file associated with install image."

Step 8: WDS vs. Microsoft Deployment Toolkit (MDT)

WDS excels at pure image-based OS deployment, but for complex deployment scenarios consider integrating with or migrating to MDT:

  • WDS strengths: Native Windows Server role, zero additional software, PXE boot out-of-the-box, good for simple OS rollouts
  • MDT strengths: Task sequences with conditional logic, application installation during deployment, driver management by make/model, Windows PE customization, Lite Touch Installation (LTI) and Zero Touch Installation (ZTI) with MECM
  • WDS + MDT together: MDT generates a LiteTouchPE boot image that WDS serves over PXE; MDT handles the orchestration while WDS handles the network transport
# If integrating MDT with WDS, update the WDS boot image with MDT's LiteTouchPE
# After building MDT deployment share and generating boot media:
$mdtBootWim = "\mdtsrv01DeploymentShare$BootLiteTouchPE_x64.wim"

# Add MDT boot image to WDS
Add-WdsBootImage -Path $mdtBootWim

# Verify all boot images
Get-WdsBootImage | Select-Object ImageName, Architecture, ImageSize

Windows Deployment Services on Windows Server 2025 provides a reliable, built-in mechanism for network-based OS deployment that integrates cleanly with Active Directory, DHCP, and Group Policy. By configuring multicast transmissions for high-density rollouts, injecting hardware-specific drivers into boot images, and pairing unattended answer files with image groups, you can reduce a bare-metal-to-joined-domain deployment to under 30 minutes with zero technician interaction. For environments requiring application installation, driver management by hardware model, or complex task-sequence logic, extending WDS with MDT delivers a complete enterprise deployment pipeline without requiring additional infrastructure beyond a deployment share.