|
Group Policy is gaining a foothold in corporations as the “onestop shop” to configure desktops. However, Group Policy has additional power to ensure that your servers are managed as well.
In this whitepaper you will learn why Group Policy matters for more than just users and workstations, but for servers as well. In addition, you will discover the Group Policy functions that work best for servers, how to use the Security Configuration Wizard to develop a crafted server security policy and new policy settings for servers that will become available with Windows Server 2008 (aka Longhorn!).
Additionally, we will provide best practices on how to successfully extend your deployment of Group Policy to your servers by implementing end-to-end management of this pervasive technology, including advanced offline management along with real-time monitoring of authorized and unauthorized changes.
Introduction
It’s likely you’re already using the power of Group Policy to perform some configuration changes to your desktops. But are you taking that power and leveraging it for your servers as well? If not, you’re missing a big opportunity to reduce costs, errors, and embrace consistent security across similar server types.
We begin this paper with an introduction on how to leverage Group Policy, not just for users and desktops, but for your server infrastructure as well. We will discuss how to review your server infrastructure and identify commonalities in both their function and configuration, something we refer to as “sameness”. Then we will examine how to apply Group Policy to quickly and easily address these areas of “sameness,” and present some real-world examples of where you can use Group Policy effectively to manage your servers.
Having presented you with an overview of where and how you can apply Group Policy to the management of your servers, it’s also important to consider how you are managing and monitoring administrative changes to Group Policy. Your servers are representative of some of your most critical IT assets, so ensuring their security and availability is paramount to both the IT services and data that they host, as well as the many end users that interact with those hosted IT services and data. As you increase your application of Group Policy across your servers, it is imperative to ensure that changes to policy settings are controlled, tested, and tracked. Unfortunately, native management tools do not provide all the capabilities that are required to deliver on these requirements, increasing the risk of everything from untested changes to unforeseen side effects.
With this in mind, this paper will then inform you how to implement a solid change management process around changes to Group Policy, including the ability to safely delegate policy editing privileges, and deliver workflow to test and review changes before authorizing their release into your production environment. Only with such an approach, can you assure that Group Policy-related changes will not have an impact upon the security and availability of your servers, and all that rely upon their availability.
Why Manage Your Servers with Group Policy?
Group Policy has historically been a desktop configuration tool. In doing so, it has created “sameness” for desktops that perform similar functions. The idea is that once you gather up similar users or computers which perform a similar function, you can deploy the same software, control the look and feel, and ensure that users leave old pieces of their jobs behind them when they move to other areas of the company.
Group Policy can perform a very similar function for your servers as well. Indeed, Group Policy for servers is not a new idea, but one that is definitely ready for more attention. The goal is to leverage the same principals, the idea of “sameness” and apply them to your Windows server infrastructure to reduce costs, minimize configuration mistakes, and create a consistently secure environment for new servers when brought online.
Finding the “Sameness”
Most people tend to look at servers as having distinct roles. This is natural. You might have servers that perform File, Print, Terminal Services, and more. However, in many cases these servers are simply “thrown together” – contained within an OU without regard for sameness.
|
