Setting up a common installation base

With all your target machines up and configured for remote access, you move on to looking at what your common base installation should look like. Since you've been doing this stuff manually by yourself for a long while, you know by heart what needs to be installed on every server and configured.

Looking back at this book as you go, you jump right into making a DSC configuration for your base setup. Since the custom software your company develops uses Roman names for code names for releases, you decide to name your configuration Pantheon and author the following DSC configuration script:

Configuration PantheonDeployment
{
  Import-DscResource -Module xRemoteDesktopAdmin
  Import-DscResource -Module xTimeZone
  Import-DscResource -Module xComputerManagement
  Import-DscResource -Module xSystemSecurity

  Node ($AllNodes).NodeName
  {
    LocalConfigurationManager
    {
      ConfigurationId      = $Node.ConfigurationId
      RefreshMode          = $Node.RefreshMode
      ConfigurationMode    = $Node.ConfigurationMode
      AllowModuleOverwrite = $Node.AllowModuleOverwrite
      RebootNodeIfNeeded   = $Node.RebootNodeIfNeeded
    }

    xComputer NewName
    {
      Name = $Node.MachineName
    }

    xTimeZone UtcTimeZone
    {
      TimeZone         = 'UTC'
      IsSingleInstance = 'Yes'
    }

    xRemoteDesktopAdmin RemoteDesktopSettings
    {
      Ensure             = 'Present'
      UserAuthentication = 'NonSecure'
    }

    xIEEsc DisableIEEscAdmin
    {
      UserRole  = 'Administrators'
      IsEnabled = $false
    }

    xIEEsc EnableIEEscUser
    {
      UserRole  = 'Users'
      IsEnabled = $true
    }

    xUac SetDefaultUAC
    {
      Setting = 'NotifyChanges'
    }

    WindowsFeature TelnetClient
    {
      Ensure = "Present"
      Name   = "Telnet-Client"
    }
  }
}

$data   = Join-Path $PSScriptRoot 'data_example_01.psd1'
$output = Join-Path $PSScriptRoot 'PantheonDeployment'
PantheonDeployment -ConfigurationData $data -OutputPath $output

The previous code is nothing too fancy and mostly in line with what you have learned throughout this book. The only thing out of the ordinary is that we are changing the name of the target node. After testing this, you find that renaming the target node requires a reboot, which by default, DSC does not do. To handle this, you add the RebootNodeIfNeeded property to your ConfigurationData hash so that DSC will reboot the host and continue working after it has come up.

You know there are more things you can add here, but this is a good start, so you stick with it. By using snippets from this book, you can wrap it up in a PowerShell script that accepts a ConfigurationData hashtable like this one:

@{
  AllNodes = @(
    @{
      NodeName        = 'app01'
      ConfigurationId = 'ab2c2cb2-67a3-444c-bc55-cc2ee70e3d0c'
    },
    @{
      NodeName        = 'app02'
      ConfigurationId = '8e8f44e6-aaac-4060-b072-c9ae780ee5f7'
    },
    @{
      NodeName             = '*'
      RefreshMode          = 'Push'
      ConfigurationMode    = 'ApplyAndAutoCorrect'
      AllowModuleOverwrite = $true
      RebootNodeIfNeeded   = $true
    }
  )
}

You can use the approaches outlined in Chapter 5, Pushing DSC Configurations, to compile and push your DSC configurations to your target nodes. You occasionally check to see that DSC has kept the servers in the state they should be in, but you know you don't have to thanks to the ApplyAndAutoCorrect configuration mode you set the LCM to. With this setting, the LCM constantly monitors the state of your servers for drift and keeps them in compliance even if you're not looking, whether you are using push deployments or Pull Servers.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset