This chapter is from the book
This chapter is from the book
This chapter is from the book
Q&A
Q. I know that many PowerShell cmdlets have a -WhatIf flag that allows you to test a cmdlet before it runs. Is there a command or parameter we can use to verify that DSC is functioning on a node?
A. Yes, indeed. You’ll want to run Test-DscConfiguration -Verbose to instruct Windows PowerShell to process all of its DSC scripts; the output returns True if all tests pass.
Q. Will you please look at my script? I ran the following two lines of code:
PS C:> .\LCMConfig.ps1
PS C:> SetupLCM -NodeName “dscclient01”
and got a bunch of red error text, as shown in Figure 18.10. What’s the problem?
Figure 18.10 You need to understand the implications of “dot sourcing” your Windows PowerShell scripts.
A. The dot-slash (.\) notation simply tells PowerShell to run the present command from the current working directory and nothing more. This means that running a PowerShell script in this way runs the code contained inside the script but removes any functions, variables, and so forth from the session immediately thereafter.
Dot sourcing occurs when you type a period (.) and then type a partial or full path to a PowerShell script. (Don’t forget to put quotes around the script path, including the dot slash.) The key difference with dot sourcing is that any objects defined inside the script persist in the user’s current runspace. This allows us to run the DSC configuration script manually as was depicted in Figure 18.10.
Q.What is the suggested configuration refresh frequency for DSC?
A. How you configure your nodes’ LCM component, and particularly the ConfigurationFreq uencyMins property value, depends entirely on how much tolerance for configuration drift you have.
DSC network traffic is relatively low compared to, say, Group Policy. However, many Windows administrators are cool with setting refresh to 48 hours because the likelihood that a server will fall out of compliance may not be particularly high.
)