Chapter 1. Before you begin
Windows PowerShell is an interesting product. It’s one of the few Microsoft products that were explicitly designed for several different audiences. Within those audiences will be beginners, intermediate users, and experts, but in many cases there’s little crossover between the audience categories. Folks who use the shell as a command-line interface—tool users, in our terminology—aren’t always interested in approaching the shell in any other way. Folks who use the shell to create tools—toolmakers, as we would call them—might use the shell as a development tool most of the time and only rarely use PowerShell as an interactive command-line interface. This book is for people—primarily administrators—who are getting started in that second, toolmaking audience.
We borrowed the term toolmaking from the tool and die industry, because we think it’s a particularly apt fit for PowerShell. In that industry, there are machinists who produce a variety of different parts and products. To do so, they use tools—drill bits, dies, and so forth—which are manufactured by tool and die makers. Both audiences—machinists and the tool and die makers—utilize many of the same skills and equipment, but they do so for different reasons. Toolmakers know that the tools they make aren’t an end product but are rather a means to an end. They know their work product will be consumed by another expert, albeit an expert with a slightly different set of goals and a different inventory of skills.
In the PowerShell world, the broadest audience of shell users is just using the tools provided to them. They’re running commands and at most combining a bunch of those commands in a script to automate some complex, multistep process. Toolmakers, on the other hand, are focused less on getting a production task accomplished and more on making a reusable, packaged tool that can complete that task—and doing so in a way that enables the tool to be handed down to the tool users, who can consume the tool in their own, simpler scripts.
Sure, there’s crossover. Today, Bob might be focused on getting a bunch of new users provisioned in Active Directory. After doing that manually for a while, Bob might think, “You know, I bet I could put this all into a script that someone from Human Resources could run, and get this off of my plate entirely.” Bob has just set himself up to become a toolmaker: using PowerShell not to accomplish a task directly but instead enabling someone else—often someone less technically proficient—to accomplish the task themselves.
We use the term toolmaking instead of scripting in order to highlight what we believe is a key difference between the two. For us, a script is something you make for yourself. It might be a bit ugly, but you’re the only one who’ll know. You can make a lot of assumptions about how it will be run, because you’ll be the one running it. Scripts are often quick and dirty, and although they might be long and complicated, they’re just a way for you to automate something that only you will ever do. For a tool, on the other hand, you can make fewer assumptions. You’re going to be handing it over to someone else, and you won’t be around to babysit it. Your tool needs to be more structured and more resilient to errors. You need to check the input your tool is given to make sure it’s correct and usable. Your tool needs to be a bit more professional, and a bit more robust, than something that you’d only ever run yourself.
Toolmaking is a step below full-on software development. Toolmakers still operate entirely within PowerShell, rather than moving into, say, Visual Studio and a .NET Framework language like C#. Toolmakers still need to exhibit some of the discipline and maturity of a developer—anticipating and handling errors, validating user input, and so forth—but toolmakers work in a simpler environment than developers and often produce less-complex tools. Developers often tap into broad portions of the .NET Framework; PowerShell toolmakers rely more heavily on PowerShell commands and may not directly access the Framework at all or may do so only minimally. We admit that it’s a fine line; in the end, it becomes more about the person. If Visual Studio just ain’t your cup of tea, and you’d rather stick with a simpler, scripting-like environment, then you’re a toolmaker. Welcome aboard.
At a minimum, you should be a confident and skilled Microsoft administrator. Whether you work with Windows, Exchange Server, SharePoint Server, or even third-party products like VMware vSphere, you should know how to quickly accomplish whatever tasks you need within your chosen technology. We’re going to keep the examples in this book pretty generic, so that you can focus on the skills and techniques rather than on the technology being managed; we’ll also keep the examples very template-ized, so that you can more easily rip them apart and repurpose them for your own uses, in your own environment. Remember, the goal here is to teach you how to make tools in PowerShell, not to teach you how to accomplish tasks in Exchange or SharePoint or whatever. The skills we’re teaching are universal and can be applied to any technology that’s administered through PowerShell.
You should also have a strong background as a tool user in Windows PowerShell. You should be confident typing and running commands, dealing with command-line errors, and even stringing commands together into a simple script. If you’re not, we suggest starting with Learn Windows PowerShell v3 in a Month of Lunches (http://MoreLunches.com), which is a better way to learn those foundational skills.
Ideally, you should even have a little bit of programming or scripting in your background. Any language is fine—C++, C#, Perl, PHP, VBScript, Python, whatever. Just enough to let you recognize an if statement, to understand what a loop does, and so forth. You won’t need major programming skills in this book, and if you have zero programming background you’ll still get along just fine; having that background will just make things a teeny bit smoother for you.
Before you get started, there are a few things you need. First, make sure you’ve read “Is this book for you?” because that section describes the skills and background we’re expecting you to bring to the table.
In addition, we expect that you have access to a Windows computer that has PowerShell v3 installed. If you have PowerShell but aren’t sure if it’s v3, open it up, type $PSVersionTable, and hit Enter. The PowerShell version should be 3.0. If it isn’t, visit http://download.microsoft.com, punch “PowerShell” into the search field, and download v3 of the Windows Management Framework, the package that includes PowerShell appropriate for your operating system. We strongly recommend that your Windows computer be running either Windows 8 or Windows Server 2012, and we even more strongly recommend that you be running it in a virtual machine of some kind. That way, if you mess anything up, you’ve only messed up a virtual machine and not your real computer.
You must make sure script execution is enabled for PowerShell by running Set-ExecutionPolicy and specifying either Unrestricted or RemoteSigned, based on your organization’s preferred setting. If you do so and receive a warning that the execution policy is being set via Group Policy, make sure that the execution policy is either Unrestricted or RemoteSigned. If it isn’t one of those, contact your Active Directory administrator to discuss the situation. For this book, we’re assuming you can run scripts without needing to digitally sign them. Again, working in an off-the-domain virtual machine is a good way to resolve that problem.
For much of this book, we assume that you will have local Administrator privileges on your machine or within your test virtual machine. When you run PowerShell, the window title bar should say “Administrator”; if it doesn’t, close the shell, right-click the icon, and select Run As Administrator. If that isn’t available or doesn’t work, then you’ll need to resolve that before continuing.
Many of the tools you’ll build in this book are designed to query multiple computers. If you only have one computer to work with, you can always specify “localhost” multiple times, to simulate connecting to multiple machines. But if it’s possible to have two or three machines to work with, it makes for a more exciting experience. We used a web-based virtual lab service called CloudShare.com to set up our environment for this book. We created a domain controller in a domain named AD2008R2 and then added a client computer and a member server to that domain. That gave us three computers to play with. Figure 1.1 shows our test environment, which we’ll use throughout this book.
Note
CloudShare.com is a commercial service and has a monthly or annual fee. It isn’t the only service of its kind (you may know of others that are free or cost less), and you may well have the resources at your job to bring up a couple of virtual machines to use as a lab. Whatever you choose to do, we think it’s worth it—even the monthly fee for a service like CloudShare.com—so that you can use PowerShell in a more realistic environment. Toolmaking is a big-league set of tasks, and that means you’ll need to be willing to invest a bit in order to have the best learning experience. You can do this entire book on a single machine—but we don’t think that’ll fully prepare you for the real world. We like CloudShare.com mainly because it lets us spin up virtual machines, completely configured (even as domain controllers) in a few seconds, so it’s super convenient for us.
Note
It’s not our goal in this book to teach you how to set up a domain controller or a test environment; we expect that you already have those skills. We consider these to be baseline skills that every Microsoft network administrator should have. If you don’t have them, then it’s very likely this isn’t the right book for you.
For some of our multi-computer examples, we’re assuming that Windows Management Instrumentation (WMI) can communicate between these machines, which typically requires that they not have a local firewall blocking any ports. You may even wish to disable the Windows Firewall, or other local firewall software, on your test machine. You wouldn’t do that in a production environment, of course, but doing so in a lab environment (or a test virtual machine) will let you follow along without having to worry about complex configurations.
For other examples, we utilize PowerShell Remoting. You can enable Remoting by running Enable-PSRemoting on each of your test machines (make sure you’re running this as Administrator). We’re assuming that any multi-machine environment that you set up will have all machines in a single domain, so that Remoting will work in its simplest, default configuration. If you only have a single machine, running the command on it and always using localhost as the remote computer name (even if you use localhost multiple times) will also work, even if your single machine isn’t in a domain at all. Make sure Enable-PSRemoting completes without error.
If you need to learn more about Remoting, consider the free Secrets of PowerShell Remoting guide available at http://PowerShellBooks.com.
For portions of this book, you’re also going to need SQL Server. We recommend downloading SQL Server Express (whatever the latest version is) and that you specifically download the package that includes the Express Management Tools (sometimes, you’ll need to download SQL Server Express and independently download the matching Express Management Tools for that version—Microsoft frequently changes their mind on how they package those). That way, you’ll get both the SQL Server backend and the GUI-based management tools. Install these packages into your test computer or virtual machine using the default installation options. SQL Server Express is free, and you’ll find it at http://download.microsoft.com—just enter “sql express” into the search field.
Note that PowerShell v3 requires Microsoft .NET Framework v4; SQL Server, depending on the version you download, will also require one or more specific Framework versions. Read the prerequisites on the download page and make sure you have everything required.
If you choose to work on a Windows Server operating system, install the Windows PowerShell ISE. To do so, from the PowerShell console, run Add-WindowsFeaturepowershell-ise and wait a few minutes. No restart should be needed for that.
There are a few other things you can choose to have on hand if you want to. They’re not absolutely necessary, but if you choose to further pursue certain topics in this book, you’ll want some tools to make life easier. These include the following:
- PowerShell Studio, formerly known as PrimalForms— This will be useful in chapters 21 though 23. This is a commercial product, available through http://primaltools.com. A free trial is available.
- An XML editor— This will come in handy a few times throughout this book. We tend to hand-code XML in a text editor like Notepad, but if you get really serious with it, a dedicated editor can be useful.
- Microsoft InfoPath— If you start authoring multilanguage help files for the tools you make, then InfoPath can be an easy way to produce the necessary source files. We tend to stick with single-language comment-based help that doesn’t require XML or InfoPath, but you may feel differently when you get to chapter 9.
This book is designed to be read one chapter at a time, in order. Each chapter builds on the ones before it, so we don’t recommend skipping around, especially on your first read-through. Each chapter is sized to be readable in about an hour, and that should in most cases include enough time to complete the hands-on lab at the end of each chapter.
We can’t emphasize the benefit of the hands-on labs enough. Make sure you’re doing those. They truly help to reinforce the concepts. If you get stuck on one, hop on http://bit.ly/AskDon and ask for help. You can also visit http://MoreLunches.com, click this book’s cover image, and download sample lab answers. But don’t peek until you’ve at least given the lab a shot on your own! The website will also direct you to additional supplementary resources, including bonus chapters, tools, narrated demo videos, and more.
Finally, stick with the one-chapter-a-day program. It can be tempting to zoom through the book, but trust us: By reading one chapter a day, you’re giving your brain time to process the day’s learning in the background. If you feel ready to move forward the next day, do one more chapter. If not, reread the previous day’s chapter and let your brain process it a bit. Hop online (http://bit.ly/AskDon) and ask questions to clarify any problems or sticking points. Above all, don’t move on to the next chapter until you’re sure you’ve gotten the previous one completely. The goal here is for you to be successful and learn something, not to just race to the end of the book!
Your Month of Lunches starts with the very next chapter. Good luck!