Kevin Holman's OpsMgr Blog

Creating granular alert notifications - rule by rule, monitor by monitor

There are a couple resources on the web about how to do this from C# and Powershell.  The best sites I have seen are at:

http://blogs.msdn.com/jakuboleksy/archive/2007/01/18/notification-subscriptions.aspx

and

http://code4ward.net/cs2/blogs/code4ward/archive/2007/09/19/set-notificationforalert.aspx

These examples are cool - showing us we can create more granular criteria than the choices exposed in the UI.

In the second link above - the basic Powershell script is posted.  However, many users have been looking for examples of how to add more specific and typical criteria.  The script above will notify on any change in resolution state.... so if you use multiple resolution states, it might send an email when the alert is created, then modified, then closed.  Many want a notification only when an alert comes in New.

The posted script also shows the Last Modified time in the notification in GMT.... where as a UI generated subscription would show the alert time in the correct local time zone. 

The post below will show some of the changes you can make here, and some example scripts.

First things first.... let's talk about what happens when you create a normal subscription in the UI:  When you run the New Subscription wizard in the UI, you are selecting from what was determined to be the most typical choices for subscribing to alerts for a notification.  What this does, behind the scenes, is create some XML, and writes that information to the "Notifications Internal Library" management pack (Microsoft.SystemCenter.Notifications.Internal)

The best thing you can do to understand what is happening - is to create a SINGLE subscription in the UI, and then export this management pack, and open it in Notepad.  What you will see - is that this MP holds all the configuration information for your SMTP server settings, default notification format, all the recipients and their information, product connector subscriptions, and the focus of this discussion: notification subscription details.

Find your simple subscription that you created - and look at the options.  This will start with:

<Monitoring>
    <Rules>
      <Rule ID="Subscription(guid) plus other settings........>
        <Category>Notification</Category>

Look at all the default options.... this will help you understand the XML format and settings for notifications.  Probably the most important to understand is <Criteria>.  What you will see is all the criteria settings you just created, using the UI.  Unfortunately - the UI does not expose all the possible settings for criteria....

So - you may ask - what settings are available?

Well - according to Jakub:  "In terms of which columns you can query for in the criteria, it is anything that is defined on the Alert table in the db."

Whoa!  That's a LOT more options.  The following columns exist in the alert table:

AlertId    
AlertName   
AlertDescription   
BaseManagedEntityId   
ProblemId   
IsMonitorAlert   
RuleId   
ResolutionState   
Priority   
Severity   
Category   
Owner   
ResolvedBy   
TimeRaised   
TimeAdded   
LastModified   
LastModifiedBy   
LastModifiedExceptRepeatCount   
TimeResolved   
TimeResolutionStateLastModified   
TimeResolutionStateLastModifiedInDB   
CustomField1   
CustomField2   
CustomField3   
CustomField4   
CustomField5   
CustomField6   
CustomField7   
CustomField8   
CustomField9   
CustomField10   
TicketId   
Context   
RepeatCount   
AlertStringId   
AlertParams   
SiteName   
ConnectorId   
LastModifiedByNonConnector

So you can see - if you don't mind a little custom XML work.... you have a lot more choices when it comes to notifications.  We can use this to create subscriptions to specific named alerts, or only alerts with a specific custom field value, a specific repeat count threshold, or for a specific computer, or resolution state.  The possibilities get pretty good.  If only this was all exposed in the UI!

Understanding, that once custom modified in XML - you will not be able to ever modify the same (non-standard) subscription in the UI, or you will break your XML customizations.

Ok - beyond criteria - what else is interesting, you ask?

<PollingIntervalMinutes>   This defaults to 1 minute and should not be changed.  This is how often the subscription will poll the SDK to look for new alerts and see if they match any notification subscriptions.

<TimeZone>  Using the script as posted - it did not contain this tag.  Therefore all alerts come in as GMT.  Using this tag - you can set your specific time zone.  Central standard time looks like this:

<TimeZone>6801000000000000C4FFFFFF00000B0000000100020000000000000000000300000002000200000000000000|Central Standard Time</TimeZone>

If you want to know your timezone code - just create any subscription in the UI - look at the Notifications Internal Library MP, and pull it out of there for use in scripting.

<IdleMinutes>  This is the tag to use for Alert aging.  This is used to delay a notification from being sent for "x" minutes, as long as it has not been changed in that time and meets all other criteria.  This is used to keep notification noise down, if alerts are closed or acknoledged quickly, or to create "nag" notifications in additional subscription to "re-notify" after "x" amount of time has passed - and nobody acknowledged or closed the alert.  NOTE:  In order to use this tag - the class targeted MUST be set to "AlertNotChangedSubscriptionConfiguration".... instead of the default which is "AlertChangedSubscriptionConfiguration".  The BEST way to understand this - is to create TWO IDENTICAL subscriptions to alerts, but set one to have alert aging enabled, set the other to not have it enabled.  What you will see is that alert aging subscriptions have a XML tag like the following:

<AlertNotChangedSubscription Property="Any"> </AlertNotChangedSubscription>

Where standard subscriptions that do not utilize alert aging will have the following:

<AlertChangedSubscription Property="Any"> </AlertChangedSubscription>

Make sure you keep these clear.  More on using these in scripts later.

Ok - that covers the most notable XML items.  I would say, it is probably easiest to just configure the XML directly when you want to use these advanced properties that are not exposed in the UI.  However, if you have the need/desire to create these types of subscriptions from script... we can do that, and let's see a couple examples.

Using the Powershell code posted from http://code4ward.net/cs2/blogs/code4ward/archive/2007/09/19/set-notificationforalert.aspx we want to make a couple changes right off the bat.

First thing - is we wont use the ProblemID field as in that example.  This field of an alert is only consistent on Monitors.  However - for any alert generated by a Monitor - the SDK property of  ProblemID will be identical to MonitoringRuleID.  Therefore, we can always use MonitoringRuleID property which will be unique and consistent, for a given alert, whether it came from a rule or a monitor.

To see these values - use get-alert in Powershell.  For a more specific command to see just these properties on new alerts:  get-alert | where {$_.ResolutionState -eq 0} | ft name,problemid,monitoringruleid.

By the way - in the database, the SDK property "ProblemID" = the DB column "ProblemID".  The SDK property "MonitoringRuleID" = the DB column "RuleID".

Ok - so we will make the changes to use MonitoringRuleID and RuleID for all alerts.  You can see the example in my attached script below... and there is an example posted at the link above.

Next - we will add the timezone information.... this is done by adding a new line under "$config.PollingIntervalMinutes = 1".  The new line should look like (without wrapping, and this example is for CST):

$config.TimeZone = "6801000000000000C4FFFFFF00000B0000000100020000000000000000000300000002000200000000000000|Central Standard Time"

