Chapter 1: Introduction to the System Center Suite

Excerpt from Microsoft System Center Enterprise Suite Unleashed

1 2 3 4 5 6 7 8 Page 3
Page 3 of 8

Major Features of System Center Configuration Manager

System Center Configuration Manager 2007 R2 SP2 has hundreds of features and functions that an IT administrator can leverage as part of their system configuration and management practices; some of the major features in the product are as follows:

  • Operating system deployment—At the start of the system’s life cycle is the installation of the core operating system. SCCM provides all the tools an organization needs to deploy an operating system, either as an imaged installation (formerly, organizations used Norton Ghost, but no longer need to because SCCM includes image creation and deployment tools) or as a scripted method of installation.

  • Patching and updating—Once the operating system has been deployed, SCCM includes the mechanism to patch and update systems. Although many organizations use the Windows Server Update Services (WSUS), a free tool for patching and updating systems, SCCM leverages everything WSUS does but also provides IT administrators a more active patching and updating addition to WSUS. The Software Updates portion of the SCCM console, shown in Figure 1.2, is an example of the detail of the update information. The active update system enforces updates, forcing systems to be patched, updated, and rebooted based on policies that the IT department publishes and ensuring consistency in the update cycle of systems.

  • Figure 1.2

    Details in the SCCM console relative to patching and updating systems.

  • Asset tracking—As part of the operating system deployment and patching and updating process, the management tool needs to know what type of hardware, software, and applications make up the system so the system can be properly updated. SCCM includes the tools necessary to track the hardware and software assets of the systems it is managing.

  • Remote control—In the event that a user working on a system needs help, or that a system needs to be serviced, SCCM has a remote-control process that allows the IT administrator or a help desk individual to remotely control and support a user or manage a system whether the system is on the network or remote of the network.

  • Software deployment—Although the operating system deployment will install the base operating system on a server or client system, applications need to be installed and managed as well. SCCM provides the tools to push out software applications, whether it is something as simple as a plug-in or utility or as complex as a complete suite or server-based application, including unique application configuration and customization.

  • Desired Configuration Management—Beyond just having an operating system and applications installed on a system, keeping a system configured in a standard setup is crucial in consistency controls. SCCM provides a process called Desired Configuration Management, or DCM, that has policies established for system configurations so that a system cannot be changed or modified beyond the configuration standards set by policy for the system. This ensures all systems have the same software, drivers, updates, and configuration settings meeting stringent audit and controls standards consistent with regulatory compliance rules.

  • Internet Client—A very significant component in SCCM is the Internet Client. In the past, for a system to be managed, the system had to be connected to the network. For remote and mobile systems, that means the system has to be VPN’d into the network to have patches and updates applied or for the IT department to inventory or remotely control the system. With the Internet Client and the use of a PKI certificate installed on the system, a remote or mobile system merely needs to be connected to the Internet anywhere in the world, and the SCCM client will automatically connect back to the corporate SCCM server through a secured tunnel to allow SCCM to inventory, patch, apply policies, and update the system. The remote system does not need to VPN into the network or do anything other than simply establish connectivity to the Internet.

  • Reporting—SCCM integrates into the product a report generation tool, shown in Figure 1.3, that comes with a full set of out-of-the-box reports, including the ability for IT personnel to create customized reports on everything from asset inventory reports to standard configuration reports to reports on the patch and update level of each laptop and desktop in the entire enterprise. Reports can also be customized in the report tool querying any data sets of information collected by SCCM and producing reports specific to the needs of the organization.

Figure 1.3

Reports tool built in to SCCM.

Background on System Center Configuration Manager

System Center Configuration Manager 2007 R2 SP2 is easily a half-dozen or more generations into the life cycle of the product. From its early roots as Systems Management Server, or SMS, that had a bad reputation for being a management product that took more to manage the management system than managing workstations and servers themselves, SCCM has come a long way.

