Book Image

Enterprise PowerShell Scripting Bootcamp

By : Brenton J.W. Blawat
Book Image

Enterprise PowerShell Scripting Bootcamp

By: Brenton J.W. Blawat

Overview of this book

Enterprise PowerShell Scripting Bootcamp explains how to create your own repeatable PowerShell scripting framework. This framework contains script logging methodologies, answer file interactions, and string encryption and decryption strategies. This book focuses on evaluating individual components to identify the system’s function, role, and unique characteristics. To do this, you will leverage built-in CMDlets and Windows Management Instrumentation (WMI) to explore Windows services, Windows processes, Windows features, scheduled tasks, and disk statistics. You will also create custom functions to perform a deep search for specific strings in files and evaluate installed software through executable properties. We will then discuss different scripting techniques to improve the efficiency of scripts. By leveraging several small changes to your code, you can increase the execution performance by over 130%. By the end of this book, you will be able to tie all of the concepts together in a PowerShell-based Windows server scanning script. This discovery script will be able to scan a Windows server to identify a multitude of components.
Table of Contents (21 chapters)
Enterprise PowerShell Scripting Bootcamp
Credits
About the Author
About the Reviewer
www.PacktPub.com
Customer Feedback
Preface
3
Working with Answer Files
Index

Chapter 3. Working with Answer Files

As you continue developing the Windows server scanning script, you may run into scenarios where you need to modify your script to run in different environments. While it's fairly low risk to modify code in a one or two-line script, large enterprise scripts require a better structure and process. The general rule of thumb is that if you need to adjust values in your script for different scenarios, you should put those values into an answer file. The contents of the answer file are read during runtime, and those values are used as input into the script. This provides another layer of stability to your scripts because you're not adding risk by modifying code in the script itself.

There are many different formats for answer files. The industry standard with .NET programs are XML-based answer files. This is due to their ability to have file format integrity built into the standards for XML. If the answer file is not formatted properly, it will not be possible...