SQL 2008 SP1 and Cumulative Update packages

For some months now Cumulative Update 3 (CU #3) for SQL 2008 SP1 is out. It resolves many SQL 2008 SP1 related issues. Each new CU contains the hotfixes/updates contained within the preceding  CU.

So it is not necessary to install CU#1, CU#2 and then CU#3. Just install CU#3 and be done with it.

In a SCOM R2 test environment of mine I installed CU #3 for SQL 2008 SP1 since I encountered some SSRS issues. With CU #3 these were solved. So when you run SQL 2008 SP1 for SCOM R2 you can install CU #3 since it solves some issues. I tested it and SCOM R2 runs like a charm.

CU #3 is to be found here. Be sure to select the correct version since there are multiple CU #3 packages available. Most of the times this package is the one you need:

New MP Released: Windows 2008 R2 Direct Access Server

Microsoft has released a new MP for monitoring Windows 2008 R2 Direct Access Server.

Taken directly from the website:

The DirectAccess Server Management Pack supports a rich set of Alarms, Monitors and Agent Tasks that can be used to successfully and efficiently manage a DirectAccess server. The DirectAccess Server Management Pack supports the following features

• Automatic discovery of the DirectAccess Server and its components, including:
  • IP-HTTPS Gateway
  • ISATAP Router
  • Network Security Component
  • 6to4 Router
  • Teredo Relay
  • Teredo Server
    
• Monitors that identify:
  • Status of Direct Access Server and its components
  • Denial of service (DoS), spoofing, and replay attacks
  • ICMP and data traffic queue overflows
  • Utilization of available IPsec states on the Direct Server

To be downloaded from here.

KB974144, Cumulative Update 1 for SCOM R2: Error code 1603

Hmm. Learned my lesson today to double check EVERYTHING!

At a new customers site I wanted to run CU#1 for SCOM R2. Got an account with admin privileges on the RMS and within SCOM. I downloaded the CU, ran it as I do normally and selected the option Run Server Update. So far so good.

But then I got an error message during the installation of CU#1. So I opened the log and at first I couldn’t find anything amiss. So I pinged a good friend of mine who has much SCOM knowledge & experience and sent him the log. But he didn’t see anything wrong either.

The log file is big however so it was time for a very thorough search through it. And now I found this:

I checked the account I used and indeed, it had no access to the SQL instance hosting the SQL Database for SCOM R2. Then the update was ran with an account with permissions on that SQL instance and now all went well.

So whenever running CU#1 make sure the account being used has access to the SQL instance hosting the SCOM R2 Database.

OpsMgr R2 and Service Level Tracking (SLT): Targeting explained.

27-01-2010 Update:
The part of this posting where an example of a SLT is built has been updated since it wasn’t spot on.

Out of the field I do get a lot of questions about setting up SLT and more specific how to get the Service Level Objectives (SLOs) with the Collection Rules (Collection rule SLO) functional.

Many times the SCOM Administrators end up with an empty Performance Collection Rule screen, like this:

And soon they say: ‘Duh! SCOM is broken!’. But wait! That’s not the case. It is all about targeting.

When that isn’t done properly, one ends up with an empty screen like the one above. And before targeting can be done properly one needs to get a better understanding about HOW SCOM operates and HOW Classes relate to each other.

Sure, you can click till you drop and hope that on a certain moment you have selected the correct Class at random, but wouldn’t it be nice to approach it in a more intelligent way?

So it is back to the drawing board AND to RTFM the related MP guide(s) as well.

Why RTFM the related MP guides you ask? Good question!

Lets take a look at the Server OS MP Guide for instance. Like every MP Guide it contains a section Understanding Management Pack Operations. This section contains much worthwhile information, like the subsection Classes. A table shows all available Classes in the related MP and describes every Class. So What?

By just looking at the table you get a better understanding of what a certain Class might or might not contain:

I have highlighted some Classes since the Description tells me these Classes do contain other instances as well. Perhaps even some Performance Counters (aka Performance Collection Rules)?

For this we need to go back to the SCOM R2 Console to investigate it further. Lets start the SCOM Console, log on as a SCOM Administrator and select the Wunderbar Authoring and go to Authoring > Management Pack Objects > Rules.

Whenever a collection happens and is to be found back in a Report it is done by a Rule. So this is the place to be. Lets apply some filtering and use the two highlighted Classes we found earlier. Click on the Change Scope link displayed on the top right in the midsection of the SCOM Console. The Scope Management Pack Object screen is shown: 

Select the option View All targets and select the two Classes (Windows Server 2008 Full Computer and Windows Server 2008 Full Operating System) and click OK. Now all related Rules for these Classes are shown:

Whoa! That’s a difference! The first Class shows only 6 rules many of which are contained within the MOM 2005 Backward Compatibility MP which isn’t interesting at all for our quest for Collection Rules.

The second Class shows 44 Rules! That’s more like it! But not EVERY Rule is a Collection Rule. And we need Collection Rules. Lets take a clearer look at these Collection Rules related to this Class:

Thirteen I have counted. So now we know what Class to select for the SLT in order to get a filled Collection rule SLO. Lets make one!

Go to Authoring > Management Pack Objects > Distributed Application > right click > Create a New Distributed Application. Give it a name like WebApp and use as a Template the Line of Business Web Application. DO NOT USE THE Default MP but create a new one instead and click OK.

Now you are in the Distributed Application Designer window. In this example I have added the SCOM Web Console as the Web Site and the OpsMgr DB as SQL Database. Also I have added an additional Component and selected the Component Operating System > Windows Operating System and added the RMS to that Component.

Now the Distributed Application model looks like this:

Save this DA.

Go to Authoring > Management Pack Objects > Service Level Tracking > right click > Create > give it a name > Next > hit the button Select for the option Targeted Class, leave the Search Result Filter as it is (Distributed Application) and select the DA we just created (WebApp) and click OK.
 

Now we are back in the main screen. The earlier created MP is automatically selected and can’t be changed. This is because the selected DA is contained within that MP and any unsealed MP cannot be referenced by any other MP. Click Next.

Click Add > Collection Rule SLO. Now the Service Level Objective (Collection Rule) screen is opened. Give it a logical name. Change the Targeted class to Windows Server 2008 R2 Full Operating System. 

Click on the Select button of the Performance Collection Rule box and the Select a Rule screen is opened. Tada! There are the thirteen Performance Collection Rules: 

Select the the Collection Rule Processor % Processor Time Total 2008 and click OK. Adjust the Aggregation Method and the Service Level Objective Goal as needed and click OK.

While we’re at it, we add a Monitor State SLO to it as well, a bit like this:

Click OK > Next > Finish > Close. 

Now the SLT is built.

Go to the Reporting Wunderbar > Reporting > Microsoft > Service Level Report Library > Service Level Tracking Summary Report. Open this report. Add the earlier built SLT, select a proper start date:

Run the Report:

Clustering & HA documentation, part II

I already posted an article about it, found here.

The same list still exists but new Cluster docs for Cluster Shared Volumes (CSV) & Migration have been added as well, to be found here.

All credits go out to the members of Microsoft's Failover and Network Load Balancing Clustering Team Blog.

Its coming! SCOM R2 Unleashed

Just got the new from this blog: the eBook SCOM R2 Unleashed is coming! Great!

Taken directly from the blog:

System Center Operations Manager 2007 R2 Unleashed - a supplement to the earlier System Center Operations Manager 2007 Unleashed - is announced for availability mid-March 2010. As a supplement, the R2 eBook includes 9 chapters of new material covering OpsMgr 2007 R2 and additional topics not in the first book. Here's the chapter lineup: Introduction and What's New Unix/Linux Management: Cross Platform Extensions Operations Manager 2007 R2 and Windows Server 2008 Using SQL Server 2008 in OpsMgr 2007 R2 PowerShell Extensions for Operations Manager 2007 Management Solutions for Small and Midsize Business Operations Manager and Virtualization Management Pack Authoring Unleashing Operations Manager 2007 Appendix A. OpsMgr R2 by Example Appendix B. Reference URLs Appendix C. Available Online Chapter 9 includes a "deep dive" into managing distributed environments, high availabiilty, business continuity, the new Visio add-in, going beyond the basics of ACS, network monitoring using distributed applications, and targeting.

Catch-22: Securing ACS Reports AND scheduling them. Part V: Auditing Security

--------------------------------------------------------------------------------- 
Postings in the same series:
Part   I: How Catch-22 was born…
Part  II: What do we need?
Part III: Setting Security
Part IV: Setting the subscriptions on the ACS Reports
---------------------------------------------------------------------------------

This will be the last posting in this series and will be all about auditing the security on the SQL Server hosting the ACS Database which is also the SQL Server Reporting Services (SSRS aka SRS) for the ACS Reports.

In order to accomplish this certain tasks need to be completed:

1. Setting an Auditing Policy on the SQL Server
2. Creating a MP which monitors the Security Event log on the SQL Server and raises Alerts
3. Creating a Notification Model for the Alerts generated by the MP mentioned in Step 2.

#1: Setting an Auditing Policy on the SQL Server
It is to be preferred that any policy is created on AD level, not on the server level since the latter is much harder to maintain and to keep a solid overview. How ever in this example I will set locally on the server the Audit Policy.

1. Go to Start, in the run box, type gpedit.msc <enter>. The Local Group Policy Editor will be started now.
   
   
2. Go to Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy and select the option Audit account management. Open it, select both options (Success and Failure) and click Apply > OK.
    
   Close the Local Group Policy Editor screen.

#2: Creating a MP which monitors the Security Event log of the SQL Server and raises Alerts
Now a MP (or better, a set of rules/monitors all contained in the same MP) needs to be created which monitors the Security Event log of the SQL Server hosting the ACS Database. These Security Events will be monitored:

Monitor/Rule Name	Security EventID	Alert Description (Based on Windows 2008 R2 events!!!)
Security Log Cleared	1102	User '$Data/Context/Params/Param[2]$' from Domain '$Data/Context/Params/Param[3]$' cleared the Security Log of server  '$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/DNSName$'
User Created	4720	User '$Data/Context/Params/Param[4]$' created the new User Account '$Data/Context/Params/Param[1]$' on server '$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/DNSName$'
User Deleted	4726	User '$Data/Context/Params/Param[4]$' deleted the User Account '$Data/Context/Params/Param[1]$' on server '$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/DNSName$'
User Added To Group	4732	User '$Data/Context/Params/Param[6]$' added User '$Data/Context/Params/Param[2]$' to Group '$Data/Context/Params/Param[5]$' on server '$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/DNSName$'
User Deleted From Group	4733	User '$Data/Context/Params/Param[6]$' deleted User '$Data/Context/Params/Param[2]$' from Group '$Data/Context/Params/Param[5]$' on server '$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/DNSName$'
Group Created	4731	User '$Data/Context/Params/Param[4]$' created the group '$Data/Context/Params/Param[1]$' on server  '$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/DNSName$'
Group Deleted	4734	User '$Data/Context/Params/Param[4]$' deleted the group '$Data/Context/Params/Param[1]$' from server  '$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/DNSName$'

The Alert Description has been set up in such a manner that an Alert is raised with a clear message like this example:

All rules/monitors (I come to that discussion further up in this posting) are disabled by default and targeted at Windows Server 2008 Computer.

Of course it could be targeted at SQL 200x Computers. This is just a matter of choice. Another approach could be creating a whole new Class and target it at that new Class. As you see, many possibilities are there and it is just a matter of choice.

For the rule/monitor the Rule target/Parent Monitor is Security (of course). With an override the rules/monitors are enabled and targeted at a single server which is the server hosting the ACS Database which is also the SQL Server Reporting Services (SSRS aka SRS) for the ACS Reports.

Discussion: Do I Rule or Monitor?
Knowing what Events to target and what the Alert Description is going to look like isn’t enough. Now the choice has to be made: do I use a Monitor or a Rule?

Monitor:
When a monitor comes into play there are some issues to reckon with. Suppose two new groups are created. Only an Alert for the first new group created will be raised. Not for the second one since the monitor is in a critical health state.

Also when a monitor is being used, it needs a reset. There isn’t another event which can be used to reset the monitor back to a healthy state. So a timer reset could be used. But when no one acts upon the Alert there is a change this Alerts goes away unnoticed. So a timer reset won’t do.

The only viable choice could be a manual reset of the monitor. When that is being used, the Alert Description needs some additional information like:

Still, technique here won’t suffice. Also some organizational processes need to be in place AND functional. So when such an Alert comes in a small chains of actions takes place, like checking out the SQL Server and getting to know why the security has been changed. Perhaps it had a valid reason and nothing bad is at order.

Rule:
When a Rule comes into play it has the advantage that even when the Rule has triggered an Alert when a new group has been created (for instance), it will do so again when a second group has been created. So one gets an Alert per created Group. And a rule doesn’t need a reset either so it is less labor extensive.

However, when closing that Alert it is gone from the Console so it easier to have it unnoticed. In order to get it noticed, a Notification Model is needed which send out the Alerts as (for instance) a mail message.

#3: Creating a Notification Model
The easiest way to achieve this is to have the Alerts raised in the Console, right click on every single Alert and create a subscription for it.

Now all is in place and you are ready to go. Now you have ACS Reports secured so only a certain group of people can run them AND to have these reports scheduled as well.

xSNMP MP Suite Beta has been released!

Krish Bash and his team of peers have worked very hard on the xSNMP MP Suite. This suite is targeted at many SNMP enabled devices. Besides the generic SNMP enabled devices it also supports:

• APC
• Brocade
• Check Point
• Cisco
• Data Domain
• HP ProCurve
• HP Proliant

Yesterday Kris and his team have released the public beta, version 1.0.8. Taken directly from Kris blog:

Want to know more? Go check it out here.

What is Opalis?

As stated in this blog posting of mine, Microsoft acquired Opalis. But what is Opalis and what does it? Good questions they are. Go check out these videos on TechNet Edge and you’ll see.

MP Authoring Survey

Microsoft wants to know what YOU think about MP authoring and how you go about it, what tools you use and so on.

Please let them know by filling out this survey. It takes 10 minutes max of your time. And yes, your input will certainly be used.

Catch-22: Securing ACS Reports AND scheduling them. Part IV: Setting the subscriptions on the ACS Reports

--------------------------------------------------------------------------------- 
Postings in the same series:
Part   I: How Catch-22 was born…
Part  II: What do we need?
Part III: Setting Security
Part  V: Auditing Security
---------------------------------------------------------------------------------

This posting is a continuation of the previous posting in this series, where the security was set on the SQL Server hosting the ACS Database which is also the SQL Server Reporting Services (SSRS aka SRS) for the ACS Reports.

With the security model in place the subscriptions can be set on the ACS Reports. These tasks must be completed:

1. Creating a secure file share where the scheduled reports can be uploaded to.
2. Changing the security settings on the DataSource used by the ACS Reports so subscriptions can be created.
3. Setting the subscriptions on the ACS Reports.
4. Testing the subscriptions set on the ACS Reports.

#1: Creating a secure file share
I won’t go in detail about creating a secure file share since that is basic knowledge & experience. Just be sure this share can be accessed by the Auditors (local group ACS Auditors) and the service account used by the backup software in order to perform its daily/weekly duties. Also enable some auditing on that share in order to keep a watchful eye on it.

But even that can be circumvented. However, there comes a certain point that only hiring loads of north Korean soldiers will lock everything down. The question is: ‘How Far Do You Want To Go?’. Not too far I hope…

#2: Changing the security settings on the data source of the ACS Reports

1. Create a local account. Give this account a logical name like Planned_Reports_ACS
   
   
2. Add this account to the local group ACS Auditors
   
   
3. Open  Report Manager by opening this address in IE: http://localhost/Reports.
   Be sure to start IE with elevated permissions otherwise you bump into this issue.
   
   
4. Click on Audit Reports > Show Details. Click on DB Audit DataSource:
   
   
   
5. Select the option Credentials stored securely in the report server. Use the account and password created in Step 1 (Planned_Reports_ACS) and select Use as Windows credentials when connection to the data source. Click Apply.
   
   
6. Close IE.

#3: Setting the subscriptions on the ACS Reports

1. Open  Report Manager by opening this address in IE: http://localhost/Reports.
   Be sure to start IE with elevated permissions otherwise you bump into this issue.
   
   
2. Click on Audit Reports and select the first report on top (Access Violation – Account Locked). The report will be rendered and presented. This is good since it shows the credentials are in place and functional.
   
   
3. Go to the fourth Tab, Subscriptions > New Subscriptions. A form will be shown.
   
   
   
4. Fill the form out like this:
   - Delivered by: Windows File Share (email will only be available when SSRS has been configured to use it, like posted here, Step 5)
   - File Name: Already provisioned. Select the option Add a file extension when the file is created.
   - Path: unc path referring to the file share created at #1
   - Render Format: PDF will do
   - User Name and Password: Account and Password created in #2
   - Overwrite options: Increment file names as newer versions are added
    
   
5. Under the section Subscription Processing Options hit the button Select Schedule.
   - Select Day > Sunday > 06:00 AM (for instance). DO NOT SELECT 02:00 AM SINCE THAT IS THE DEFAULT MAINTENANCE TIME!
   
   
   Select a start date and hit OK.
   
   
   
6. Now you are back in the screen/form as described in Step 4. Under the header Report Parameter Values needs some special attention. For the Start Date and End Date deselect the option Use Default first and than select NULL.
      
   
   This needs some explanation. In SQL NULL is NOT zero. NULL means unknown data. SQL 2008 Server Books Online for SSRS writes this about using NULL in publishing reports (found here):
   
   
   What happens is that all available data will be used in the scheduled ACS Report. So when the default retention setting is being used in ACS (14 days) and this report runs every 12 days, every report will have an overlap of 2 days. Of course you could set the days in Step 5 at 13 or even 14 but I rather have some overlap then a (slight) possibility missing out on some data.
   
   
7. Click OK.

#4: Testing the subscriptions set on the ACS Reports

How do you know whether the subscription works? By testing it! Duh! So go back to Step 5 of #3 and change the setting in such a manner that the Report is scheduled to be rendered within a few minutes. Check out the file share in order to see the report is created AND uploaded. Also open it in a PDF viewer to see whether it contains valid AND readable data.

Also SSRS itself for the scheduled report will show information in the tab Subscription for the Scheduled Report.

When all is in place and functional the other ACS Reports can be scheduled as well. Be aware that some ACS Reports need some additional parameters in order to run. So some of those reports can not be scheduled or need some more attention before being scheduled.

KB974144, Cumulative Update 1 for SCOM R2: What options do update what components?

Out of the field I do get many questions like:

I want to update the SCOM R2 Console on my workstation. What option do I select in order to achieve that?

Therefore I have written this article about what the selections in the update screen do update what component.

• Run Server Update
  Applies to any SCOM R2 Management Server (RMS, MS), UI, Web Console
  
  
• Run Agent Update
  Applies to SCOM R2 Agent which are typically manually installed. Does NOT apply to Management Servers.
  
  
• Run Gateway Update
  Applies to SCOM Gateway Server Role
  
  
• Run ACS Server update
  Applies to ACS Collector Server Role.
  

Cumulative Update 1 for System Center Operations Manager 2007 R2

Hot hot! Only just released, the Cumulative Update 1 for System Center Operations Manager 2007 R2. It resolves these issues (taken directly from the website):

This update is to be applied on systems which meet one or more of these conditions:

1. System is a Root Management Server
2. System is a Management Server
3. System is a Gateway
4. System runs a SCOM R2 Agent
5. System is a Web Console Server
6. System runs a SCOM Console
7. System is ACS Collection Server

The update must be installed in this order:

1. Root Management Server
2. Manual update of the SCOM Database
3. Manual import of the Management Pack library
4. Secondary SCOM Management Servers
5. Gateway Servers
6. Deploy the Agent Update to the Agents which have been pushed from the Console (not manually installed!)
7. Systems running the SCOM Console
8. Systems running the SCOM Web Console
9. Systems running the ACS Collector role
10. Update must be applied on systems which have the SCOM R2 Agent manually installed.

Want to know more? Check these sites out:

1. Release Notes AND Installation Steps, KB974144.
2. Download location.

Advice:
As with any other update READ the instructions and understand them fully before proceeding. Also make sure to have a valid backup of the OpsMgr database AND the RMS available. This update has been thoroughly tested in the field, but is better to be safe then sorry. :)

