Sharing of thoughts and information is what blogging is all about. This way we can learn from each other. Post A Comment!These postings are provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.
Anthony Bartolo Twitter | LinkedIn
Pierre Roman Twitter | LinkedIn
I had the opportunity to attend the Microsoft Management Summit this past week in San Diego, CA and it was a GREAT event!! I was able to sit in on a number of sessions and the presentations and content was great but so too were the questions at the end of each of the presentations. I find it fascinating to hear how others are using a product that I work with.
The one thing about the questions that really caught my attention was the number of people that were struggling to grasp some of the basic functionality of MOM. The same questions keep coming up, be it in a session at MMS or on the newsgroups so my intent with this blog is to try to provide some context around one of these reoccurring questions which has to do with the use of parameters in the creation of rules.
There seems to be a big knowledge gap around parameters so my goal is for this blog post to shed some light on what they are, how to use them, and how to identify what information is going to be collected by each parameter.
Let’s start with a look at the body of a typical event, in this case a security event that gets logged to the Security Event log when auditing of Object Access is enabled and the auditing of modifications to an Organizational Unit (OU) have been configured within Active Directory. The event we will focus on is event id 566 which occurs when some type of directory service access occurs such as the permissions of an OU are changed. The details of this event pulled right from the event log are shown below.
Event Type: Success Audit
Event Source: Security
Event Category: Directory Service Access
Event ID: 566
Time: 5:44:29 PM
Object Server: DS
Operation Type: Object Access
Object Type: organizationalUnit
Object Name: OU=Marketing,DC=DEMOMOM,DC=com (Resolution requires ResolveGUID)
Handle ID: -
Primary User Name: DEMODC2$
Primary Domain: DEMOMOM
Primary Logon ID: (0x0,0x3E7)
Client User Name: administrator
Client Domain: DEMOMOM
Client Logon ID: (0x0,0x16E743)
Looking at the details of this event, you can see that any collection event rule that you create can collect up to 14 parameters. But how do I know this just by looking at the event as it appears in the event viewer. The answer to that lies in the information found in the Description field, bolded in the event description above. Each line in the description section of your event is viewed as a parameter by MOM when collecting event information. Even though the Description field as a whole is captured in the event information within MOM and persisted into the OnePoint database, this field has a character limit of 255 characters in the database. So for better granularity and reporting and to ensure that all of the description data is collected, each line or entry in the Description field is stored as a parameter and assigned a unique parameter number.
So in this example above, the following would be true.
Parameter 1: DS
Parameter 2: Object Access
Parameter 3: organizationalUnit
Parameter 4: OU=Marketing,DC=DEMOMOM,DC=com
Parameter 5: -
Parameter 6: DEMODC2$
Parameter 7: DEMOMOM
Parameter 8: (0x0,0x3E7)
Parameter 9: administrator
Parameter 10: DEMOMOM
Parameter 11: (0x0,0x16E743)
Parameter 12: WRITE_DAC
Parameter 13: WRITE_DAC
Parameter 14: organizationalUnit
Knowing this, now you can use these parameters in the creation of your event rules by defining them in the Advanced Criteria. The beauty of this is that it offers you the ability to, at a very granular level, filter the application of a rule so that it only matches the events that you are interested in. This is extremely important when we are creating rules to monitor object access events. Without the use of advanced criteria, your MOM agent, management server and database could become overwhelmed very quickly due to the sheer volume of events generated with this event id.
So now that you know what they are, how to use them and how to identify what information is going to be collected by each parameter let’s look at the event above and explore a couple other critical concepts.
First, let’s start by explaining what I mean by ‘resolution requires ResolveGUID’ next to Object Name: OU=Marketing,DC=DEMOMOM,DC=com in the Event Description section of the Event detail above. ResolveGUID is a REG_DWORD value that must be created in the HKLM\Software\Mission Critical Software\OnePoint key in the registry and assigned a data value of 1 in order for the ‘unfriendly’ GUID that represents the Active Directory object to be resolved to the ‘friendly’ name of the OU in AD. You can read more about this in my blog at http://spaces.msn.com/rorymccaw.
Now onto the lesser known information that I just learned (and haven’t myself had the opportunity to test yet) of at MMS through discussions with members of the product group. (Thanks Doug and Ahnanda!) When using parameter information in your rules the order of the parameters is critical and you should place the criteria that will be most unique to the event and that you wish to have processed first at the top of the your list of criteria.
Also, pay particular attention to the events that require the ResolveGUID functionality after you initially implement them as it isn’t uncommon to find that not all of the events generate alerts so testing is key. More on testing in a minute. Should you find that the events don���t always get collected go back into your rule and add another advanced criteria called Message DLL and set this to equal * (wildcard) and move this to the top of your parameter list, above even your most unique criteria and I am told by the product group that this will solve the problem. (Again, I am blogging this on the plane ride back from MMS so I haven’t been able to confirm this myself.)
Now back to testing. Testing of all new rules, rule changes and new management packs being imported is critical prior to a production installation and a tool that will save you hundreds of hours of time and make you much more efficient in this process is Silect Software’s MP Studio line of products, particularly the Professional or Enterprise Editions that offers the profiling functionality feature. With MP Studio Professional or Enterprise Edition you are able to import your rules into Silect’s database, not your production OnePoint database and then direct the rule to run against a specific production server, in this case one of your production domain controllers. Then sit back and watch what’s collected. This one feature, never mind the other great features will offer you’re an immediate return on investment (ROI) in any large MOM 2005 deployment. With MP Studio you are now able to see what the results of your newly configured rule will be without having to deploy it into your production MOM environment. Talk about helping to mitigate your risk and increase your confidence level as the MOM administrator.
If this information was helpful to you and you have other areas or topics where you would like me to share more information, please feel free to contact me at firstname.lastname@example.org. I would also encourage you to look to the MOM 2005 Bootcamp that we have developed to provide detailed, advanced technical knowledge, not unlike the content covered here on MOM 2005 that can help you learn how to improve your implementation of MOM in your environment or your customer’s environment. For more information on the MOM 2005 Bootcamp look to www.infrontconsulting.com/events.htm. We have deliveries scheduled throughout North America but also work with customers to provide customized on-site training as well. It’s four days of MOM training that you just can’t find anywhere else!!
There seems to be a big knowledge gap around parameters so my goal is for this blog post to shed some...
Great article about MOM parameters on the Canadian IT Professionals blog
PingBack from http://alpesh.nakars.com/blog/?p=59