Some of the major revisions and history of the product are as follows:

  • Systems Management Server v1.x—Systems Management Server (SMS) v1.x had a few versions, 1.0, 1.1, and 1.2, all available in the mid-1990s to support systems typically in a Windows NT environment. Because Windows NT domains were clusters of systems but not really a highly managed hierarchy of systems, SMS 1.x had its own site structure for identifying and managing systems. With most organizations at the time using Ghost to deploy system images, and patching and updating not really a common practice, SMS pretty much just provided the packaging of software programs and upgrades of software programs for systems. An expert who knew how to bundle up Microsoft Office or Adobe Acrobat into an MSI installation script had a full-time job as the process of packaging applications during these early days was neither easy nor intuitive. Smaller organizations found it was easier to just take a CD-ROM and walk from computer to computer to install software than try to create a “package” and hope that the package would deploy properly over the network.

  • Systems Management Server v2.0—SMS 2.0 came out in 1999 and provided similar software-deployment processes as before; however, instead of using ad hoc site configurations, SMS 2.0 started to leverage subnets as its method of identifying systems on a network. SMS 2.0 also transitioned into the Active Directory era, although not without its challenges as it was a non-AD product that was somewhat set up to support an Active Directory environment. Needless to say, SMS 2.0 was about as successful as SMS 1.x was in helping in systems management.

  • Systems Management Server 2003 (also known as SMS v3.0)—SMS 2003 came out to specifically support systems in an Active Directory environment, and although Microsoft now supported Active Directory sites, the product still required a packaging and scripting expert to be able to do anything with the product. Patching and updating became a requirement as viruses and worms spread across the Internet and a tool was needed to do the updates. So SMS 2003 was best known for its ability to provide patching and updating of systems; however, the setup and complexity of SMS 2003 to just control patching and updating allowed a number of other third-party companies like Alteris, Marimba, and LanDesk to challenge Microsoft in having an easier system for patching, updating, and deploying software.

  • System Center Configuration Manager 2007—By 2007, Microsoft rebranded their management products under the System Center designation and finally broke away from the old legacy “site” concept of the Windows NT-based SMS product and fully redesigned the product for Active Directory, calling it System Center Configuration Manager 2007. With significantly better packaging, patching, and inventory tools along with a much better server role structure, SCCM 2007 finally “worked.” Organizations were now able to create software packages in minutes instead of days. Patching and updating leveraged the highly successful WSUS patching tool with enhancements added into the SCCM update for patching and updating to enforce updates, force system reboots, and better manage the mobile workforce.

  • System Center Configuration Manager 2007 SP1—SCCM 2007 SP1 added support for managing Windows Vista systems as well as support for remote-management components that Intel built in to their chipset called vPro technologies. With systems with vPro built in, an SCCM administrator can wake up a powered-off system, boot the system to a remote-management guest operating system, and perform management tasks, including flashing the system BIOS without ever touching the actual system.

  • System Center Configuration Manager 2007 R2—The R2 release of SCCM 2007 added automatic computer provisioning and multicast support for operating system deployments into the R2 release of the product. R2 also added App-V support in addition to ForeFront integration into the R2 release of the product.

  • System Center Configuration Manager 2007 R2 SP2—Most recently, the release of SCCM 2007 R2 SP2 has now added the support of dozens of features, functions, and tools that support the imaging, management, and support of Windows 7 client systems.

What to Expect in the System Center Configuration Manager Chapters

