| Profil de OperationsOperations ManagerBlogListes |  Outils  Aide |
|
20/09/2006 Computer Group problem with Windows OS Desktop MPIf you have installed the Windows Base OS Desktop MP, you may have noticed some interesting results ... like your Windows 2003 systems are being monitored using the rules from the Desktop MP. This is because the Microsoft Windows XP Computers Group has a formula that identifies any OS greater than version 5.1 as Windows XP.
The problem with this formula is while the version for Windows XP is 5.1.2600, Windows 2003 is version 5.2.3790 (the third set of digits is the build number); so rules from the Desktop MP will target Windows 2003 servers!
To add to the fun, Windows XP Professional x64 edition is also version 5.2.3790, and we do want to target those systems.
Let's look at a way to modify the formula. The formula for the Computer Group delivered with the management pack is:
AttributeValue(Microsoft Windows Current Version)>=”5.1”
To change it to ignore Windows 2003 Server, you could modify the formula to:
(AttributeValue(Microsoft Windows Current Version)>=”5.1” AND AttributeValue(Microsoft Windows Current Version)<”5.2”)
Unfortunately, this modification will not pick up 64-bit versions of Windows XP, which would have to be manually added to the computer group. It will also exclude Windows Vista systems.
This computer group rule is in version 05.0.3000.000 of the management pack. 19/09/2006 Getting a handle on the Availability Reporting Management PackAn indicator of operating system stability is the amount of time the OS itself is available. Microsoft’s Availability Management Pack (AR MP) can help you identify servers with unexpected outages. The MP tracks server availability over a period of time and uses reports to track trends. You can use these reports to identify causes for both planned and unplanned downtime.
Most of Microsoft’s management packs are installed by extracting files (.akm and .xml files) from a downloaded package. The AR MP is a bit different as it has four separate pieces:
When you extract the files, you get two MSI installer files in addition to the akm and rdl components:
Although the akm creates a number of rule groups, it does not link any computer groups to these rule groups, which is required for the rules to function. You will want to either use a custom computer group or link the rules to the Microsoft Windows Servers computer group. Here is where things start go get exciting. Documentation in the Availability Reporting Management Pack Guide states computer groups should be linked to the following rule groups:
Unfortunately, without version 005.0.5000.000 or above of the MP, linking the groups as suggested above does not generate any reports! As Microsoft discusses in support document #914989 (http://support.microsoft.com/kb/914989/), the workaround at that time was to associate the computer groups with the top-level rule. Microsoft released a substantial update to the Availability Reporting MP at the end of August 2006. The updated version appears to have resolved the computer group issues so the original documentation now does represent the correct mapping.
For obvious reasons, this makes it important to know which version of the management pack you are working with. To date, Microsoft has released three versions of this MP. Since there are multiple parts to the management pack, just checking the version of the rule group in the Administrator console is not enough.
Microsoft suggests running a SQL Server query, documented in KB 924633 (http://support.microsoft.com/kb/924633/). The query has the following syntax:
SELECT * FROM MRAS_MRASInstallVersion The query returns values for two important fields:
If you have the August 2006 version of the Availability Reporting MP, the TableVersion Value is 1.0, the ProcVersion is 1.8, and the akm file version is 05.0.5000.000. Specifically:
There are several other gotcha’s to implementing the Availably Reporting MP, which we discuss in our forthcoming book, Microsoft Operations Manager 2005 Unleashed, http://tinyurl.com/yxtrqd. 08/09/2006 How to Resolve Issues Configuring the MOM 2005 SharePoint WebpartWith the release of MOM 2005 SP1, we were no longer able to get the MOM 2005 SharePoint WebPart to work correctly. The first issue we ran into was just getting it installed. The installation failed unless we included the correct SharePoint Virtual Server information which for us is highlighted below. The Virtual Server Physical Location defaulted correctly. SharePoint Virtual Server (including port)
Virtual Server Physical Location:
C:\inetpub\wwwroot
Next we had to change the config.web file for SharePoint (for us located under C:\Inetpub\SharePoint), from the following:
<trust level="Full" originUrl="" />
To this:
<trust level="WSS_Minimal" originUrl="" />
And do an IISreset.
Now we could add the WebPart to the Sharepoint (or WSS) site, but it would error out when we attempted to configure it by pressing the “Show MOM 2005 Property ToolPane” button. With significant help from Microsoft we made the following change. Edit the config.web file for SharePoint (for us located under C:\Inetpub\SharePoint), to add the following information just after the </configSections> tag: <runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="microsoft.web.ui.webcontrols"
publicKeyToken="31BF3856AD364E35"
culture="neutral" />
<!-- Redirecting to version 5.0.2749.5 of the assembly. -->
<bindingRedirect oldVersion="5.0.2749.0"
newVersion="5.0.2911.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
Next do an IISreset. You may also need to copy the microsoft.web.ui.webcontrols.dll file to the SharePoint bin directory (for us it was C:\inetpub\SharePoint\bin). After this we were able to configure the WebPart! MOM 2005 Security AccountsMOM 2005 Accounts: What are they, what they do, and what permissions do they need? We’ve seen and run into quite a bit of confusion about the different security accounts that exist in MOM 2005. Specifically what accounts exist for MOM, what they do, and what permissions do they need to do it. The following is an attempt to provide a summary of this information based upon our own experiences. For Microsoft’s best practices you can refer to the Microsoft MOM security guide which is available at: http://go.microsoft.com/fwlink/?linkid=33035. Most of the debate revolves around the Action accounts that are used within MOM. The recommended approach is to use Local System (the Network Service on Windows 2003 is recommended over Local System) to provide the required functionality. The MOM Agent Action accounts should be run as Network Service unless the account cannot effectively be given the permissions it requires based on management packs deployed to that system. As an example, the SQL Server management pack requires access to various databases which will not be available unless the Local System/Network Service account is given permission to those databases. We can think of more than one organization which was not comfortable with a system account having that level of permissions into their databases. The following is a summary of the security accounts in MOM, what they do, and the recommended permissions. Basically you have to have an account with permissions to deploy the agents (the Management Server Action account is recommended) and one which will have access rights to the MOM databases (the MOM DAS account). For more detailed information on these, our upcoming MOM 2005 Unleashed book provides quite a bit more than what is listed below. • Management Server Service account (the MOM Service account) – What does it do? Communicates with the agents, runs local agent on the management server
– What type of account should I use? Local System/Network Service
• Management Server Action account – What does it do? Installs/uninstalls agents, runs server-side responses on the management server, computer discovery, agentless operational data gathering, runtime tasks from the MOM console
– What type of account should I use? domain admin, or local admin for each server to install an agent on
• MOM DAS account – What does it do? Controls access to data in the OnePoint database
– What type of account should I use? domain account, permissions to the OnePoint database (permissions are configured by the MOM setup program)
• MOM Reporting account – What does it do? Data transfer between the Operations and Reporting databases
– What type of account should I use? Use the “MOM DAS” account
• MOM Agent Action account(s) – What does it do? Runs responses (scripts, managed code responses) on the managed system, collects performance data and events
– What type of account should I use? Local System/Network Service, or domain user as a local admin*
• MOM Agent Service Action account(s) – What does it do? Used when communicating with the management server and running the agent
– What type of account should I use? Local System/Network Service, or local admin
*On Windows 2000 Server, the Action account must be a member of the local Administrators group. On Windows Server 2003, you can use a low-privileged account for the agent’s Action account under certain circumstances (see Microsoft’s MOM 2005 Security Guide for more information). |
|
|
