How to manage Windows with Puppet

IT pros have long aligned themselves with either Linux or Windows, but it has grown increasingly common for organizations to seek the best of both worlds.

For traditional Windows-only shops, the thought of managing Windows systems with a server-side tool made for Linux may be unappealing, but Puppet has increased Windows Server support over the years and offers capabilities that System Center Configuration Manager and Desired State Configuration do not.

Use existing Puppet infrastructure

Many organizations use Puppet to manage Linux systems and SCCM to manage Windows Servers. SCCM works well for managing workstations, but admins could manage Windows more easily with Puppet code. For example, admins can easily audit a system configuration by looking at code manifests.

Admins manage Windows with Puppet agents installed on Puppet nodes. They use modules and manifests to deploy node configurations. If admins manage both Linux and Windows systems with Puppet, it provides a one-stop shop for all IT operations.

Combine Puppet and DSC for greater support

Admins need basic knowledge of Linux to use a Puppet master service. They do not need to have a Puppet master because they can write manifests on nodes and apply them, but that is likely not a scalable option. For purely Windows-based shops, training in both Linux and Puppet will make taking the Puppet plunge easier. It requires more time to set up and configure Windows systems in Puppet the same way they would be configured in SCCM. Admins should design the code before users start writing and deploying Puppet manifests or DevOps teams add CI/CD pipelines.

SCCM works well for managing workstations, but admins could more easily manage Windows with Puppet code.

DSC is one of the first areas admins look to manage Windows with Puppet code. The modules are written in C# or PowerShell. DSC has native monitoring GUI, which makes the overall view of a machine’s configuration complex. In its enterprise version, Puppet has native support for web-based reporting. Admins can also use a free open source version, such as Foreman.

Due to the number of community modules available on the PowerShell Gallery, DSC receives the most Windows support for code-based management, but admins can combine Puppet with DSC to get complete coverage for Windows management. Puppet contains native modules and a DSC module with PowerShell DSC modules built in. Admins may also use the dsc_lite module, which can use almost any DSC module available in Puppet. The dsc_lite modules are maintained outside of Puppet completely.

How to use Puppet to disable services

Administrators can use Puppet to run and disable services. Using native Puppet support without a DSC Puppet module, admins could write a manifest to always have the net logon, BITS and W3SVC running when a Puppet run completes. Place the name of each Windows service in a Puppet array $svc_name.

$svc_name  = [‘netlogon’,’BITS’,’W3SVC’]


   service { $svc_name:
   

   ensure => ‘running’


}

In the next example, the Puppet DSC module ensures that the web server Windows feature is installed on the node and reboots if a pending reboot is required.

dsc_windowsfeature {‘webserverfeature’:

  dsc_ensure = ‘present’

  dsc_name = ‘Web-Server’

}

reboot { ‘dsc_reboot’ :

  message => Puppet needs to reboot now’,

  when    => ‘pending’,

  onlyif  => ‘pending_dsc_reboot’,

}

Go to Original Article
Author:

Try these PowerShell networking commands to stay connected

While it would be nice if they did, servers don’t magically stay online on their own.

Servers go offline for a lot of reasons; it’s your job to find a way to determine network connectivity to these servers quickly and easily. You can use PowerShell networking commands, such as the Test-Connection and Test-NetConnection cmdlets to help.

The problem with ping

For quite some time, system administrators used ping to test network connectivity. This little utility sends an Internet Control Message Protocol message request to an endpoint and listens for an ICMP reply.

ping test
The ping utility runs a fairly simple test to check for a response from a host.

Because ping only tests ICMP, this limits its effectiveness to fully test a connection. Another caveat: The Windows firewall blocks ICMP requests by default. If the ICMP request doesn’t reach the server in question, you’ll get a false negative which makes ping results irrelevant.

The Test-Connection cmdlet offers a deeper look

We need a better way to test server network connectivity, so let’s use PowerShell instead of ping. The Test-Connection cmdlet also sends ICMP packets but it uses Windows Management Instrumentation which gives us more granular results. While ping returns text-based output, the Test-Connection cmdlet returns a Win32_PingStatus object which contains a lot of useful information.

The Test-Connection command has a few different parameters you can use to tailor your query to your liking, such as changing the buffer size and defining the number of seconds between the pings. The output is the same but the request is a little different.

Test-Connection www.google.com -Count 2 -BufferSize 128 -Delay 3

You can use Test-Connection to check on remote computers and ping a remote computer as well, provided you have access to those machines. The command below connects to the SRV1 and SRV2 computers and sends ICMP requests from those computers to www.google.com:

Test-Connection -Source 'SRV2', 'SRV1' -ComputerName 'www.google.com'

Source Destination IPV4Address IPV6Address
Bytes Time(ms)

------ ----------- ----------- -----------
----- --------

SRV2 google.com 172.217.7.174
32 5

SRV2 google.com 172.217.7.174
32 5

SRV2 google.com 172.217.7.174
32 6

SRV2 google.com 172.217.7.174
32 5

SRV1 google.com 172.217.7.174
32 5

SRV1 google.com 172.217.7.174
32 5

SRV1 google.com 172.217.7.174
32 5

SRV1 google.com 172.217.7.174
32 5

If the output is too verbose, and you just want a simple result, use the Quiet parameter.

Test-Connection -ComputerName google.com -Quiet
True

For more advanced network checks, try the Test-NetConnection cmdlet

If simple ICMP requests aren’t enough to test network connectivity, PowerShell also provides the Test-NetConnection cmdlet. This cmdlet is the successor to Test-Connection and goes beyond ICMP to check network connectivity.

For basic use, Test-NetConnection just needs a value for the ComputerName parameter and will mimic Test-Connection‘s behavior.

Test-NetConnection -ComputerName www.google.com

ComputerName : www.google.com
RemoteAddress : 172.217.9.68
InterfaceAlias : Ethernet 2
SourceAddress : X.X.X.X
PingSucceeded : True
PingReplyDetails (RTT) : 34 ms

Test-NetConnection has advanced capabilities and can test for open ports. The example below will check to see if port 80 is open:

Test-NetConnection -ComputerName www.google.com -Port 80

ComputerName : google.com
RemoteAddress : 172.217.5.238
RemotePort : 80
InterfaceAlias : Ethernet 2
SourceAddress : X.X.X.X
TcpTestSucceeded : True

The boolean TcpTestSucceeded returns True to indicate port 80 is open.

We can also use the TraceRoute parameter with the Test-NetConnection cmdlet to check the progress of packets to the destination address.

Test-NetConnection -ComputerName google.com -TraceRoute

ComputerName : google.com
RemoteAddress : 172.217.5.238
InterfaceAlias : Ethernet 2
SourceAddress : X.X.X.X
PingSucceeded : True
PingReplyDetails (RTT) : 44 ms
TraceRoute : 192.168.86.1
192.168.0.1
142.254.146.117
74.128.4.113
65.29.30.36
65.189.140.166
66.109.6.66
66.109.6.30
107.14.17.204
216.6.87.149
72.14.198.28
108.170.240.97
216.239.54.125
172.217.5.238

If you dig into the help for the Test-NetConnection cmdlet, you’ll find it has quite a few parameters to test many different situations.

Go to Original Article
Author: