Now here we are at the end of our story, and you might be wondering what there is left to cover. We've gone over all there is to go over in an introductory book, except how to handle certain situations in the real world. In our testing environments, we've had known quantities and clear requirements. We were able to use the latest software and therefore had an easy time using DSC. However, the real world is messy and filled with complex and conflicting requirements, old legacy software, and inflexible deployment processes. How does DSC fit into situations like this?
In this chapter, we will cover:
- Real life DSC usage
- Setting up a common installation base
- Installing software
- Configuration management refresher
- Selective software upgrades
- Reporting status
After coming this far, you're on the bandwagon and are ready to implement DSC in your production environment. You're the admin for numerous servers and you want to start getting things in order right away. You've talked it over with your boss and you both know there isn't enough room on the VM server for a dedicated instance just to stand up to the DSC Pull Server when it hasn't proven itself yet. You've agreed to start out with pushing DSC configurations to show progress and in a month re-evaluate the progress.
When you open up the list of servers you manage, you notice that they are a mix of Windows 2008 R2 and Windows 2012 R2. A sigh of relief escapes your mouth when you remember the last of the old Windows 2003 servers were migrated off a couple months ago in preparation for the end of life cutoff that happens this year. With the list of different OS and IP addresses handy, you decide to use PowerShell to investigate how many of them have PowerShell Remoting (PSR) up-and-running:
[PS]> New-PSSession –ComputerName (gc ./servers.txt) –ErrorAction 0 –ErrorVariable "+sessionErrors"
Note
The preceding example uses the error capturing functionality PowerShell provides to allow New-PSSession to continue running regardless of any errors connecting to any of the servers in the list provided. Any errors are collected in the variable name provided for the user to look at after the execution run completes.
It's a crude but effective test, as any server with a running and configured PSR endpoint will respond, and those that don't will not respond. You know that installing PowerShell and enabling PSR is part of the initial manual build process for installing OS in your environment, but even so there are a few machines that don't respond.
Note
As covered earlier in the book, you know you do not have to have PowerShell Remoting enabled in order for DSC to function; the only requirement is to have WinRM configured.
In your environment, enabling PowerShell Remoting handles setting up WinRM but also enables your ad hoc remote administration, so it's a no-brainer to use this as your opportunity to ensure it's enabled on every machine in your environment.
Invoking Enable-PSRemoting –Force on the remaining servers wouldn't be too much trouble manually, but doing so with Sysinternals psexec works quicker because you have administrator access to the target machines.
[PS]> Get-Content ./non_compliant_servers.txt | % { psexec $_ -s -h -d powershell Enable-PSRemoting –Force }
It may feel like cheating to drop down to psexec to get PSR running, but you know it won't be required much longer as all Windows 2012 R2 installs come with PSR enabled and are securely configured by default.