I still look at lots of AppSense implementations and see the Enterprise Auditing for the Deployment Groups set to the defaults. The defaults are useful - if you'd like to know whether you're using an old configuration or there isn't a configuration applied. All joking aside, in the default configuration you're not going to see much useful. I've lost track of the amount of AppSense admins who tell me "well there wasn't anything in the logs" - that's because you haven't set anything up!
AppSense DesktopNow can log centralized or locally. If you're using the Management Center, it would make more sense to log centrally. If you're not, then it makes more sense to log locally and then send these events up to a central monitoring system (SCOM,for instance). You configure local logging in the configuration itself - Tools | Auditing for EM, and Home | Auditing for AM and PM.
In this post, we're just concerned with setting your auditing to a helpful level. We will cover the local logging and log shipping in a separate post (hopefully very soon, because I need to do this for someone). Whether you centralize through Management Center or a third-party tool is entirely dictated by your own preferences, budget and choices.
In the Management Center, you can see both Events and Alerts on a Deployment Group basis. It's important to understand the relationship between Events and Alerts.
- Events are generated by the settings under the Enterprise Auditing tab on the Deployment Group
- The Events generated then trigger Alerts based on the Alert Rules under Alerts | Alert Rules
The upshot of this is, if you don't configure the Enterprise Auditing to audit the required Events, the Alert Rules won't be triggered as the Events don't exist to trigger the enabled Alerts. A bit confusing? Yes. Effectively, a whole host of useful Alert Rules are on by default, but because the corresponding Enterprise Auditing isn't on by default, then you don't ever get the Alerts that are pre-configured. At least that's the way I've always managed to interpret it, please someone correct me if I am wrong.
Events or Alerts and Events?
In my environments, I generally disable all of the Alert Rules and simply use the Events tab under the Deployment Group to see "what's going on". The only real benefit Alerts give you, in my experience, is a consolidated view for multiple Deployment Groups. Alerts don't auto-resolve (even if the trigger Condition is rectified, rather annoyingly), so if you're using them, you will have to go in and Resolve or Delete them all on a regular basis. Compared to dedicated monitoring systems like SCOM, the Alerts in the Management Center are really quite rudimentary, which is why I just prefer to look through the Events for information that I need.
Deciding whether to use Alerts or just Events is entirely your choice. The Alerts section does allow you to configure SNMP or SMTP responses to Events, which can be handy, so you may want to consider this in your decision. You can also do very basic severity levels (Critical, Low and High being your available choices). If you do decide to simply use Events,I generally Disable the Alert Rules rather than Delete them, as you can then always re-enable them as required. Setting up an Alert Rule again isn't rocket science, but you have to look up the event id.
 |
| Disabling an Alert Rule |
What to audit
Again, this depends entirely on your environment, your needs, and your preferences. Some events have to be balanced against what value they provide and how much noise they will generate. What I've got listed here is just a basic baseline configuration for people who want to have something better than the default but aren't quite clear yet about their specific requirements. I'm sure everyone has their own events they like to audit!
You configure this on a per-Deployment Group basis, from the Settings | Enterprise Auditing tab.
Application Manager
9000 - Prohibited execution request (probably one of the most important ones)
9004 - Application limit denial
9005 - Time limit denial
9016 - The file's ownership could not be changed
9023 - Self-Elevation request
9099 - Application Manager is not licensed (again, important one!)
Environment Manager
9399 - Environment Manager is not licensed (important)
9406 - A user logon action failed to complete successfully
9408 - A user logoff action failed to complete successfully
9410 - A computer startup action failed to complete successfully
9421 - A user session reconnect action failed to complete successfully
9423 - A user session disconnect action failed to complete successfully
9425 - A user session locked action failed to complete successfully
9427 - A user session unlocked action failed to complete successfully
9429 - A process started action failed to complete successfully
9431 - A process stopped action failed to complete successfully
9433 - A network connected action failed to complete successfully
9435 - A network disconnected action failed to complete successfully
9652 - Personalization settings for a managed application failed to load
9653 - Personalization settings for a managed application failed to save
9660 - Personalization for a managed application failed
9661 - A timeout occurred whilst trying to communicate with the Personalization Server
Management Center
9702 - An agent or configuration was created or deleted
9703 - A user was created, modified or deleted
9740 - A security role was created, modified or deleted
Additionally, some people choose to monitor the various events for EM/PM/AM Agent restarted unexpectedly. I don't usually turn this on as there is generally service monitoring available, but should it not be, you might want to consider these events also.
Performance Manager
9199 - Performance Manager is not licensed (important)
If you're concerned about the effects of clamping and thresholds, you should configure additional events to audit here.
User Personalization Manager
9600 - Personalization Server failed to connect to the Personalization Database
This baseline set of events to audit should hopefully provide you with a better overview of what is going on in your AppSense DesktopNow environment. Over time, you can tune it to your specific requirements. As I mentioned before, you need to balance the value of alerts versus the amount of data that will be generated.
In a near-future post I will discuss how to log locally and archive the events to a central, third-party system.