vCenter Operations Manager (vCOPS): What It Is and Why You Should Use It

For years, vSphere has had alarms to let you know when things are above or below thresholds you specify. The problem is that these thresholds are static; you set a value and are notified if it is above that value, such as CPU utilization >75%. While useful, it can lead to many false alarms if you have a virtual machine (VM) that routinely exceeds that value or one that spikes to that value for a while during a batch-processing interval. Now, vCenter Operations Manager (vCOPS) lets the computer do what it does best: monitoring and alerting, figuring out what is "normal", and then notifying administrators when things are abnormal.

For years, vSphere has had alarms to let you know when things are above or below thresholds you specify. This is a great first step in identifying items that may require your attention and/or further investigation. The problem is that these thresholds are static; you set a value and are notified if it is above that value, such as CPU utilization >75%. While useful, it can lead to many false alarms if you have a virtual machine (VM) that routinely exceeds that value or one that spikes to that value for a while during a batch-processing interval. In those cases, that level of CPU utilization is expected and normal, and looking at it again just leads to wasted time, and soon to ignoring alarms as probable false positives. In addition, it fails to alert you if utilization is below normal, such as a service failure causing processing to stop. Knowing when you have a "real" issue is the key. The problem is when there really is an issue, you may ignore it, thinking it is not a real issue. There have been case studies done of companies that have worked on setting threshold for a year to find what the "right" values are for VMs. That is a huge waste of time and money, and it does not work well in a dynamic environment.

Another issue for many deployments is that the VMs may have wasted resources - VMs that are over-provisioned, powered off, or even removed from the inventory, but still on disk. This wastes resources and drives up the Total Cost of Ownership (TCO). The question is how to identify those resources and get them back. Conversely, other machines may not have the required resources to run well - which ones are they and what do they need? How do I know which VMs are consuming a lot of resources and impacting the performance of other VMs?

All these, and many other questions, can be answered by carefully studying performance graphs in the vSphere Client (or the new Web Client) and monitoring alarms. The problem is, these tasks are time-intensive and administrator time is both expensive and at a premium. Enter vCenter Operations Manager (vCOPS). Let the computer do what it does best: monitoring and alerting, figuring out what is "normal", and then notifying administrators when things are abnormal.

vCOPS is a tool from VMware that is designed to analyze your environment, figure out what is "normal", and alert you when abnormalities occur. These abnormalities can be at the VM, host, cluster, or data store levels. vCOPS is designed to help you find both undersized and oversized VMs as well as wasted resources. It can help you spot issues early. It provides root-cause analysis for issues detected. If you also have vCenter Configuration Manager (vCM - part of the vCOPS Management Suite), it can correlate events that occurred in the environment with results in the VM, host, etc. The tool will gather data over time and dynamically set thresholds and report back when they are exceeded. vCOPS is designed to alert you when things are not normal and not bother you about little events that are normal (and probably common) in your environment.

The vCOPS Management Suite includes several other tools that are also useful in analyzing and diagnosing issues and relationships in your environment. The Where Do I Get It? section lists the options available in the suite, as well as details on other products that come with vCOPS, and the What Editions Are Available? section lists the capabilities available in each edition.

Most environments with more than a few servers and a few dozen VMs need vCOPS (or a similar tool). There are just too many things going on and too few administrators to watch all that is happening to effectively manage issues. Also, there are too many false alarms raised for things that may be normal in an environment, such as a server using a lot of CPU doing batch processing overnight. This could be fixed by adjusting alarm values for those VMs, but that requires a lot of data-gathering and analysis to figure out what is "normal" for each VM and then implementing of those custom alarms on all affected VMs, leading to management by exception. The more data-gathering and analysis that take place in an environment, the more complex and costly it is to manage.

View the original article here

Unified Communication Manager - Class of Service

