Why PowerShell? Why scripting?, Study Guides, Projects, Research of Computer Science

Download Why PowerShell? Why scripting? and more Study Guides, Projects, Research Computer Science in PDF only on Docsity!

Table of Contents

ReadMe

About this Book

A Brief Overview

Why Scripting? Why a Shell?

Why PowerShell?

The Business Story

Where Can You Learn More?

Why PowerShell Remoting? (While we're answering "Whys")

Why PowerShell?

By Warren Frame and Don Jones

An incredibly concise look at why Windows PowerShell is important, from both a technical and business perspective.

This guide is released under the Creative Commons Attribution-NoDerivs 3.0 Unported License. The authors encourage you to redistribute this file as widely as possible, but ask that you do not modify the document.

Was this book helpful? The author(s) kindly ask(s) that you make a tax-deductible (in the US; check your laws if you live elsewhere) donation of any amount to The DevOps Collective to support their ongoing work.

Check for Updates! Our ebooks are often updated with new and corrected content. We make them available in three ways:

Our main, authoritative GitHub organization, with a repo for each book. Visit https://github.com/devops-collective-inc/ Our GitBook page, where you can browse books online, or download as PDF, EPUB, or MOBI. Using the online reader, you can link to specific chapters. Visit https://www.gitbook.com/@devopscollective On LeanPub, where you can download as PDF, EPUB, or MOBI (login required), and "purchase" the books to make a donation to DevOps Collective. You can also choose to be notified of updates. Visit https://leanpub.com/u/devopscollective

GitBook and LeanPub have slightly different PDF formatting output, so you can choose the one you prefer. LeanPub can also notify you when we push updates. Our main GitHub repo is authoritative; repositories on other sites are usually just mirrors used for the publishing process. GitBook will usually contain our latest version, including not-yet-finished bits; LeanPub always contains the most recent "public release" of any book.

About this Book 4

A Brief Overview

PowerShell etnhusiasts often find themselves explaining why someone with responsibilities on the Microsoft side of the IT shop should learn PowerShell. We decided to write this as a reference going forward.

We won’t be arguing for PowerShell over other Microsoft languages such as VBScript or batch, or general purpose languages such as Python or Perl. There is a place for all of these languages, but if you work with the Microsoft and surrounding ecosystems, PowerShell is an important language to learn.

What's also important to understand is that Microsoft has made an enormous commitment to PowerShell. It isn't going away, and indeed the company is building more and more of their management solutions on top of it. To a degree, Microsoft is even backing off from building management tooling, knowing that you can use PowerShell to build your own tools. That's significant.

But let's move on.

A Brief Overview 5

Why PowerShell?

Microsoft describes PowerShell as “a task-based command-line shell and scripting language… built on the .NET Framework.” What is so great about PowerShell? Why should you use it?

PowerShell is both a command-line shell and

scripting language

Fight fires quickly using existing or custom PowerShell commands or scripts at the shell, no need to compile code. Develop your code at the command line before creating a function or script around it. Write quick and dirty scripts that you will use a single time or a handful of times. Write formal, readable, production level scripts that will maintain your services for years.

What is the cost of this investment? Learning PowerShell. Pretty reasonable, considering you will likely need to do so regardless of your current language of choice, assuming you work with the Microsoft ecosystem.

PowerShell can interact with a dizzying number

of technologies.

The .NET Framework, the Registry, COM, WMI, ADSI. Exchange, Sharepoint, Systems Center, Hyper-V, SQL. VMware vCenter, Cisco UCS, Citrix XenApp and XenDesktop. REST APIs, XML, CSV, JSON, websites, Excel and other Office applications. C# and other languages, DLLs and other binaries, including Linux or Unix tools. A language that can work with and integrate these various technologies can be incredibly valuable.

Windows is not text based. Sooner or later you will need to do something that you can’t do with -nix tools and other text based languages. Many of the technologies that PowerShell can interact with simply do not have text based interfaces, and may not even be directly accessible from more formal languages like Perl or Python.

The moral here is that PowerShell is the best "glue" Microsoft has ever provided us for tying together disparate systems. It's better than previous Windows-based shells because it understands, and works with, the API-based nature of Windows itself, which is vastly different from what previous text-based shells did.

Why PowerShell? 7

PowerShell is object-based.

This gives us incredible flexibility. Filter, sort, measure, group, compare or take other actions on objects as they pass through the pipeline. Work with properties and methods rather than raw text.

If you have spent time deciphering and programmatically working with text based output, you know how frustrating it can be. What delimiter do I split on? Is there even a delimiter? What if a particular result has a blank entry for a column? Do I need to count characters in each column? Will this count vary depending on the output? With objects, this is all done for you, and makes it quite simple to tie together commands and data across various technologies.

PowerShell isn’t going away.

Microsoft is putting its full weight behind PowerShell.

PowerShell support is a requirement in the Microsoft Common Engineering Criteria, and a Server product cannot be shipped without a PowerShell interface. That means very few Microsoft server products can't be managed by PowerShell - and the few that can't, will be able to soon.

Vendors other than Microsoft have strong support for PowerShell. This includes IBM, Cisco, Citrix, VMware, NetApp, Dell, and dozens more.

In many cases Microsoft uses PowerShell to build the GUI management consoles for its products. Some tasks can’t be performed in the GUI and can only be completed in PowerShell. This is a big deal: In an increasing number of situations, you can't manage the product fully unless you use PowerShell. That applies to cloud-based offerings like Azure and Office 365, too.

Consolidate and multiply your learning

Your reward for learning PowerShell is the improved ability to control and automate the many technologies it integrates with. You can use the same set of commands to filter, export, redirect, modify, extend, and perform actions against output for all of these technologies. You can pick up PowerShell skills and take them in any direction you need - Hyper-V, vCenter, SQL, AD, XenApp, and more.

Your reward for learning specific tools or executables such as net.exe or schtasks.exe, is the ability to work with those specific tools. With PowerShell, your learning investment blossoms into an enormous ecosystem of capability.

Why PowerShell? 8

The Business Story

If you've ignored PowerShell up until now, or were skeptical about it, let's look at what Microsoft has done.

In version 1 , PowerShell emerged as a the first management interface specifically designed for administrative automation.

In version 2 , PowerShell gained native remote management capabilities, enabling remote management of any server or client running PowerShell. PowerShell's "reach" extended to hundreds of management APIs, enabling real-world management. The product also matured a deceptively simple, powerful scripting language that can be used to build professional- grade units of automation.

In version 3 , PowerShell learned to run long-running tasks in a disconnected, stateless fashion - called workflows. The product's reach extended even further, covering all major Microsoft server platforms, and pushing into Microsoft's cloud offerings. By this version, PowerShell was a very real thing, so much so that many Microsoft native GUIs began to use PowerShell "under the hood."

In version 4 , PowerShell was extended with even more "reach," and gained a new technology: Desired State Configuration. DSC lets administrators describe, in more-or-less plain text, how a computer should be configured. Leveraging the existing investment in PowerShell, DSC then puts the machine into that state, and keeps it there.

In version 5 , PowerShell matured DSC and extended its "tool making" capabilities into professional developer space. With support in Visual Studio, PowerShell started to span a much broader spectrum of user, from entry-level administrators to advanced developers.

The point is that Microsoft has clearly been building PowerShell since its v1 release in 2006. They've done so in a way that they've never done before in languages like VBScript, and they've done so while maintaining consistency and efficiency.

What's more, PowerShell has inspired a broad ecosystem of supporting vendors, and an enthusiastic global community. Administrators are, more than ever, able to get assistance, answers, and even ready-made solutions from those vendors and that community.

The Business Story 10

Where can you learn more?

There is a wealth of information on PowerShell.

Start at PowerShell.org, a community-owned and -operated web site that hosts a friendly Q&A forum. The organization also offers numerous free ebooks, runs the annual PowerShell Summit event in North America and Europe, hosts a DSC GitHub repository, runs an annual Scripting Games contest, and much more. Anyone with development or scripting experience should pick up PowerShell in Action v2. It’s written by the co-designer and principle author of PowerShell, Bruce Payette, and is the standard reference. It provides the best depth you will get short of verbose articles on the web, gives insight into some of the design decisions behind the language, and is perfectly applicable today despite being written for PowerShell v2. Windows PowerShell for Developers is more narrowly focused but a good read for the experienced. Those without scripting or development experience might want to start with lighter reading, such as Learn Windows PowerShell in a Month of Lunches. Want to learn on the fly? PowerShell includes everything you need to learn directly from the shell. Get-Command, Get-Help, Get-Member, and Select-Object will get you exploring and learning PowerShell. Prefer videos? Product inventor Jeffrey Snover and Jason Helmick hosted two free PowerShell sessions that have proven quite popular: Getting Started with PowerShell 3.0 and Advanced Tools and Scripting with PowerShell 3.0. Or, check out the PowerShell.org YouTube channel, featuring technical videos and session records from every PowerShell Summit event.

Where Can You Learn More? 11

enable specific users to perform specific tasks that they wouldn't normally be able to - but only through the specific channel and interface you've set up.

Comparing Remoting to what came before

Before Remoting, most Windows remote management was conducted over Remote Procedure Calls, or RPCs. These usually employed port-hopping, making them incredibly difficult to manage through a firewall. Contrast that with the one port you have to deal with in Remoting.

A lot of organizations today simply install management tools on servers, and then use Remote Desktop to "remotely manage." That's an incredibly poor idea, and is a major reason why Windows Server take so many patches, so many reboots, and other maladies. The code needed to support a full GUI, and therefore RDP, is massive - and that means patches are inevitable. Running management tools on the server , usually under administrator credentials, is opening the door to an attack.

In short, most organizations seem to be worred about the security "implications" of PowerShell Remoting. The implications are significant - Remoting is much more secure than what you've been doing. It's also more efficient, imposes less overhead on servers, and lets servers run with a leaner operating system that will require fewer patches, fewer reboots, and fewer service packs. Those servers will also boot faster, run fewer processes, run fewer services, and consume less storage space for the OS. Those servers will require less memory overhead for the OS, meaning you can pack more of 'em into a virtualization host. Sounds horrible, right?

But here's the best reason

Quite simply, the main reason to enable Remoting is that you haven't got any choice. Microsoft has moved firmly in this direction, and enables Remoting by default on Windows Server 2012 and later. The company disables Remote Desktop by default, which should tell you something.

Further, in Nano Server, logging onto the console isn't even an option , whether you use Remote Desktop or not. There is no local login. Remoting is literally your only option for managing the server. That's going to be the case going forward.

Running a Windows environment without enabling Remoting - at least on servers - is like driving a car without wanting to depress the accelerator. It isn't much fun, and you aren't going to get very far.

Why PowerShell Remoting? (While we're answering "Whys") 13