Website under construction

Figure 5-4:
Remote debugger in action 
Job debugging 
One useful function in Windows PowerShell is the ability to execute scripts as background jobs. These 
jobs can run without clogging up the main console screen, letting you proceed with additional tasks. 
This was fine, but these jobs could sometimes be difficult to troubleshoot and could require a lot of 
trial and error in order to develop robust scripts that could truly be run as jobs. 
Now, with Server 2016, Windows PowerShell introduces the Debug-Job cmdlet, which gives you the 
ability to debug these background jobs more effectively. Figure 5-5 shows this cmdlet being used. 
Note how Debug-Job shows you the line and character at which the job broke. 

---

140 
CHAPTER 5 | Systems management 
Figure 5-5:
The Debug-Job cmdlet outputting an error in a background job 
To get to this break state, the same cmdlet Set-PSBreakPoint or Wait-Debugger is used to “pause” the 
script and enter the debugger. You can type these cmdlets into your script and then verify the state of 
the job so that you can verify if it has encountered the breakpoint and is ready to debug. Figure 5-6 
shows you a sample of this. 
Figure 5-6:
Background Job State
Runspace debugging 
Runspaces
were introduced to solve a few problems that background jobs had introduced, such as 
resources issues and performance problems. Runspaces are different from jobs in that they generate a 
new thread of execution for the environment which doesn’t come with the same overhead as a 
background job. 
More info For more information on runspaces and how to use them, go to 
http://blogs.technet.microsoft.com/heyscriptingguy/2015/11/26/beginning-use-of-powershell-
runspaces-part-1/
. 
Figure 5-7 depicts a runspace being created. 
Figure 5-7:
Creating a runspace 
Much like jobs, to debug a runspace, you need to obtain its “ID.” Figure 5-8 shows the available 
runspaces and then entering the debug session using the Debug-Runspace cmdlet. 
Figure 5-8:
Debugging a runspace 

---

141 
CHAPTER 5 | Systems management 
The first runspace, ID 1, is always the original Windows PowerShell session you are in. Use the 
previous referenced link to dive deeper into runspaces for your environment. 
Desired State Configuration 
Windows PowerShell Desired State Configuration (DSC) is a hot topic nowadays. DSC is a new 
configuration management platform with which administrators can use Windows PowerShell for 
deploying and managing software services and also for managing the environment in which these 
services run. Windows Server 2016 introduces several improvements to DSC, and in this chapter, we 
dive into two of these enhancements: the new Local Configuration Manager and a new partial 
configuration feature.