Archive

Archive for June, 2010

Service Level Dashboard

June 14, 2010 1 comment

The Service Level Dashboard for System Center Operations Manager 2007 R2 addresses the need that managers, application owners, and IT professionals have to make sure that their resources (applications and systems) are available and performing at acceptable levels. It does this by tracking, reporting, and helping to manage service levels for line-of-business (LOB) applications. Most organizations have a number of LOB applications that are managed by IT and used by one or more business groups. The work that these applications perform is often business-critical. IT and the primary user of the application customarily seek to ensure that an application’s performance and availability meet requirements by putting in place a service level agreement (SLA). The SLA governs a range of service aspects of applications that can include everything from outage response time to disk space availability.

In order to determine that a service level commitment is being met, IT and business users must be able to monitor service levels.

The Service Level Dashboard meets the need of organizations to track service levels not only for an application, but also for an application as a service, a group, or a class of object. It identifies any shortfalls between service goals and actual performance, thereby enabling organizations to accurately measure and view, in near real time, Service Level Objectives (SLOs) for business-critical applications or groups of objects within Microsoft® System Center Operations Manager 2007 R2. This means that organizations are aware of problems as soon as they appear and can track their relative business impact. The Service Level Dashboard also helps IT to proactively fix problems in services before service levels are breached.

Open the Operations console with an account that is a member of the Operations Manager 2007 R2 Administrators profile. Select the Administration view. In the navigation pane, click Management Packs. In the Management Packs pane, right-click and click on Import.

Click on Add and select the Management Pack which you want to import. Click on Install.

Check for status.

Click on Close, when import the Management Pack is successful.

Installation of Share point 3.0 sp1

Double click on Setup.exe to start the Microsoft windows SharePoint Services 3.0 sp2 setup wizard. On license wizard, accept the agreement. Click Continue.

Click on Advance option installation type.

In server Type, choose the option Stand alone.

Specify the location to install the programs. Choose the location by click on Browse option.

Check the Installation Progress.

Click on Close, after completion of Setup.

Configure the SharePoint product and Technology

Go to the Start, administration Tool and click on SharePoint Product and Technologies. To configure the SharePoint click on Next on Welcome to SharePoint Product and Technologies.

Click on Yes.

The configuration task started. Check the configuration steps.

Check the Configuration Steps.

Check the Configuration Steps.

Click on Finish when configuration Successful.

Install the Service Level Dashboard

Copy the ServiceLevelDashboardV2_x64.msi file from the location you specified during download to a Windows SharePoint Server that has SharePoint 3.0 Central Administration installed. Run the .msi file to begin the installation process.

Accept the License Agreement. Click on Next.

Follow the steps in the installation wizard, which will prompt for the following information:

OpsMgr Username – HCLCOE\OPS-Admin

OpsMgr User Password – **********

OpsMgr DW Server Name – COE-S-OM

OpsMgr DW DB Name-OperationsManagerDW

Site Owner Login Name – HCLCOE\65124

Email Address – 65124@hclcoe.in

SharePoint DB Server Name – COE-S-OM

Session DB Name – SLDSessionDB

URL of SLD SharePoint –http://coe-s-om:51918

Click on Next.

Click on Install.

Check for progress.

Check for progress.

Click on Finish to Complete the Setup.

Check for SLD management pack successfully imported.

Open site

http://10.20.52.110:51918/default.aspx

Create SLO for an application or group

In the Operations console, from the Authoring view, click Management Pack Objects and then, in the Authoring navigation tree, click Service Level Tracking. In the Actions pane, click Create. In the Name box, type the name of the application or group. You can optionally provide a description. Click Next.

Under Targeted class, click Select to specify the class for the service level, and then click Distributed Application or Group. Select the management pack where this service level will be saved. You can use an existing management pack or create a new one. Click on Next.

On the Service Level Objectives page, click Add and then click Monitor state SLO to create a new monitor to track the availability of the application or group.

