Summary: Honorary Scripting Guy, Sean Kearney, goes over some often missed, easy-to-use PowerShell techniques for those who are starting out.
I had heard a rumor that many of the management tools actually run PowerShell code in the backend. Is there any way to see what code it’s running?
Honorary Scripting Guy, Sean Kearney, is here today, and, yes, it’s true. This hidden gem is one of the most frequently missed pieces by many people who use PowerShell. The GUI in many cases is calling up PowerShell.
Let’s begin with something pretty simple: managing users in Active Directory and auditing groups. For me, that’s a pretty standard, day-to-day task for most administrators.
A lot of people currently use Active Directory Users and Computers. It’s very fast and efficient. However, if you haven’t looked at the Active Directory Administration Center in Server 2012, you’re missing out on a gold mine!
This particular tool passes everything through PowerShell while you still work in the GUI. Here’s an example. Let’s pretend that my boss said, “Hey, who in our network has domain admin access?”
In the Active Directory Administrative Center, I can search for a property in the Global Search context. Here I search for the group domain admins.
When I press Enter on the found object, I can see the properties of that object.
In this case, there is only one member. I’m going to show you something about PowerShell here. Every single action is logged as a PowerShell cmdlet.
To view how this process was done in PowerShell, you need to look down on the bottom to see the words, WINDOWS POWERSHELL HISTORY. Click the little arrow to expand the window.
This will expand a log window. You might not see anything until you select the Show All box.
Click the Clear All tab and do something basic in the console, such as viewing that same group again. When you do that, some information will appear in the window.
This is your search for the group in the console, followed by accessing the group, and then the group membership. This is the PowerShell code that did the work for you.
If you’d like to grab the PowerShell code to play with or to use again, just click the code, and then choose your favorite “Copy All Combo” – CTRL-A, CTRL-C.
You can then paste the code directly into Notepad for safekeeping. You can also paste each individual line into an open PowerShell console to see what each line does. This console alone is a pretty good way to use the GUI and get the PowerShell code to play with on your own.
In the following sample, the Get-ADGroupMember content from the console was pasted and run in a PowerShell console.
This same technique works for almost anything you do in the Active Directory Administrative Center including disabling and unlocking accounts. It gives you the option to use PowerShell for some regular tasks without having to learn the code part.
Another great example is the Microsoft Deployment Toolkit, which is just ripe with automation in both VBScript and PowerShell. It offers a feature that you’ll often find in GUI-based applications from Microsoft.
It’s the mythical, magical View Script box that you may have been overlooking during your wizards.
Here in the Microsoft Deployment Toolkit, we’ll do a basic import of a driver from the C:\Drivers folder.
As you continue, the wizard will import the drivers from the source folder to the Microsoft Deployment Toolkit. If this task were very long, a problem is that the process would tie up the Microsoft Deployment Toolkit console until it was done.
At the very end, you’ll notice something you might have overlooked: the View Script button.
If you click View Script, you will see the actual PowerShell code that performed this operation. Here’s the example from the action where we imported the driver.
So, even if you don’t know how to code in PowerShell, you can see the “C:\Drivers” folder. If you needed to add more drivers to the same structure, you could change “C:\Drivers” to the new source folder easily. If you just pasted the code into PowerShell right now, you’d notice something.
First, it does the action again and warns a lot about “Already existing.” The second and more critical piece is that the console is not tied up during this process.
Think about when you update media in the Microsoft Deployment Toolkit. Wouldn’t this be handy? It also means that although you didn’t learn how to script in PowerShell, you learned how you could make PowerShell useful for you.
Interesting thought, eh?
Other applications, such as System Center Virtual Machine Manager, do this as well. Keep your eyes out for various applications that contain View Script. You may just find some hidden gold in there!
Stop on by tomorrow when Honorary Scripting Guy, Will Anderson, shows us a neat solution that he found to a problem he encountered in Azure Resource Manager!
I invite you to follow the Scripting Guys on Twitter and Facebook. If you have any questions, send email to them at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow.
Until then always remember that with Great PowerShell comes Great Responsibility.
Sean Kearney
Honorary Scripting Guy
Cloud and Datacenter Management MVP