IT administrators who already rely on PowerShell are not always immune to difficulties. For example, there is often no overview of when a script was last executed and by whom. Also, you can’t delegate recurring tasks because, for example, you can’t assign admin rights to Exchange tasks, or because only a few people in your organization really know PowerShell. In addition, the more machines that need to install and maintain PowerShell modules, the more confusing the work becomes.

The answer to these and other challenges can only be “centralization”. Administrators or IT departments should take a closer look at everything that is currently being done with PowerShell and consider how this can be done centrally. It’s worth the effort, because PowerShell will help you do more in less time. What are the reasons for bundling all PowerShell activities?

1. Standardization

The goal of standardization is to always perform recurring, similar tasks in the same way. This includes, for example, that all processes are executed with the identical, current scripts and PowerShell modules.

2. Collaboration

If standards are defined, scripts can easily be developed and maintained in a team or in several teams. New scripts can easily be added to a central repository.

3. Control

Centralization also enables easy traceability of all PowerShell activities. For example, who executed which scripts when and with what result? This question can be answered quickly with the help of central processes.

4. Security

The central administration of credentials plays a role in the secure use of PowerShell, as does the uncontrolled granting of privileged permissions to users.

5. Delegation

Centralization ensures that scripts can be executed not only by experts, but also by help desk users or users from specialist departments. Especially for recurring tasks this is an enormous relief.

6. Automation

Automatically trigger PowerShell scripts with the right parameters by third-party systems, which is also easy to do with centralization. For example, monitoring or workflow systems can be integrated into a fully automated process.

Now that the “why” has been clarified, the question arises: How can the whole thing be implemented?

In the following we describe the procedure in five steps with the help of ScriptRunner.

1. Centralization of the scripts

Centralizing scripts is about storing all PowerShell scripts in a well-structured way. This can be done according to target systems like Exchange, Office 365 or Azure or according to target groups like helpdesk or end users.
The folder names automatically represent tags that can be used to filter scripts later. In addition to the scripts, PowerShell modules are also part of the centralization. Thus, the modules for Office 365 or Azure can be installed centrally exactly once. After that, the functions are available for all activities.

2. Centralization of the credentials

To use PowerShell scripts, credentials are usually required. If these are located centrally in the server’s credential store or are provided by a password server, nothing stands in the way of central execution. CyberArk, Pleasant and Thycotic solutions can be used as password servers. Depending on the target system, different credentials can of course be used. To circumvent possible limitations regarding the number of parallel sessions, several credentials can also be used for one target (e.g. Office 365).

3. Permissions

When using ScriptRunner, all PowerShell scripts are executed by the ScriptRunner service. The ScriptRunner service uses the stored user and password information for the respective target systems. Typically, service accounts are used as users. For example, helpdesk users can now execute scripts without requiring privileged permissions on systems such as Exchange, Sharepoint, or Azure. This means that a user who is a simple domain user can run selectively shared PowerShell scripts, e.g. to set up an absence notification for colleagues in Exchange or to unlock a user account.

Administration is done with the web application, the Admin App. Targets are configured here and linked to the appropriate credentials.

4. Running and monitoring PowerShell scripts

When ScriptRunner centrally executes PowerShell scripts, several options are available.

• Manual execution by a user of the Delegate App
• Scheduled for tasks we regularly delete log files
• Automatically event-triggered by third-party systems

Each execution of a script is logged in detail. The ScriptRunner Dashboard shows an overview of all activities and possible problems during processing. Filter functions make it easy to evaluate and compare information about dedicated actions or target systems.
The Delegate App is available so that users can easily complete tasks. The input fields required for execution are provided via a convenient web interface. The dynamic web interface is automatically generated by the ScriptRunner solution. This means that manual programming of a user interface is a thing of the past.

An example: Out-of-office settings. The target “Exchange” is coupled with the credential and connected with a query – all in one place. If the task is now started, all functions and input fields are displayed that are stored in the script. This allows you to select for which Out-of-Office is to be set up, for which period of time, etc., you want to set up the query. If the process is to be automated, this can be done easily with the help of the ScriptRunner WebService connectors.

5. Delegating the PowerShell execution

If users of the Helpdesk or other users should execute scripts, they can be delegated with the Admin App. The execution then takes place via the Delegate App. Users see the actions assigned to them and start them by clicking on the respective tile in the web interface. Which input fields are displayed for an action or are already filled automatically is freely configurable. No PowerShell knowledge is required for execution, nor is privileged access to backend systems. Frequently used actions such as resetting a password or similar can be marked as favorites and are available immediately after the Delegate App has been started.

Conclusion

Centralization turns PowerShell into a tool that can no longer be used only by PowerShell experts. This allows many tasks to be safely and easily delegated by IT administrators to helpdesk teams and end users. This relieves sysadmins and improves and accelerates many IT processes.