Kevin Holman has written a posting about his installation experiences. Check it out here.

Catch-22: Securing ACS Reports AND scheduling them. Part III: Setting Security

--------------------------------------------------------------------------------- 
Postings in the same series:
Part   I: How Catch-22 was born…
Part  II: What do we need?
Part IV: Setting the subscriptions on the ACS Reports
Part  V: Auditing Security
---------------------------------------------------------------------------------

In this posting I will describe how to setup security. Also some groups and accounts need to be created. These groups and accounts will be used when adjusting the security settings on the SQL Server hosting the ACS Database which is also the SQL Server Reporting Services (SSRS aka SRS) for the ACS Reports.

Before continuing first a small Visio drawing about how the ACS components (Forwarders, Collector, Database, SSRS instance) are setup and relate to the SCOM managed environment:

Some explanation is at order here. As you can see most ACS components are separated from the SCOM environment. The ACS components are ‘highlighted’ by green circles. The circle around the monitored servers (SCOM Managed Servers) is not totally ‘closed’ since these servers report to the regular SCOM environment as well. The red arrows visualize the ACS related traffic.

Some SCOM Managed Servers have the ACS Forwarder enabled. These ACS Forwarders send all the Security Events to the ACS Collector. This is a separate SCOM Management Server which is purely dedicated to the ACS Collector role. The ACS Collector sends the collected events – after applying some basic filtering – to a dedicated SQL Server which only hosts the ACS database which is also the SQL Server Reporting Services (SSRS aka SRS) for the ACS Reports. On this server the ACS Reports will be rendered.

