While scripts are a powerful automation tool, if not done correctly, they can leave you with false data. Most System Administrators utilize scripting as an action in response to triggered event from an agent or listener such as SCCM, Logic Monitor, ConnectWise Automate or Solar Winds. When an event occurs and triggers the agent monitor, a script is executed to perform a specific action with the hopes of resolving the issue. Here are some potential problems with the trigger-execute method:
– You’re testing on a single machine which may not be a good representation of your overall network environment.
– As a “Fire and Forget” script, you have no idea if it worked.
– If the customer or stakeholder ask for a report, you do not have usually have data regarding the event or resolution.
Here are some suggestions on how to setup your scripts so this is not an issue:
1. IDENTIFY the problem in your script:
Let your script check for an issue prior to fixing anything. This serves as an extra check and queues up the data in your script for reporting. Once identified, have a log started to track you’re the status of your script. It is advised to keep appending the log with each step or action within your script.
2. RUN the action procedure:
This is your attempt to fix what is broken or preform a specific action. Remember to log EVERYTHING for tracking. This will include the logging of your action step.
3. VERIFY:
After your action procedure finishes, did it work? Sometimes you can simply re-run the script from the beginning and let the “Identify the problem” section of your script tell you if the script worked. This verification process is called recursion: the repeated application of a procedure. If recursion gets too complicated, you can always call the Identify section of your script in-line as an additional check.
4. REPORT the results:
Remember that log where we keep adding data? IT is a good idea to send the log results to the tech who ran the script. Reporting is critical for the technician or stakeholder who ran the processes or is auditing results. The report information should include, but doesn’t have to be limited to:
- Name of the client/department
- Name of the agent/system/device
- Name of the script
- Success/fail notification
- Results of the action
Think about what information you would like to see if you were trying to solve the end users problem with your script. As the admin who wrote the script, you are going to want debug information. Use the detailed log you appended at each step in the script and push that information into your RMM (Remote Monitoring Management) or asset management database. Adding the log data will allow you to debug any issues or errors and make the necessary tweaks to improve the script for the next time it is used.
IronEdge Group Recognized on CRN’s 2024 MSP 500 List
Houston, Texas, February 12, 2024 — IronEdge Group is honored…