In this book, four chapters are dedicated to the System Center Configuration Manager product. These chapters are as follows:

  • Chapter 2, “System Center Configuration Manager 2007 R2 Design and Planning”—This chapter covers the architectural design, server placement, role placement, and planning of the deployment of System Center Configuration Manager 2007 R2 SP2 in the enterprise. The chapter addresses where to place site servers, discusses how to distribute images and large update files, introduces the various server roles and how the server roles can be placed all on a single server in a small environment or distributed to multiple servers, and covers the best practices that have been found in combining certain roles and the logic behind combining roles even in the largest of enterprises.

  • Chapter 3, “System Center Configuration Manager Implementation and Administration”—Chapter 3 dives into the installation process of SCCM along with routine administrative tasks commonly used in managing an SCCM environment. This includes the familiarization of the SCCM management console features and how an administrator would use the management console to perform ongoing tasks.

  • Chapter 4, “Using Configuration Manager to Distribute Software, Updates, and Operating Systems”—Chapter 4 gets into the meat of SCCM, focusing on core capabilities like distributing software, patching and updating, and creating and deploying operating systems. Any organization with SCCM implemented tends to use these features and functions at a minimum. The whole value in SCCM is to deploy operating systems (either imaged or scripted), patch and update systems, and deploy new software programs. This chapter covers the process as well as digs into tips, tricks, and lessons learned in sharing best practices used when deploying these features in the enterprise.

  • Chapter 5, “Configuration Manager Asset Management and Reporting”—The final chapter on SCCM in this book covers other components, such as the asset management feature and the reporting capabilities built in to SCCM. Some organizations only use the asset feature in SCCM as the prerequisite to patch and update the system, whereas other organizations greatly utilize the asset management function for regulatory and compliance purposes. It’s the same with reporting: Some organizations never generate a report out of SCCM, just using SCCM for operating system deployment, updates, and software pushes. However, other organizations heavily depend on the reporting capabilities in SCCM to generate reports for Sarbanes-Oxley (SOX) auditors or security compliance officers to prove the operational status of the systems.

System Center Configuration Manager 2007 R2 SP2 is a very powerful tool that is the start of the life cycle of a networked environment, providing templates and standard configurations for systems all the way through updates, management, and reporting. Jump to Chapters 2 through 5 of this book for specific information and deployment and configuration guidance on how SCCM can be best leveraged in your enterprise.

Understanding System Center Operations Manager

System Center Operations Manager (SCOM) 2007 R2 is the second product being addressed in this chapter. SCOM is used to monitor and alert network administrators when something (a server, workstation, network device, application, and so forth) is not working as expected, such as being offline, in a failed state, or even not running as fast as normal. The SCOM management console, shown in Figure 1.4, provides details about the events and errors of the systems being monitored and managed by SCOM.

Figure 1.4

The System Center Operations Manager console.

In the past, system monitoring was simply monitoring and alerting when something was “down”; however, with System Center Operations Manager, the monitoring is proactive and alerts are triggered before problems cause a system to fail. SCOM proactively checks the operation of systems and devices, and when the devices are performing differently than normal—which many times is a precursor to a pending system failure—SCOM begins the alert and notification process.

Business Solutions Addressed by System Center Operations Manager

System Center Operations Manager helps an organization be proactive about system operations rather than waiting for a server or application to fail, incur operational downtime, and recover from the failure. SCOM helps IT personnel ensure systems are running as expected. SCOM monitors the normal operation of servers, workstations, and applications to create a known baseline on how the systems are operating. When the systems fall out of the norm of the baseline, meaning that something is wrong, and while downtime has not occurred, the systems or applications are not running as they always do and IT personnel are then notified to review the situation and take corrective action.

SCOM also helps the IT department identify systems that should be replaced before others due to reliability issues. SCOM can keep track of system uptime and downtime and generate a report that ranks the reliability of systems based on their ongoing performance. If all things were equal in terms of age or depreciation schedule of systems, yet an organization will be replacing a portion of the systems, the reports can be used to identify which systems should be replaced first.

SCOM also has the ability to monitor applications as if a user is accessing the application and not just based on whether a system is operational or not. A system can appear to be fully operational, yet when users try to log on to the system, they could get logon errors or terrible access performance. SCOM has the ability to utilize automation by having a client system log on to a web server or an application server with stored credentials and validate that systems throughout the enterprise are more than operational and are serving users as expected.

SCOM can also be used to produce reports that help auditors and regulators validate that the organization’s IT operations meet regulatory compliance requirements. Automated report generation for information such as password attempt violations, service-level agreement details, encrypted data access validation, and the like makes SCOM more than just a monitoring tool, but an information compliance reporting tool.