Lastly - we will modify the Alert Criteria with our custom subscription criteria.  What we want to do - is subscribe to any alert with a given "MonitoringRuleID" GUID, which using this script, will query that value from the common Alert Name we see in the console.  We can use any criteria here.  Things to keep in mind - the first <expression></expression> tags are not necessary, as they are understood.  Any other AND/OR groupings have to be done manually.  Here is the code from the sample script (this should always be one line in the script - I wrapped it here to make it readable):

$config.Criteria =
"<SimpleExpression>
   <ValueExpression>
     <Property>RuleId</Property>
   </ValueExpression>
     <Operator>Equal</Operator>
   <ValueExpression>
     <Value>$MonitoringRuleId</Value>
   </ValueExpression>
</SimpleExpression>"

What the above will do - is to create a subscription that will match on the specific alert name given to the script, and then create a notification on ANY change to the alert.... such as when the alert is generated (New) AND when the alert is closed.

Let's add some new criteria using an AND statement - which will ONLY subscribe to NEW alerts:

$config.Criteria =
"<And>
  <Expression>
    <SimpleExpression>
      <ValueExpression>
        <Property>RuleId</Property>
      </ValueExpression>
        <Operator>Equal</Operator>
      <ValueExpression>
         <Value>$MonitoringRuleId</Value>
      </ValueExpression>
    </SimpleExpression>
  </Expression>
  <Expression>
    <SimpleExpression>
      <ValueExpression>
        <Property>ResolutionState</Property>
      </ValueExpression>
        <Operator>Equal</Operator>
      <ValueExpression>
        <Value>0</Value>
      </ValueExpression>
    </SimpleExpression>
  </Expression>
</And>"

That will work MUCH better.... if we only want to see a notification for new alerts.  Keep adding to the criteria sections to get the subscription to match exactly what you want.

The only other things I changed in the script - was the echoed statement about what was shown to the user running the script:

write-Host "Executing script to subscribe to specific alert by name..."

And then I changed the formula for naming the subscription.  Since these CANNOT be modified in the UI without breaking them - I changed the default naming for these script generated subscriptions:

$Subscription.DisplayName = "Script created - Do NOT MODIFY in UI - " + $NotificationRecipientName + " - " + $AlertName

This creates subscriptions in the GUI that tip any admin's off - to leave them alone:

Lastly - if we want to use Alert aging in our script - we need to change a couple of items.  First - we need to add a new line for $config.IdleMinutes under the "$config.PollingIntervalMinutes = 1".  Here is an example:

$config.IdleMinutes = 60

That will add an hour delay - and only notify when the alert has been unchanged, and in the console for an hour.  In order to use alert aging delay - we must also change the "$config = New-Object" line from "AlertChangedSubscriptionConfiguration" to "AlertNotChangedSubscriptionConfiguration".  Therefore - in order to use alert aging - you need a different script, than if you dont want alert aging.... and if you have different criteria - you will need a script for each scenario. 

Below - I am attaching a zip file with a couple script examples.....

One script to subscribe to NEW alerts without alert aging, and another with alert aging.

Tips:  It is probably easier just to edit the Notification MP XML for your customizations.  Just remember - to ALWAYS back this file up.... and keep several copies, in case you ever modify the file in a way that is not supported.   

Agent Pending Actions can get out of synch between the Console, and the database

When you look at your agent pending actions in the Administration pane of the console.... you will see pending actions for things like approving a manual agent install, agent installation in progress, approving agent updates, like from a hotfix, etc.

 

This pending action information is also contained in the SQL table in the OpsDB - agentpendingaction

 

It is possible for the agentpendingaction table to get out of synch with the console, for instance, if the server was in the middle of updating/installing an agent - and the management server Healthservice process crashed or was killed.

 

In this case, you might have a lingering pending action, that blocks you from doing something in the future.  For instance - if you had a pending action to install an agent, that did not show up in the pending actions view of the console.  What might happen, is that when you attempt to discover and push the agent to this same server, you get an error message:

 

"One or more computers you are trying to manage are already in the process of being managed.  Please resolve these issues via the Pending Management view in Administration, prior to attempting to manage them again"

 

The problem is - they don't show up in this view!

 

To view the database information on pending actions:

select * from agentpendingaction

You should be able to find your pending action there - that does not show up in the Pending Action view in the console, if you are affected by this.

 

To resolve - we should first try and reject these "ghost" pending actions via the SDK... using powershell.  Open a command shell, and run the following:

get-agentpendingaction

To see a prettier view:

get-agentpendingaction | ft agentname,agentpendingactiontype

To see a specific pending action for a specific agent:

get-agentPendingAction | where {$_.AgentName -eq "servername.domain.com"}

To reject the specific pending action:

get-agentPendingAction | where {$_.AgentName -eq "servername.domain.com"}|Reject-agentPendingAction

We can use the last line - to reject the specific pending action we are interested in.

 

You might get an exception running this:

Reject-AgentPendingAction : Microsoft.EnterpriseManagement.Common.UnknownServiceE
xception: The service threw an unknown exception. See inner exception for details
. ---> System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]:
Exception of type 'Microsoft.EnterpriseManagement.Common.DataItemDoesNotExistExc
eption' was thrown.

If this fails, such as gives an exception, or if our problem pending action doesn't even show up in Powershell.... we have to drop down to the SQL database level.  This is a LAST resort and NOT SUPPORTED.... run at your own risk.

There is a stored procedure to delete pending actions.... here is an example, to run in a SQL query window:

exec p_AgentPendingActionDeleteByAgentName 'agentname.domain.com'

Change 'agentname.domain.com' to the agent name that is showing up in the SQL table, but not in the console view.

How to install IIS on Server 2008 to support OpsMgr Web Console and Reporting

The IIS role on Server 2008 is required for Web Console support, and SQL reporting.  Below are the steps to have a IIS configuration with all the options that are necessary:

 

On the server, run Server Manager

 

Click Roles, then Add Roles.  Click Next.

On the Select Server Roles screen - select Web Server (IIS).  Click Next.

 

Click Next.

On the Select Roles Services screen - add the following check boxes:

• HTTP Redirection
• ASP.NET (add the required additional roles)
• ASP
• Basic Authentication (if using Forms Based auth and SSL)
• Windows Authentication (if using Windows account authorization)
• IIS 6 Management Compatibility  (adds all sub-roles)

 

 

Click Next.  Click Install.

Installing the Web Console on a 2008 Management Server - using Windows Authentication

Below is a step by step on taking a Windows 2008 Management Server, and adding the Web Console...  with the requirement of using Windows authentication.  The easiest method is to use Forms Based auth for Web Console servers.... but using Windows Auth is possible if you can leverage constrained delegation (more on this later).

 

I will start by running setup, and checking the prerequisites for the web console:

 

 

