November 28th, 2012 by Jeremy Sherwood, Cloud Strategist
A while back I wrote a blog about Agent vs. Agentless Monitoring. Looking back at what I wrote, I realized that we have made, and continue to make significant strides in this area with ScienceLogic’s EM7. IT Service Management delivered on the idea of minimizing impact while maximizing the value wrung out of data collected via a range of agent and agentless approaches. Now we can instrument IT Services in creative and useful ways. New Dynamic Applications using methods other than SNMP, such as XML, SSH, WMI, continue to broaden our collection capabilities. The latest of these is soon to be released in 7.3: Windows Powershell Monitoring.
A year ago I had a requirement in front of me to “manage Windows using WMI.” Thinking I had everything I needed, I set forth to have our development staff build better WMI-based Windows monitoring. I was working with a lead developer who was then new to the company and had some pretty decent Windows chops. He questioned “why WMI?” Customers don’t like WMI. It’s difficult to implement, has security issues, and the instrumentation seems to change with every release of a managed Microsoft product. Even Microsoft was moving away from WMI, in particular with Exchange 2010, which is among our list of products that will soon have a shiny new Power-Pack. We quickly re-scoped the project to (more properly) deliver Windows management aligned with Microsoft’s directions, but implemented in such a way as to allow easy and simple implementation without increasing support or product costs.
We thought about that one for a while. The solution would have to be part of the Windows domain. It would have to run Powershell scripts on behalf of EM7 and return the results, where they could be stored with the correct end device. It would need to replicate the core functionality for managing system resources and availability.
The first problem proved the stickiest. Should we build a Windows-based appliance? Some of the problems with that approach include licensing of the OS and patching: we would need to QA the platform constantly. It would increase both product and support costs. After a lot of discussion and white board sessions we settled upon a well-vetted, proven approach based on the manager/agent architecture: utilize an existing Windows host as a Powershell proxy. The benefits are significant: the customer owns the box. They control it’s security. They can manage it’s patches, etc. And it’s a single point to administer per Windows domain. We would securely connect to it and use it as our window into the Windows domain. On our end, the Dynamic Applications are written to gather specific data into Config or Counter collections, where they can be used in dashboards, deports, and thresholds.
We were off and running. The project proceeded quickly and without incident. But the best part was the powerful capabilities it delivered to us. Capabilities we will be able to leverage into the coming releases to instrument more Windows systems, services, and applications more deeply and consistently than ever before. We don’t have to touch any host in the Windows domain in order to manage it. The Windows Powershell Proxy host provides a secure tunnel through which EM7 can manage the entire Windows domain at no incremental cost, and without compromising security.
We could have accomplished this with agent-based technology. In fact, we manage Windows environments quite well via SNMP agents. The downside is that the agents need to be distributed, installed, configured, and secured on each managed Windows host. Now we can offer in addition an agentless solution that only requires one host to be configured.