Traditionally, with Windows PowerShell, you have two main ways of accessing PowerShell: the PowerShell console and the Windows PowerShell ISE. The ISE was popular and was designed to be extendable.
Developers could also host and access the PowerShell engine. This architecture allows an application to leverage PowerShell. For more details on hosting PowerShell, see https://packt.link/CQAVf.
The ISE, however, does not support PowerShell 7 and Microsoft has developed an outstanding replacement, the Microsoft Terminal. You can use this as a high-fidelity way to access Windows PowerShell and PowerShell 7.
The PowerShell console
In the early versions of PowerShell, the Windows PowerShell console was the only way to access it. Strictly speaking, the console is an application (conhost.exe) that exposes the Windows PowerShell engine to the end user and looks like this:
Figure 2.15 – PowerShell console
The Windows PowerShell Integrated Scripting Environment (ISE)
Microsoft first introduced the ISE with Windows PowerShell V2 but made substantial improvements with Windows PowerShell V3. The ISE combines a good script editor with a console window. In Windows, this application is at C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell_ise.exe.
It’s worth noting that while you can continue to use the ISE, Microsoft has ceased active development of the product. The replacement is Visual Studio Code.
The ISE is a good tool that enables you to create, test, and use PowerShell scripts. The ISE looks like this:
Figure 2.16 – The ISE
Windows Terminal
The original console application did not allow Microsoft to extend the console. As a replacement, Microsoft developed Windows Terminal. The goal was to create a great terminal, capable of hosting cmd.exe, Windows PowerShell, and PowerShell 7 (and more). The terminal also supports a tabbed interface.
The terminal looks like this:
Figure 2.17 – Windows Terminal
Windows 11 also allows you to use the console or Windows Terminal. You access this by using the Windows 11 Settings apps and navigating to the For developers page, like this:
Figure 2.18 – Terminal settings
For a more detailed overview of Windows Terminal, see https://packt.link/BQi45.
Microsoft Visual Studio Code
As part of the move away from the Windows PowerShell ISE, Microsoft launched a new tool, Visual Studio Code. Visual Studio Code looks a bit like the ISE, with a three-pane layout (folders and files on the left, an editor pane in the top right, and the terminal in the bottom-right pane).
Visual Studio Code looks like this:
Figure 2.19 – Visual Studio Code
Visual Studio Code is not loaded into Windows 11 by default, but you can use the Windows Store to install the product. You can also download the latest versions directly from GitHub at https://packt.link/Y5CEr. Or you can use your favorite package manager to install Visual Studio Code.
For more information on Visual Studio Code or to download the product, see https://packt.link/QfvFZ. Once installed, Visual Studio Code detects available updates and prompts you to install them.
One great feature of Visual Studio Code is the extension architecture. This allows you to add a huge range of extensions, greatly enhancing your usage. For example, you can add a spell-checker, a great drawing package, Git Integration, and support for Markdown. For more details on the available extensions and how to manage Visual Studio Code extensions, see https://packt.link/K13Jv.
Desired State Configuration
Desired State Configuration (DSC) is a management framework in Windows PowerShell that provides a standardized way of defining a system’s DSC. This enables the complete automation of device configuration using a declarative model: you create a configuration that states how a device should be configured, publish that configuration, and then wait for the devices to update themselves to match the configuration. DSC, as described here, is only available using Windows PowerShell.
A single configuration can be used across multiple devices, ensuring all hosts have identical and standardized settings. DSC prevents configuration drift when numerous changes occur over time.
DSC supports two deployment methods:
- Push mode: In this mode, the administrator makes the configurations and manually pushes them to the target devices. Push mode is one-way communication and can only work if the devices are available on the network during the push. This option best suits small environments where all devices are always connected. It also assumes that the appropriate PowerShell modules are available on all devices.
- Pull mode: In this mode, the administrator creates a pull server that hosts the configuration information. You then configure each device to contact this server at regular intervals (such as every 15 minutes) to look for any configuration changes. The device can pull the DSC data and any required modules if found. Using pull mode allows you to automate the deployment of configurations to a high frequency and doesn’t require further interaction from the administrator.
DSC, in Windows PowerShell, has both a configuration and a resource side, and a configuration manager runs the show between the two:
- Configurations: These are PowerShell scripts that define and configure the resources. The DSC engine will examine the configuration to ensure the system adopts the desired state.
- Resources: A resource is a code that keeps the target of a configuration in a specific state. By default, DSC has several resources, which you can see by running the
Get-DSCResource cmdlet. These are typically in Windows PowerShell modules:
Figure 2.20 – Getting DSC resources
- Local Configuration Manager (LCM) runs on the local device to ensure the configuration is applied correctly. The LCM polls the system to ensure that the state defined by the configuration is maintained, and corrects any errors.
An example of how you would use DSC configurations would be to prevent a specific process from running or having a registry key or security policy set in a particular way to meet your security requirements.
Use the official Microsoft DSC resource kit for more advanced configuration: https://packt.link/ZpjZw.
At the time of writing, DSC does not provide the rich features available with Windows PowerShell. Beginning with PowerShell V 7.2, PowerShell no longer ships with the PSDesiredStateConfiguration module as part of the PowerShell 7 download. This has allowed a separate DSC team to invest in and develop DSC independently of PowerShell (and has the benefit of reducing the size of the overall PowerShell download package).
While you can do some DSC-based configuration, DSC for PowerShell 7 does not currently include the richness available in Windows PowerShell. For more details on DSC and Powershell, see https://packt.link/CBsp0.
Free Chapter