We need to add the Web Server Role, and make sure we include all required sub roles.  This is documented here:

http://blogs.technet.com/kevinholman/archive/2008/09/26/how-to-install-iis-on-server-2008-to-support-opsmgr-web-console-and-reporting.aspx

 

Once IIS is installed correctly - now run the pre-requisite check again:

 

All good.  At this point - we can run SetupOM.exe, and add the web console component.

We will choose Windows Authentication for this exercise.

 

Setup should complete.  If you get an error here.... you might need to open a case with Microsoft... as some hotfixes can possibly block additional OpsMgr roles from being added, such as the web console.  I have 951380, 954049, and 956240 installed.  I was not able to add the web console.... due to the following error:

 

Error 1334.The file File196.2FD07918_9082_437D_99BC_FD43602A4625 cannot be installed because the file cannot be found in cabinet file Data.Cab. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.
MSI (s) (00:84) [12:38:44:863]: Product: System Center Operations Manager 2007 -- Error 1334.The file File196.2FD07918_9082_437D_99BC_FD43602A4625 cannot be installed because the file cannot be found in cabinet file Data.Cab. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.

 

If you are affected by this.... (common also when hotfixes wont apply) we need to do a little work in the registry....   open up HKCR\Installer\Products\DF6E5EFF035E66C49971553D96AA0E4D\Patches

 

Back this key up by exporting it first....  once backed up... delete the REG_SZ GUIDS, and then open the "Patches" REG_MULTI_SZ key, and delete all guids from there.  When done - it should look like so:

 

 

****Note:  If you are running a OpsMgr management group that was originally installed as RTM, then upgraded to SP1 - you might need to leave the following guids in place in the registry when attempting to use this workaround:

727B3A3ADCF2D1945BFF1FD34105570A    (this references MOM2007QFEPreSP1.msp)
8CABA70B215243145A51419A9073262F    (this references MOM2007SP1.msp)

 

 

Now - rerun setup....

Ok....  When setup is complete.... one thing we need to discuss.  KB 954049 is required for Server 2008 support.  If you had already applied this hotfix, you must now re-apply it in order to patch the web console files in the hotfix.  The simplest way is to find the MSP file for your OS version in the C:\Program Files\System Center 2007 Hotfix Utility\ folders.

And, once installed... make sure you re-import your original reg backup we took.  This workaround will typically get you through a web console add, or a hotfix install.

 

Once that is covered - lets test the console, from the management server itself.  Launch the web console from the shortcut on the start menu.

 

 

What you will likely see... is one or more security prompts asking for your username and password.... the console it trying to use Windows Auth.  Once this fails, you will be presented with a forms based authentication screen.... or an error.

 

If you check the OpsMgr event log - you will likely see these errors:

Log Name:      Operations Manager
Source:        Web Console
Date:          9/24/2008 1:06:11 PM
Event ID:      10
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      OMMS3.opsmgr.net
Description:
Instance: 5ogbhfrszo2xqx45iw2wid45.

Error: Data Abstraction Layer: Exception while connecting to the server 'omrms.opsmgr.net'
Thread was being aborted.

This means we need to set up Kerberos constrained delegation, so that Windows Auth can work.

 

1.  Check the SPN of the domain account used for the SDK service account.  For instance... my domain is OPSMGR, my SDK Account is OPSMGR\momsdk07, and my RMS is OMRMS.opsmgr.net.  I will begin... by inspecting the SPN's attached to my SDK account:

setspn /L OPSMGR\momsdk07

Results:

Registered ServicePrincipalNames for CN=momsdk07,OU=SCOM,OU=Accounts,OU=US,DC=opsmgr,DC=net:
        MSOMSdkSvc/OMRMS
        MSOMSdkSvc/omrms.opsmgr.net

This is good.  If for any reason these are missing - we need to add the MSOMSdkSvc class SPN of the RMS computer, to the domain account used for the SDK.  So in my case, this would look like:

setspn /a MSOMSdkSvc/OMRMS OPSMGR\momsdk07

setspn /a MSOMSdkSvc/OMRMSopsmgr.net OPSMGR\momsdk07

 

2.  Verify Domain Functional Level: If you are configuring constrained delegation, you need to verify that the domain controller is operating at Windows Server 2003 functional level. (Note: This is required for constrained delegation.)  Launch "Active Directory Domains and Trusts" with domain admin credentials.  In the console tree, right-click the domain for which you want to verify the domain level select Properties in the context menu.

 

 

 

3.  Verify user account options. 

Open AD Users and Computers, and find the SDK account.  Examine the properties, account tab, and ensure that "Account is sensitive and cannot be delegated" is NOT selected.

 

 

 

4.  Configure constrained delegation:

In ADUC, find the computer account that the web console is installed on. 

Right click it, choose properties, and select the Delegation tab.

If in a Windows Server 2003 domain, on the Delegation tab, click Trust this computer for delegation to specified services only.

And choose the Use Kerberos only radio button.

Click the Add button

In the Add Services dialogue click the Users and Computers button

In the Select Users or Computers dialogue specify the domain account that the SDK service is running under and click OK.

 

In the Add Services dialogue select the service type MSOMSdkSvc and click OK.

 

Click OK to close the Properties Dialogue.  When complete - it will appear as:

 

 

Once this is complete - Constraint Delegation is set up.  You might need to wait for AD replication, and might need to bounce the SDK service on the RMS for this to start working.

These constrained delegation steps work perfectly for Windows Server 2003 - however you might not be successful in Server 2008.  For my Server 2008 Web Console, I had to change the Delegation option for the Web Console server, to "Trust this Computer for delegation to any service (Kerberos only)"....

What hotfixes should I apply ?

In general - you should evaluate all hotfixes available, and only apply those applicable to your environment.

This list is nothing official.... this is just a general list of the recommended hotfixes I end up proactively applying to most environments.... it is not complete and you may be affected by other issues.

 

This is current as of 9-12-2008

 

951979 - Problems occur on a management server that is running System Center Operations Manager 2007 Service Pack 1 when certain management packs are installed

•         Microsoft.SystemCenter.2007.mp  6.0.6278.19               
•         Microsoft.SystemCenter.ACS.Internal.mp  6.0.6278.19               
•         Microsoft.SystemCenter.Internal.mp  6.0.6278.19                       
•         Microsoft.Mom.BackwardCompatibility.mp  6.0.6278.19

I recommend this hotfix for ALL environments.

                 

954049 - Description of the hotfix rollup package for System Center Operations Manager 2007 Service Pack 1 and for System Center Essentials 2007 Service Pack 1: July 25, 2008

•         See article.  This is for Server 2008 support.

I recommend this hotfix for ALL environments which will have Server 2008 as a monitored agent or server role.

 