The bottom line is that SCOM helps IT personnel identify problems that need to be fixed before the problems create downtime that impacts the operations of the business. This is critical in keeping employees productive for internal servers, and helps an organization maintain business continuity when their servers host applications that help the organization generate revenues. A properly designed, implemented, and configured monitoring tool like SCOM can mean the difference of an organization focused on productivity and continuity versus an organization that is constantly recovering from system failures.

Major Features of System Center Operations Manager

System Center Operations Manager 2007 R2 has hundreds of features and functions that an IT administrator can leverage as part of their system monitoring and proactive management practices; some of the major features in the product are as follows:

  • Server and client system monitoring—Key to SCOM is its ability to monitor servers and client systems. Using an agent that installs on the system (or agentless if the administrator desires), information about the system(s) is reported back to the SCOM monitoring server with operational data tracked and logged on a continuous basis.

  • Event correlation—SCOM is smart enough to know that when a wide area network (WAN) connection is down, the status of all of the servers and devices on the other side of the WAN connection becomes unknown. Rather than sending hundreds of alerts that SCOM has lost contact with every device on the other side of a WAN, SCOM instead sends a single alert that the WAN connection is down and that the status of devices on the other side of the WAN are in an unknown state.

  • Event log collection—Key to regulatory compliance reporting is to note system changes as well as potential security violations. SCOM has the ability to collect event logs and syslogs from systems, consolidate the data, and provide reports on the aggregate of information such as failed password attempts against all monitored servers in the environment.

  • System monitoring—Monitoring in SCOM is more than just noting that a system is up or down, but also the general response time of the system and applications running on the system. Specific applications can be monitored using SCOM, such as monitoring SharePoint servers, SQL servers, or Exchange servers, as shown in Figure 1.5.

  • Figure 1.5

    System monitoring and alerting in SCOM of specific servers in an environment.

  • Client system monitoring—Added in recent updates to SCOM is the ability to monitor and report on not just servers, but also client workstations in a network. Client system monitoring is commonly used to monitor and help manage and support critical client systems. A critical client system might be a laptop that belongs to a key executive, or it could be a workstation that serves as a print server or data collection device. Whatever the case, SCOM has the ability to monitor servers as well as client systems in the enterprise.

  • Application monitoring—SCOM has the ability to monitor specific application and website URLs, not just to see if the servers are running or if the website is responding, but to actually confirm that the site is responding in a timely manner. This deep level of monitoring, shown in Figure 1.6, confirms response time and can even have test user accounts log on to session states to validate that a site or protected site is responding as expected.

  • Figure 1.6

    Monitoring applications and web URLs in SCOM.

  • Service-oriented management—Traditional system monitoring treated all systems the same, so whether a single (only) system of its type in a network or a system that has multiple redundant nodes, any system failure would result in a page or alert. SCOM is service oriented, meaning that if multiple servers exist for redundancy, the administrator will not be urgently paged or alerted if one of many systems is down. As long as the service (such as email routing, web hosting, or domain authentication) continues to operate, a different level of response (such as an email notification instead of an urgent page) is triggered.

  • Integrated solutions databases—For administrators debugging a problem, the process usually involves grabbing event errors out of the log files, going to Microsoft TechNet to research the information, finding the solution, and then going back to the server to try the solution. With SCOM, it has Microsoft’s TechNet information integrated into the system so that when an event occurs and shows up on the SCOM console, right there with the event error is the symptom information and recommended solution that an administrator would normally find in TechNet online. Additionally, SCOM not only has the information of what an administrator should do (like start and stop a service), but SCOM also presents a Restart Service option on the SCOM console screen for the administrator to simply click the option to restart the service. If that solution solves the problem, SCOM allows the administrator to choose to have that solution (like restarting the service) automatically run the next time the event occurs on ANY server in the environment. This self-healing process allows an organization to set processes that automatically trigger and resolve problems without having an administrator manually identify and perform a simple task.

  • Service-level agreement (SLA) tracking and reporting—Many organizations have, publish, and manage to a specific service-level agreement metric, so if a network service is offline or degraded, the service-level quality is triggered and the overall service-level agreement is measured. SCOM has reports as well as a Dashboard view component that provides administrators the ability to know the status of system operations in the network.

  • Reporting—With previous versions of SCOM, reporting was an external add-on. Effectively, if an administrator wanted a report on the status of systems, a separate report tool was run. With the latest releases of SCOM, the reports are available right within the SCOM console. From a common console, an administrator can monitor systems as well as generate reports on every managed system in the environment.