In the Name box, type the name of SLO. For example Availability SLO App Test

Under Targeted class, click Select to specify the class for the service level, and then select the appropriate class based on your requirements.

Under Monitor, click Availability.

For Service level objective goal, provide the numerical measure for your objective. For example, if your goal is 99.99 percent availability, type 99.990.

To refine what the monitor tracks as available, select or clear any of the following state criteria to be counted as downtime:

Unplanned maintenance

Unmonitored

Monitoring unavailable

Monitor disabled

Planned maintenance

Warning

Click OK.

Optionally, on the Service Level Objectives page, you can add more SLOs. For example, you can add a new Performance rule SLO to create a new collection rule to track the performance of the application.

Click Next.

Review the summary, and then click Finish.

On the Completion page, click Close.

Configure the Initial Service Level Dashboard

Open Home page of your Site.

http://coe-s-om/default.aspx

On the site home page, on the Site Actions menu, click Site Settings.

On the Site Settings page, click People and Groups.

On the People and Groups page, on the Quick Launch, click More.

On the People and Groups: All Groups page, on the Settings menu, click Set up Groups.

On the Set up Groups menu, select a group for each set of users that you want to change. Alternatively, select Create a new group to assign a set of users to a custom group.

Click OK.

Add users to a Custom group.

Click on OK.

Click Team Site Members to view user is successfully added.

Configure the Dashboard Web Part

Open the SLD site, click the Site Actions menu, and click Edit Page.

http://coe-s-om:51918

In the Dashboard ConfigurationWeb Part:

From the list of Service Levels, select a service level. (You can only select a maximum of six Service Levels per dashboard.)

For Dashboard Refresh Rate, Specify the value from 0 to 1440 (minutes). The value 0 indicates no refresh.

For Dashboard Default View, choose a default view from the drop-down list.

For Aggregation Type, choose Hourly or Daily from the drop-down list.

Note   It is recommended that you choose Daily for the Aggregation Type if you choose more than 24 hours for Dashboard Default View. Click Apply Filter to save the settings.

Check the below snaps for Dashboard.

Click on Apply Filter.

And view SLD Reports.

Report -1

Report -2

Report -3

Categories: OpsMgr'07

Monitoring cross platform operating systems

To monitor the cross platform these are the point you need to follow-

1. Discover and install the agent

2. Configure runas accounts

3. Varification

1. Discover client and install agent

Open the Operations console with an account that is a member of the Operations Manager 2007 R2 Administrators profile. Select the Administration view, and click on Discovery Wizard.

Select What you want to discover-

· Windows Computer

· Unix/Linux Computers

· Network Device

Here we will discover Linux computers. Click Next.

In define criteria wizard click Add.

Give IP address and credentials for computer you want to discover.

Enable SSH based discovery and click on Discover.

View discovery progress.

After completion of successful discovery, click Next, it will install agent on remote system.

Check client installation status. And click Done to close wizard.

Click details to check status.

2. Configure Run As for cross platform

In Microsoft System Center Operations Manager 2007 R2, Run As profiles and Run As accounts are used to provide credentials that have the necessary privileges that the default Action account might not have for running rules, tasks, and monitors. To monitor UNIX and Linux computers, you must configure both the UNIX Action account profile and the UNIX Privileged account profile. You must go through the “To configure run as for cross platform” procedure below once for each profile.

If you will not configured Run As account for cross platform monitoring, you may see this alert in SCOM console.

Alert Name – Secure Reference Override failure.

Follow below given steps to resolve this issue.

Open the Operations console with an account that is a member of the Operations Manager 2007 R2 Administrators profile.

Select the Administration view.

In the navigation pane under Run As Configuration, select Runas Account.

Right click and Create Run As Account to start the Create Run As Account wizard.

If the Introduction page appears, click Next.

On the General page, select Basic Authentication from the Run As Account Type list. Notice that there are other options to choose from.