954903 - The Monitoringhost.exe process may consume all the CPU resources when a large amount of performance data is created by using a managed data source module in System Center Operations Manager 2007

•         Mommodules.dll 6.0.6278.36
•         This also includes/supersedes:

1.      950853 - A memory leak occurs when you monitor Exchange Server 2007 by using the MOM 2007 agent in System Center Operations Manager 2007

•         Mommodules.dll  v6.0.6278.11

2.      951380 - Some computer properties for a cluster node may not be collected by the discovery process in System Center Operations Manager 2007 Service Pack 1

•         Mommodules.dll  6.0.6278.20

I recommend 950853 and 951380 for all environments, however, since 954903 includes BOTH of these... I recommend deploying that hotfix since it will be simpler from an agent impact perspective.  However, if you already have 951380 installed, this is the really more critical one.

 

956240 - The SQL Server process may consume lots of CPU resources on the server that hosts the Operations Manager 2007 database after you make Operations Manager 2007 configuration changes

•         Microsoft.mom.dataaccesslayer.dll  6.0.6278.37

Only "required" if you feel you are affected.

956423- Reconnecting a management group with Tiering scenario sets incorrect MG

•         Microsoft.enterprisemanagement.operationsmanager.dll  6.0.6278.40

Only required if using connected management groups.

 

956689 - Web Application Template Wizard does not use specified RunAs account for Proxy authentication

•         Momnetworkmodules.dll   6.0.6278.41
•         This also includes/supersedes:

951526 - The Root Management Server (RMS) of System Center Operations Manager 2007 Service Pack 1 or Essentials 2007 Service Pack 1 becomes unstable or unusable if a management pack is imported
•         Momnetworkmodules.dll 6.0.6278.24

951526 is required if you use the current Dell Hardware MP, however, you might as well implement the link above for 956689 since it includes 951526 and fixes a potential issue with proxy auth.

 

Make sure you see:  http://blogs.technet.com/kevinholman/archive/2008/06/25/a-little-tidbit-on-hot-fixes-for-opsmgr.aspx

Several of these updates require agent updates as well, so be prepared to deal with those.

 

ALWAYS make sure you double-check the DLL version to make sure the hotfix successfully applied after installing.
ALWAYS make sure you read the instructions to understand if the hotfix is a SQL update, installed to the RMS, MS, and/or Gateway, AND/OR applies to agents as well.

Using OpsMgr to see which servers have not been logged on to via RDP

This came up in a discussion group.... and while it maybe not be all that interesting of a topic.... it is interesting to see the kinds of reports you can write with OpsMgr and look for unique scenarios.

 

The question was - "How can I run a report - and see all my servers that have NOT been logged onto via RDP in the last 30 days?"

 

First - we need to find out what events are logged, so we can capture which servers ARE being logged on to via RDP.  If you have an audit policy that logs successfull logons, we will log an event 528 in the security event log, and the "LogonType" for a RDP logon is "10". 

Here is a link which describes these logon types and what they mean:  http://www.windowsecurity.com/articles/Logon-Types.html

 

So - we want to collect event 528.... but ONLY those events that are RDP... or logon type 10.... so we need to know which Event Parameter that logontype corresponds to, so we can write a rule which will ONLY collect these events.  You can use the logparser tool I mentioned here:  http://blogs.technet.com/kevinholman/archive/2008/04/22/using-event-description-as-criteria-for-a-rule.aspx

As an alternative - if you don't want to use LogParser for some crazy reason... you can create an alert generating event rule for all event 528's, and then in the alert description, simply paste the following - to show you what each parameter in an event equals:

Parameter 1:  $Data/Params/Param[1]$ <BR />

Parameter 2:  $Data/Params/Param[2]$ <BR />

Parameter 3:  $Data/Params/Param[3]$ <BR />

Parameter 4:  $Data/Params/Param[4]$ <BR />

Parameter 5:  $Data/Params/Param[5]$ <BR />

Parameter 6:  $Data/Params/Param[6]$ <BR />

 

Ok.... so now.... we need to write our event collection rule.  It should look something like this:

 

 

At this point.... we can run a simple generic "Event Analysis" Report and look for all event 528's in the Data Warehouse in a given time period.  Any servers that DONT show up.... haven't logged this event.

 

 

 

However, what we REALLY want is something that just shows me the list of all machines in the data warehouse that HAVE NOT generated this event.... for that, we can use a custom query:

 

select distinct elc.computername from Event.vEvent ev
inner join vEventLoggingComputer elc on elc.eventloggingcomputerrowid = ev.loggingcomputerrowid
where NOT eventdisplaynumber = '528'
order by elc.computername

 

Just paste this into a simple visual studio report, add some time/data parameters, and there you have it.  In fact - lets walk through that.  You can use the copy if Visual Studio that gets installed with the SQL 2005 client tools.

1.  Start up visual studio.

2.  File, New Project.  Choose the Report Server Project Wizard:

 

3.  Click Next to start the Report Wizard.

4.  Create a new Data Source (we will swithc our report to use an existing one later)

 

5.  Click Edit, and put in the server\instance, and then choose the data warehouse database.  Choose Test Connection to make sure it's all good:

 

 

 

6.  Click OK, then Next.  Paste in your query that gives you the output you want... from the query I listed above:

 

 

7.  Click Next, and Finish on Report type.

8.  Type a name for the report, such as "Inactive RDP Servers"  Check the box to Preview the report.

 

 

9.  Click Finish.  The preview comes up.  This is a pretty inefficient query, so it might take some time to run in a big datawarehouse.  We will need to adjust some of the column widths using a drag and drop function on the layout tab.... the initial formatting is bad.  Click the Layout tab, and you can drag the column headers to make the report look good:

 

 

10.  Now my report looks good.... but I need to add some date/time parameters....  Click the "Data" tab now.  From the top menu, choose Report, Report Parameters.  Click Add.  Add a StartDate and EndDate paramter, and choose DateTime as the data type, exactly as shown:

 

 

11.  Choose OK, and now when you preview your report, you will have some nice date pickers.

12.  From the top menu, choose build, build report project.  Then browse to your user profile, and find the RDL file we created under \Documents\VisualStudio.

13.  You can take this RDL and import it into your reporting website.  http://servername/Reports  You should create a custom folder there for custom reports.  They will automatically show up in the SCOM console.

14.  Once you import this file, we need to select it in the reporting website, and update the Data Source. 

 

 

15.  Browse the shared data sources, and select the Data Warehouse Main.  Click OK, and make sure you click APPLY on the next screen.

16.  Now run your report.  Pick a start and end time, and run it - here is mine:

 

 

 

You can repeat the above process using this wizard for any query that you want to turn into a report.

Print Server MP updated - added support for Server 2008 to 6.0.6392.0

The updated Print Server MP has been released, update version is 6.0.6392.0