This server needs to be secured in such a manner that only a certain group of people (the auditors) can render the ACS Reports and that not a single domain administrator can do so as well. Also will the ACS Reports be configured in such a way that these can be scheduled as well.

Lets start!

Some comments:
Steps 1 to 3 are very well documented in SCOM Unleashed. Since I am not a copy cat I can only describe the outlines here. All steps described must be done on the SQL Server hosting the ACS Database which is also the SSRS Server for the ACS Reports.

1. Create a local group. Be sure to give this Group a logical name, like Local Auditors.
   
   
2. Grant this group access within SQL Server. Create for this purpose a new login referring to this group and select as default database the one used for ACS.
   
   
3. Grant this login db_datareader permissions on the ACS database
   
   
4. Change the group membership of the local Administrators group in such a way that the Domain Admins aren’t a member of that server any more.
   
   Make sure not to lock your self out!
   
   You can add the local group you created at Step 1 to the local Administrators group. However, this way the Auditors have total control of the ACS server which is a ‘bit’ too much. It is better to have them access the Report Server Web Console remotely through IE from another system. This way the server stays secure.
   
   Also, add a special account here. This account and password are only known to a small group of people (max. 3). This account is used for publishing reports and admin access to that server.
   
   
5. Open  Report Manager by opening this address in IE: http://localhost/Reports.
   
   Be sure to start IE with elevated permissions otherwise you bump into this issue.
   
   
