1. Getting Started
Its early Friday morning, and you are still waking up from a cozy sleep when your phone rings. Its the company that you work for, informing you that a primary server is having problems and not functioning as expected. So, time to wake up and figure out what happened to the server.
Did it get rebooted? Was a patch installed last night? And, ultimately, what changed? That is always the big question: What changed?
With tools like Windows PowerShelland the release of PowerShell Web Accessyou can now start troubleshooting and, hopefully, start resolving Windows problems from outside your network.
This book is dedicated to essential first steps to help the IT administrator start troubleshooting Windows Server and figure out what changed. The first tool used should not be the built-in GUI tools; it should be PowerShell, especially as more things happen with Windows that dont involve the graphical user interface. PowerShell allows the IT administrator the ability to remotely troubleshoot a server and figure out what happened.
Note
All of the source code used in this text is separated by chapter and made available online by visiting http://www.apress.com/971484218501 .
This chapter kicks things off the book and gives you, the reader, a chance to see the authors style and how we use PowerShell. Since PowerShell is a product that helps manage other products that make life easier for Windows system administrators, it does not have just one use. While working on this project, several alternate methods of doing things with Active Directory came suddenly to mind. Some of them sped up things that we were used to doing another way.
This book is meant to be a reference tool; this chapter is just a warm up for the things to come. Enjoy the ride.
Getting to Know PowerShell
Having a set of PowerShell commands at the ready will help when you get that phone call. So the first thing to look at is how long the computer has been running. So, you type the following command:
Get-WmiObject Win32_OperatingSystem -ComputerName Server1 | Select-Object @{Name = 'LastStartTime' ; Expression = {[Management.ManagementDateTimeConverter]::ToDateTime($_.LastBootUpTime)}}
But realistically, that command isnt one that you can quickly remember and understand at 3:00 AM. You were ready for this, though, and you created a function that allows the same command with shorter syntax, something like this:
Function Get-TSUptime {
param ($ComputerName = $env:COMPUTERNAME)
$WmiOS = Get-WmiObject Win32_OperatingSystem -ComputerName $ComputerName
[Management.ManagementDateTimeConverter]::ToDateTime($WmiOS.LastBootUpTime)
}
It is much easier to type Get-TSUptime rather than the first example.
In this book, we will talk about how to get the basic information and how to convert some of the commands into functions. Once you have a lot of functions, you can build modules of common functions.
This book is designed to help you write your own PowerShell commands and use them to troubleshoot your environment. Because each environment is unique, this book helps you figure out what your organization needs.
What works for one company, may not necessarily work elsewhere. This book lets you know what to monitor and how to set up some of your troubleshooting tools.
Much of PowerShell is backward compatible to allow scripts written on a Windows 10 computer to operate in previous versions of Windows. We have tested the examples in this book with Windows 10 , Server 2016 , Server 2012 R2 , and Windows 8.1. It is possible that many of these scripts will work in other versions of the operating system, but we have not tested them there. In addition, the examples provided here are as is with no warranty provided. Use them at your own riskpreferably in a lab to help you build tools that you can then use in production. We have done testing, but your mileage may vary depending on your environment. Some PowerShell cmdlets will only be available in later versions and we will make sure to mention which cmdlets work with what versions of operating systems.
This book is not the definitive answer to troubleshoot all Windows problems, but rather a guide to help you build your own tools.
GUI Tools vs. PowerShell
Microsoft has shipped GUI tools to administer Windows and other applications for as long as Windows has been around. Active Directory Users and Computers (ADUC ) is a great example of one of these tools. How does it stack up against PowerShell? Lets find out.
Lets open ADUC and PowerShell to examine the differences. We need to make a couple of assumptions to get started. To follow along completely, you should run Active Directory Domain 2012 and your client computer should be Windows 8.
Note
Windows Server 2012 and Windows 8 are no longer the current release. We will try to stay with the currently released version of both the server and client OS where possible. When we deviate from that, we will point it out, but in general, you should assume our examples are Windows 10 and Windows Server 2012 R2.
You should also have Remote Server Admin Tools installed because, lets face it, ADUC isnt part of the default tools on a client operating system. You can find the tools at http://www.microsoft.com/en-us/download/details.aspx?id=39296 .
So, quickly modify a users description and go!
Using ADUC: (1) Right-click your Active Directory domain. (2) Click Find. (3) Enter the users login name. (4) Right-click the user name. (5) Click Properties. (6) Click in the Description field and enter a description. (7) Click OK. (8) Close the Find window.
Note
By the way, using Active Directory Administrative Center (ADAC), introduced in Windows Server 2008, is faster than ADUC. Most people running a 2008 domain do not use this new and improved GUI. In some cases, the older tools work just as well; in other cases, people have simply not heard of the new tools. Search for ADAC or Active Directory Administrative Center to check it out.
See how easy that was? Now lets try the same thing in PowerShell.
Using PowerShell, type Set-ADUser djacobs -Description 'Sales at BigCompany' and hit Enter. Done!
So, which way is faster?
In many cases, PowerShell will be faster once you get the hang of it, but there is a bit of a learning curve to the new method. We will do our best to help you get moving with the command syntax for troubleshooting Windows. After reading this book, we hope that you will be inclined to first try things with PowerShell and only use the GUI to check your work.
For those of you who have touched PowerShell before and are curious why we didnt import any modules to run the previous code, PowerShell versions 3 and higher do not require the modules to be imported first; you can load them on the fly when cmdlets are used. For those of you who dont know what a cmdlet or a module are, keep reading.
Another example is when someone in your organizations HR department gives you an Excel file and they want you to update several fields for all users: telephone numbers, offices, descriptions, titles, and managers. Using ADUC, you can spend days updating those fields for all of your users, depending on the size of the environment. And, for those of you with many users, we hope that it doesnt take you days to complete.