Class of Service is a way of controlling which phone numbers a phone, gateway, voicemail port, etc. has access to. By creating multiple partitions and multiple Calling Search Spaces (CSS), an administrator can control which devices can make long-distance or international phone calls or calls to any other phone number. It can also control when these calls can be placed by applying time schedules to the partitions. Using the basic components of Partitions and CSSs, you can create just about any class of phone service model imaginable, to suit any need.

Class of Service within Unified Communication Manager (UCM) is a way of controlling which phone numbers a particular device can call. For example, do you want the phone in the lobby to be able to call a long-distance number? Normally, we would not want this to be possible, and restricting the phone numbers a particular device can reach is used extensively within most corporations. Cisco Class of Service is achieved by implementing two components that allow great flexibility in this area. These two basic components are called Partitions and Calling Search Spaces.

This white paper defines these two components and how they interact with each other in a way that everyone can relate. Afterwards you will see how simple and yet flexible this can be used in many different situations.

What is a Partition? A partition is a container of phone numbers, route patterns, calls park numbers, etc. A partition is just like a phone book. For example the Dallas partition would contain all the phone numbers of employees in Dallas, while the Chicago partition would contain all the phone numbers of employees in Chicago, and the corporate partition would contain all the phone numbers of ALL the employees. So a partition contains a list of phone number or route patterns that are both allowed (routed) and not allowed (blocked). For example the Long Distance PSTN partition would contain the pattern 9.1XXXXXXXXXX that would match all Long-distance numbers that are routable. But there are generally some long-distance numbers that we don't want to allow, like premium service numbers. Therefore, we need to include a pattern like 9.1900XXXXXXX that will block these numbers in the partition, thus allowing a device to call any long-distance number except for those blocked premium service numbers that begin with 1900. You can see that a partition is basically a group of numbers, containing both routable and blocked numbers that are grouped together.

The only rule with partitions is that each number within a partition must be unique. This simply means that you cannot have the same number or pattern listed more than once in a single partition. But identical numbers are allowed; they just need to be listed in different partitions. For example, notice that the route pattern 911 is listed below in two different partitions. We have two identical patterns, but they are listed in separate partitions. This is perfectly legal.

Local_PSTN_PT: Used to contain local PSTN numbers that do not incur a charge. Note the 7-digit number that begins with 976. These are classified as premium service numbers that can charge back on your monthly phone bill, we want to block these numbers.

LongDistance_PSTN_PT: Used to contain long distance numbers you are going to allow or block. This will route all 11-digit numbers except for the premium service numbers (Area code = 900 or NPX=976), which are blocked.

Internal_PT: Are used to contain internal extensions of employees, meet-me conference bridge numbers, etc.

The partition is a special partition. Think of it as the "default" partition. When you create a new extension or route pattern, these are automatically assigned or listed in the partition, unless you specify something else. I will cover the use of this special partition later, but for now you need to be aware that it exists.

Another feature of partitions is that we can control when a partition can be accessed via the time schedule. For example, if you want to restrict access to long-distance calls to normal business hours, you can apply a time schedule to the partition, thus defining the hours that the partition can be accessed.

By creating several time schedules, you can define which employees have access to various partitions during the day. Time Schedules are applied to the partitions directly and are composed of one or more time periods.

To achieve the above example of restricting long-distance calls to normal business hours you would need to do the following:

1. Define a "time period" - for example, "8to5MF" defines a schedule of time from 8 am to 5 pm on Monday through Friday.
2. Define a "time schedule" - for example, "Normal Business Hours" and it contains the time period "8to5MF".
3. Finally, apply the time schedule to the "LongDistance_PSTN_PT" partition.

At this point, you need to test it by placing calls after 5 pm or on the weekend; if everything was done correctly, the call will be rejected.

View the original article here

Microsoft System Center Configuration Manager 2007 SP2, R2, R3: Making Sense of the Three Versions

Microsoft has engaged in a continual process of upgrading, enhancing, and improving its System Center Configuration Management server since its release several years ago. At this point, organizations who plan to use the product for Operating System Deployment must seriously consider an upgrade to Service Pack 2, or they lose the ability to support Windows 7 workstations. Service Pack 2 is also a necessity for the organization wishing to take full advantage of Out of Band Management.

