Other Management Tools

There are other ways you can manage Windows Server 2008 besides the tools we’ve discussed so far. Let’s examine these now. Specifically, we’re going to look at the following items:

• Group Policy

• Windows Management Instrumentation (WMI)

• Windows PowerShell

• Microsoft System Center

Group Policy

Group Policy in Windows Vista and Windows Server 2008 has been enhanced in several ways, including:

• Several new areas of policy management, including configuring Power Management settings, blocking installation of devices, assigning printers based on location, and more.

• A new format for Administrative Templates files called ADMX that is XML-based and replaces the proprietary-syntax ADM files used in previous versions of Windows.

• Network Location Awareness to enable Group Policy to better respond to changing network conditions and remove the need for relying on ICMP for policy processing.

• The ability to use local group policy objects, the capability of reducing SYSVOL bloat by placing ADMX files in a central store, and several other new features and enhancements.

A good source of information about Group Policy in Windows Vista (and therefore also in Windows Server 2008, because the platforms were designed to fit together) is Chapter 13, “Managing the Desktop Environment,” in the Windows Vista Resource Kit from Microsoft Press. Meanwhile, while your assistant is running out to buy a couple of copies of that title (I was lead author for that title and my retirement plans are closely tied to the royalties I earn from sales, so please go buy a dozen or so copies), let’s kick back and listen to one of our experts at Microsoft telling us more about post-Vista enhancements to Group Policy found in Windows Server 2008:

From the Experts: What’s New in Group Policy in Windows Server 2008

The following is a description of some of the Group Policy enhancements found in Windows Server 2008.

Server Manager Integration

The first noticeable change in Windows Server 2008 is how the Group Policy tools are presented. In past operating systems, other than Windows Vista, an admin would have to go to the Microsoft Web site to download the Group Policy Management Console (GPMC) and install it on every administrative workstation where Group Policy management is performed. In Windows Server 2008, the installation bits are delivered with the operating system. No more downloads, no more wondering where the installation media is-it is just there.

A difference in this new environment is how optional Windows components are installed. Windows Server 2008 introduces a new management console for servers called Server Manager. This is the tool that is used to install server roles, as well as optional Windows components. If you choose to go the old-school route and add Windows components from the Add/Remove Control Panel, it will launch Server Manager.

Not only do you use Server Manager to install the optional components, but the GPMC console itself is hosted within the Server Manager console. This means all of your administrative tools are kept in one place and are easily discoverable. Of course, you will still be able to find the tools in the common locations, such as Administrative Tools.

Search/Filters, Comments, and Starter GPOs

These features really enhance the administrative experience around managing and authoring policy. They are, technically, multiple features, but they work well when described as a “feature set,” as they all address the same business problem-difficulty in authoring policy. As you are probably aware, in the Windows Vista/Windows Server 2008 wave of operating systems there are hundreds of new settings to be managed. This means the total number of settings approaches 3000. That is a lot of manageable settings. Even though this provides a ton of value to the IT Professional, it increases the complexity when it comes to actually locating the setting or policy item that you are trying to manage. Microsoft has provided a “settings” spreadsheet that contains all the Group Policy settings in one relatively easy-to-use document, but it really doesn’t solve the problem. Microsoft has received feedback from many IT pros that there needs to be a method within the Group Policy tool itself to make finding the right settings easier.

Now with Search and Filters, when you are authoring a policy right in the editor you have a great mechanism to locate the setting you are looking for. You will see a new Filter button in the toolbar, and if you right-click on the Administrative Templates node in the editor you will see a menu item called Filter Options. Filter Options allows you to set the criteria that you are looking to search on. For example, you can narrow your view to only configured items, specific key words, or the system requirements (for example, Internet Explorer 6.0 settings). Filter Options provides a very intuitive interface and has great flexibility to help in locating the settings that you are looking for. Once you set Filter Options and turn on the Filter (global setting), the editor displays only settings that you are targeting. The Group Policy team is really excited to bring these features to you because we know it will reduce some of the administrative burden of what is otherwise a fantastic management technology.

You can also filter for settings that have Comments. This is also a new feature introduced in Windows Server 2008. You can now place a comment on any setting that you want. This means when admins are authoring policy, they can document their intentions at author time and other administrators can use that Comment as a search criteria. This feature is incredible at helping Group Policy administrators communicate to themselves, or other administrators, why specific settings are being managed and what the impact of those settings is.