Background on System Center Operations Manager

System Center Operations Manager 2007 R2 has over a decade of history at Microsoft and many years before that before Microsoft acquired the technology back in 1999. From its early roots as Operations Manager 2000 to what is now System Center Operations Manager 2007 R2, SCOM has come a long way.

Some of the major revisions and history of the product are as follows:

  • NetIQ Enterprise Event Manager—System Center Operations Manager has its roots from a 1999 product acquisition Microsoft made from NetIQ. The product, NetIQ Enterprise Event Manager, was already a well-established tool for monitoring network environments and formed the basis of Microsoft’s operations management offering.

  • Microsoft Operations Manager (MOM) 2000—In 2000, Microsoft took the NetIQ product and rebranded it as Microsoft Operations Manager 2000, doing a little to include support for monitoring and managing the newly released Active Directory 2000 and Windows 2000 Server; however, for the most part, MOM 2000 was the NetIQ product with a new name. For the next five years, Microsoft released service packs and management packs to update the product to support all of the new Active Directory–supported products Microsoft was releasing like Exchange 2000 Server, Exchange Server 2003, SharePoint Portal Server 2001, SQL Server 2000, and the like.

  • Microsoft Operations Manager (MOM) 2005—With the release of MOM 2005, Microsoft now had its first fully revised Microsoft monitoring and management product. Most organizations would consider this the Microsoft v2.0 of the product where core components such as event monitoring, event correlation, proactive monitoring, integration with TechNet support data, and the like made MOM 2005 a good Microsoft-focused monitoring and alerting product.

  • System Center Operations Manager 2007—SCOM 2007 was a major improvement from Microsoft and one where the product was truly revised to meet the needs of enterprises. SCOM 2007 was now fully integrated with Active Directory so that servers and server roles (such as all Exchange front-end servers or all domain controllers) could be identified as a group. Role-based security was added so that there was better granular control over views and tasks that an administrator was able to perform. Also, the addition of an audit log collection system that auditors and regulators were looking for consolidated log information in which SCOM 2007 was able to extract log information and make that available for reporting.

  • System Center Operations Manager 2007 SP1—SCOM 2007 SP1 included a rollup of all hotfixes for SCOM 2007, support for Windows 2008 as the base operating system that SCOM could run on, and a significant update to the Asset Intelligence (v1.5) component of SCOM for organizations that need better asset tracking and awareness.

  • System Center Operations Manager 2007 R2—For those who have been using SCOM for a long time, the release of SCOM 2007 R2 was seen as a huge turning point of making SCOM a truly enterprise monitoring and management solution. SCOM 2007 R2 provided support for not only Windows-based servers and applications, but also now has support for non-Windows-based systems like UNIX and Linux system monitoring. SCOM 2007 R2 also has the ability of granularly defining Service Level Objectives, such as monitoring and assessing the response time of a specific logon procedure or web page view rather than simply pinging the system to see if it was up. In addition, significant improvements in scalability have been achieved, where monitoring of workloads can now be measured in the thousands of events per agent, allowing SCOM to reach into the largest data centers to manage Windows and non-Windows servers, network appliances and devices, and client systems throughout an enterprise.

What to Expect in the System Center Operations Manager Chapters

In this book, four chapters are dedicated to the System Center Operations Manager product. These chapters are as follows:

1 2 3 4 5 6 7 8 Page 3
Page 3 of 8
IT Salary Survey: The results are in