http://technet.microsoft.com/en-us/opsmgr/cc539535.aspx

The monitors are loaded under the following classes:

Print Server

Windows 2008 Print Services Role

The rules are loaded under the following classes:

Microsoft Windows 2000 Print Servers Installation

Microsoft Windows 2003 Print Servers Installation

Windows 2008 Print Services Role

Some initial musings:

1.  This updated MP can *UPDATE* the previous conversion Print MP for 2000 and 2003.  You don't technically have to delete your old Print MP's first - as the 2000/2003 components are still a conversion MP with a dependence on the MOM 2005 Backwards compatibility, and will upgrade your existing MP.  HOWEVER.... there is an issue when upgrading the MP... if you do choose to upgrade, the print server views are not nested all under a single view tree, there will be a tree for 2000/2003, and then a tree which has 2008 under it.  If you delete the old MP first, then import the new MP's, all will be under a single view tree.  This will be better if you scope views for specific operators, so I have to recommend skipping the upgrade, deleting your previous version MP, and importing these as new.

2.  This updated MP still collects a LOT of Performance data out of the box, per printer.  See Print Server management pack fills the Operational DB with TONS of perf data for ideas on turning this off out of the box unless you really need it - or consider overriding the collection to not be so frequent.  If you have a lot of print servers with large numbers of queues, this could be more perf data than you really want to deal with.  The cool thing is - the 2008 MP's have resolved this, by disabling some of the perf collection rules by default, letting you enable them if you want, and the remaining enabled rules are set to "optimized" which will result in much less data insertions into the databases.

3.  It does appear that while we have classes that discover all servers with the Spooler service running, we only apply rules to Windows 2000 and Windows 2003 server instances that have at least 1 *shared* printer.  For instance - we don't populate the "Microsoft Windows 2003 Print Servers Installation" or "Print Server" class unless the discovered instance have one or more shared printers.  This is good and will limit the noise from the MP, as only shared printer queues would be typical for a print server.

4.  The State View under 2000 and 2003 Print servers is not so good.  It is targeting a class that doesn't have any state... as there are no monitors targeting this class, so nothing would ever populate this view... and the default fields listed are not useful at all.  I would be inclined to recommend ignoring this view, and creating a new one, targeting "Print Server" class - which actually has monitors targeting it - so it will show state. 

Here is the default state view.... very strange:

This view doesn't really tell us anything.... and while we could customize/personalize it to "clean it up" a bit.... it is still targeted to a class that does not contain any monitors, so it would never show state.

Instead - I decided to create my own view for 2000 and 2003 printers - and target the "Print Server" class.  However - this failed with an error.... due to the "Print Server" class being flagged as "internal" only for some reason in the XML.  The "Internal" or "Public" flag is a setting on a class that allows you to use that class outside of the MP it came from.  A quick check using MPViewer shows us that it is indeed Internal.  Since this is the only class that has monitors underneath it for 2000/2003 print servers, I don't believe we will be able to create a simple State view here... we can use the Windows Computer Class and scope it to a group, however, this will include state from all kinds of monitors, and not just the print service.  Best I can think of if you really need a state view for legacy print servers, and this is exactly how it worked in the previous MP.  The 2008 specific state view is good and works well.

5.  My Server 2008 Print server did not discover anything.... even after installing a local printer and sharing it.  This is because the MP discovers the "Print Services" role in 2008, which I had not added.  I think this is good - as only dedicated 2008 print servers would have this role added.  Once I added this, and bounced the healthservice to speed up discovery on the agent, it popped right in.

6.  The Legacy alert, event, and performance views for 2000 and 2003 aren't working out of the box - probably because they are scoped to a class that the collection rules are not targeting.  You can easily work around this by creating new views in your own MP - and scope the view to the "Microsoft Windows 2003 Print Servers Installation" class, or create a perf view that is un-scoped by class, but uses logic like "Object = Print Queue".  You can do this for alert, event, and perf views.

Updated Exchange 2003 MP released version 6.0.6387.0

 

http://www.microsoft.com/technet/prodtechnol/scp/opsmgr07.aspx?SCPProdID=3

 

 

This is a pretty major update - and it looks to address the biggest issues with the Exchange 2003 MP.... most notably reducing Self Tuning Threshold noise, SSL enabled alerts, Report fixes and added report descriptions to make them easier to run, fixes to Mail flow, etc...

 

Note:  You will need to take a look at the overrides you have put in place for the existing MP.  If you have already addressed some of these issues fixed below - you may want to consider deleting your overrides that deal with these updates, and re-tune if necessary.

 

 

 

The following list includes all of the changes contained in this update of the Exchange Server 2003 Management Pack.

·      Removed Exchange front end service state monitors that would cause duplicate alerts to be generated.

·      Updated the KnowledgeBase for Performance Collection Rules for Mail flow receiver, Exchange Mail Flow Monitor (Sender Part) and Exchange Mail Flow Monitor (Receiver part) to clarify how these should be configured.

·      Updated the alert description for ExBPA alerts to direct the administrator towards the ExBPA events view since more than one issue may have been found, while only one alert is generated.

·      Changed the scripts for the Exchange Mail Flow Monitor (Receiver Part) so that setting the number of Max missed runs override now works, enabling users to set a threshold for when mailflow alerting should occur. 

·      Documented supported overrides for Mail Flow monitoring in the Exchange Server 2003 Management Pack guide. For more information, see the “How to Configure Mail Flow Monitoring” section of this guide.

·      Changed the top level display name of the folder in the Operations Manager 2007 console to be “Exchange Server 2003”. Note that all Operations Manager 2007 console users will need to clear the console cache for this to display correctly.

·      Changed the Collect_Message_Tracking_statistics script so that it generates an alert if it can’t access the message tracking logs.

·      Added logic to collect event 9950 from the Check_Mailbox_Store_Status.Monitor, enabling users to find which store was dismounted. 

·      Removed the override from the “SSL Should be Enabled” monitor specifying the list of servers to be excluded from the Secure Sockets Layer (SSL) check. Added documentation in the Exchange Server 2003 Management Pack Guide for how to handle this scenario. For more information, see the “How to Configure SSL Monitoring” section of this guide.

·      The sensitivity of all Self Tuning Threshold rules and monitors in the management pack was lowered, increasing the threshold at which the monitors alert.

For this management pack version, the following Self Tuning Threshold monitors have been disabled and replaced with static “consecutive samples over threshold” monitors: 

·    MSExchangeIS\RPC Averaged Latency

·    MSExchangeIS Mailbox\Send Queue Size

·    SMTP Server\Remote Retry Queue Length

·    SMTP Server\Local Queue Length

·    SMTP NTFS Store Driver\Messages in the queue directory

·    MSExchangeIS Transport Driver\TempTable Current