6. Alter the Site Settings of SSRS by going to Site Settings > Security > New Role Assignment. Add the group created in Step 1. Grant them the role of System User. Save the new configuration.
   
   
7. Go back to the start page of Report Manager and alter the Object Settings by going to Properties > New Role Assignment. Add the group created in Step 1. Grant this Group the role of Browser. Save the new configuration.

With these steps the basic security has been altered in such a way that only a small group of people can access this server. Also has the access to the ACS Database been restricted. Of course, need the other groups with Admin access within SQL to be checked out as well. But that goes without saying… :)

And remember, the more difficult a security model is built the more gaps there are….

Next posting will be about Step 2: Setting the subscriptions on the ACS Reports.

New KB article: push installation of the SCOM Agent to a server running Terminal Services fails

Microsoft has released a KB article which addresses this issue: the push installation of SCOM Agent to a server running Terminal Services times out. You receive an error message like this:

The MOM Server could not execute WMI Query "Select * from Win32_Environment where NAME='PROCESSOR_ARCHITECTURE'" on computer "computername".
Operation: Agent Install
Error Code: 80004005
Error Description: Unspecified error

The cause and workaround are described in this KB article: KB978360.

New MP released: Microsoft Forefront Threat Management Gateway (TMG) 2010

Microsoft has released a new MP for monitoring TMG 2010.

