Evaluate the Policy
Having created a policy, you should evaluate it
to see whether your server is in compliance. If you select Evaluate
from the context menu of the Server Security Policy policy, you will
launch the Evaluate Policies dialog box, shown in Figure 3.
Figure 3. Evaluate Policies dialog box
In Figure 3,
you can see that the policy that you created failed its evaluation. To
view the details of the failure, click the View hyperlink in the
Details column. Figure 4
shows an example of what you’ll see. You’ll get a list of the criteria,
and that list will include a pass/fail result for each one.
Note
Some policy dialog boxes use a blue highlight against light blue
hyperlink text. It is very hard to see on print and on the screen, but
it’s there; trust me.
Figure 4. Details dialog box
Figure 4
shows that the policy’s evaluation failed because the common criteria
switch was disabled and because the login mode was mixed and not set to
integrated mode. You can see that having a policy is an easy and fast
way to ensure your servers are in compliance.
In this example, you evaluated a single server.
The real power of policy-based management comes with the easy ability
to deploy and evaluate policies across multiple servers and multiple
versions of SQL. You can create policies that check down level versions
of SQL Server including SQL Server 2000, SQL Server 2005, and SQL
Server 2008.
To evaluate multiple servers on demand, you can
use the Registered Servers window in SSMS. This functionality has been
expanded to include the concept of a central management server.
Using the Central Management Server
In the Registered Servers window of SSMS, there
is a node called Central Management Server. A central management server
(CMS) is not a special server or a new edition of SQL Server; rather,
it’s a SQL Server instance that you and your DBA team decide on to be
the central management server.
Having a CMS server solves
two problems. First, imagine the scenario where you are on a DBA team
of five other people. Everyone is responsible for the 50 SQL Server
instances your company owns. To make administration easier, you create
a registered server list of all 50 SQL Server instances. You export
this list and e-mail it to your DBA team. Your manager sees that you
are proactive and really trying to save the company money by decreasing
wasted time. Fast-forward a few days to when some new servers come
online and some old ones are consolidated. Now, it’s time to send out
the registered servers list again, but this time, you forget because
you are trying to troubleshoot a faulty backup on one of your servers.
Your co-workers don’t know the new server names and are stuck until
they can get hold of you. Now, your manager doesn’t think so highly,
and in the words of Sir Topham Hat (from the children’s series Thomas
the Tank Engine), “You are causing confusion and delay!”
To solve this registered server fiasco, SQL
Server has the capability to create a shared registered servers list,
and that is the purpose of the central management server. Now, as you
make changes to the registered servers list, everyone can see and
leverage the same list.
The central management server allows you to group your servers. In Figure 5, SQL_DBA_1 is a SQL Server instance that is defined as a CMS. Within it is a folder called Production. Production contains two instances, SQLPROD_1 and SQLPROD_2.
Figure 5. Registered Servers view showing Central Management Server node
A few options are available in the
context menu of the folders within the central management server. One
of them, New Query, allows you to execute a query against all the
instances within the Production folder. Another capability is the
ability to execute policies. Imagine now how easy it is to determine
whether all your servers are in compliance. It is almost just a
right-click of a mouse button.
