Book Image

Windows Server 2012 Automation with PowerShell Cookbook

By : EDRICK GOAD
Book Image

Windows Server 2012 Automation with PowerShell Cookbook

By: EDRICK GOAD

Overview of this book

Automating server tasks allows administrators to repeatedly perform the same, or similar, tasks over and over again. With PowerShell scripts, you can automate server tasks and reduce manual input, allowing you to focus on more important tasks. Windows Server 2012 Automation with PowerShell Cookbook will show several ways for a Windows administrator to automate and streamline his/her job. Learn how to automate server tasks to ease your day-to-day operations, generate performance and configuration reports, and troubleshoot and resolve critical problems. Windows Server 2012 Automation with PowerShell Cookbook will introduce you to the advantages of using Windows Server 2012 and PowerShell. Each recipe is a building block that can easily be combined to provide larger and more useful scripts to automate your systems. The recipes are packed with examples and real world experience to make the job of managing and administrating Windows servers easier. The book begins with automation of common Windows Networking components such as AD, DHCP, DNS, and PKI, managing Hyper-V, and backing up the server environment. By the end of the book you will be able to use PowerShell scripts to automate tasks such as performance monitoring, reporting, analyzing the environment to match best practices, and troubleshooting.
Table of Contents (19 chapters)
Windows Server 2012 Automation with PowerShell Cookbook
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

Managing security on PowerShell scripts


Due to the powerful capabilities of PowerShell, maintaining a secure environment is important. Executing scripts from untrustworthy sources could damage data on your system and possibly spread viruses or other malicious code. To deal with this threat, Microsoft has implemented Execution Policies to limit what scripts can do.

Note

The execution policies only limit what can be performed by scripts, modules, and profiles, these policies do not limit what commands are executed in the interactive runtime.

How to do it...

In this recipe, we will view the system's current execution policy and change it to suit various needs. To do this, carry out the following steps:

  1. To find the system's current execution policy, open PowerShell and execute Get-ExecutionPolicy.

  2. To change the system's execution policy, run Set-ExecutionPolicy <policy name> command.

  3. To reset the execution policy to the system default, set the policy to Undefined.

  4. To change the execution policy for a specific session, go to Start | Run and enter PowerShell.exe –ExecutionPolicy <policy name>.

How it works...

When a script is executed, the first thing PowerShell does is, determine the system's execution policy. By default, this is set to Restricted, which blocks all the PowerShell scripts from running. If the policy allows signed scripts, it analyzes the script to confirm it is signed and that the signature is from a trusted publisher. If the policy is set to unrestricted, then all the scripts run without performing checking.

Setting the execution policy is simply done via the command. Here we see several examples of viewing and setting the execution policy to various settings. There are six execution policies as follows:

  • Restricted: No scripts are executed. This is the default setting.

  • AllSigned: This policy allows scripts signed by a trusted publisher to run.

  • RemoteSigned: This policy requires remote scripts to be signed by a trusted publisher.

  • Unrestricted: This policy allows all scripts to run. It will still prompt for confirmation for files downloaded from the internet.

  • Bypass: This policy allows all scripts to run and will not prompt.

  • Undefined: This policy resets the policy to the default.

When changing the execution policy, you will be prompted via a command line or pop-up window to confirm the change. This is another level of security, but can be disabled by using the –Force switch.

There's more...

  • Approving publishers: When running scripts from new publishers, there are two primary methods for approving them. The first method is to open the certificates MMC on the local computer and import the signer's CA into the Trusted Publishers store. This can be done manually or via a group policy. The second method is to execute the script, and when prompted, approve the publisher.

  • Defining execution policy via GPO: The execution policy for individual computers, groups, or enterprise can be controlled centrally using group policies. The policy is stored under Computer Configuration | Policies | Administrative Templates | Windows Components | Windows PowerShell. Note however that this policy only applies to Windows 7/2008 or newer operating systems.

  • Permissions to change the execution policy: Changing the execution policy is a system-wide change, and as such requires administrator level permissions. With Windows default access controls in place, this also requires you to start PowerShell as an administrator.

    Changing the execution policy requires elevated permissions to run, so you may need to open PowerShell with Run as administrator to set the policy. If you are attempting to change the policy without sufficient permission, an error will be returned.

Tip

Best practice is to enforce some level of signature checking in most environments. In Dev/Test environments, it may be common to set the policy to Unrestricted to expedite testing, but it is always suggested to require fully signed scripts in production environments.