The last piece of this feature set is called Starter GPOs. Starter GPOs are a starting point for administration. When a GPO is created, you can still create a blank GPO, or you can choose to create your GPO from one of the pre-existing Starter GPOs. Starter GPOs are a collection of preconfigured Administrative Template settings, complete with comments. You will see a node in the Group Policy Management Console (GPMC) called Starter GPOs. Simply right-click on this node and choose New. You will have a Starter GPO that is available to edit. There is delegation available on the Starter GPO container to ensure that only specific administrators can modify it..

This feature set-Search/Filters, Comments, and Starter GPOs-comes together to greatly enhance the authoring and management experience around Group Policy. It provides ease of authoring and discovering settings, inline documentation of Group Policy settings, and baseline configurations for starting the process.

ADMX/ADML

ADMX/AMDL files were introduced in Windows Vista to replace the legacy data format of the ADM files that we have become used to. ADMX files are XML files that contain the same type of information that we have become familiar with to build the administrative experience around Administrative Template settings. Using XML makes the whole process more efficient and standardized. ADML files are language-specific files that are critical in a multilanguage enterprise. In the past, all localization was done right within each ADM file. This caused some confusing version control issues when multiple administrators were managing settings in a GPO from workstations using different languages. With ADMX/ADML, all administrators work off of the same GPOs and simply call the appropriate ADML file to populate the editor.

Another value associated with ADML/ADMX files is that GPOs no longer contain the ADM files themselves. Prior to Windows Vista/Windows Server 2008, each GPO created would contain all the ADM files. This was about 4 MB by default. This was a contributing factor in SYSVOL bloat.

Take a look at http://www.microsoft.com/GroupPolicy to read more on ADMX/ADML. You can also find the ADMX migration utility to help in moving to this new environment at http://technet2.microsoft.com/windowsserver/en/technologies/featured/gp/default.mspx. Just a note that ADM and ADMX can coexist; read up on it on one of the sites just referenced.

Central Store

Related to ADMX files is the Central Store. As was previously stated, ADM files used to be stored in the GPO itself. That is no longer the case. Now the GPO contains only the data that the client needs for processing Group Policy. In Windows Vista/Windows Server 2008, the default behavior for editing is that the editor pulls the ADMX files from the local workstation. This is great for smaller environments with few administrators managing Group Policy, but in larger, more complex environments or environments that need a bit more control, a Central Store has been introduced. The Central Store provides a single instance in SYSVOL that holds all of the ADMX/ADML files that are required. Once the Central Store is set up, all administrators load the appropriate files from the Central Store instead of the local machine. Check out one of the Group Policy MVP’s Central Store Creation Utility at http://www.gpoguy.com/cssu.htm. You can also find more information on the Central Store at http://www.microsoft.com/grouppolicy.

Summary

Windows Server 2008 and Windows Vista have introduced a lot of new functionality for Group Policy. Administrators will find that these new features for management, along with the around 700 new settings to manage, will increase the ease of use of Group Policy and expand the number of areas that can be managed with policy.

–Kevin Sullivan
Lead Program Manager for Group Policy,
Windows Enterprise Management Division

Pretty cool enhancements, eh? Sorry, that’s the Canadian coming out of me, or through me, or channeling through me-whatever.

Windows Management Instrumentation

WMI is a core Windows management technology that administrators can use to write scripts to perform administrative tasks on both local and remote computers. There are no specific enhancements to WMI in Windows Server 2008 beyond those included in Windows Vista, but it’s important to know about the Windows Vista enhancements since these apply to Windows Server 2008 also. Here are a few of the more significant changes to WMI in Windows Vista and Windows Server 2008:

• Improved tracing and logging The WMI service now uses Event Tracing for Windows (ETW) instead of the legacy WMI log files used on previous Windows platforms, and this makes WMI events available through Event Viewer or by using the Wevtutil.exe command-line tool.

• Enhanced WMI namespace security The NamespaceSecuritySDDL qualifier can now be used to secure any namespace by setting WMI namespace security in the Managed Object Format (MOF) file

• WMI namespace security auditing WMI now uses the namespaces system access control lists (SACL) to audit namespace activity and report events to the Security event log.

• Get and Set security descriptor methods for securable objects new scriptable methods to get and set security descriptors have been added to Win32_Printer, Win32_Service, StdRegProv, Win32_DCOMApplicationSetting, and __SystemSecurity.