In the Display Name box, enter a name to identify the UNIX Action Account or UNIX Privileged Account credentials. Here we are creating UNIX Action Account so enter Step by Step Run As UNIX Action Account, do the same procedure for UNIX Privileged Account and give name as Step by Step Run As UNIX Privileged Account, and then click Next.

On the credential page, enter appropriate values in the Account Name, Password, and Confirm Password boxes, and then click Next.

In distribution security page click More Secure option, so that you have to manually select the computer to which this credential will be distributed.

This creates the Step by Step Run As UNIX Action Account or Step by Step Run As UNIX Privileged Account object and maps it to the actual UNIX account credentials that will be used for non-privileged or privileged interaction with the UNIX-based computers that you will be monitoring.

Click Close to close the Create Run As Account wizard.

In the Accounts pane, double-click the account you just created.

i.e. Step By Step Run As UNIX Action Account and Step By Step Run As UNIX Privileged Account

In the Run As Account Properties dialog box, select the Distribution tab and choose the Distribute credentials to selected computers option.

Click Add to open the Computer Search dialog box.

 

From the Option list, choose Show management servers, and then click Search.

In the Available items text box, choose the management server that these credentials will be distributed to, and then click Add.

Click OK to close the Computer Search dialog box.

Click OK to close the Run As Account Properties dialog box.

In the navigation pane under Run As Configuration, select Profiles.

Right-click the UNIX Action Account or UNIX Privileged Account profile, and select properties from the context menu to open the Run As Profile Properties – UNIX Action Account or Run As Profile Properties – UNIX Privileged Account dialog box.

Click Add to select a Run As account to add to this profile.

If you have selected UNIX Action Account then in run as account option select Step By Step Run As UNIX Action Account.

And, If you have selected UNIX Privileged Account then in run as account option select Step By Step Run As UNIX Privileged Account.

Add class to this Run As Account.

Click save to save this configuration.

Click close to finish it.

That’s it, now you have configured Run As Account for cross platform.

3. Verification of Unix Client reporting

Click on Monitoring pane and then click Unix/Linux server.

The same will show you the Status of client.

After our initial discovery of the system, the pieces of Health Explorer actually populated were rather limited. These included the Availability/Unix Heartbeat Monitor, and the Configuration pieces.

After a little while, additional sections started appearing . The Operating System Availability Rollup and each of the core services were added, and the Performance counters started gathering data as well.

Health explorer View.

Alert if service stops.

See Disk Performance report for Linux client.

Categories: OpsMgr'07

SMS 2003 Client Push Installation Method Explained

Reference – http://myitforum.com/cs2/blogs/jgilbert/archive/2007/02/22/sms-2003-client-push-installation-method-explained.aspx

There seems to be some confusion about how the client push installation method works to get the SMS 2003 Advanced Client installed on discovered resources at secondary sites lately. I’ve done some research on this and tried to explain the process here to try and avoid any further confusion. The main point to understand before beginning is the difference between enabling the site-wide client push intallation method and using the Client Push Installation Wizard. The site-wide client push installation method will only install clients to assigned resources (within the site’s boundaries), while the Client Push Installation Wizard will attempt to install the client on non-assigned systems (not within the site’s boundaries).

I’ve tried to summarize this using three scenarios:

Discovery and the site-wide client push installation method IS
NOT
enabled at the secondary site

Discovery and site-wide client push installation method IS
enabled at the secondary site

Discovery IS enabled at the primary site, but it IS NOT enabled at the secondary site, and site-wide client push installation method IS enabled at the secondary site.

So, first a quick summary of how all of this works. Getting the Advanced Client installed via the site-wide client push installation method requires (very high level summary here) a Discovery Data Record (DDR) created by a discovery method, and a Client Configuration Request (CCR) generated by a site server for the discovered resource. CCR’s are only created for systems discovered that are (a.) within the site’s boundaries
(not roaming boundaries) and (b.) the discovered resource matches the criteria you’ve set in the site-wide client push installation properties. Once a CCR is processed by the site server’s Client Configuration Manager (CCM) component, the client installation process is initiated.

