1

We've been using DSC basically since its day 1 release, but one thing we've never been able to do successfully (either by direct plain DSC or via invoking DSC via puppet) is configure Windows networking in a way that doesn't cause major issues when applying the configuration.

The issue is this:

Using the Microsoft DSC modules (currently xNetworking), you have directives for:

  • xDhcpClient (this disabled DHCP for a connection)
  • xIPAddress (this sets an IP address on a connection)
  • xDNSServerAddress (this sets the DNS settings on a connection)
  • xDefaultGatewayAddress (this sets the default gateway on a connection)

The problem is that applying any of these settings, one at a time, causes the network connection on the host to drop, and everything immediately stops applying - leaving the host broken and unable to be connected to remotely, meaning you have to console into the machine.

For example:

  • xDhcpClient - setting this to $false immediately removes IP address, gateway and DNS from the machine, leaving it unable to be contacted. And you must set this property, because if your DHCP lease just happens to match the permanant IP address of this server, DSC will return InDesiredState = true (which is technically correct)
  • xIPAddress - setting this to, say 172.16.110.10/23 causes the network to reconnect, and leaves no default gateway or DNS entries meaning that if you are pushing from a different subnet, you can't connect. Also, because there is no DNS entries, you can no longer contact domain controllers to authenticate any new requests
  • xDNSServerAddress - This one is actually not so bad, if you set this first the setting sticks but you still run into other issues
  • xDefaultGatewayAddress - You can basically never set this as if you set it without setting an IP address first, you end up with a gateway, but no IP address. If you set this last, it never gets executed as something else trips up the connection first (either no DNS server so you can no longer authenticate a new session, or puppet just immediately fails due to the fact that it can't contact the puppet master any more)

On Linux, you handle this by editing the interface's configuration file and then puppet notifies the networking service to restart at the very end of the puppet run, so everything else has the chance to finish first.

On Windows, the moment you apply xDhcpClient, xDNSServerAddress or xDefaultGatewayAddress the entire process falls apart as the network disconnects.

For example, this is what happens when applying puppet:

Notice: /Stage[main]/Stacknet::Single::Windows/Dsc_xdnsserveraddress[NY-DSCTEST01-PRI-VMNIC_DNS]/ensure: created
Notice: /Stage[main]/Stacknet::Single::Windows/Dsc_xdhcpclient[NY-DSCTEST01-PRI-VMNIC_DHCP]/ensure: created
Notice: Applied catalog in 18.40 seconds
Error: Could not send report: Failed to open TCP connection to ny-puppet.example.com:8140 (getaddrinfo: No such host is known. )

Puppet run fails because it can't contact the puppet master any more

No IP address, but a successful application of DNS

The puppet run just stops because it can no longer connect to the puppet master.

Is anyone else configuring networking on Windows via Puppet or DSC? If so, how are you overcoming these issues?

Mark Henderson
  • 68,823
  • 31
  • 180
  • 259
  • Which Puppet version are you deploying on the Windows nodes? – jcharaoui Aug 23 '18 at 16:16
  • An idea might be to create a scheduled task, say five minute ahead, with the relevant PowerShell commands to modify the network properties. This way, when the commands are actually launched, the Puppet run will have ended. The downside is that Puppet wouldn't be able to capture any errors returned by the command themselves. – jcharaoui Aug 23 '18 at 16:23
  • It was Puppet 5.3.1, now we're on 5.5.1. We ended up finding a workaround but I don't remember what it was off the top of my head. – Mark Henderson Aug 23 '18 at 19:44

0 Answers0