·    SMTP Server\Remote Queue Length

Note:  The Self Tuning Threshold monitors above are still in the management pack, but disabled by default.

For more information, see the “How to Configure Self Tuning Threshold Monitors” section of this guide.

·      Updated several display strings and alert messages in the management pack.

·      Removed the reference to the Backwards Compatibility Management Pack. Removed the Exchange Server Configuration Report, as this was dependent on collecting Backwards Compatibility Management Pack properties.  

·      Updated the Active Client Logons by day report to display the correct data.

·      Updated the Exchange Information Store Usage report to display the correct data

·      Updated the Exchange Message Transfer Agent (MTA) Usage report to display the correct data.

·      Updated the MTA Work Queue Length by day report to display the correct data.

·      Updated the Top 100 public folders by message count report to display the correct data.

·      Updated a number of scripts that collect data mainly for reporting purposes to correctly collect data if the managed server running Exchange uses locales other than US English.

·      Updated the monitor checking the Extensible Storage Engine (ESE) Log CheckPoint Depth so that it collects the correct counter and can alert appropriately.

·      Updated the KnowledgeBase for the Outlook Web Access Logon Failure performance collection rule to clarify its behavior and available overrides.

·      Updated the Disk Space Monitor to generate warning or error alerts depending on the condition, also changed it to a 3-state monitor. For documentation of this monitor, see the “How to Configure Disk Space Monitoring” section of this guide.

·      Updated the Exchange Topology Discovery script to generate less data. Removed discovery of the AdminGroup and RoutingGroup instances, which were not used in the topology diagram. Added an override to the Topology Discovery script to control whether Routing Group connectors should be discovered or not. The default value for this override is “true”.

·      Updated the Exchange Server 2003 Management Pack Guide with instructions for monitoring the MTA service on clustered servers running Exchange. For more information, see the “How to Configure Exchange Server Clusters to be Monitored” section of this guide.

·      Updated report descriptions in the management pack.

·      Updated the management pack guide to new format.

New DHCP and DNS management packs released for Windows 2000, 2003, and 2008

The MP catalog:  http://www.microsoft.com/technet/prodtechnol/scp/opsmgr07.aspx?SCPProdID=3  has new management packs.... Native DNS and DHCP MP's have been published.

These add Windows 2008 server support, and many changes to the old MP's.

DHCP:

The new version is 6.0.6383.0

A note on these new MP's.... there is a base library, and then MP's for each OS.... 2000, 2003, and 2008.  Only import the OS versions that you need to support in a DHCP role in your network.

*** You MUST DELETE any previous version of the DHCP management pack you were running FIRST.  The old DHCP MP was a conversion MP from MOM 2005, and this new MP is a native rewrite.  Therefore - it will NOT upgrade your old MP and you need to delete it.  You will also need to delete any override MP's you had for the old DHCP MP.  Document what these were, and evaluate if you want to re-apply them toward the new MP.  Best to start fresh when a MP is completely re-written.

To import the Server 2008 DHCP MP - you must first import the Server 2008 Base OS MP's.

DNS:

The new version is 6.0.6278.27

A note on these new MP's.... there is a base library, and then MP's for each OS.... 2000, 2003, and 2008.  Only import the OS versions that you need to support in a DNS role in your network.

*** You MUST DELETE any previous version of the DNS management pack you were running FIRST.  These new native MP's will NOT upgrade any previous versions, and running an older version alongside these new versions is NOT supported.  You will also need to delete any override MP's you had for the old DNS MP.  Document what these were, and evaluate if you want to re-apply them toward the new MP.  Best to start fresh when a MP is completely re-written.

To import the Server 2008 DNS MP - you must first import the Server 2008 Base OS MP's.

READ THE GUIDES.  There are several optional steps that should be given a sincere review.... including enabling and tuning many performance threshold monitors that are disabled out of the box, security requirements, objects that must be created for advanced monitoring, etc..

 

 

*****  NOTE - the DNS MP is reported to cause some high CPU utilization.  Recommend you test this MP in a dev environment, and then limited production to look at the impact.  This is known and being investigated.

 

***** NOTE - The DHCP MP has a known issue logging an event about not being able to read the event log - for the workaround - see:  http://blogs.msdn.com/steverac/archive/2008/08/27/updated-dhcp-management-pack-issue.aspx

Check out the new OpsMgr site - OpsManJam.com

Check it:   http://www.opsmanjam.com/default.aspx

 

This is a new site dedicated to OpsMgr content.  Here you can find all kinds of downloadable tools, management packs, scripts, and articles.... that come from internal Microsoft resources, like MCS, PFE, PSS, MSIT, and the OpsMgr product teams.  I expect to see the content growing over time....

 

They already have some good stuff up there, and they have some cool plans.

 

Check out the search in the upper right hand corner:

 

This search is more focused than generic Live, Google, or Yahoo searches... and you can scope it event further.

For instance.... say you are looking for more information on maintenance mode..... perhaps you saw a blog post with good stuff a while back but cant find it now?  You paste that in there.... and choose Blogs:

 

 

Another cool feature.... is they are planning making the MPViewer HTML dumps available on the site.... that will make is easy to send  the content of a specific MP to someone in your company - in a simple, easy to read format.....

 

The site is now RSS enabled.... so if you prefer to use a RSS feed reader, you can do this as well to stay current.

Updated Dell MP released 3.1 A01

Just a few musings on the new Dell hardware MP.

Download Now

 

1.  The MP comes in three files....

Dell.Connections.001.mp - for Servers and Printers
Dell.Connections.Client.mp - for Business Computers
Dell.Connections.StorageArray.mp - for MD3000™ and MD3000i™ Storage Arrays

So most of you will just need to import the Server MP.  No need or benefit to import the storage array MP unless you support and monitor those specific array models above.  I recommend deleting any Dell MP's you had previously imported.. along with any overrides, and starting from scratch on this one, but in place upgrade from 3.0 is supported on OpsMgr SP1.

 

2.  To monitor an agent's hardware, OMSA 5.3 or later must be installed on the server.  Updating OMSA will likely require several BIOS and driver updates on your servers... so plan accordingly.  If you deploy this MP and some agents do not have OMSA 5.3 or later installed (they have an older version) then the MP will group them under "unknown", and Dell monitoring will be disabled.  This is a huge improvement from previous versions.... where monitoring still tried to apply and ended up causing WMI problems on the agents.  What would be *MUCH* better.... is to take any agent without OMSA 5.3 or newer.... and drop it into a group, or class, where ONLY event log and performance monitoring is done.... since these are native.  That way - if an agent with OMSA 5.1 or 5.2 is out there - most of the critical events will still match event log expressions, as these do not change very often.  Still... best to just update the OMSA version so your monitoring is complete and current, end-to-end.

 

