How to Train New Technicians on Script Use Without Exposing Sensitive Variables

Proper IT technician training is paramount to scaling IT operations, especially with automation. Scripts contain sensitive variables hardcoded or exposed during execution. Improper handling increases the probability of data leaks and can create bad habits among junior technicians.

A structured training and script management process is crucial for any IT team to protect data and build technician confidence.

Training new technicians on script use without exposing sensitive data

Proper IT technician training involves separating secure variables from script logic, storing variables in the Windows Registry, using environment variables for training-safe placeholder data, creating training versions of production scripts, and auditing script changes and execution during training.

📌 Prerequisites:

• Standard script templates for onboarding
• Administrator rights for deploying training scripts
• Secure storage mechanism for protected values
• Defined documentation for script structure and safe editing practices

📌 Recommended deployment strategies:

Method 1: Separate secure variables from script logic

When onboarding new IT technicians, the first thing you should do is separate secure variables from script logic. Separating them reduces security risks and enables safer automation.

📌 Use Case: Prevents new technicians from seeing and sharing sensitive information by pulling them from secure storage

Avoid hardcoding sensitive data like:

• Admin passwords
• API tokens
• SMTP credentials
• Backup keys
• Internal server names

Instead, reference:

• Encrypted credential stores
• Environment variables
• Registry paths
• NinjaOne or RMM-injected fields

Method 2: Store secure variables in the Windows registry

This method stores sensitive data in the Windows registry, ensuring only authorized processes or administrators can access it.

📌 Use Case: Gives multiple scripts secure access to sensitive values while restricting access

1. Press Win, type PowerShell, then click Run as administrator.
2. Copy and paste the following code into the prompt, then press Enter:

• • Secure technician-hidden values in HKLM (HKEY_LOCAL_MACHINE):

New-Item -Path "HKLM:\SOFTWARE\Org\ScriptSecrets" -Force

Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\ScriptSecrets" -Name "SMTPHost" -Value "mail.domain.com"

Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\ScriptSecrets" -Name "SecureToken" -Value "XYZ123"

💡 Note: SMTPHost, mail.domain.com, and XYZ123 are just place holders. Replace them with the email server and SecureToken.

This script centralizes all scripts, as they can reference the same stored values without embedding them in the code.

• • Access securely in training scripts:

$smtp = Get-ItemProperty -Path "HKLM:\SOFTWARE\Org\ScriptSecrets" -Name "SMTPHost"

$token = Get-ItemProperty -Path "HKLM:\SOFTWARE\Org\ScriptSecrets" -Name "SecureToken"

💡 Tip: Use NTFS (New Technology File System) permissions or GPO to restrict registry key access to admin-level processes

⚠️ Warning: Before deploying the settings change on different endpoints, it’s best to test it out on a local machine first. (For more info, refer to: Things to look out for)

Method 3: Use environment variables for training-safe placeholder data

This method sets a variable that ensures all scripts can reference a specific path consistently without editing them individually.

📌 Use Case: Standardizes non-sensitive paths across all machines without editing individual scripts

1. Press Win, type PowerShell or cmd, then click Run as administrator.
2. Copy and paste the following code into the prompt (depending on what tool you use), then press Enter:

• • CMD:

setx NOC_SCRIPTS "C:\NOC\Scripts"

💡 Note: C:\NOC\Scripts represents the path to a directory on your system. It’s the folder that will be stored as the value of the valuable NOC_SCRIPTS.

• • PowerShell:

$path = $env:NOC_SCRIPTS

The scripts above are convenient ways to give all scripts a consistent reference point for paths or values anyone can see.

⚠️ Warning: Ensure you copy and paste the proper script, as incorrect syntax can cause errors. (For more info, refer to: Things to look out for)

Method 4: Create training versions of production scripts

This method ensures the production script pulls sensitive values from secure sources, while the training script uses harmless placeholders for safe sharing.

📌 Use Case: Provides training scripts that use harmless placeholders

Before you create production scripts, it’s crucial to have two versions:

• Training: This script should have placeholders like “smtp.placeholder.local”
• Production (secured): Meanwhile, this script reads from protected sources, encrypted files, or credential vaults.

