Windows Deployment Services in Azure = No

Can SCCM be truly in Azure only? That depends on whether you consider an on premise PXE service as a part of the SCCM infrastructure or not.

WDS is not supported in Azure: https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines

But we all know that ‘not supported’ doesn’t always mean ‘doesn’t work’. There are many things in the Microsoft world that start off as not supported but end up being fully fledged features.

Let’s put it to the test;

  • In Azure, an SCCM primary site server running a PXE enabled DP with a boot image and Windows 10 image task sequence deployed to to the collection ‘All Unknown Computers’.
  • On premise, a DHCP server with options 66 and 67 configured. An RRAS running a IKEv2 VPN to Azure.
  • Any/Any is open on the firewalls between the Azure and on prem subnets.

What we get is…

In the screenshot below:

10.1.0.50 – PXE Boot Client

10.1.0.9 – VPN Gateway

10.0.0.4 – WDS (SCCM)

pxe

The WDSNBP.com file is downloaded using TFTP. But when it tries to get the boot image file it gets ‘No response from Windows Deployment Services server’.

After this the PXE client switches to download the pxeboot.com boot image which is the wrong image. The PXE session is therefore a failure.

There is no firewall block and clearly some traffic is being responded to by the WDS.

Using netmon we get the below trace from the WDS server

azuretrace

The first image, column 1 is the source IP, column 2 is the destination. We can see that the Request is being received by the WDS server and an ACK packet is being sent back to the PXE client. This is repeated.

Below are the ports the traffic is using. One of them is UDP 68:

pxeport

So why doesn’t the PXE client think the WDS server is responding?

Below is the netmon from the on premise RRAS server, remember this is the VPN gateway on prem.

onpremtrace

It shows the requests being relayed to Azure, but nothing coming back. Something in Azure is blocking this.

A little googling and this comes up: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq

“What protocols can I use within VNets?

You can use TCP, UDP, and ICMP TCP/IP protocols within VNets. Unicast is supported within VNets, with the exception of Dynamic Host Configuration Protocol (DHCP) via Unicast (source port UDP/68 / destination port UDP/67).”

And so there we have it. Azure appears to be actively interfering with UDP port 68 traffic, likely preventing it from being routed down the VPN. So in this scenario, the PXE service needs to be setup on premise.

Only by saying that the PXE service is not a part of the SCCM infrastructure could we, in this scenario, say that SCCM is entirely cloud based.