I participated in a panel at Kaseya Connect that talked about automation. One of the audience questions was "how do you manage creating procedures by your team?". That simple question led to this blog post, where I'll explain in more detail what we do.

First of all, I encourage all of our team members to create procedures. I use a small document "Intro to Programming" that I wrote when I taught a Windows Administration course at a local college. It's very basic and presents concepts that can be easily understood, even by those with little or no exposure to programming. This doesn't mean, however, that I turn my engineers loose as "wannabe programmers"!

1. As an introduction, I have a 1 page sheet that explains how to create Kaseya procedures. This covers the following points:
   • All procedures must have a complete and accurate description field that explains the purpose of the procedure.
   • Each procedure must have liberal comments that define the logic - what are you trying to do? This allows other engineers to understand what's being done should things go awry sometime in the future.
   • Start with the procedure template - it illustrates the standard ways that we perform certain tasks, such as defining the KWorking folder; verifying and using the TEMP Folder whenever possible AND cleaning up after the install or process is complete; and dealing with Managed Variables in a way that provides a default value if the MV isn't defined. (The link above is a zip file with the Intro to Programming PDF and the Kaseya Procedure template.)
2. Each procedure undergoes a code review before the engineer can even test-run it. The code review verifies the above points were followed, checks the basic logic, and insures that common code methods are used. Once the review is complete, the procedure is approved and the engineer can test their code. Yes, this takes work, especially when the engineer hasn't thought the logic all the way through! It does, however, insure that any engineer can support any of the procedures, and makes them more effective at this task. The unwritten goal is to get a procedure published for production in the minimum number of review/approval passes! It's also an opportunity to explain why one logic method might be preferred over another, and why standard methods - even when they contain more lines of code - are better in the long run.
3. When testing is complete, one of the NOC Management team members will move the procedure into the shared folder and send an announcement that the new procedure is available.

Much of what we do builds on standard ways of operation, and the procedures are no exception. Standards result in consistency of operation, which improves reliability. Reliability in the environment is a double-win for us - we get fewer alerts and the customer has fewer problems, making them more willing to work with us on projects. The effort needed to follow thes standards is minimal in comparison to the dividends it pays.