I’m first to admit that I’ve been slow to appreciate the advantages of using Windows PowerShell for administering, managing, and configuring Windows Server, but that’s not to say that I’ve ignored it completely. Server Core forced me to take note, but beyond the basic setup, PowerShell can largely be disregarded with the help of GUI management consoles. But am I giving PowerShell a fair shake? Perhaps you should take closer look at what it can do for you and determine if there’s a place for PowerShell in your Windows server management strategy.
Using PowerShell to Manage Windows Server
Recently I’ve been looking more carefully at the capabilities of PowerShell Remoting and how to configure endpoints so that IT staff can perform only specific tasks, and how best to log those activities. This led me to think about some of the traditional challenges associated with server management and how PowerShell might be a better fit than GUI tools. PowerShell might also be able to provide some of the additional logging and reporting features that third-party solutions currently deliver for internal governance or regulatory compliance. Some GUI management consoles are already driven by PowerShell, such as in Exchange Server.
PowerShell and Managing Windows Servers
In managed environments, configuration changes to servers tend to be predictable in that we plan for those changes, test them, and then deploy. For non-critical maintenance work, Windows Server provides a fairly granular system for assigning IT staff only the permissions they need to perform a given task, such as the ability to manage Active Directory users or restart a Windows service.
Servers are often managed remotely, whether using a remote desktop session or the Remote Server Administration Tools (RSAT). PowerShell also has remote management capabilities, allowing you to run scripts or commands across thousands of servers at the press of a button. PowerShell lets you create remote configuration endpoints to define who can connect to servers remotely, and restrict what actions can be taken at a granular level.
For example, you might allow a group of users to connect to a server remotely using PowerShell and limit the permissions those users have on the server, restrict the PowerShell modules they have access to, and even specify which commands they can run. If you are not afraid of .NET programming, it is even possible to control which parameters can be specified for a given command.
PowerShell and Auditing
With many organizations needing to comply with industry and government regulations, auditing the actions IT staff perform on servers is an integral part of ensuring compliance. Although Windows has an event log, it’s not reasonable to expect that every action a user might take on the desktop is recorded, leaving only logging of significant events.
While the Windows event log doesn’t record all events, there are third-party solutions that operate independently of native Windows logging and record more information. But are they able to record everything? Probably not. Other solutions take a different approach by capturing the screen to physically record the actions an administrator takes. This may be the only foolproof way to ensure that all actions are captured, but it doesn’t provide an easy way to search and analyze those changes.
PowerShell logging can be turned on per module, and every command that is run – whether from the local console or remotely – is then logged, including information you would expect: who ran the command, what parameters were specified, and more. Extra information might be shown in the log, such as what AD objects a command, such as Get-ADUser, binds to.
Server Management Strategy
While there is still a place for GUI management tools, PowerShell offers significant advantages that might persuade you to look at what is on offer and how it could save your organization money. Some of the advantages of PowerShell include:
- Powerful automation capabilities
- Data collection and reporting
- Secure remote management
On the downside, PowerShell has what may be a steep learning curve for your IT staff. Additionally, logging must be enabled per module, the quality of logging can differ between modules, and the information recorded may not be enough to satisfy regulatory requirements.
Nevertheless, if you haven’t done so already, I’d recommend taking a closer look at what PowerShell can do for you and determine if it has a place in your server management strategy. PowerShell 4.0, which is currently in preview, will add Desired State Configuration (DSC) capabilities to the mix, as well as a series of other improvements.
Tagged with Windows Server 2012