I’ve been doing some work recently for a client who has an AppSense infrastructure which seems to be a little unloved. Well, that’s probably not a fair appraisal, what would be more accurate is to state that they’ve never been shown or told how to keep their infrastructure in tip-top condition. Around this subject, there are a few tasks that, at the time of writing, have to be done manually in the AppSense Management Suite. We will use this article to document these manual administration tasks so that you don’t let your own Management Suite installations get into the same metaphorically cobweb-ridden state that this one is in!
Upgrades
This might seem blindingly obvious to some, but getting your upgrades done in a timely fashion is the main manual administrative task that can help you out. I know most of you will probably be shaking your heads, but I’ve worked at more than a few clients where they have been running very out-of-date software and wondering why they’re suffering from so many performance issues and other bugs.
However, that’s not to say you should upgrade your entire suite as soon as a new version is available. Life on the bleeding edge is hard! Managing the change and upgrade process should be something that it is integral to your IT strategy – and if it isn’t, then it would bring you a wide-ranging scope of benefits if you made it so. Proper planning, testing and backout processes will prove invaluable to ensure that you can stay relatively up-to-date without causing unnecessary downtime to your users.
I’m not about to go into an exhaustive discussion about managing change and mitigating risk in this post, but if you can contrive to stay not more than two or three releases behind the current latest version (and I’m talking minor, not major, versions here), you should do a good job of keeping your software healthy. It also pays to have a good read of the bug fixes in each new version to check that there isn’t a fix being released for a problem you’re experiencing.
Clear historic events from the AppSense Management Console
Particularly in small installations, I see this a lot. Since the day it was installed, no-one has bothered to Acknowledge, Resolve or Delete any of the Alerts from the Management Console. It probably doesn’t take much working out to realise that allowing masses of events to accumulate in this fashion puts an unnecessary strain on the database and the Management Center. At present version (8.3.49.0), there isn’t any functionality to remove alerts after a certain period of time, and the Management Center will capture the defined alerts indefinitely until they are removed, possibly slowing the console down significantly in the process.
It makes sense to spend a few minutes on a regular basis removing Alerts that are no longer relevant. It’s up to you how you manage this – whether it is deleting events over a specific age, or deleting the ones that are marked as Resolved, or any way you want to really. This obviously depends on whether you need to use the Alerts section of the console as a reference for any support issues. The main one I tend to find myself referencing is the Application Execution Denied alert which lets you know when Application Manager blocks something from running, which can be very handy in proactively identifying false positives. But once you have defined a process for your support teams to manage the Alerts, then removing the unneeded ones will allow your system to run much more optimally.
If you use the Actions function in Alert Rules to auto-forward events via SMTP or SNMP to distribution lists or another management tool, then you don’t need to keep these alerts at all – they’ve already been handed off into another system. If this is how you manage your alerts, you can probably remove all of them on a daily or weekly basis – although I would recommend you check the retention settings at the other end before implementing.
If you are getting inundated with irrelevant Alerts, then it would also be prudent to either disable the problematic alert globally (in the Alerts tab) or specifically in the Enterprise Auditing section on a Deployment Group level. This will cut down on the amount of alert maintenance required.
 |
| A bulk deletion of historic Alerts in the AppSense Management Console |
Remove inactive devices from the console
In much the same vein, inactive devices aren’t automatically removed from the Deployment Groups section of the Management Center. And again, this is a process that will need to be clearly defined, so you don’t (for instance) remove devices such as laptops which have genuine reasons not to check in with the Management Center for long periods of time. As a good rule of thumb, servers that don’t check in for long periods should be removed, unless they are the accounts for templates, images or similar.
If you have a system that is still up but simply doesn’t need to be managed by AppSense any more, then removing the configurations and agents by uninstallation will remove it gracefully from the console (you can do this manually or by moving the system to a Deployment Group with nothing assigned). If the system no longer exists or is no longer contactable, then using the Delete and Unregister context-menu commands from the Deployment Group will remove it from the console, and henceforth the database. Keeping the devices list up-to-date, as with the Alerts above, helps the database achieve optimal performance.
 |
| List of devices showing a server that has not checked in for a long period of time |
Remove unneeded packages from the AppSense Management Console
Every configuration change you save is stored in the Management Center for rollback purposes. This is a great idea – if you inadvertently make a configuration change that causes an issue, then you can simply roll the Deployment Group back to a previous configuration version and all will be well. But once you’ve saved hundreds of changes to your configurations, you will have hundreds of previous versions stored in the Management Center. Again, storing all of these configurations can slow down the performance of your server and your consoles.
The same is true of Agents – they are also cached for archive purposes each time that a new one is loaded into the database (usually when an upgrade is done or a patch applied). In the same vein, you should remove old versions of agents when it is proven that there are no issues with the newer ones.
At risk of repeating myself, you again will need to define an appropriate retention period and/or number for the configurations and agents you wish to keep. However, I can state with certainty that I don’t do an awful lot of configuration rollbacks – and I have seen clients who have literally been maintaining hundreds of configuration versions, in some cases going all the way back to the very first one they saved, years in the past. I’d say unless you have made a major settings change to an application that isn’t used very much, then maintaining configurations older than a few weeks or months is probably not necessary. Don’t forget you can save configurations to disk rather than storing them all in the Management Center, so if you’re paranoid, you can maintain backups without affecting your database performance.
Agents shouldn’t need to be maintained except perhaps the previous version, just in case a serious bug rears its head a few months after an agent upgrade. You’d also be surprised at the amount of enterprises I see where they are keeping copies of the x86 agents even though all of their managed endpoints are x64. If you’re purely x64 and have no plans to reintroduce x86 kit, then you can halve your number of agents almost immediately.
 |
| Unneeded Environment Manager configurations being removed |
Gather and review OS performance data
Finally, you can put a process into place to monitor the performance of your AppSense database and web servers, using the tools that you would use for other servers in your enterprise. Regular reviews of this data will provide an insight into any potential issues that may cause detrimental performance. You can use any amount of tools, native or third-party, to achieve this sort of performance monitoring. You can also use the AppSense-provided Management Packs for System Center Operations Manager to ensure that your systems are running as optimally as possible. However, as the SCOM MPs are technically an automated function, they’re a bit out of scope for this post and will be something I cover in detail in another article in the very near future.
Quick update – as pointed out on Twitter by Mark Schill, you could put together an SQL statement to do the events pruning automatically for you. That’s definitely something we’ll visit in a future post, it sounds really interesting, but for the purposes of this article we’ll stick to what you need to do to administer these things without possibly invalidating your AppSense support 🙂
Share
