- 0 minutes to read

How to run custom PowerShell scripts securely with Nodinite

Use custom PowerShell scripts to extend Nodinite monitoring and automation, but keep the runtime model tight. In Nodinite v7, the Windows Server Monitoring Agent is hosted as an IIS web site, so the secure approach is to use a dedicated IIS identity per group, grant only the permissions the script actually needs, and limit remote access to the smallest possible scope.

This page answers the common security question directly: how do you run custom PowerShell scripts as securely as possible without losing the flexibility of the Nodinite Windows Server Monitoring Agent?

Note

This guidance applies to Nodinite 6.4.0.0 and later. Starting with 6.4.0.0, PowerShell monitoring entries and their optional user-action scripts are grouped by identity. In v7, each group is hosted by the IIS web site and shares the same restricted execution identity for PowerShell. Changes such as adding scripts, editing scripts, renaming groups, or renaming individual monitor/script entries require the password for the affected collection.

Security Model at a Glance

graph LR A[" Admin or Operator"]:::actor B[" Nodinite v7 IIS Web Site"]:::site C[" PowerShell Group"]:::group D[" Restricted IIS Identity"]:::identity E[" Monitoring Script"]:::script F[" Optional User-Action Scripts"]:::script G[" Monitored Windows Server"]:::target A -->|Manages| B B -->|Hosts| C C -->|Shares| D D -->|Runs| E D -->|Runs| F E -->|Checks / reports| G F -->|Remediates / details| G B -->|HTTPS / TLS| A classDef actor fill:#90EE90,stroke:#2E7D4E,stroke-width:2px,color:#000 classDef site fill:#87CEEB,stroke:#2E5C8A,stroke-width:2px,color:#000 classDef group fill:#FFD700,stroke:#A67C00,stroke-width:2px,color:#000 classDef identity fill:#FFB347,stroke:#B86B00,stroke-width:2px,color:#000 classDef script fill:#D6EAF8,stroke:#5B7FA3,stroke-width:2px,color:#000 classDef target fill:#FADBD8,stroke:#B03A2E,stroke-width:2px,color:#000

Diagram: In Nodinite v7, the IIS web site hosts each PowerShell group under a shared restricted identity. The monitoring script and optional user-action scripts stay in the same security boundary, while operators access the site over HTTPS/TLS.

Sensitive Change Flow

flowchart LR A[" Change request"]:::change --> B[" Password for affected group"]:::gate B --> C[" Update authentication or script collection"]:::change C --> D[" IIS group updated"]:::ok D --> E[" Restricted identity remains in place"]:::ok classDef change fill:#D6EAF8,stroke:#5B7FA3,stroke-width:2px,color:#000 classDef gate fill:#FFB347,stroke:#B86B00,stroke-width:2px,color:#000 classDef ok fill:#90EE90,stroke:#2E7D4E,stroke-width:2px,color:#000

Diagram: Sensitive changes are gated by the password for the specific PowerShell group, so authentication or script updates remain tied to the same IIS-hosted identity boundary.

Restore Behavior After Backup

When restoring backups, PowerShell group behavior depends on what was restored:

  • Restoring a current backup without PowerShell configuration drift normally keeps behavior unchanged.
  • Restoring an older backup where PowerShell group scripts/configuration differ can result in affected entries becoming disabled.
  • To re-enable those entries, perform a change in that collection and provide the password for the affected group.

This ensures that restored script execution is still tied to verified ownership of the impersonated account.

Why this matters

PowerShell scripts can monitor almost anything that Windows exposes, which is useful and powerful. The same flexibility can become a risk if scripts are too broad, if secrets are embedded in the script body, or if remote access is left open longer than necessary.

The goal is simple: keep monitoring flexible for operators, but narrow enough that a script failure or a compromised credential cannot reach more than it should.

Security baseline

Area ✅ Recommended practice ❌ Avoid
Identity Use a dedicated IIS identity for each PowerShell group and separate accounts for script maintenance. Use a personal admin account for day-to-day monitoring.
Permissions Grant only the rights the script needs on the target server, such as WMI, service control, file system, or SQL access. Make the account a local administrator everywhere by default.
Secrets Keep passwords, tokens, and connection strings out of the script body. Hard-code secrets in scripts or comments.
Remote access Enable WinRM and firewall access only for the servers that truly need remote execution. Open remote access broadly across the network.
Run-time Use IIS hosting with TLS for secure transport and application pool isolation. Use the older Windows Service hosting model without TLS, which is more complex to secure.
Script changes Review, test, and version control script updates before publishing them to production. Let anyone edit live script collections.
Output Return concise status text and avoid dumping sensitive objects or environment data. Write full object dumps that may expose details you do not need.

Use separate accounts

Keep the IIS identity that hosts the Nodinite Windows Server Monitoring Agent separate from the accounts used to maintain the script collection. That separation makes it easier to audit changes and reduces the blast radius if one account is compromised.

If a script needs remote access, create an identity that has access only to the target systems it must reach. Do NOT reuse the same identity for unrelated administration tasks.

Grant least privilege

Start from the smallest set of rights that makes the script work. For example, a service check may only need service read access, while a file drop check may only need directory read access.

If a script works after you grant broad administrative rights, reduce those rights again and test the script one more time. In most environments, that extra pass reveals which permission was actually required.

Keep secrets outside the script body

Do not embed passwords, API keys, or connection strings directly in the script. If a script must authenticate to another system, keep that credential handling separate from the logic that evaluates state.

Also avoid echoing secret values into the output stream. Script output is designed for operators, so keep it readable and limited to the information needed to understand the state.

Restrict remote execution

Use remote execution only when the agent cannot evaluate the target locally. When remote execution is necessary, keep WinRM enabled only on the target servers that need it and scope firewall rules as narrowly as possible.

If you can run the script locally on the monitored server, that is usually the cleaner option because it removes an extra network hop and reduces the number of moving parts.

Review script collections before publishing

Treat the PowerShell script collection like application code. Require review before changes reach production, keep a previous version available for rollback, and test the script in a non-production environment before you publish it.

This is especially important for Remote Actions because they may be used interactively by operators or end users.

Starting with Nodinite 6.4.0.0, the management experience reflects the identity group shown in the UI. A single group can contain the monitoring script and its optional corrective or detail actions, all sharing the same restricted PowerShell account.

Keep output small and explicit

Return a short status message that explains what the script checked and what happened. If the script returns objects or tables, format the result so it is easy to read in Monitor Views.

Practical checklist

Before you publish a new script, confirm the following:

  • The script runs under a dedicated IIS identity for its group.
  • That identity has only the permissions the script needs.
  • No passwords, tokens, or keys are stored in the script body.
  • WinRM and firewall rules are limited to the target servers that need remote execution.
  • The script has been reviewed and tested in a non-production environment.
  • The output is concise and does not expose sensitive data.
  • Your environment is updated regularly to receive monthly security and platform fixes from Nodinite and Microsoft (see Monthly updates FAQ).

When to use a separate collection

Create a separate script collection when one script needs broader access than your normal monitoring checks, when the script is used for remediation, or when a different team owns the logic.

That separation makes it easier to apply tighter permissions, review the changes independently, and keep the operational model understandable.

If you update authentication or another sensitive setting for a collection, provide the password for that specific group when Nodinite prompts for it.

Next Step

PowerShell Monitoring Features