Taken directly from the website: ‘This MP monitors Forefront TMG and includes monitors and rules to track the deployed topology & features, performance, availability, and reliability of Forefront TMG components. With detailed alert information, you can quickly identify and troubleshoot Forefront TMG issues, minimizing time-to-resolution when problems occur. You can collect and analyze performance trends and metrics, and obtain performance information that allows you to manage bottlenecks, identify capacity requirements, and proactively manage your Forefront TMG deployment to resolve issues before problems occur.’

To be found here.

New MP released: Windows Server 2008 R2 Routing and Remote Access Service (RRAS)

Microsoft has released a new MP for monitoring RRAS based on Windows Server 2008 R2.

Taken directly from the website: ‘The Routing and Remote Access Service (RRAS) Management Pack provides monitoring for RAS, VPN and Routing scenarios. This management pack includes monitors and event rules for the RemoteAccess service and the RasMan service. It monitors the service application event log for these services. The events collected from each service indicate critical issues with Remote Access operations during deployment and day to day management.’

To be found here.

Management Pack Authoring Guide v2

Brian Wren is a technical writer focusing on management pack authoring. His initial focus is a new version of the Management Pack Authoring Guide which will provide background concepts, processes, and specific walkthrough examples on creating management packs for OpsMgr.

The first section – about the Service Model – of the new Authoring Guide went live Friday January the 8th. Significant progress on the Composition section has been made and will be the next to be published.