3.  Dell is still using their own internal terminology to revision MP's.....  Such as.....  "3.1 A01".....  what does that mean to an OpsMgr admin?  Dell should put the actual MP version as seen in the OpsMgr console on their download page.....  The previous version of the "Dell Management Pack" file "Dell.Connections.001.mp" was 3.0.0.27.   The new MP imports as 3.1.0.118.  The COOL thing.... is that Dell put the "3.1 A01" into the common name of the MP which shows up in the OpsMgr console.... so finally an OpsMgr admin can know if he is current or not based on Dell's download page.  :-)

 

4.  Dell MP's do not currently support Server 2008.... according to their support matrix in the guide.  Hope this is coming out soon. 

 

5.  KB951526 IS REQUIRED!!!  I think this needs a little more stress than a small blurb in the appendix.... if you plan on using this MP - you should first apply 951526 to your OpsMgr environment.

 

6.  You REALLY need to read the guide on this one.  After importing the Dell Server MP.... all your management servers will start logging a 31707 event error every 5 minutes, complaining about not being able to find a directory.  You have to run the DellBMCLogSetup.exe on all management servers, which creates a local directory and file in C:\DellReports.  Fundamentally - anything optional like this.... should be disabled by default.... instead of logging constant errors by default.... letting the end user enable it if they want this type of monitoring.  The rules involved in this appear to be targeting the "Management Server" class, and run a script every 360 minutes, and another rule monitors the contents of a text file that would get created.

 

That's about all I could see initially.  I'll be looking forward to testing it on live Dell servers... and see if they have solved the problems interacting with WMI that I experienced with previous versions.

 

Update 8-18-08

Apparently there is what appears to be a bug in this MP.... on all my management servers, I see the following events in the OpsMgr event log:

 

Event Type:    Warning
Event Source:    Health Service Modules
Event Category:    None
Event ID:    21402
Date:        8/18/2008
Time:        3:15:46 PM
User:        N/A
Computer:    OMMS2
Description:
Forced to terminate the following process started at 3:14:46 PM because it ran past the configured timeout 60 seconds.
Command executed:    "C:\WINDOWS\system32\cscript.exe" /nologo "BMCLogGet.vbs"
Working Directory:    C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 15\2829\

One or more workflows were affected by this. 

Workflow name: Dell.Connections.BMCLogRetrieve
Instance name: OMMS2.opsmgr.net
Instance ID: {7E69629F-1CAD-62A7-F706-6ED089BA940F}
Management group: OPS

 

Event Type:    Warning
Event Source:    Health Service Modules
Event Category:    None
Event ID:    21413
Date:        8/18/2008
Time:        3:15:46 PM
User:        N/A
Computer:    OMMS2
Description:
The Event Policy for the process started at 3:14:46 PM has detected errors in the output.  The 'ExitCode' policy expression:
    [^0]+
matched the following output:
    3

Command executed:    "C:\WINDOWS\system32\cscript.exe" /nologo "BMCLogGet.vbs"
Working Directory:    C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 15\2829\

One or more workflows were affected by this. 

Workflow name: Dell.Connections.BMCLogRetrieve
Instance name: OMMS2.opsmgr.net
Instance ID: {7E69629F-1CAD-62A7-F706-6ED089BA940F}
Management group: OPS

 

The above is recurring every 6 hours... (360 minutes)... and also creating an application exception that is being picked up by AEM:

 

 

Some notes on the dell discovery:

 

The primary discovery (fist discovery that runs) is targeting Windows Computer.  However - this discovery does not show up in the Ops console under "object" discoveries due to a problem with the MP.

You can see this in MPviewer, however:

 

 

So ALL Windows computers will be inspected to see if they are a "Dell System" every 6 hours.  It does this by running a script on ALL Windows Computers every 6 hours to see if they are a Dell server. 

 

The script appears to simply check WMI to see if a value for Manufacturer = Dell, and then collect BIOS information.  Then it will populate instances of the Dell System Class.  You can see these under Monitoring/Discovered inventory to see if this is working.

 

Here is the discovery script, which anyone can pull from the XML:

 

************************************

Option Explicit
On Error resume next

Dim oArgs
Set oArgs = WScript.Arguments
if oArgs.Count &lt; 3 Then
   Wscript.Quit -1
End If

Dim SourceID, ManagedEntityId, TargetComputer       

SourceId = oArgs(0)
ManagedEntityId = oArgs(1)
TargetComputer = oArgs(2)

Dim oAPI, oDiscoveryData, oInst
Set oAPI = CreateObject("MOM.ScriptAPI")
set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)

Dim strComputer, WbemServices, wbemObjectSet, wbemObject, sQuery
Dim Manufacturer
strComputer="."
Set WbemServices = GetObject("winmgmts:" &amp; "{impersonationLevel=impersonate}!\\" &amp; strComputer &amp; "\root\cimv2")
If IsEmpty(WbemServices) Then
    MOMDebugLog "Unable to open WMI Namespace root-cimv2.  Check to see if the WMI service is enabled and running, and ensure this WMI namespace exists." &amp; Err.Description
Else
    GetManufacturerName()
    If Instr(Manufacturer, "Dell") Then
        set oInst = oDiscoveryData.CreateClassInstance("$MPElement[Name='Dell.Connections.DellSystem']$")
        call oInst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", TargetComputer)
        call oInst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.LogicalDevice']/DeviceID$", TargetComputer)
        call oDiscoveryData.AddInstance(oInst)
    End If
End If

' Submit the data
Call oAPI.Return(oDiscoveryData)

Set oDiscoveryData = Nothing
Set oAPI = Nothing
Public Function GetManufacturerName ()
    'Retrieving ManufactuferName
    On Error resume next
    Set wbemObjectSet = wbemServices.ExecQuery("select * from win32_bios")
    If Err.Number &lt;&gt; 0 Then
        ErrorMessage = "Number:" &amp; Err.Number &amp; "Description:" &amp; Err.Description
        MOMDebugLog (ErrorMessage)
    End If
    If (wbemObjectSet is Nothing) or (IsNull(wbemObjectSet)) Then
        LogMessage = "Unable to retrieve Manufacturer"
        MOMDebugLog (LogMessage)
    Else
        LogMessage = "Manufacturer Name retrieved successfully"
        MOMDebugLog (LogMessage)

        Dim objItem
        For Each objItem in wbemObjectSet
            'Error checking
            If Err.Number &lt;&gt; 0 Then
                ErrorMessage = "Number:" &amp; Err.Number &amp; "Description:" &amp; Err.Description
                MOMDebugLog (ErrorMessage)
            End If
            'Object Retrieval
            If not objItem is nothing Then
                Manufacturer = objItem.Manufacturer
            End If
        Next               
    End If
    Set wbemObjectSet = Nothing
