Resistance is futile: You will use PowerShell

Microsoft is making more and more server admin functions command-line-only. Here's why you should embrace that shift

Let me state at the outset that I like PowerShell, Microsoft's command-line scripting tool for its various servers. I don't "love" it because I'm not a PowerShell guru -- I'm an Exchange guy. I love when email goes from point A to point B. When I can create a mobile device policy and enforce it all in one line of code? I like that -- it's cool and saves me time. PowerShell is on my list of awesome tools.

But I also believe there has to be a reason why I'm using PowerShell: to automate tasks that would normally take me longer through a GUI. Microsoft has been increasingly requiring the use of PowerShell in its server admin tools. I've found in some cases a disconnect between the GUI and what you can do with PowerShell, removing admins' ability to choose the interface that's easiest for them.

[ Read J. Peter Bruzzese's primer on using PowerShell. | Stay atop key Microsoft technologies in InfoWorld's Technology: Microsoft newsletter. ]

Let me give you two examples from Exchange.

First, in Exchange 2010 on a Hub Transport server, I can enable antispam agents using a PowerShell script (Install-AntispamAgents.ps1). After running the script, the Antispam tab appears in the Exchange Management Console, so you can manage those agents through the GUI. But in Exchange 2013, running that same script on your Mailbox server doesn't cause any antispam controls to appear in the GUI-based Exchange Management Console; you can manage the agents. Instead, you have to use both the Exchange Management Shell and PowerShell.

Second, in the ActiveSync policies in Exchange 2010, you can adjust settings with simple checkboxes and easily determine, for example, if a policy would allow a user from using the smartphone's camera or open a browser on the smartphone. But in Exchange 2013, all the advanced settings have been pushed off to the shell, even though the policies still exist and some of their settings remain in the GUI.

It's not just in Exchange. Last month in London at the SharePoint Evolution Conference, a session abstract said, "With the release of SharePoint 2013, Microsoft has nearly doubled the number of PowerShell cmdlets that are available for managing the product. This increase coupled with the fact that many things can now only be managed using PowerShell (such as search topology) means that administrators and developers alike must embrace PowerShell in order to be successful with SharePoint."

When you look at SQL 2012, Lync 2013, System Center tools, Windows Server 2008 R2, or 2012, you'll find things you can do only via PowerShell. Mark Minasi -- the best-selling author, popular technology columnist, commentator, keynote speaker, and IT consultant -- told one interviewer, "This thing happens where once they get the PowerShell religion. About 15 to 20 percent of what you want to do, you can only do with PowerShell." He compares Microsoft's PowerShell strategy as similar to that of the colonizing Borgs of "Star Trek: The Next Generation": "Resistance is futile. We will assimilate your technology."

This de-GUI-ization doesn't make sense, and I'm confident it would have taken no time for Microsoft to have made those options available in the GUI-based management console. This forced use of PowerShell must be intentional, but I'm at a loss as to why.

Still, let's look at the positive. If you talk to anyone who, like myself, has been pushed to learn more PowerShell, you'll find that ultimately we all admit we're happy for the push. For starters, it means we finally have a tool that helps us script or automate actions without being a genius. PowerShell is cut and paste. Once you learn how to do something, you can keep doing it -- change a few parameters and you're good to go. Another plus is if you are learning PowerShell while your peers aren't, your boss has one more reason to pay you more and to keep you onboard.

Another upside to the PowerShell shift is that is lets you set up headless servers, which take less room and cost less (no monitor or other peripherals needed). Microsoft is clearly hyping that notion, too. In Windows Server 2008, it pushed Server Core, a command-line-only interface that got little traction. In Windows Server 2012, Microsoft has made the move to the command line a little more appealing, with its minimal server interface option that you can switch to and from the full GUI -- it's a smaller-footprint middle ground between Server Core and a full GUI install.

So use PowerShell wherever possible. Even though it is being forced on you, embrace it. After all, it can make your life as an admin easier.

Still, I wish Microsoft's development teams would come up with strong reasons for needing to use PowerShell to do certain tasks. Think twice before not putting admin tools in the GUI. And make it easier for admins to find out what can be done only in PowerShell by providing a simple "Things you can do only through PowerShell" article for each product at TechNet. That would sure save a lot of us some time searching for GUI how-tos that don't exist.

This story, "Resistance is futile: You will use PowerShell," was originally published at Read more of J. Peter Bruzzese's Enterprise Windows blog and follow the latest developments in Windows at For the latest business technology news, follow on Twitter.

Copyright © 2013 IDG Communications, Inc.

How to choose a low-code development platform