PowerShell in the enterprise - TechED India 2011

Editor's Notes

• #4: In this session, we will look at what is PowerShell (very briefly) and then move onto why PowerShell is an important skillset for any IT Professional out there. We shall then look at the challenges in adopting PowerShell as the automation platform and see some of the best practices and recommendations to overcome those challenges. Finally, we shall look at some of the tools for the job and how each tool solves a specific problem.Stop me any time you have a question. But, remember, this is not a PowerShell fundamentals session. So, if you have any of those questions, I prefer taking them offline. With that note, let us get started.
• #5: I am giving away 2 PowerGUI Pro Licenses. Thanks to Quest software for that.Also, a Windows PowerShell 2.0 best practices book by Ed Wilson, the Scripting Guy.
• #6: How many of you are system administrators?How many of you know what is PowerShell?How many of you know have “really” used PowerShell in your day to day work?PowerShell is the command-line shell and the scripting language from Microsoft. It was released in 2007 along with Windows Vista and Longhorn. PowerShell is currently in version 2. Microsoft is really putting lot of effort in making PowerShell as “THE” management interface for various MS products. In fact, MS has a Common Engineering Criteria program which is about a set of engineering requirements every MS product should comply with. If you look up the web site and go to manageability section, you would find that “Windows PowerShell is the Microsoft standard for automation”. And, then, you can also a find a list of all MS products that comply or don’t comply with this. Go to Score Cards on the same page, click by technical area, and select Windows PowerShell Scripting and click on product compliance. The ones in green are having full compatibility and support for Windows PowerShell Scripting.Now, we understand that MS is really putting lot of effort in pushing windows PowerShell as the automation platform. Now, that said, Microsoft isn’t alone. There are several other companies and partners building PowerShell support into their products, building Products for PowerShell itself, and making the whole IT automation even more easier. Question: Do you know any other companies with PowerShell support in their products?There are several hardware vendors adopting PowerShell as their management interface. For example, Dell has PowerShell cmdlets to manage their EqualLogic and Compellent storageNetApp released Data ONTAP PowerShell tool kit for managing their storageIntel has vPro cmdlets to manage system hardware and also, HP for their blade system management. These are just a few examples. We also have VMWare, RedHat, and others building PowerShell support into their products for management.So, as an IT pro, PowerShell is a necessary skill set going forward. If you have not started using PowerShell yet, this is the right time. I am sure having PowerShell in your CV adds tremendous value. Now, with all these companies along with MS pushing PowerShell so much, the IT administrators in the data center face a few challenges.
• #7: Properly Manage PowerShellHow do you manage PowerShell in the data center. It is a product. Although, it is enabled by default Server 2008 R2 and Windows 7, not all data centers would have come to the recent OS yet. So, how do you deploy and update PowerShell?If you are going to deploy Windows PowerShell across your enterprise, you should review the best practices described below. These are especially recommended if several administrators will be using PowerShell scripts to manage production assets. Adhering to the best practices will ensure you get the most from your PowerShell investment in a secure and efficient manner.Securing PowerShellWhenever we think about scripts, the first thing that comes to my mind is security. What if the scripting platform itself is compromised? What if someone runs a rouge script?Tell you a story here: I was a system administrator at the beginning of my career. I managed a few hundred desktops and a few Windows & Unix servers. Early 2001 was when I started my career. So, I was actually managing Windows 95/98 and Windows 2000 desktops. If any of you are as old as I am, you may remember Anna Kournikova & LoveBugviruses. These were VBScripts spreading through email. So, when a user double-clicked on the attachment, scripting engine used to run the file and it sent emails to all people in the address book. This was possible because there were no restrictions on who can run those scripts in general and how. That was a major challenge. Although, we could filter the scripts at exchange, there was always a set of people who were blindly clicking the attachments they received through their personal emails, etc. The other workaround which we used was to change the default handler for .vbs files. We used Group Policy to change that to .txt file and whenever someone double-clicked on the .vbs file, it opened up in Notepad. But, that is not real protection. Ideally, the real restriction should have been at the scripting engine level. This is what PowerShell provides and we shall see how to use that.Of course, another challenge would be: How do we make automation effective?This is another big challenge. Automation isn’t just about writing scripts. It is also about how well those scripts were written, how easy those scripts are for someone to read and understand, and what tools do you use to develop these scripts, etc. You may use notepad for writing scripts but Is that the right thing to do? And, you may have someone in your org who just downloaded or written a cool script for doing some task against your production servers. Now, do you know if that script is optimized for speed, written with all coding standards in place, etc? We shall see some scripting standards and tools for the job towards the end of this session.
• #9: So, I said PowerShell engine itself supports restricting script execution. This is achieved using called script execution policies. These policies are the conditions under which PowerShell runs scripts. By default, PowerShell does not run any scripts. It allows only command execution. So, when you, as an administrator, not changed any default PowerShell settings, your end users, or any programs won’t be able to execute any scripts. Of course, one thing to remember is: an execution policy does not prevent user from running each command within a script. These execution policy settings are stored in the registry. (HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\PowerShell\\1\\ShellIds\\Microsoft.PowerShell)You can use Get-ExecutionPolicy cmdlet to see the current execution policy setting and use Set-ExecutionPolicy to change it.<Demo> There are 5 types of execution policies. <Demo> Get and Set Execution Policies.Users can change the execution policy using Set-ExecutionPolicy cmdlet. However, this requires administrative privileges. This essentially means that you have to be at the elevated command prompt. This is another layer of security. You cannot change script execution policy unless you have the admin privileges.<Demo> Script SigningI will briefly touch upon script signing here and show an actual demo to you. A few execution policies such as AllSigned and remoteSigned require that the PowerShell scripts you want to run be digitally signed.Any script that will be executed in a production environment, especially on mission-critical servers, shouldbe signed with a code signing certificate trusted by your domain. You can certainly acquire a code signingcertificate from a third-party vendor, but it doesn‘t take much to set up the free Certificate Services fromMicrosoft and issue your own. Since the certificates are essentially issued by your domain, they areautomatically trusted by all member servers and desktops.A digitally signed script is critical because it ensures that the script has not been modified since it was lastsigned. You can use the Get-AuthenticodeSignaturecmdlet to verify signature integrity.<You can also use Group Policy to Set Execution Policy>#Can be set via Group Policy#Precedence is as follows:#Group Policy: Computer Configuration#Group Policy: User Configuration#Execution Policy: Process (or PowerShell.exe -ExecutionPolicy)#Execution Policy: CurrentUser#Execution Policy: LocalMachine
• #11: Always start with the Shell. It is not always a good idea to begin trying to write a few hundred lines of PowerShell script. Instead, start with the shell. Anything you can run at the shell can be into a script. First, verify how the command runs in the shell. Once you have the expression or command working, you can put it into a script. Also, to start with, avoid writing complex expressions. Start with a simple expression and build on it as you see it working. If you write complex expressions and it results in an error, it becomes quite tough to debug.PowerShell is an object based shell. Which means you pass around objects when dealing with PowerShell commands and scripts. This is a change in mindset from the usual Shell experience where everything is TEXT. When scripting in PowerShell, It is always a good idea to receive and return Objects. This way you can use the built-in cmdlets to manipulate the objects and work with them.<DEMO> Object based shellCoding StandardsCode OptimizationsWhen writing scripts, you should always look for code optimizations. While it is important to achieve the goal of automation, it is also very important to optimize the code for speed of execution and resource utilization. For example, you write a script that works on, let us say a few 100 servers, but takes ages to complete and eats up all the memory you have on the management station, there is no use. These kind of long running scripts have to be always optimized. And, there are several ways to achieve this. You can look at how you can create faster looping constructs and how you can limit the number of properties you retrieve, etc. Let us a couple of demos to understand this.<DEMO Coding standards>
• #13: PowerShell has been around for a few years now and the PowerShell community is very strong. There are many experts who respond to questions on twitter, facebook, Stackoverflow and several other forums every day. And, this is not just about PowerShell MVPs. There are also other MVPs and PowerShell experts who are eager to help you. In fact, last morning I wanted to write something to automate my 2+TB SQL TB restore. I have 11 such databases to restore for testing purpose on a regular basis. I know someone must have already solved such a problem. So, I pinged a friend of mine who happens to be a SQL MVP and he pointed me to a PowerShell script that uses SMO and PowerShell for database restores. See, I solved 50% of my problem just asking a question. Now, all I had to do was wrap it up in another simple PowerShell Script to do the DB restores in background and wait for all the restores to complete. Simple!This simply means, you may have a great idea for a script but someone might have already thought about it. There is poshcode.org and technet script center for code sharing. These sites a few thousand community submissions. While you may or may not find the exact script you are looking for but these sites can be a very good starting point.
• #14: It should go without saying: any PowerShell script or function—whether developed internally or downloaded from a source like PoshCode.org—must be tested thoroughly in a non-production environment.Be sure to test not only how the script runs successfully, but also how it fails. What happens when you pass it invalid parameters or if a required resource is unavailable? What can you do to make the script or function fail? It is critical that you understand how the script handles problems. This is especially true of internally developed scripts. You should be able to take this information and revise your script to make itas robust as possible.You should have peer code reviews, unit testing, pilot testing, as well as management sign-off and approval. Administrative scripting does not have to be ad hoc or throwaway; in fact, it‘s just the opposite, scripting should be closely managed. PowerShell can bring a server or network down with only a few lines of code, assuming proper permissions. You should not have PowerShell scripts running in your environment that you don‘t understand, trust and approve.