End Function
                                                    </ScriptBody>
                <TimeoutSeconds>300</TimeoutSeconds>
              </DataSource>
            </MemberModules>
            <Composition>
              <Node ID="DS" />
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>System!System.Discovery.Data</OutputType>
      </DataSourceModuleType>
      <DataSourceModuleType ID="Dell.Connections.DellServer.DiscoveryRule" Accessibility="Internal" Batching="false">
        <Configuration>
          <xsd:element name="IntervalSeconds" type="xsd:integer" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
          <xsd:element name="Computer" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
        </Configuration>
        <OverrideableParameters>
          <OverrideableParameter ID="IntervalSeconds" Selector="$Config/IntervalSeconds$" ParameterType="int" />
        </OverrideableParameters>
        <ModuleImplementation Isolation="Any">
          <Composite>
            <MemberModules>
              <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.DiscoveryProvider">
                <IntervalSeconds>$Config/IntervalSeconds$</IntervalSeconds>
                <SyncTime />
                <ScriptName>DellServerDiscovery.vbs</ScriptName>
                <Arguments>$MPElement$ $Target/Id$ $Config/Computer$</Arguments>
                <ScriptBody>

******************************

 

 

Next.... we see the next discovery will target our newly populated "Dell System" class instances - and run the "Dell Server Discovery"..... and once again - this discovery does not show up in the Ops console under Object discoveries.... This would be a really good discovery to override - if you wanted to limit the number of Servers to initially receive the Dell Management Pack.... however by not exposing this to the ops console, that functionality has been somewhat limited.  You can see it in MPViewer:

 

 

This discovery runs a script every 6 hours against all discovered instances of "Dell Systems Instances".  The script is a bit long.... but this is the core script that discovers most of the Dell objects, to populate the other classes such as BIOS, hardware, software, etc...  The script connects to WMI - polls some information, and checks to see if OMSAVersion = RequiredOMSAVersion = 5.3 

It LOOKS like if you have a newer version of OMSA... like 5.4 - this wont work either... unless I am reading the script wrong.  I cant test this as I don't have any Dell servers.  Regardless.... it is designed to look for the supported OMSA version of 5.3, and if not - then it dumps the machines into an Unknown group.  If it works properly, you will be able to go into Monitoring, Discovered Inventory, and load the "Dell Server Instance" class and see the discovered systems and their attributes.

My experience installing a SCOM Management server on Windows Server 2008

Figured I might as well chronicle the process.

 

1.  First - starting off with a generic install of Server 2008 x64 Enterprise.  Since this is running on Hyper-V, I installed the Hyper-V additions to make it run correctly under the hyper-v host.  Gave it a static IP, joined my domain, enabled remote management so I can TS into it.  I will be logging in as an account that is a member of the OpsMgr admins group, local admin on all servers, and SA over all databases.

2.  Left UAC, Windows Firewall, and IE ESC enabled and in their default configurations.  I added my SCOM Admins global group to the local admins group, and I explicitly added the domain SDK and management server action accounts to the local admins group.

3.  Ran Windows Update and updated to all critical updates.  The first batch after a clean install was 12 updates totaling 127MB as of this writing.

4.  Ran the 3 required Server 2008 hot-fixes to support OpsMgr Server roles on Windows 2008:  951327  and  952664  and  953290

5.  Ran OpsMgr's SetupOM.exe - and kicked off the pre-req checker.  It failed:

 

 

Luckily - those are built into the OS.....  so I run Server Manager, add features, and check the boxes next to .NET Framework 3.0 and Windows Powershell.

That didn't take long... now the pre-req checker again - and all greens....  so let's kick off the install.

 

6.  During setup - I de-selected the DB and Web Console.... leaving the Management Server, User Interfaces, and Command Shell.

7.  I gave it the database location, Action account, SDK account, anf joined the CEIP program.  Said No to Microsoft Update and away the install goes.  I *have* seen issues where customers need to run SetupOM.exe "as an Administrator" from the right click menu... so if you get an error about not being able to verify accounts - try that.  I did not get that error.

8.  Install was a success!   I have had customers state this failed... with configuring Windows Firewall errors, but I did not get any errors.

9.  A quick look at the console to make sure things look good.  My new management server shows Healthy in the Administration pane of the console.  No major alerts in the console with regard to the new MS.  I hit the Management Server State dashboard view, and pulled up Health Explorer for the new MS.  All good.

10.  I spot check the new MS event log.... in the OpsMgr log... some funny business is going on..... all my agents are reporting in this log that they are not heart-beating.  However - this is a new MS and no agents are even assigned to it.  This could be a temporary issue, as the new configuration is becoming active.  If I check all those agents in the console - they are still heart-beating just fine, and no heartbeat alerts were generated.

11.  I checked the Windows Firewall configuration - and the OpsMgr install configured the firewall to open Inbound ports for access to the management server:

 

 

12.  Before we add any agents on this management server - we need to get it patched up to spec with the other management servers in my environment.  I currently am running 951380 and 954049.... so both will need to be applied to this management server.  This is to make sure this MS is patched, and to apply the update files the the management server's \AgentManagement folder... so any subsequent agents that are push from this MS will get the updates that are consistent with my environment.  I start with 951380... run the MSI - accept all defaults, then kick of the hotfix update from the installer splash screen.  Then I kick off 954049 roll-up for Server 2008...

13.  Another quick spot check of the OpsMgr event log... looks good.  No major issues.  I checked the \Health Service State folders.... we have a current OpsMgrConnector.Comfig.xml.... and it lists the RMS as the Parent, and has all my agents as Children.  Good.  I spot check the Management Packs folder, and I can see all my MP's have downloaded.

14.  Time to move agents....  I moved them in the console... to load balance my environment.

 

On the new MS event log - as agents get updated config... they will move to this management server, and we will see the following type events for each agent:

Log Name:      Operations Manager
Source:        OpsMgr Connector
Date:          8/4/2008 10:33:34 PM
Event ID:      20020
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      OMMS3.opsmgr.net
Description:
The health service {33196DB1-42DB-7D62-A12F-9C6A4620CF80} running on host dc2.opsmgr.net and serving management group OPS with id {E7850522-67DF-F9E6-888A-38C99239AB74} is available.

Doesn't get much easier than this.  :-)

 

 

Update....

As an afterthought... I went back and double-checked my \AgentManagement folder... and found that 951380 msp was present - but 954049 msp was missing.  I did install it - and I don't think I got any errors..... the hotfix utility was there - but I could not find the MSI log from it.....   I tried to reinstall it manually, by running the MSP file in the hotfix folder, but this gave a weird error.... so I just uninstalled the hotfix utilities from control panel/programs and features, and then re-ran the MSI for this hotfix.  It installed just fine, and now shows up in all places.  It appears that the management server did not like getting patched with 951380 and 954049 without