• Manipulate security descriptors using scripts The Win32_SecurityDescriptorHelper class now has methods that allow scripts to convert binary security descriptors on securable objects into Win32_SecurityDescriptor objects or Security Descriptor Definition Language (SDDL) strings.

• User Account Control User Account Control (UAC) affects what WMI data is returned, how WMI is remotely accessed, and how scripts must be run.

What all this basically means is that WMI is more secure and more consistent in how it works in Windows Server 2008, which is good news for administrators who like to write WMI scripts to manage various aspects of their Windows-based networks.

Still, from personal experience, I know that writing WMI scripts isn’t always easy, especially if you’re trying to get them to run properly against remote machines. Windows Vista and Windows Server 2008 complicate things in this regard because of their numerous security improvements, including User Account Control (UAC). So it’s instructive if we sit back and listen now to one of our experts at Microsoft, who will address this very issue in detail (this sidebar is worth its weight in gold):

From the Experts: WMI Remote Connection

Talking about management obviously implies the need to connect remotely to the Windows systems you want to manage. Speaking about remote connection immediately implies security. Management and security are not always easy to combine. It is not rare to see situations where management represents a breach of security, or the other way around; it is not rare either to see security settings preventing the proper management of a system. In this respect, WMI is not different from any other technologies; it provides remote management capabilities involving some security considerations.

Windows Vista and Windows Server 2008 come with a series of new security features. The most important one is called User Account Control (UAC). It is very likely that every administrator in the world will be challenged by the presence of UAC, especially if you use the Local Accounts part of the Administrator group to perform remote access. This is because any token account used in this context is automatically filtered and finally acts as a normal user in the remote system. Therefore, it is wise to consider the various security aspects to properly and securely manage your remote systems.

Before looking at the UAC aspects, let step back and look at the requirements to call WMI remotely. This applies to any Windows platform since Windows 2000. We will examine the Windows Vista and Windows Server 2008 aspects next.

To connect remotely, four conditions must be met:

1. Firewall Introduced with Windows XP, the Windows Firewall must be properly set up to enable connectivity for the WMI RPC traffic. Usually, you get an “RPC connection failure” if the Windows Firewall is enabled and RPC is disallowed. If you get an “access denied” message, the firewall is not the root cause of the issue. Keep in mind that the firewall is the key component to go through before anything else happens. Before Windows Vista and Windows Server 2008, RPC traffic must be enabled to allow the WMI traffic to go through. With Windows Vista and Windows Server 2008, a dedicated set of Firewall WMI rules is available to enable only WMI traffic. (This can be done with the FW.MSC MMC snap-in, Group Policies, Scripting, or NETSH.EXE.) Note that if you use WMIDiag (available on Microsoft Download Center), it will tell you which NETSH.EXE command to use to configure your firewall properly.

2. DCOM Once the firewall gate is passed, it is time to consider the DCOM security. The user issuing the remote call must have the right to “Launch and Activate” (which can be viewed and changed with DCOMCNFG.EXE) for both the My Computer and Windows Management and Instrumentation objects. By default, only users who are part of the Administrators group of the remote machine have the right to remotely “Launch and Activate” these DCOM objects.

3. WMI namespace Once the DCOM security is verified, WMI namespace security comes next. In this case, the user connecting to a remote WMI namespace must have at the minimum the Enable Remote and Enable Account rights granted for the given namespace. By default, only users who are part of the Administrators group of the remote machine have the Enable Remote right granted. (This can be updated with WMIMGMT.MSC.)

4. Manageable entity Last but not least, once WMI has accepted the remote request, it is actually executed against the manageable entity (which could be a Windows Service or a Terminal Server configuration setting, for instance). This last step must also succeed for the WMI operation to succeed. WMI does not add any privilege that the user does not have when issuing the WMI request. (By default, WMI impersonates the calls, which means it issues the call within the security context of the remote user.) So, depending on the WMI operation requested and the rights granted to the remote user, the call might succeed or fail at the level of the manageable entity. For instance, if you try to stop a Windows service remotely, the Service Control Manager requires the user to be an Administrator by default. If you are not, the WMI request performing this operation will fail.

   This describes the behavior of WMI since Windows 2000. In the light of Windows Vista and Windows Server 2008, things can be slightly different because UAC is enabled by default on both platforms and everything depends on whether you use a local account or a domain account. If you use a local user of the remote machine who is a member of the Local Administrators group, the Administrators membership of the user is always filtered. In this context, DCOM, WMI, and the manageable entity are applying the security restrictions with respect to the filtered token presented. Therefore, with respect to the UAC behavior, the token is a user token, not an administrative token! As a consequence, the Local User is actually acting as a plain user on that remote machine even if it is part of the Local Administrators group. By default, a user does not have the rights to pass the security gates defined earlier (in step 2, 3, and 4).

   Now that the scene is set, how do you manage a remote Windows Vista machine or 2008 server while respecting the Firewall, UAC, DCOM, WMI, and manageable entity security enforcements?

   This challenge must be looked at in two different ways:

5. The remote machine is part of a domain. If the remote machine is part of a domain, it is highly recommended that you use a Domain User part of the Local Administrators group of the remote machine (and not a Local User part of the Local Administrators group). By doing so, you will be a plain Administrator because UAC does not filter users out of the Local Administrators group when the user is a Domain User. UAC only filters Local Users out of the Local Administrators group.

6. Your machine is a workgroup machine. If your machine is in a workgroup environment, you are forced to use a Local User part of the Local Administrators group to connect remotely. Obviously, because of the UAC behavior, that user is filtered and acts as a plain user. The first approach if you are in a large enterprise infrastructure is to consider the possibility of making this machine part of a domain to use a Domain User. If this is not possible because you must keep the machine as part of a workgroup, from this point you have two choices:

   • You decide to keep UAC active. In this case, you must adjust the security settings of DCOM and WMI to ensure that the Local User has the explicit rights to get remote access. Don’t forget that a best practice is to use a dedicated Local Group and make this Local User a member of that group. In this context, the WMI requests against the manageable entity might work or not depending on the manageable entity security requirements (discussed in step 3). If the manageable entity does not allow a plain user to perform the task requested, you might be forced to change the security at the manageable entity level to explicitly grant permissions to your Local User or Group as well. Note that this is not always possible because it heavily depends on the manageable entity security requirements and security management capabilities of the manageable entity. For the Windows Services example, this can be done with the SC.EXE command via an SDDL string, the Win32_Service WMI class (with the Get/SetSecurityDescriptor methods implemented in Windows Vista and Windows Server 2008), or Group Policies(GPEDIT.MSC). By updating the security at these three levels, you will be able to gracefully pass the DCOM and WMI security gates and stop a Windows Service as a plain user. Note that this customization represents clearly the steps for a granular delegation of the management. Only the service you changed the security for can be stopped by that dedicated user (or group). In this case, you actually define a very granular security model for a specific task. (You can watch the “Running Scripts Securely While Handling Passwords and Security Contexts Properly” webcast athttp://go.microsoft.com/fwlink/?LinkId=39643 to understand this scenario better.) Now it is possible that some manageable entities only require the user to be an Admin (typical for most devices) because there is no possibility to update the security descriptor. In such a case, for a workgroup scenario, only the second option (discussed next) becomes possible. Last but not least, keep in mind that these steps are also applicable in a domain environment to delegate some management capabilities to a group of domain users.

   • You decide to disable the UAC filtering for remote access. This must be the last-resort solution. It is not an option you should consider right away if you want to maintain your workgroup system with a high level of security. So consider it only after investigating the possibility of making your system part of a domain or after reviewing the security wherever needed. If making your system part of a domain is not possible, you can consider this option. In this case, you must set the registry key in the reference shown below to ZERO on the remote system. Note that you must be an administrator to change that registry key. So you need to do this locally once, before any remote access is made. Note that this configuration setting disables the filtering on Local Accounts only; it does not disable UAC as a whole.

     [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]"Local AccountTokenFilterPolicy"=dword:00000001

     Once set, the registry key is created and set to ONE, and the Local User remotely accessing the machine will be an administrator (if the user is a member of the Local Administrators group).Therefore, by default, the user will pass the security gates defined in steps 2, 3, and 4. Note that it is required to reboot the machine to get this change activated.

     –Alain Lissoir

     Senior Program Manager, Windows Enterprise Management Division (WEMD) Check out Alain’s Web site at http://www.lissware.net.

Windows PowerShell

Another powerful tool for automating administrative tasks in Windows Server 2008 is Windows PowerShell, a command-line shell and scripting language. PowerShell includes more than 130 command-line tools (called cmdlets), has consistent syntax and naming conventions, and uses simplified navigation for managing data such as the registry and certificate store. PowerShell also includes an intuitive scripting language specifically designed for IT administration. As of Beta 3, PowerShell is included as an optional feature you can install on Windows Server 2008.

PowerShell can be used to efficiently perform Windows Server 2008 administration tasks, including managing services, processes, and storage. PowerShell can also be used to manage aspects of server roles, such as Internet Information Services (IIS) 7.0, Terminal Services, and Active Directory Domain Services. Some of the things you can do with PowerShell on Windows Server 2008 include

• Managing command-line services, processes, the registry, and WMI data using the get-service, get-process, and get-wmiobject cmdlets.

• Automating Terminal Services configuration, and comparing configurations across a Terminal Server farm.

• Deploying and configuring Internet Information Services 7.0 across a Web farm.

• Creating objects in Active Directory, and listing information about the current domain.

For example, let’s look at the third item in this list-managing IIS 7.0 using PowerShell. But rather than have me explain this, why don’t we listen to one of our experts at Microsoft concerning this?

From the Experts: PowerShell Rocks!

Of all the new Microsoft technology coming down the pipe, PowerShell has got to be one of the most exciting (after IIS 7.0 of course). You might wonder why I am so excited about the new scripting shell for Windows. Even if PowerShell is better than Command Prompt on steroids, what does this have to do with my main passion, Web servers and Web applications? Check out the Channel9 video I did with Jeffrey Snover, architect of PowerShell, to get an idea of how cool PowerShell really is (see http://channel9.msdn.com/Showpost.aspx?postid=256994). In the video, we show off a demo we put together for Bob Muglia’s keynote article in TechEd IT Forum this week, which appears to have gone very, very well. Well done, Jeffrey.

A long, long, long time ago, when I was in school and even after that, before I came to Microsoft and joined the IIS team, I used Linux and spent my days in BASH and ZSH getting work done. Until now, we sadly never really had the productive power of an interactive shell on Windows. So as a previously heavy user of shells, I have to tell you what I really like about this new shell interface on its own, and then I’ll explain the many ways PowerShell can make work simpler for IIS administrators.

OK, first off, in PowerShell you input commands on objects, not text, and PowerShell returns objects and not text. So you can easily pipe commands together in one line. This allows me to input in just one line complicated commands like this one:

PS C:\Windows\System32> Get-ChildItem -Path G:\ -Recurse -Include   *.mp3 | Where-Object -FilterScript {($_.LastWriteTime -gt     "2006-10-01") -and ($_.Name -match "pearl jam")}| Copy     -Destination C:\User\bills\Desktop\New_PJ_MP3s 

which recursively looks through my entire external hard drive (G:), collects all the “Pearl Jam” mp3s that were recently added, and copies them into a folder on my desktop. Never was I given a text output listing all the mp3s, and I didn’t have to use the Copy command over and over. I just piped all the items to Copy once.

Another thing I like so much about PowerShell is how consistent PowerShell commands are. In the preceding example, I used only one Get-ChildItem command, but rest assured if I wanted to get anything else, the command for that would start with Get. Similarly, if we want to stop a process or an application or anything, we always use the Stop command, not kill, not terminate, not halt, just stop.

Finally, I love that PowerShell is extensible. I love this because it means my team can produce a whole set of IIS PowerShell cmdlets to help you manage IIS 6.0, IIS 7.0, and future versions of IIS. You will also be able to submit your IIS PowerShell scriptlets to this community area (coming very soon).

Now that I’ve listed my favorite things about this new shell, I’d like to give you a few ways that PowerShell can and will make IIS administration simpler than ever before. The top 5…

1. IIS 7.0 has a new WMI Provider for quickly starting, stopping, creating, removing, and configuring sites and applications. Now use PowerShell to give a list of applications sorted by a particular configuration setting. Then pipe apps with the particular setting into the tasks you were performing before with the WMI Provider. My colleague Sergei Antonov wrote and just published a fantastic article, titled “Writing PowerShell Command-lets for IIS 7.0,” that describes how to write PowerShell cmdlets using our WMI provider.

2. Because IIS 7.0 has a distributed file-based configuration store, you can store your application’s IIS configurations in a web.config file in the application’s directory next to its code and content. Use PowerShell to rapidly XCopy deploy the application to an entire Web farm in one step.

3. IIS 7.0’s new Web.Administration API allows admins to write short programs in.NET to programmatically tackle frequent IIS 7.0 management tasks. Then, because PowerShell completely supports the .NET Framework, use it to pipe IIS objects in and out of these handy bits of code.

4. With IIS 7.0, you can use the new Runtime Status and Control API to monitor the performance of your Web applications. Use PowerShell to monitor performance information at a regular interval of every five minutes, and then have this valuable runtime information displayed to the console or sent to a log file whenever CPU is above 80%.

5. Take advantage of IIS 7.0’s extensibility by writing your own custom request processing module with its own configuration and IIS Manager plug-in. Then write a PowerShell cmdlet to serve as a management interface to expose your custom IIS configuration to the command line and to power your IIS Manager plug-in.

   For more information on managing IIS 7.0 using PowerShell, see “An Introduction to Windows PowerShell and IIS 7.0,” found at http://www.iis.net/default.aspx?tabid=2& subtabid=25&i=1212.

   –Bill Staples

   Product Unit Manager, IIS

Like WMI discussed earlier, Windows PowerShell is a work in progress and is still evolving. For example, Windows PowerShell version 1.0 doesn’t yet have any cmdlets for managing Active Directory, but by using the .NET Framework 2.0 together with PowerShell, you can manage Active Directory even so.

Chapter 14, “Additional Resources,” has lots of pointers to where you can find more information about using PowerShell to manage Windows Server 2008. But before you flip ahead to look there, listen to what another expert at Microsoft has to say concerning the raison d’être behind PowerShell:

From the Experts: The Soul of Automation

“Civilization advances by extending the number of important operations which we can perform without thinking about them.”

Alfred North Whitehead, “Introduction to Mathematics” (1911) English mathematician & philosopher (1861 - 1947)

I really understood Whitehead’s point during the great windstorm of 2006 when we lost power in my area for six days. During this time, we were without the benefits of most of the things I took for granted. I was struck by how much time it took to do things that previously I performed without thinking about them. Washing the dishes in the sink by hand took a lot more time than using the dishwasher. There were dozens of things like this. I didn’t mind terribly, but I found myself resenting that I didn’t have time to do as much reading as I usually do.

Whitehead’s point is not that civilization advances by us becoming non-thinking idiots. Rather, by increasing the number of things that we don’t have to think about, we free up time to think about new things and solve new problems, and then transform those things into things that we no longer have to think about. And so on and so on. Because I spent time doing dishes means that I didn’t have time to read, which meant that I didn’t get more educated, which would have made it easier to move the ball forward.

This is the essence of PowerShell and the soul of automation. In our world, there is no end of interesting and hard problems to think about, and the degree that our tools continue to make us think about the low-level junk is the degree to which we reduce the time that we have to think about the interesting problems. The ball gets moved forward as we adopt better and better tools that do what we want them to do without us having to tell them, and by our getting in the habit of using automation for repeating operations and sharing that automation with others.

Huge advances come from the accumulation of small deltas. In David Copperfield, Charles Dickens wrote, “Annual income twenty pounds, annual expenditure nineteen pounds six, result happiness. Annual income twenty pounds, annual expenditure twenty ought and size, result misery.” Einstein said it this way, “The most powerful force in the universe is compound interest.” So the next time you find yourself thinking about how to do something that you’ve done before, you should take it as an opportunity to invest a little bit and automate the activity so that you don’t have to think about it again. Give the function a good long name so that you can remember it, find it, and recognize it when you see it; then give it an alias so that you can minimize your typing (for example, Get-FileVersionInfo and gfvi).

Last but not least, SHARE. Put your script out on a blog or newsgroup or Web site so that others can benefit from your thinking. Newton might have figured out gravity, but if he didn’t share his thoughts with others, he would not have moved the ball forward. OK, so your script is not in the same league as “F=ma,” but share it anyway because “huge advances come from the accumulation of small deltas.”

Enjoy!

–Jeffrey Snover

Partner Architect, Windows Management

Microsoft System Center

Finally, the Microsoft System Center family of enterprise management solutions will be supporting management of Windows Server 2008, though at the time of this writing, the date for such support has not been made known to me. System Center is a collection of products that evolved from the earlier Microsoft Systems Management Server (SMS) and Microsoft Operations Manager (MOM) platforms. The plan for the System Center family currently includes the following products:

• System Center Operations Manager (the next generation of MOM)

• System Center Configuration Manager (the next generation of SMS)

• System Center Data Protection Manager

• System Center Essentials

• System Center Virtual Machine Manager

• System Center Capacity Planner

Keep your eye on these products as Microsoft announces its support for Windows Server 2008. You can find out more about System Center at http://www.microsoft.com/systemcenter.