You're reading from Windows Server 2016 Automation with PowerShell Cookbook - Second Edition
Troubleshooting is the art and science of discovering the cause of some problem in your organization's computing estate and providing a solution that overcomes the problem. Troubleshooting encompasses a variety of tasks.
One common issue to begin this chapter with is troubleshooting network connectivity. With applications and services increasingly being networked and with the proliferation of wireless devices, network connectivity can be a problem in many organizations. In the first recipe, you look at some commands that can help you to troubleshoot this area.
Microsoft has built a troubleshooting framework into both Windows 10 and into Server 2016. These troubleshoots enable common problems to be resolved by an IT pro just running the troubleshooter. And for the really adventurous ones, you could even build your own troubleshooter, but such details are outside the scope of this book.
Troubleshooting is not just what you do when an issue arises. It also involves being proactive...
One of the first troubleshooting tasks is checking the network connectivity between a client (or server) computer and another server computer. The client and server computers can be on the same physical subnet, or thousands of miles away and separated by routers. In order to provide a successful service to a client, your infrastructure needs to enable clients to connect to.
Traditionally, you might have used tools including Ping
, Tracert
, and Pathping
. You can continue to use these Windows console applications within PowerShell—they work the way they have always worked. You may find even more useful, two newer cmdlets available with Windows Server 2016 which have additional useful features. The cmdlets also return output as objects which makes it easier to utilize the cmdlets on a PowerShell script.
This recipe uses one console command (Ping.exe
, or just Ping
in PowerShell) and two cmdlets, Test-Connection
and Test-NetConnection
. The Test-Connection
is an older...
Windows includes a number of troubleshooting packs. These are tools that you can use to diagnose and resolve common errors.
In this recipe, you see how to use the troubleshooting packs:
- Get troubleshooting packs:
$TSPackfolders = Get-ChildItem `
-Path C:\Windows\diagnostics\system -Directory
$TSPacks = Foreach ($TSPack in $TSPackfolders) {
Get-TroubleshootingPack -Path $TSPack.FullName}
- Display the packs:
$TSPacks | Format-Table -Property Name, Version,
MinimumVersion, Description `
-Wrap -Autosize
- Get a troubleshooting pack for Windows Update:
$TsPack = $TSPacks | Where-Object `
id -eq 'WindowsUpdateDiagnostic'
- Look at the problems this troubleshooting pack addresses:
$TSPack.RootCauses
- Look at the solutions to these issues:
$TSPack.RootCauses.Resolutions...
In IT, the term best practices refers to guidelines setting out the best way to configure a server or application as defined in subject matter experts (such as the application's development and support teams). Some best practice recommendations may not apply or be relevant. Following best practice can both solve existing issues and avoid future ones, but a bit of common sense is needed to ensure you are following the advice that is relevant for you and your organization.
A best practice model is a set of specific guidelines. A BPA is an automated tool that analyzes your infrastructure and points out areas where it the environment is not compliant with the best practice model.
Windows provides a built in BPA framework, complete with PowerShell support for managing the BPA process. Windows and applications come with a number of BPA models. The PowerShell cmdlets let you find the BPA models, invoke them, and then view the results.
Since not all BPA model guidelines are...
Windows computers maintain a set of event logs that document events that occur on a given machine. Any time an event occurs, the application or service can log events which can then be used to help in the debugging process.
In Windows, there are two types of event logs: Windows logs and application and services logs. Windows logs began with Windows NT 3.1 and continue in Windows Server 2016 and are important components in troubleshooting and system monitoring.
Windows Vista added a new category of logs, application and services logs. These logs contain events that are within a single application, service, or other Windows component. Windows comes by default with a set of application and service logs—adding components such as new Windows features or roles often results in additional application and service logs.
These logs give you a great picture of what your system is actually doing. Additionally, you can also add new event logs and enable scripts to log events which occur...
By default, every Windows computer in your organization keeps its own local event logs. You examined these logs in the Searching event logs for specific events recipe. The logs on SRV1
, for example, are separate from the logs on DC1
. In larger environments, analyzing event logs across large number of servers is complex. With 100 servers, you would need to run a script on each of those 100 servers, which could become quite complex. Having each server forward events to a central computer can simplify this task greatly.
Also consider what happens if a server is compromised. Hackers often clear event logs after doing naughty things on a hacked machine. This helps to cover the hacker's tracks. A best security practice is to get the event details sent to a central and hopefully more secure server as quickly as possible. With Windows, you can use using event forwarding to achieve this.
Forwarding event logs to a central server allows you to centralize your log...