5 Tips for Managing Windows Servers More Efficiently

As virtualization technologies continue to be adopted at rapid speed, an ever increasing number of servers must be managed. This requires that different techniques be used to automate common administrative tasks, reduce total cost of ownership and manage servers remotely.

The following are five tips to help manage Windows servers more efficiently.

Tip 1: Implement a change control process.

One of the best ways to guarantee good service to users is to set up a change control process for proper governance over changes made to mission-critical servers. If IT support staff has unrestricted access to important servers, such as domain controllers and line-of-business applications like Exchange, it won’t be long before somebody makes a change that causes a serious outage. Not only that, but without change control, it will be hard to determine what changed and when, which will make reverting to the previous configuration a very time-consuming process.

The five steps outlined below define a complete change control process. Taking even some of these steps and creating a process that suits your business will benefit your organization’s bottom line:

1. Record what needs to be changed, and determine the importance and likely impact on services.
2. Assess the impact in more detail by carrying out a full risk assessment, and ensure there’s a mission or technical reason to take the change forward.
3. Create a detailed plan on how to perform the change, including a full back-out strategy in case a problem is identified.
4. Test the plan in a lab or preproduction environment.
5. Implement the plan in your production environment, and if successful, the change request can be closed.

Tip 2: Separate mission-critical objects, and delegate control in Active Directory.

If you have properly thought-out security in place on your servers and Active Directory, systems will be easier to manage because changes can’t easily occur without IT staff going through the necessary channels. When designing security for Active Directory, (see Figure 1) start by following basic advice.

Microsoft recommends that the default Administrator account in Active Directory should be disabled and renamed to make it harder for hackers to find. There should be a maximum of two accounts assigned Domain Admin rights. And the following groups, which are included in Windows for the purposes of backward compatibility, shouldn’t be populated because members of these groups are able to elevate to administrator privileges: Account Operators, Server Operators, Print Operators and Backup Operators.

Design Active Directory so that mission-critical objects, such as user accounts used to run system services, are separated into Organizational Units (OUs) that help desk staff can’t access without obtaining permission through an appropriate process. Other objects, such as employee user accounts, can be located in OUs where permissions are assigned to IT staff for the purposes of everyday management using the Delegation Wizard in the Active Directory Users and Computers (ADUC) management console.

Figure 1 – Active Directory Delegation of Control Wizard

Tip 3: Use Group Policy to manage configuration and security.

Because of the power of Group Policy and its potential to make changes across many servers at once, system administrators often shy away from using it. Therefore, it’s sometimes the case that server configurations are managed manually or using security templates, but these can be labor-intensive solutions.

Group Policy is part of Active Directory and can be used to create Group Policy Objects (GPOs) that define configuration and security settings for servers (see Figure 2). GPOs are applied to OUs and can be further filtered by AD groups. Because of its power, make sure to delegate control to modify GPOs only to qualified members of the IT team.

Figure 2 – Managing Group Policy settings in the Group Policy Management Console (GPMC)

Tip 4: Learn PowerShell.

The PowerShell scripting environment is your friend, especially if you need to automate repetitive tasks. One of my favorite uses of PowerShell is to install OS features or roles in place of the Server Manager GUI. For example, here’s an easy way to quickly add the Windows Server File Resource Manager from a PowerShell console window:

IMPORT-MODULE SERVERMANAGER
ADD-WINDOWSFEATURE FS-RESOURCE-MANAGER

Here’s a more complex set of actions including a long list of prerequisites for installing an application such as Exchange (with Hub Transport and Mailbox server roles):

IMPORT-MODULE SERVERMANAGER
ADD-WINDOWSFEATURE NET-FRAMEWORK,RSAT-ADDS,WEB-SERVER,WEB-BASIC-AUTH,WEB-WINDOWS-AUTH,WEB-METABASE,WEB-NET-EXT,WEB-LGCY-MGMT-CONSOLE,WAS-PROCESS-MODEL,RSAT-WEB-SERVER –RESTART

Windows 2008 R2 introduced the AD PowerShell module, enabling system administrators to manage Active Directory using PowerShell natively for the first time. Install the module as follows:

IMPORT-MODULE SERVERMANAGER
ADD-WINDOWSFEATURE -NAME "RSAT-AD-POWERSHELL" –INCLUDEALLSUBFEATURE

To get a list of the available commandlets, type:

GET-HELP *-AD*

Tip 5: Use remote management tools.

Windows Server Remote Server Administration Tools (RSAT) can be downloaded for Vista and Windows 7, and appear as an option for installation at Turn Windows features on or off in the Programs Control Panel applet. You can choose to install specific tools or the complete set.

With the tools installed, you can perform common administrative tasks, such as creating and modifying Active Directory user accounts with the Active Directory Users and Computers (ADUC) management console. Provided you’re either logged on to a workstation with a domain account or start the tool with alternate credentials, it’s possible to work with the tools while no longer needing to log on interactively to a domain controller.

PowerShell V.2.0, which is included in Windows 7 and Windows Server 2008 R2 out of the box, allows administrators to run commands against servers across a network and is supported on Windows Vista (Service Pack 1) or later, Windows 7, Windows Server 2008 and Windows Server 2008 R2. PowerShell requires that the WinRM 2.0 service is running and set to start automatically on the computers that should be connected to remotely. Run the command below in a PowerShell window to enable remoting:

ENABLE-PSREMOTING –FORCE

Assuming all the computers you want to connect to — and from — are part of an Active Directory domain, no further configuration is required. Here’s an example of using PowerShell against a remote computer (“computername”) to query Windows Management Instrumentation (WMI) for information about local disks, and then format the information to show only the device IDs and free disk space:

INVOKE-COMMAND COMPUTERNAME {GET-WMIOBJECT WIN32_LOGICALDISK | SELECT DEVICEID,FREESPACE}

INVOKE-COMMAND CAN BE SHORTED TO ICM AND SIMILARLY, GET-WMIOBJECT SHORTENED TO GWMI.