You should also use scripting standards like:

1. Afterward, include scripting standards by pressing Win + R, typing PowerShell, then clicking Run as administrator.
2. Copy and paste the script below into the prompt, then hit Enter.

# BEGIN: Do not edit

$APIKey = Get-ItemPropertyValue -Path "HKLM:\SOFTWARE\Org\ScriptSecrets" -Name "ProdAPIKey"

# END: Do not edit

💡 Note: The script above flags restricted sections with comments and applies read-only permissions on the scripts.

⚠️ Warning: Be careful not to use the training script for anything other than training purposes. (For more info, refer to: Things to look out for)

Method 5: Audit script changes and execution during training

This method tracks who runs critical scripts and when to a registry key to create a record you can review.

📌 Use Case: Maintains a record of who ran key scripts and when for easier review

1. Press Win, type PowerShell, then click Run as administrator.
2. Copy and paste the following code into the prompt, then press Enter:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\ScriptAudit"

-Name "LastRunBy" -Value "$env:USERNAME - $(Get-Date -Format u)"

You can also validate the changes by following the steps below:

1. Press Win, type cmd, then click Run as administrator.
2. Copy and paste the following code into the prompt, then press Enter:

reg query HKLM\SOFTWARE\Org\ScriptAudit

💡 Tip: Schedule log reviews to ensure safe script usage.

⚠️ Things to look out for

Additional considerations

The following best practices focus on minimizing risk while maintaining operational efficiency.

Role-based execution

Use least-privilege accounts or RMM roles to control script execution. You can do so via the following:

• Assign permissions so accounts only run the scripts they need.
• Restrict access to sensitive script types, such as modifying system configurations.

These practices minimize damage to compromised accounts.

Output sanitization

Ensure scripts never echo secrets like passwords, tokens, and API keys to the console or logs. This process involves the following:

• Mask sensitive data in output.
• Avoid storing credentials in plaintext within logs.
• Review script output handling before deployment.

Parameterization

Use param() blocks in PowerShell to safely handle inputs.

• Require parameters instead of hardcoding sensitive values.
• Avoid printing parameter values to the console.
• Implement validation attributes to enforce input formats and prevent injection attacks.

Script signing

Digitally sign final scripts used in production to prevent modification by only running trusted-author scripts, which you can combine with execution policies to enforce trust.

Troubleshooting common issues

The following are common scripting issues that surface during IT technician training and how to resolve them.

Tech sees protected variables

It’s ideal to restrict scripts with sensitive variables. You can use proper access controls, like enforcing file system ACLs that limit who can read or modify scripts. Sometimes, it’s safer to separate confidential values into secure vaults or encrypted parameter stores to keep them out of the script source.

Script fails in training

Scripts may fail during training or testing phases. To address this, implement error handling to detect and respond to missing resources. Wrapping critical lookups in try/catch blocks prevents failures.

It’s also recommended to use checks such as Test-Path or Get-ItemProperty before accessing files to ensure the script confirms they exist.

Variable injection not working

Variable injection may fail because of execution policy restrictions or mismatches in the script. It’s crucial to confirm execution policy settings using Get-ExecutionPolicy -List to verify that the script is permitted to run.

NinjaOne services that support IT technicians’ onboarding

MSPs can onboard new technicians into automation roles without sacrificing security or exposing sensitive data with NinjaOne.

• Restricting script editing and execution to assigned technician roles
• Injecting secure values at runtime using custom fields or policy templates
• Logging script activity and output per device and technician
• Providing version-controlled script repositories for training vs production scripts
• Enabling script review workflows before promoting scripts to live use

Prevent accidental data leaks by properly training IT technicians

Training new IT technicians to use and modify information prevents exposure to sensitive data. You can do so by abstracting values using the registry and GPO, creating safe training versions of automation scripts, and using NinjaOne’s controlled script access, execution, and reporting.

Related topics:

• Three Reasons Why You Should Learn PowerShell (With PowerShell Training Resources)
• Why You Should Learn PowerShell (With Resources to Start)
• IT Management Guide: How to Create a Culture of IT Learning
• IT Department Guide: Training Employees on New IT Tools
• Become a certified IT Ninja