SOP-001 · SOP

Testing a Script Safely Before Rollout

A repeatable way to prove a new script is safe on one device before it reaches every device you manage.

What it does

A repeatable way to prove a new script is safe on one device before it reaches every device you manage. Written in plain language so any technician, or a trained staff member, can follow it.

Requirements

Access to the systems the procedure mentions and permission to make changes. No special tools. Works with WIN-001 Disk Space Monitor and Cleanup, WIN-004 Uptime and Reboot Status, WIN-006 BitLocker Status Check.

How to run it

Not a script. Follow the steps in order, or adapt them for your team.

Testing steps

1. Read it through once and adjust names, schedules and contacts for your organization.
2. Walk through it with one colleague on a single site or device before adopting it.

Rollback steps

Each change step in the procedure lists how to undo it.

Purpose

Run any new or changed script on one test device first, confirm what it does, and only then roll it out in small groups. This keeps one bad setting from reaching every device at once.

Who this is for

Anyone who runs scripts on more than one device or account, whether by hand, with a scheduled task, or through a management tool such as an RMM, MDM, Intune or Group Policy.

Before you start

• Pick one test device that matches the devices you plan to target (same operating system and build).
• Make sure nobody depends on the test device while you test.
• Read the script's item page: what it does, requirements, settings and rollback.
• Have a place to save notes, such as a ticket or a shared document.

Steps

1. Download the latest version of the script from your library. Write the version number in your notes.
2. If the script has a Mode setting, start with Report or Preview. These modes change nothing.
3. Set up the script exactly as the item page's "How to run it" section describes: run as, script type, and timeout. This applies whether you use a management tool, a scheduled task, or an administrator window.
4. Run it on the test device only. Do not schedule it yet.
5. Open the output and the log file. Confirm the device name, the values reported, and the exit code. Exit code 0 means OK, 1 means needs attention, 2 means error.
6. Compare the result with what you see on the device itself. The numbers should match.
7. If the script makes changes, run it again in its change mode (for example Clean or Apply) on the same test device.
8. Check the device afterward. Confirm only the expected change happened and that the user's apps and files still work.
9. Run the script a second time. A well-behaved script should report that nothing else needs changing.
10. Practice the rollback steps from the item page once, so you know they work.

Rolling it out

1. Pilot group: run it on 5 to 10 devices, or about 5 percent, for one to two days.
2. Review results. Look for errors, timeouts, and any device that reports something unexpected.
3. Expand to about 25 percent, then everyone, reviewing results between each step.
4. Only then add a schedule, if the script is meant to run regularly.

Record keeping

• Note the script ID, version, settings used, test device, date and result.
• When a new version comes out, repeat this SOP before replacing the old one.

Stop and roll back if

• The script returns exit code 2 on more than one device.
• Any user reports a problem that started after the script ran.
• The output does not match what you expected from the test.

Version and change log