And again, your input is much appreciated, whether it is positive, negative or corrections. Also when something isn’t totally clear, please let Microsoft know. `Leave your comments on TechNet, the blog of Brian or mail to MOM Documentation Feedback.

Want to know more? Check this out.

Catch-22: Securing ACS Reports AND scheduling them. Part II: What do we need?

--------------------------------------------------------------------------------- 
Postings in the same series:
Part   I: How Catch-22 was born…
Part III: Setting Security
Part IV: Setting the subscriptions on the ACS Reports
Part  V: Auditing Security
---------------------------------------------------------------------------------

In this posting I will describe the needed setup in order to get ACS Reports secured so only a certain group of people can run them AND to have these reports scheduled as well.

There is a caveat to reckon with:
The security settings on the SQL Server Reporting Services (SSRS aka SRS) instance for ACS can be circumvented. So auditing and alerting upon it is a requirement. 

Setting up secured AND scheduled ACS Reports consist out of these three major steps:

1. Setting security
2. Setting the subscriptions on the ACS Reports
3. Auditing security

First the security needs to be set on different objects. Also certain groups and accounts have to be created which will be used when setting the security. Secondly the reports have to be scheduled. However, when all that is in place, the security can be circumvented. So a third step is needed: auditing of the server hosting the SQL Reporting Server Services instance has to be configured. But only to have a security event logged when the security settings of the server have been changed (like adding/deleting a user from a group) won’t suffice. An Alert is needed as well. So a MP needs to be built as well which will raise an Alert. But now we have an Alert showing up in the Console which can be closed pretty fast. So a Notification is at order.

As you can see, there is much more to it then meets the eye…

Every major step consist out of several other tasks:

1 - Setting Security:
A – Creating the needed accounts and groups
B - Securing the SQL instance
C - Securing the server hosting the SQL Server Reporting Service instance
D - Securing the SQL Server Reporting Service instance > Site Settings
E - Securing the SQL Server Reporting Service instance > Object Settings

2 – Setting the subscriptions on the ACS Reports:
A – Creating a file share and setting the security
B – Setting the subscriptions on the ACS Reports
C – Testing the subscriptions on one or more ACS Reports

3 – Auditing Security:
A – Enabling and configuring the Audit Policy on the SSRS server
B – Testing the Audit Policy
C – Creating a MP which Alerts when the security settings on the SSRS Server have been changed
D – Creating a Notification Model which sends out an e-mail/sms message when an Alert comes in from this MP

It goes too far to write down every needed step in detail. Also – as stated before – some steps are described in detail in the book SCOM Unleashed. So those steps I will certainly not describe in detail. Just buy the book! :)

The next posting in this series will be about Step 1: Setting Security.

Catch-22: Securing ACS Reports AND scheduling them. Part I: How Catch-22 was born…

--------------------------------------------------------------------------------- 
Postings in the same series:
Part  II: What do we need? 
Part III: Setting Security
Part IV: Setting the subscriptions on the ACS Reports
Part  V: Auditing Security
---------------------------------------------------------------------------------

In the field I bumped into a situation which seemed like Catch-22: Audit Collection Services (ACS) had to be implemented. On itself no problem.

One of the requirements started the move towards Catch-22: the database had to keep its data for 60+ days. From the community I got the advise not to keep the data that long in the database since ACS Reports – maintaining older data – would take ages to be rendered. Also would the size of the ACS database grow to an enormous size. And huge databases cost a lot of money and effort to maintain. As stated in this blog posting of Kevin Holman:

Again, no problem. With an archiving solution this issue could be addressed: the ACS database would run with the default grooming settings (14 days) and older data would be archived and accessible for reports. But in this case budget didn’t allow for it.

Hmm. How to solve this? So I started to think and think and finally...

I thought to have found the solution: I would keep the default grooming settings on 14 days on the ACS Database AND would schedule all the available preset ACS Reports to run on a weekly basis and have the results uploaded to a secured file share!

This way I had both of two worlds: a well performing ACS environment with an acceptable ACS database size AND much of the most important collected data would be available in the format of the uploaded reports. Of course, no new queries could be run for data older than 14 days since it was groomed out of the ACS database, but under these circumstances it was the best to achieve.

So far so good. But another requirement introduced Catch-22 full blown: the ACS Reports had to be accessible by the auditors only.

Why? In order for SQL Server Reporting Services (SSRS aka SRS) being able to run scheduled reports, it needs to have the related credentials stored locally on the SSRS server. Otherwise this message will be shown:

But when these credentials are stored locally, every one with local administrator permissions on that server, won’t be challenged for his/her credentials when running ACS Reports, thus every one who is local administrator can run the ACS Reports whether or not they are an auditor!

Look here at SQL Server Central for more on that topic.

And the security where only ACS Auditors are allowed to run the ACS Reports is true requirement. No shortcuts there.

With the help of a much appreciated SQL guru/colleague (thanks so much Mark D. !) the Catch-22 got solved. Not easily but it can be done. So this series will be about how to go about it when ACS has these requirements:

1. ACS Reports much be secured so only a certain group of people can run these reports  and certainly not the Domain Admins.
2. Data must be kept no too long in the ACS database since it introduces issues: bad performance and a huge database.
3. ACS Reports must be scheduled in order to keep some data older than the grooming settings set on the ACS Database.
4. An archiving solution can not be used.

Remark:
In this series I will outline certain needed steps. Reason why I do this is because these steps are described in detail in the Big Orange Book: SCOM Unleashed. Since I am not a copy cat I will refrain my self from describing those details. All I can say here is that when you are really into SCOM/OpsMgr, this book is worth every euro-/dollar cent since it contains very valuable information for any one who runs a SCOM environment.

DNS MP: Where are my reports? Part III: DNS Performance Report

--------------------------------------------------------------------------------- 
Postings in the same series:
Part  I: Found them but they turn up empty…
Part II: Lets build a report…
---------------------------------------------------------------------------------

As stated in the second posting in this series, this article will be about creating a DNS Performance Report. For this go to the Reporting Pane in the OpsMgr Console > Microsoft Generic Report Library and open the Performance Report.

This blog posting of mine tells you how to go about it. In Step 4 of that posting select as a Group one DNS server. At Step 6, go to the first tab ‘Search By Name’ and select in the dropdown box ‘Management Pack Name’ the related MP. In this example I use Microsoft Windows DNS 2008 Server.

Hit the search button and all available counters will be shown:

When you don’t know what all these counters exactly tell you, start PerfMon on a DNS Server (type it in the start menu and run it). Select the DNS Counter, select the option Show Description and select the related counter. In the Description box the counter will be explained.

This way you can select the counters you deem important. Per counter insert a new Chart with a new Series. Select per Chart/Series a meaningful counter. Give every chart a meaningful name. Now the Settings screen will look a bit like this: (Still this blog posting is being used as a basis)

Click OK.

Select a From date and run the report. Check it out whether it is OK and meet up to the expectations. Adjust it when needed and test run it again.

When the report is OK, publish this report as stated in this blog posting of mine (steps 1, 4 to 7). Now it looks like this:

Experiment with it and be surprised. There is much more to be found in OpsMgr than meets the eye.