locked
Windows User Object / Entity RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello All,

    I have been researching writing a management pack for Ops Manager 2007.  It seems that the model-based design used in OpsMgr excludes any knowledge of a particular user.  From what I can tell, the default libraries easily support discovery of applications that are specific to a particular windows client (which, to my understanding, represents a machine with windows OS installed).  I was curious if it’s possible to discover applications on an individual user basis.  For instance:

    Right now in my tests / investigation, I have written a dummy app that writes a key to the registry when it is active.  I have created a MP that uses a registry probe to discover this application (I used the Windows.LocalApplication entity.)  This works great, and I can now monitor this application on every machine.  What I would like to do however, is monitor it for every user.  So in the case that I have multiple users on the same machine, I can monitor the health of each instance of the application.

    Is this achievable through some other entity?  I am not sure on the difference between Windows.LocalApplication and Windows.UserApplication; perhaps it is UserApplication that I need.

    If it is not already built in, is it possible to extend some other entity and implement this?

    Another problem I ran into is that the registry probe is limited to the HKLM hive.  Is this because I used Windows.LocalApplication as the inherited object?  The application that I want to write a MP for only writes information to HKCU.  I figured if OpsMgr would discover individual users then it would be possible to check HKCU.

    Are some of my assumptions wrong? I am using OpsMgr 2007 R2 and agentless monitoring.

    Thanks for your time,

    Ryan

    • Edited by Ryan Yandle Wednesday, June 3, 2009 6:16 PM
    Wednesday, June 3, 2009 1:02 AM

Answers

  • Question
    Sign in to vote
    1
    Sign in to vote
    In short, if the key you are looking for involves HKCU instead of HKLM, the SCOM agent cannot easily probe that part of the registry.  The reason is that the agent (healthservice) runs outside of a user context, so there really is no user hive.  Further, the way windows works, there is not really a possibility of an app that runs for multiple users at the same time (HKCU changes with each login and is user context specific).  A process that runs without a winstation (like healthservice) cannot "see" the current user registry because it is transient and private to each user.

    To manage this kind of application, you need to monitor the application - and your discovery needs to find it.  Traditional discoveries determine if an app is installed, but make no distinction as to whether the app is running, let alone which users are running it on a given host context.  The discovery would need application metadata support to help the discovery script in the MP discover the user context.  This would raise perf issues (why does the user matter in a health model some may ask, and it would be a rousing debate).

    Ops manager assumptions is that the app is either a server app (one instance, HKLM focused if registry discovery used) or a single user client app - where the discovery determines that the app is installed.  Installed for a user could be of interest - but since the best match comes when the app team writes the MP, they make sure app install supports discovery.

    If you are outside of that barrier (e.g. you got the app, have no control over how it was writen, and are pretty sure the provider never heard of or planned for monitoring, then you have to adjust - look for running processes, rather than registry keys.  This makes for tricky monitoring, since most user apps are  not of interest to centralized ops (imagine the help desk call that starts "my outlook is frozen again, what should I do" - answer "do what we all do madam, suck it up and wait."

    It isn't like the ops team will want to get an alert at 4:00 am if someone's outlook seems frozen for 5 minutes.  User workstation monitoring is special like this - by the time you notice a problem, the user already rebooted.  Not very alert worthy.  Reporting and ACS is better tuned for this kind of "crash and frozen app" for reporting use cases.
    Microsoft Corporation
    • Proposed as answer by Marco Shaw Wednesday, June 3, 2009 7:12 PM
    • Marked as answer by Ryan Yandle Wednesday, June 3, 2009 7:40 PM
    Wednesday, June 3, 2009 4:52 AM