The fourth edition of Microsoft's System Management Server was released in August, 2007 with a new name, System Center Configuration Manager (SCCM), making it part of the System Center brand, along with a considerable package of enhancements extending the SMS 2003 product. Since the initial release of SCCM, there have been two service packs, an R2 version, and the beta version of R3. Keeping track of which iteration is necessary for which feature is a daunting task that has been complicated by the R3's continued beta status and the v.Next product that has been demonstrated at Microsoft's MMS and TechEd events. In this white paper, we will go through the components of each variety of the product that is often called ConfigMgr in an effort to clear up the confusion around this very valuable piece of management software.

In broad strokes, SMS and its re-named child provide an enterprise with the ability to centrally deploy applications and operating systems, inventory software and hardware, manage the distribution of updates and patches, and permit the reporting of each of those crucial components. As a replacement for SMS 2003, SCCM 2007 brought with it several brand-new features including Desired Configuration Management, Wake on LAN, and Network Access Protection.

Desired Configuration Management (DCM) provided an organization with the ability to analyze and compare their existing computers against a previously created standard. Wake on LAN allowed the deployment of applications and patches to a machine that is a low power state. Network Access Protection permits an organization to exclude non-compliant machines from gaining access to the network.

Additionally, a significant number of capabilities that had been introduced as Feature Packs in SMS 2003 were now included in the SCCM 2007 standard deployment, including Operating System Deployment, Asset Intelligence, and Mobile Device Management. In many ways, SCCM 2007 was the natural progression of a solid and mature product. The new and enhanced capabilities made a good business case for an upgrade for SMS 2003 users and for the adoption of the product for those using other tools or were attempting to gain a better grasp of their environment.

In May of 2008, the first Service Pack of SCCM 2007 was released. It provided some new features such as Out of Band Management, support for Soft Grid (now App-V) applications, as well as enhancements to Asset Intelligence and license management capabilities. By introducing the entirely new Out of Band Management capability, which allowed for the control of systems that were powered off or in a low power state, Microsoft signaled that it would continue its strategy of adding significant components to the ConfigMgr product through the interim service packs and releases.

At the end of August 2008, Microsoft released the R2 version of ConfigMgr 2007 to market. As a new "version," it was made available without additional cost to SCCM customers who participated in the Software Assurance program. Release 2 came with an updated help file, which continues to prove quite useful, in addition to new capabilities previously unavailable in SCCM 2007.

As a feature pack, R2 provided five new capabilities. Foremost is support for SQL Reporting Services, which enables the level of extensibility that many enterprises demand. Additionally R2 allows for integration with Microsoft's Forefront Client Security (FCS) application, allowing the usage of Desired Configuration Management packs to leverage the capabilities of the anti-virus and anti-spam of FCS. The third new feature is Client Status Reporting, which can assess the health of client machines. Also provided is true App-V 4.6 support for the newly labeled Soft-Grid system. Last, but certainly not least, are the improvements to Operating System Deployment, which include the ability to deploy the OS to computers without first adding them to the ConfigMgr database and the ability to use multicasts for OSD.

Perhaps the most powerful feature of the NT 6.x operating systems (Vista, Server 2008, and Windows 7) is their new BIOS-agnostic approach to deployment. In short, an image created on or for a Dell Computer could be deployed without modification to a Lenovo or a Hewlett-Packard. That was hardly the case with the previous Microsoft operating systems as images made for Dell 620s could not be deployed to Dell 630s. Unfortunately, Microsoft's initial NT 6.0 end user OS ran into substantial "market resistance" from the enterprise user. While I was an early proponent of Vista, that OS suffered some drawbacks. Now, with Windows 7, we finally had something we could whole-heartedly support. With a Release to Market to essentially coincide of that of Windows 7, ConfigMgr 2007 SP2 was launched.

View the original article here