Scenario1. Discovery and client push IS NOT enabled at the secondary site.
If a discovered resource is within the boundaries of a secondary site, how is
it installed using a client push method (when discovery and client push at the secondary site IS NOT enabled)?

Step1 (DDR creation). If you have enabled a discovery method at the primary site that discovers a resource within a secondary site’s defined boundary, the primary site will create a DDR for the resource. Because the resource is not within the primary site’s defined site boundaries no CCR will be created (client will not be installed). The DDR created will be stored in the database until it is deleted by the “Delete aged discovery data
maintenance task. The DDR is then sent to the secondary site as a PDR
(processed DDR). Because the secondary site does not have client push enabled, that’s the end of the line for that PDR and it will not be processed.

Here’s where it get interesting:
Step 2 (CCR creation). If you use the Client Push Installation Wizard to
push the client out to discovered resources–AND uncheck the “Include
only clients assigned to this site
” check box, a CCR will be created
for the DDRs representing non-assigned resources in the database and an attempt will be made to get the client installed on them. Once installed, the Advanced Client (at the secondary site) will be assigned to the primary site and report up via the secondary site’s proxy management point–if one exists at the secondary site.

Scenario2. Discovery and client push IS enabled at the secondary site.
If a discovered resource is within the boundaries of a secondary site, how is
it installed using a client push method (when discovery and client push at the secondary site IS enabled)?

Step1 (DDR creation). A discovery method at the secondary site discovers a
resource and creates a DDR (forwards to primary site to store in the site
database). The primary site receives the DDR, stores it in the database and
sends the PDR (processed DDR) back to the secondary site.

Step2 (CCR creation). The secondary site recieves the PDR (processed as a DDR) and sees that a discovered resource is within its boundaries (and meets the defined site wide client push installation properties) and creates a CCR for the resource itself (CCR’s do not travel up the hierarchy). At this point, CCM at the secondary site will begin the client installation process by checking for a management point to push the source files to the resource to get the client
installed. If the secondary site has a proxy management point, the client
installation files will be pushed from there, otherwise, the site’s default
management point (at the primary site) will be where the source files come
from.  Once installed, the client will be assigned to the primary site and
report up via the secondary site’s proxy management point–if one exists at the secondary site.

Scenario 3. Discovery IS enabled at the primary site, but it is NOT
enabled at the secondary site, and site-wide client push installation
method IS enabled at the secondary site.


If the primary site discovers a resource that is located within the boundaries of a secondary site, how is it installed using a client push method (when discovery IS NOT enabeld at the secondary site, but client push IS enabled)?

Step 1 (DDR creation). If you have enabled a discovery method at the primary site that discovers a resource within a secondary site’s defined boundary, the primary site will create a DDR for the resource. Because the resource is not within the primary site’s defined site boundaries no CCR will be created (client will not be installed). The DDR created will be stored in the database until it is deleted by the “Delete aged discovery data
maintenance task. The DDR is then sent to the secondary site as a PDR
(processed DDR). Unlike Scenario 1, because the secondary site does have
client push enabled, the PDR can now be processed.

Step 2 (CCR creation). The secondary site recieves the PDR (processed as a DDR) and sees that a discovered resource is within its boundaries (and meets the defined site wide client push installation properties) and creates a CCR for the resource itself (CCR’s do not travel up the hierarchy). At this point, CCM at the secondary site will begin the client installation process by checking for a management point to push the source files to the resource to get the client installed. If the secondary site has a proxy management point, the client installation files will be pushed from there, otherwise, the site’s default management point (at the primary site) will be where the source files come from.  Once installed, the client will be assigned to the primary site and report up via the secondary site’s proxy management point–if one exists at the secondary site.

Note-
Either way, once CCM begins processing the CCR for a resource, it will attempt to install the client once an hour for about 168hrs (one week) before giving up.

Categories: ConfigMgr'07