FAQ

After upgrading my system to Windows 10 ScriptRunner update fails.

After upgrading my system to Windows 10 ScriptRunner update fails. It is also not possible to uninstall ScriptRunner.

ScriptRunner Uninstallers previous to build number 2795 are not compatible with Windows 10.

In this case, for the ScriptRunner Service:
1) Manually delete the registry entry: ‚HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\AppSphere ScriptRunnerSvc\DisplayVersion‘

2) Stop the ScriptRunner service.
3) Install ScriptRunner 2.52 or newer. Make sure to install to the exact previous installation folder, so that all previous files will be replaced and no old versions will be kept.


For the Team Apps:

1) Manually delete the registry entry: ‚HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\AppSphere ScriptRunnerTeamApps\DisplayVersion‘.

2) Install ScriptRunner 2.52 or newer. Make sure to install to the exact previous installation folder, so that all previous files will be replaced and no old versions will be kept.

Are there different views of the dashboard bar chart?

Are there different views of the dashboard bar chart?

The bar chart at the bottom of the dashboard shows the results of all script activities within a specified time interval. You can filter the data using filters on the category panels or the tags in the navigation submenu.

There are three different views for the bar chart:

  • Single: View each single started action, and show the amount of time it took the action to run.
  • Hourly: Show one bar per hour, and the number of actions started in this hour.
  • Daily: Show one bar per day, and the number of actions started on this day.

In either case, you see scripts with errors in red, and scripts without errors in green.

Ausgesperrt – wie kann ich die ScriptRunner Admins zurücksetzen?

Ich habe in den Berechtigungen für die ScriptRunner Administrator-Rolle wohl etwas falsches eingetragen, jedenfalls erhalte ich jetzt in der Administrator App immer die Meldung „ScriptRunner Administration: Zugriff verweigert.“

Wie komme ich jetzt wieder in die ScriptRunner Oberfläche, um die Einstellungen für die Administrator-Rolle zu korrigieren?

ScriptRunner erlaubt immer (zusätzlich zu den Einstellungen der Administrator-Rolle unter „Berechtigungen“, die auch für Remotezugriffe gelten) lokalen Administratoren lokalen Zugriff.

Sie können also die Administrator App lokal auf dem ScriptRunner Service Host und „Als Administrator“ starten, und dann die Berechtigungsgruppe für die Administrator-Rolle korrigieren.

Can I change the ScriptRunner user interface language?

Can I change the language of the ScriptRunner user interface?

The local language of the ScriptRunner Apps can be changed in the Apps.

Currently there is English and German.

Error after successful installation: Invalid license – Error accessing Activation Server

After installing ScriptRunner, I cannot use Administrator App – when I start the app, the initial splash screen shows „Invalid license“ and an error message: Error accessing Activation Server.

When you install the ScriptRunner Service on a system for the first time, ScriptRunner will activate a 30 days trial license for up to 5 users. Activation is internet based on an Activation Server. „Error accessing Activation Server“ means that this activation could not be done because the activation server on the Internet could not be reached.

To solve this, connect the ScriptRunner system (with the installed ScriptRunner Windows service) to the Internet, and stop and restart the ScriptRunner Windows service to complete activation of the 30 days trial license.

The ScriptRunner service will require an Internet connection to reach the Activation Server also to activate a freeware or full license, and to change or verify the license status. If the ScriptRunner system does not have Internet access at all, contact our product support to opt in for an offline license.

The „Error accessing Activation Server“ can also occur if you use a proxy server in your network to access the Internet. This is described in this FAQ entry.

Fehler nach der Installation: Ungültige Lizenz – Fehler beim Zugriff auf den Aktivierungsserver

Ich habe ScriptRunner installiert. Wenn ich jetzt die Administrator App starte, kommt auf dem Startbild immer eine Fehlermeldung: Ungültige Lizenz, „Fehler beim Zugriff auf den Aktivierungsserver“ (bei englischem Windows: Invalid license, „Error accessing Activation Server“).

Wenn Sie den ScriptRunner Service zum ersten Mal auf einem System installieren, aktiviert ScriptRunner eine 30 Tage Test-Lizenz für bis zu 5 Benutzer. Die Aktivierung dieser Lizenz erfolgt Internet-basiert auf einem Aktivierungsserver.

Der ScriptRunner Service benötigt dafür nach der Installation Zugang zum Internet.

Schließen Sie den ScriptRunner Service Host ans Internet an, und starten Sie den ScriptRunner Windows-Dienst neu, damit die Aktivierung der 30 Tage Test-Lizenz durchgeführt werden kann.

Ohne Internetzugang können Sie ScriptRunner nicht mit dieser initialen Trial-Lizenz ausprobieren, sondern benötigen einen Aktivierungs-Schlüssel.

Fehlermeldung: Kommunikationsproblem beim Zugriff auf den Aktivierungsserver

Beim Starten von ScriptRunner bekomme ich die Fehlermeldung „Kommunikationsproblem beim Zugriff auf den Aktivierungsserver“.

ScriptRunner benötigt beim ersten Start eine Internetverbindung, um den „30 Tage Demo-Modus für bis zu fünf Benutzer“ der Lizenz zu aktivieren. Die Aktivierung erfolgt automatisch durch den ScriptRunner-Service. Die hier beschriebene Fehlermeldung besagt, dass diese Aktivierung nicht erfolgen konnte, weil der Aktivierungsserver im Internet nicht erreicht wurde.

Um dies zu beheben, verbinden Sie das ScriptRunner-System (mit installiertem ScriptRunner Dienst) mit dem Internet, und stoppen und starten Sie den ScriptRunner Dienst, damit die Aktivierung erfolgen kann.

Der ScriptRunner Dienst wird auch später bei der Aktivierung einer Freeware- oder Vollizenz Verbindung mit dem Aktivierungsserver benötigen. Sollte das System, auf dem der ScriptRunner-Dienst installiert ist, grundsätzlich keinen Internetzugriff haben, gibt es weitere Möglichkeiten eine Offline-Lizenz einzuspielen. Bitte kontaktieren Sie dazu unseren Support.

Dieser Fehler kann auch auftreten, wenn Sie die Internetverbindung in Ihrer Umgebung über einen Proxy-Server herstellen. Die Lösungen sind in einem eigenen FAQ-Eintrag beschrieben.

Gibt es noch mehr Beispielskripte?

Wo finde ich weitere Skripte die ich auf meine Umgebung anpassen und ausführen kann?

Im Script Center von Microsoft finden Sie zahlreiche Skripte zu unterschiedlichen Systemen und Produkten.
Dort stehen Ihnen Skripte in verschiedenen Skriptsprachen zur Verfügung.

How about backup/restore of the ScriptRunner configuration?

In order not to lose any changes in the ScriptRunner configuration (actions, target systems, …) after an operating system issue, I would like to make regularly backups of the ScriptRunner configuration.

After initial installation, the current state of the ScriptRunner product is defined by the following files and system components:

  1. The script files in your script library,
  2. ScriptRunner configuration and runtime data,
  3. ScriptRunner user credentials stored in Windows Credential Manager.

You can backup the files of points 1 and 2 easily after you stop ScriptRunner. For ScriptRunner 2014, the configuration and runtime data for a user are in

%AppData%\AppSphere\ScriptRunner

For ScriptRunner 2015, the respective data is on the ScriptRunner Service host in

%ProgramData%\AppSphere\ScriptRunnerSvc

After restoring the Windows system and maybe re-installing ScriptRunner you can restore this data from your backup into these locations (again, after stopping ScriptRunner on the system).

The ScriptRunner credentials stored in Windows Credential Manager are different. ScriptRunner 2014 uses the Credential Manager instance of the current user, ScriptRunner 2015 the instance of the service account of the ScriptRunner Service. You have to backup the respective instance in addition to the file backup and restore mentioned above.

Alternatively, ScriptRunner can re-store the Windows Credential Manager entries for you: Enter each of the credential elements in the ScriptRunner UI, enter the respective password, and click OK. (Really, ScriptRunner does not have the passwords elsewhere.)

Note: The ScriptRunner license has a built-in copy protection and is valid for the original system where it was activated. To migrate to a new system, contact our sales or support team.

How can I change the font size in ScriptRunner?

The screen resolution of my system is 800×600 pixel at maximum. Can I change the font size in ScriptRunner?

The ScriptRunner 2015 Apps store your current size for the next start as a local browser cookie.

You can increase and decrease the font size in your browser by holding down the Ctrl key and move the mouse wheel up or down. Alternatively you can press and hold theCtrl key and press either the + (plus) or (minus) keys on the top of the keyboard to increase and decrease the font.

ScriptRunner also supports pressing the Ctrl key and 0 (zero, not 0 on the number pad) at the same time to reset the font back to the default font.

How can I filter reports in the dashboard?

If I want to see all reports that originate from a specific target system, or only the reports from a certain script: How can I do this?

You can filter the reports shown in the dashboard by tag, just as with every view, by choosing the respective tag in the navigation submenu.

Additionally, to filter for a target, credential, script, or action, or a combination of these four categories, select a filter element on the respective category panel(s).

Alternatively, you can use an entry from a categorie’s list view directly as the current dashboard filter by selcting the entry in the list fiew and clicking the Dashboard button in the action bar. For example, if you are in the targets view and want to see all the reports for a specific target, click the target in the list and change with a click on the Dashboard button into the dashboard view; the dashboard will set the current filter from the selected target context.

In the dashboard view, whenever you want to see the report contents of the current report selection, change to the report viewer with a click on the Report button in the action bar.

 

How can I import my target machines into ScriptRunner?

I want to get my existing machines into the ScriptRunner target list.

Is there an option? Can I import all machines from my domain?

You can import your machines into ScriptRunner from a CSV file.
The file must be ANSI, with one line per machine, with the properties separated with ‚;‘.

The properties are:

  • FQDN
  • tags list to apply in ScriptRunner (comma separated)
  • use SSL (0=no, 1=yes)
  • PS Remoting port number

Example line:

testsystem.mydomain.com;Performace,System,Support;0;5985

To create such a file for all machines in your domain, there is a sample script „Export_AD_Computer.ps1“. Open the script to adapt it to your environment.

You can execute the script with an action in ScriptRunner.

How can I profit from using tags?

What are tags used for? Why should I use tags?

Tags are used for filtering, managing, labeling of actions, scripts, credentials and target systems.

You can display and manage your tags on Settings -> Tags page. You can create, edit or delete your tags there. ScriptRunner automatically creates tags form the subfolders of the script path and attaches these tags to the correspondig scripts; when you create an action for a script, the action will automatically inherit the tags of the script.

You can attach other tags to your actions, scripts, credentials or target systems later in their new and edit wizards respectively.

You can filter each table view for tags, to quickly find the objects you are looking for.

The ScriptRunner 2015 Delegate App will show the tags of the delegated actions as a tab in the tab bar.

How do I activate local execution of PowerShell scripts?

If I try to run a script with ScriptRunner, I get an error message that running scripts is disabled on this system. How can I enable running scripts.

he options to execute PowerShell scripts on a Windows system, either locally or even from remote using PowerShell Remoting, are initially disabled by default in Windows. To be able to execute PowerShell scripts on your system, you need to set the PowerShell execution policy accordingly. To check this, open a PowerShell console or ISE with the user that will run ScriptRunner (the user must have administrative rights), and type:

PS C:\Windows\system32> Get-ExecutionPolicy -List
Scope               ExecutionPolicy
—–               —————
MachinePolicy       Undefined
UserPolicy          Undefined
Process             Undefined
CurrentUser         Undefined
LocalMachine        Undefined

To work with ScriptRunner, the setting on the ScriptRunner system as well as all the target systems should be RemoteSigned or Unrestricted. You can change the execution policy with the command:

Set-ExecutionPolicy –ExecutionPolicy RemoteSigned -Force

This will enable the local execution of all PowerShell scripts on your system for all local users. It will also enable the execution of signed scripts via PowerShell remoting, if PowerShell remoting is enabled.

Alternatively you may allow script execution only for the current user.

Set-ExecutionPolicy -Scope CurrentUser –ExecutionPolicy Unrestricted

For more help about this topic:

Get-Help about_Execution_Policies

Alternatively you may follow the link http://go.microsoft.com/fwlink/?LinkID=135170.

How do I add a target system to the trusted hosts list?

I get the following error message:

Capture.PNG

In order to use PowerShell remoting for targets that are located in another domain, than the ScriptRunner system, you have to add these target systems to the trusted hosts list of the ScriptRunner system.

You may display the trusted host list with the following command: (Open a PowerShell-Console or -ISE as administrator)

Get-Item WSMan:\localhost\Client\TrustedHosts

You may use the following command to add a computer to the trusted hosts list:

Set-Item wsman:localhost\client\TrustedHosts -Value *

for any host or

Set-Item wsman:localhost\client\TrustedHosts -Value *.mycompany.com

for all hosts in mydomain.com or

Set-Item wsman:localhost\client\TrustedHosts -Value mycomputer.mydomain.mycompnay.com

for a single host.

How do I check how many and which users have a ScriptRunner license assigned?

I would like to check the ScriptRunner license subscription status. Where can I find license information?

You can find your user license count and the number of assigned users on the startup screen of the Administrator App.

In Tools -> License you can see a current update of the license status at any time.

In ScriptRunner 2015, the ScriptRunner Service instance is also an (internal) user. Therefore, the LicenseViewer.exe will always show one additional user license used by the ScriptRunner Service.

There is a utility called LicenseViewer.exe, which is located in the subfolder bin of the ScriptRunner installation directory.

You may use this utility to view details of your ScriptRunner license.

For example, you can display the number of users, that use ScriptRunner and their user accounts. Furthermore, you can display the numbers of available user licenses.

How do I enable PowerShell remoting on a target system that is located in another domain?

I cannot run a PowerShell script with ScriptRunner on a target system that is located in another domain.

However, I successfully enabled PowerShell remoting on this target system, as described in another FAQ entry.

What to do?

If you have already enabled PowerShell remoting on the target system, and the target system is pingable from the ScriptRunner system, you may try to establish a telnet session to your target system on your PowerShell port – PowerShell uses port 5985 for PowerShell remoting by default.

Of course it is not possible to open a valid telnet connection to port 5985 at all, because there is no telnet server listening on that port. However, in case there are any firewall rules missing for port 5985, the corresponding error message will show up in your console which you simply would not see in a PowerShell session.

telnet <servername-or-ip> [port-number]

 

Then if you reach the machine using telnet, to check if you can also open a PowerShell session to your remote target, type the following in a PowerShell console or ISE on the ScriptRunner system.

New-PSSession -ComputerName <target-fqdn> -Credential <domain\user>

 

If this fails, you may check the trusted host list.

Get-Item WSMan:\localhost\Client\TrustedHosts

To add the target system to the trusted host list type:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value <target-fqdn>

 

Opening a session can also fail, because your user has not the required rights on the target system.

You may add the user to the group of users which are allowed to use the Microsoft.PowerShell  session configuration. This can be done by typing:

Set-PSSessionConfiguration Microsoft.PowerShell –ShowSecurityDescriptorUI

Alternatively you may add the user to the local group Remote Management Users by typing…

net LOCALGROUP ‚Remote Management Users‘ /ADD <domain\user>

 

We provide a PowerShell script which analyzes your current PowerShell configuration. The script is located in the Support subfolder of the ScriptRunner installation directory. You may run this script on your target system under the user context of your remote user to run some of the checks mentioned above.

How do I enable PowerShell remoting on a target system?

Every time I try to run a script on my remote target system, I get an error message. How do I enable PowerShell scripting on this target system?

Capture.PNG

If you have already enabled PowerShell remoting, check the following:

Is the target machine reachable from the ScriptRunner system?

ping <target ip-address>

or

ping <target NetBIOS name>

 

If you try to establish a cross-domain connection, there are some more drawbacks. For further information follow the link cross-domain session.

Every target system where you want to execute PowerShell scripts with PS Remoting must be configured for PS Remoting to allow remote access from the ScriptRunner system. On Windows Server 2012, Windows PowerShell remoting is enabled by default. You do not need to run it on computers that only send commands. PowerShell includes a very simple cmdlet for enabling PowerShell remoting:

Enable-PSRemoting [-Force] [-SkipNetworkProfileCheck] [-Confirm] [-WhatIf] [ <CommonParameters>]

Open an administrative PowerShell console or ISE on the target system and execute:

Enable-PSRemoting -Force

The Enable-PSRemoting cmdlet performs the following operations:

– Starts the WinRM service.

– Sets the startup type on the WinRM service to Automatic.

– Creates a listener to accept requests on any IP address.

– Enables a firewall exception for WS-Management communications.

– Registers the Microsoft.PowerShell and Microsoft.PowerShell.Workflow session configurations, if it they are not already registered.

– Registers the Microsoft.PowerShell32 session configuration on 64-bit computers, if it is not already registered.

– Enables all session configurations.

– Changes the security descriptor of all session configurations to allow remote access.

– Restarts the WinRM service to make the preceding changes effective.

 

For further information see http://go.microsoft.com/fwlink/p/?linkid=289576.

How do I use script input parameters with ScriptRunner?

My PowerShell script requires input parameters.

How do I display, use and edit values for the input parameters of my script?

In ScriptRunner, you can enter values for script input parameters in the action wizard for creating, editing, or executing an action.

If you check „Cannot be changed at script runtime“, this parameter will not show again when you start the script. Otherwise you can change the value for this script parameter each time you execute the action.

Capture.PNG

Script parameters for wizard interaction will be detected automatically by ScriptRunner if they are declared in the scripts using a leading PowerShell PARAM block. ScriptRunner will additionally read the parameter description from the .PARAMETER entry of a script comment.

Alternatively, for scripts that do not contain a PARAM block, you can declare the required variables directly in the script using a „#ASR“ comment line. Where you previously entered a variable value into the script manually, ScriptRunner will provide this same variable in the PowerShell session before starting the script; the variable will have the value you provided in the wizard of the ScriptRunner app.

For examples with further details to both ways of input declaration, refer to the built-in help for the Scripts view in the Administrator App, or to the sample scripts.

Note: Empty parameters

Sometimes a parameter is optional. If ScriptRunner detects an empty parameter when starting an action, the execution wizard will always show the parameter card before the script is started.

If you leave the value for a parameter like „$para“ blank, ScriptRunner will skip the parameter. In case of „#ASR“ parameter declaration, ScriptRunner will not create the $para variable, a fact you can test in your script with „if ($para)“.

In case of PARAM block declaration, PowerShell makes things special. Due to the fact that PS Remoting will transfer script parameter values as pure list and not by name as dictionary, ScriptRunner can skip only the last empty parameters. Previous gaps in the parameter values have to be filled by $null, to keep the values in sequence with the declared parameters. As a consequence, default values given in the PARAM block will only be used from the end.

Note: PSCredential parameters

ScriptRunner 2015 will parse the PowerShell PARAM block for parameter names, but currently ignores all other kind of information like data types, Mandatory, default values – except for the type [PSCredential]: If a parameter is declared as of type PSCredential, ScriptRunner will use the configured Credential entries for parameter value selection. The PowerShell host will then read the respective credential object from the Windows Credential Manager when the script is started, and will use the credential as parameter value for this parameter.

If you use „#ASR“ parameter declaration, use „Type: PSCredential“ like this:

#ASR Parameter: MyCred Type: PSCredential Description: Credential to use

How does ScriptRunner manage the script repository?

How does ScriptRunner manage the scripts in the data path?

Scripts and their declared input parameters are periodically read from the script library path (ScriptRunner 2014: at startup only). The script path can be configured on Settings wizard. Changes require a restart of the ScriptRunner Service to take effect.

ScriptRunner will automatically create a tag for each subfolder you create in the script path, and attach to each script all the tags reflecting the script’s subfolders.

How should I implement error handling in my script?

I would like to see error messages in the action reports. What should I consider in my script implementation.

Scripting errors should be handled within the PowerShell script.

There are several options to do this. For example, you may use trap, a try/catch block, error variables, etc.

If you output runtime messages or intermediate results in your script, you can check this output later in the report in ScriptRunner and understand the process. However, avoid using Write-Hostin your scripts; depending on the PowerShell host, the messages might not be output at all, so might not show up in the action reports of ScriptRunner.

Instead, use Write-Output for simple output of text or objects, Write-Error to create an error, and Throw to create a terminating error.

How to configure ScriptRunner for an Internet proxy?

In our network we use an Internet proxy server to access the Internet.

What does this mean for ScriptRunner?

The ScriptRunner Windows service will at times try connect to a license server on the Internet, to change or refresh the current license status. Without a valid Internet connection errors will occur („Error accessing Activation Server“), for example after initial installation of ScriptRunner while activating the 30 days trial license (see this FAQ entry), and will refuse any user interaction.

If an Internet proxy must be used in your environment to get access to the Internet, there are different options depending on the situation.

  1. If you run the ScriptRunner Windows service under a specific service account, ScriptRunner will use the proxy settings in the Internet Settings of Internet Explorer of this service account (set e.g. using group policies).
  2. If you run the ScriptRunner Windows service as LocalSystem, ScriptRunner will use the system proxy settings (as configured using e.g. NETSH.EXE).
    Since ScriptRunner is a 32-bit service process, the settings in Wow6432Node for 32-bit processes will be used. Note that for Windows 7 / Windows Server 2008 R2 this requires to use the NETSH.EXE in C:\Windows\SysWOW64!
  3. If you want to set a fixed proxy just for the ScriptRunner Windows service, without any influence on other processes or system settings, you can configure the proxy explicitly for ScriptRunner.
    For this, add a REG_SZ entry to the Registry at
    KEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\AppSphere\ScriptRunnerSvc\General
    with a name of InternetProxy and a value containing your proxy server and port (as usual separated by ‚:‘, as in: proxy.mydomain.com:8080).

 

How to configure ScriptRunner for an Internet proxy?

In our network we use an Internet proxy server to access the Internet.

What does this mean for ScriptRunner?

The ScriptRunner Windows service will at times try connect to a license server on the Internet, to change or refresh the current license status. Without a valid Internet connection errors will occur („Error accessing Activation Server“), for example after initial installation of ScriptRunner while activating the 30 days trial license (see this FAQ entry), and will refuse any user interaction.

If an Internet proxy must be used in your environment to get access to the Internet, there are different options depending on the situation.

  1. If you run the ScriptRunner Windows service under a specific service account, ScriptRunner will use the proxy settings in the Internet Settings of Internet Explorer of this service account (set e.g. using group policies).
  2. If you run the ScriptRunner Windows service as LocalSystem, ScriptRunner will use the system proxy settings (as configured using e.g. NETSH.EXE).
    Since ScriptRunner is a 32-bit service process, the settings in Wow6432Node for 32-bit processes will be used. Note that for Windows 7 / Windows Server 2008 R2 this requires to use the NETSH.EXE in C:\Windows\SysWOW64!
  3. If you want to set a fixed proxy just for the ScriptRunner Windows service, without any influence on other processes or system settings, you can configure the proxy explicitly for ScriptRunner.
    For this, add a REG_SZ entry to the Registry at
    KEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\AppSphere\ScriptRunnerSvc\General
    with a name of InternetProxy and a value containing your proxy server and port (as usual separated by ‚:‘, as in: proxy.mydomain.com:8080).
Installs Scriptrunner on systems running Microsoft Windows 10 ?

Installs Scriptrunner on systems running Microsoft Windows 10 ?

Yes, since Buildversion number 2795 ScriptRunner Service as well as the ScriptRunner Team Apps are running on Windows 10 .

Is it possible to execute other scripting languages than Windows PowerShell?

I would like to execute batch / cmd / vb scripts with ScriptRunner. How can I do this?

If you filter the scripts table for the Non-PS tag, you will find a sample script that allows executing scripts written in other scripting languages through PowerShell, in particular batch, cmd and Visual Basic scripts. You can execute the sample script locally as well as remotely.

To run the sample script, enter the script file path on the remote system. If required enter the command line string within ScriptRunner into the script parameters page of the action wizard.

The script will detect the scripting host to use and whether the script is on the local file system or on a network share. Finally, the script will be executed using the respective scripting host.
Of course you can adopt the code to your needs and extend it to execute more scripting languages.

Is it possible to execute other scripting languages than Windows PowerShell?

I would like to execute batch / cmd / vb scripts with ScriptRunner. How can I do this?

If you filter the scripts table for the Non-PS tag, you will find a sample script that allows executing scripts written in other scripting languages through PowerShell, in particular batch, cmd and Visual Basic scripts. You can execute the sample script locally as well as remotely.

To run the sample script, enter the script file path on the remote system. If required enter the command line string within ScriptRunner into the script parameters page of the action wizard.

The script will detect the scripting host to use and whether the script is on the local file system or on a network share. Finally, the script will be executed using the respective scripting host.
Of course you can adopt the code to your needs and extend it to execute more scripting languages.

Is it possible to execute Visual Basic scripts with ScriptRunner?

How do I execute VB scripts with Scriptrunner? How can I provide values for the input parameters of my VB script from ScriptRunner?

It is possible to execute VB scripts with ScriptRunner. VB scripts execute locally with the Direct Local Execution target.

For Direct Local Execution, ScriptRunner always uses CScript as a runtime environment for VB script execution. For ScriptRunner 2015, the ScriptRunner Service will execute all scripts, so VB scripts will run on the ScriptRunner Service host („Direct Service Execution“) and with the service user account of the ScriptRunner Service.

To execute a VB script on a remote target system, execute a PowerShell script with PS Remoting on the remote system and start the VB script there. Refer to the respective FAQ topic for more information.
You may enter VB script parameters into the input form of the action wizard (see figure beneath), as a space separated list, just like using command line parameters. Note that script parameters that contain space characters must be surrounded by quotation marks.

Capture.PNG

Is it possible to run a script on several target systems concurrently?

There are cases where I would like to run a script on several target systems. For example, to collect status values in a server farm, or to change something on many client systems.

How can I do this with ScriptRunner?

ScriptRunner allows to run a script on multiple targets in a single action, using PowerShell Remoting. For this, select more than one target in the action wizard, by pressing CTRL.

ScriptRunner will then call PowerShell Remoting with the selected target list, and PowerShell will run the script on these systems concurrently (up to a default of 32 target systems).

The „Direct Local Execution“ target does not use PowerShell Remoting and therefore cannot be used with other targets in a single action; use „PS Loopback Remoting“ in this case. PowerShell Remoting does not allow to use targets in parallel that would require different user credentials or a different authentication mechanism. For more details, see the PowerShell documentation for the New-PSSession cmdlet.

Is it possible to run a script on several target systems concurrently?

There are cases where I would like to run a script on several target systems. For example, to collect status values in a server farm, or to change something on many client systems.

How can I do this with ScriptRunner?

ScriptRunner allows to run a script on multiple targets in a single action, using PowerShell Remoting. For this, select more than one target in the action wizard, by pressing CTRL.

ScriptRunner will then call PowerShell Remoting with the selected target list, and PowerShell will run the script on these systems concurrently (up to a default of 32 target systems).

The „Direct Local Execution“ target does not use PowerShell Remoting and therefore cannot be used with other targets in a single action; use „PS Loopback Remoting“ in this case. PowerShell Remoting does not allow to use targets in parallel that would require different user credentials or a different authentication mechanism. For more details, see the PowerShell documentation for the New-PSSession cmdlet.

Is it possible to run scripts with different sets of parameter values at once?

I want to run a PowerShell script with different parameter values at once. Is this possible with ScriptRunner?

You have got the option to define a set of parameter values in the run action wizard (see figure beneath). These set of parameter values will be executed sequentially. Every set of parameter values will write its result into a report of its own.

Capture.PNG

Is it possible to transfer a ScriptRunner license between users?

An employee has left the company. How do I transfer the ScriptRunner user license to another user?

You can lock the license of the former employee, so that it is available for another user. For this, use the tool LicenseViewer.exe in the ScriptRunner Service installation folder.

  • Stop the ScriptRunner service.
  • Open a Command Prompt „as Administrator“, and start LicenseViewer.exe with parameter „-DL“:

LicenseViewer.exe -DL

  • Select the former employee in module „Fullversion“, and click „Lock“.
  • Close LicenseViewer.
  • Start the ScriptRunner service.

The license is now available for the other user.

Is it possible to use IP addresses instead of a FQDN or NetBIOS name for target systems?

I get the following error message:

Capture.PNG

The default / Kerberos does not support IP addresses for authentication. Hence, NTLM is used for authentication, if you specify an ip address for your target system.

If you would like to use NTLM for authentication, the following configuration for PowerShell remoting is required:

  • You have to configure your system for https transport or alternatively add the ip address of the target system explicit to the trusted hosts list of your local system. (see How do I add a target system to the trusted hosts list?)
  • Specify an credential explicitly for the action you would like to execute. (Do not use Current User)

For further information see Microsoft TechNet: about_Remote_Troubleshooting

Ist die ScriptRunner-Oberfläche nur in englischer Sprache verfügbar?

Kann man die Sprache der ScriptRunner-Oberfläche ändern?

Die lokale Spracheinstellung der ScriptRunner Apps kann direkt in der Oberfläche geändert werden.

Zur Zeit stehen die Sprachen Deutsch und Englisch zur Verfügung.

Kann ich auf dem Dashboard verschiedene Ansichten wählen oder das Aussehen anpassen?

Kann ich auf dem Dashboard verschiedene Ansichten wählen oder das Aussehen anpassen?

Das Säulendiagramm auf dem Dashboard bietet einen schnellen Überblick über die Ausführung und den Erfolg von Skripten in einem Zeitintervall. Die Daten lassen sich durch die Filter in den Rubriken-Kacheln und die Tags im Submenü weiter einschränken.

Für das Säulendiagramm gibt es drei verschiedene Ansichten:

  • Einfach: Einzeldarstellung jeder gestarteten Aktion, wobei die Ausführungszeit des Skripts angezeigt wird.
  • Stündlich: Stündlich kumulierte Darstellung, wobei die Anzahl der in dieser Stunde gestarteten Aktionen angezeigt wird.
  • Täglich: Täglich kumulierte Darstellung, wobei die Anzahl der an diesem Tag gestarteten Aktionen angezeigt wird.

In jedem Fall werden Ausführungen mit Fehlern in Rot, und solche ohne Fehler in grün angezeigt.

Kann ich einsehen welche und wie viele Benutzer lizenziert sind?

Kann man in ScriptRunner sehen welche Benutzer eine ScriptRunner-Lizenz verwenden und wie viele Lizenzen noch verfügbar sind?

Die Anzahl der lizenzierten Benutzer und die davon bereits zugeordneten Lizenzen werden bei jedem Start der Administrator App direkt auf dem Startbild angezeigt.

Unter Einstellungen -> Lizenz kann man diesen Lizenzstatus jederzeit aktualisiert abrufen.

Da in ScriptRunner 2015 auch die ScriptRunner Service Instanz bereits als ein Benutzer gezählt wird, weist das Programm LicenseViewer.exe intern immer einen zusätzlichen Benutzer aus.

Im Unterordner bin des ScriptRunner-Installationsverzeichnisses finden Sie das Programm LicenseViewer.exe. Nach dem Start des Programmes werden Ihnen verschiedene Informationen zur Lizenz angezeigt. Im Bereich Module können Sie beispielsweise einsehen, wie viele Benutzer ScriptRunner auf dieser Maschine nutzen und wie viele Benutzer es noch nutzen können. Ebenso können Sie sich die Anmeldenamen der einzelnen lizensierten Benutzer anzeigen lassen.

Kann ich IP-Adressen an Stelle von FQDN bzw. NetBIOS Namen verwenden ?

Ich bekomme folgende Fehlermeldung:
ERROR:  The WinRM client cannot process the request. If the
authentication scheme is different from Kerberos, or if the client
computer is not joined to a domain, then HTTPS transport must be used
or the destination machine must be added to the TrustedHosts
configuration setting.

Die Kerberos-Authentifizierung unterstützt keine IP-Adressen,
dadurch wird standardmäßig die NTLM Authentifizierung verwendet, wenn Sie eine IP-Adresse angeben.

Wenn Sie NTLM-Authentifizierung verwenden, ist das folgende Verfahren für das Remoting erforderlich:
  1. Konfigurieren Sie den Computer für den HTTPS-Transport oder fügen Sie die IP-Adresse des
    Remote Computers der TrustedHosts Liste auf dem lokalen Computer hinzu.
    Siehe „Wie kann ich Zielsysteme zur TrustedHosts Liste hinzufügen?“
  2. Geben Sie explizit ein Benutzerkonto beim Ausführen der Aktion an.
    Dies ist auch dann erforderlich wenn Sie die Aktion als angemeldeter Benutzer ausführen wollen.

Siehe auch: Microsoft TechNet – about_Remote_Troubleshooting

Kann ich mit ScriptRunner auch Skripte anderer Skript-Sprachen als Windows PowerShell ausführen?

Ich möchte mit ScriptRunner nicht nur meine PowerShell-Skripte, sondern auch VB-, Batch- und Cmd-Skripte verwenden. Ist dies möglich?

Unter dem Tag-Filter Non-PS finden Sie ein PowerShell-Beispielskript, das auch das Ausführen von Skripten anderer Skriptsprachen mittels PowerShell erlaubt. Das Skript behandelt Batch- und Cmd-Skripte ebenso wie Visual-Basic Skripte. Das Skript läßt sich sowohl lokal als auch auf einem Remote-System ausführen.

Das Skript ermittelt die zu verwendende Skriptsprache und ob das Skript auf dem System verfügbar ist oder auf einem Netzlaufwerk liegt. Danach wird das Skript unter Verwendung des entsprechenden Scripting Host ausgeführt.

Sie können das Skript natürlich an Ihre Bedürfnisse anpassen und um die Ausführung anderer Skriptsprachen erweitern.

Für das Ausführen auf einem Remote-Zielsystem gelten natürlich die gleichen Voraussetzungen, wie für PowerShell-Remoting im allgemeinen.

Kann ich mit ScriptRunner auch VB-Skripte ausführen?

Ist es möglich mit ScriptRunner auch VB-Skripte auszuführen? Wie funktioniert die Parameterübergabe bei VB-Skripten?

ScriptRunner dient in erster Linie zum Verwalten und Ausführen von PowerShell-Skripten.

Aber ScriptRunner unterstützt auch das Ausführen von VB-Skripten. VB-Skripte können nativ allerdings nur auf dem Zielsystem „Direct Local Execution“ ausgeführt werden. ScriptRunner 2015 führt alle Skripte im ScriptRunner Service aus, VB-Skripte daher auf dem ScriptRunner Service Host („Direct Service Execution„) und unter dem Dienstbenutzeraccount des ScriptRunner Service.

Um VB-Skripte auch auf anderen Zielsystemen auszuführen, ist es notwendig, die Ausführung dort über ein PowerShell-Skript via PowerShell-Remoting zu initiieren (siehe gesondertes FAQ-Topic).

Parameter, die an das Skript übergeben werden sollen, können im Aktions-Assistenten auf der Seite Skript-Parameter eingegeben werden (siehe unten). Die Eingabe der Parameter erfolgt, wie aus der Kommandozeile gewohnt, als Leerzeichen getrennte Liste. Parameter, die Leerzeichen enthalten, müssen in Anführungszeichen stehen.

Capture.PNG

Kann ich PowerShell Skripte parallel auf mehreren Zielsystemen ausführen?

Manche Skripte eignen sich dazu, auf einer ganzen Reihe von Zielsystemen ausgeführt zu werden. Etwa um Statuswerte einer Serverfarm einzusammeln oder Konfigurationsänderungen auf vielen Client-Systemen durchzuführen. Wie macht man das mit ScriptRunner?

ScriptRunner kann mit PowerShell Remoting Skripte parallel auf mehreren Zielsystemen ausführen. Man wählt dazu für eine Aktion im Assistenten einfach mehrere Zielsysteme aus, per Mausklick mit STRG.

ScriptRunner erstellt dann ein PowerShell Remoting Kommando mit der Liste der ausgewählten Zielsysteme, die die PowerShell daraufhin (bis zu einer Obergrenze von standardmäßig 32 Zielsystemen) gleichzeitig abarbeitet.

Das spezielle Zielsystem „Direct Local Execution“ verwendet kein PowerShell Remoting und lässt sich daher nicht mit anderen Zielsystemen kombinieren. Verwenden Sie „PS Loopback Remoting“, wenn das Skript gleichzeitig auch lokal ausgeführt werden soll. PowerShell Remoting erlaubt es auch nicht, in einem Kommando Zielsysteme zu kombinieren, die unterschiedliche Benutzerkonten oder unterschiedliche Authentifizierungseinstellungen benötigen (siehe auch PowerShell Dokumentation zum New-PSSession Kommando).

Kann ich Skripte mit unterschiedlichen Parameterbelegungen ausführen?

Bei manchen Skripten ist es sinnvoll sie kurz nacheinander mit verschiedenen Parameterwerten auszuführen.

Ist das mit ScriptRunner möglich?

Hierzu bietet Ihnen ScriptRunner beim Ausführen einer Aktion, die Möglichkeit auf der Parameter Karte mehrere Sets von Parameterwerten zu definieren.

Beim Abfragen von Festplatteneigenschaften, Diensten, Prozessen o.ä. ist es sinnvoll diese Informationen gezielt abzufragen.

Beim mitgelieferten Beispielskript „DiskInfo“ können Sie z.B. zuerst die Eigenschaften der primären und danach der sekundären Festplatte ermitteln.

ScriptRunner führt das Skript sequenziell pro Set von definierten Parameterwerten aus, und liefert jeweils einen Bericht.

Kann ich Skripte parallel auf mehreren Zielsystemen ausführen?

Manche Skripte eignen sich dazu, auf einer ganzen Reihe von Zielsystemen ausgeführt zu werden, etwa um Statuswerte einer Serverfarm einzusammeln oder Konfigurationsänderungen auf vielen Client-Systemen durchzuführen.

Wie macht man das mit ScriptRunner?

ScriptRunner kann mit PowerShell Remoting Skripte parallel auf mehreren Zielsystemen ausführen. Man wählt dazu für eine Aktion im Assistenten einfach mehrere Zielsysteme aus, per Mausklick mit STRG.

ScriptRunner erstellt dann ein PowerShell Remoting Kommando mit der Liste der ausgewählten Zielsysteme, die die PowerShell daraufhin (bis zu einer Obergrenze von standardmäßig 32 Zielsystemen) gleichzeitig abarbeitet.

Das spezielle Zielsystem „Direct Local Execution“ verwendet kein PowerShell Remoting und lässt sich daher nicht mit anderen Zielsystemen kombinieren; verwenden Sie „PS Loopback Remoting“, wenn das Skript gleichzeitig auch lokal ausgeführt werden soll. PowerShell Remoting erlaubt es auch nicht, in einem Kommando Zielsysteme zu kombinieren, die unterschiedliche Benutzerkonten oder unterschiedliche Authentifizierungseinstellungen benötigen (siehe auch PowerShell Dokumentation zum New-PSSession Kommando).

Kann ich VB-Skripte auch auf anderen Zielsystemen ausführen?

Wie kann ich VB-Skripte auch auf anderen Zielsystemen ausführen?

Unter dem Tag-Filter Non-PS finden Sie ein PowerShell-Beispielskript, das auch das Ausführen von Skripten anderer Skriptsprachen mittels PowerShell erlaubt. Das Skript behandelt Batch- und Cmd-Skripte ebenso wie Visual-Basic Skripte. Das Skript läßt sich sowohl lokal als auch auf einem Remote-System ausführen.

Das Skript ermittelt die zu verwendende Skriptsprache und ob das Skript auf dem System verfügbar ist oder auf einem Netzlaufwerk liegt. Danach wird das Skript unter Verwendung des entsprechenden Scripting Host ausgeführt.
Sie können das Skript natürlich an Ihre Bedürfnisse anpassen und um die Ausführung anderer Skriptsprachen erweitern.

Für das Ausführen auf einem Remote-Zielsystem gelten natürlich die gleichen Voraussetzungen, wie für PowerShell-Remoting im allgemeinen.

Kann man eine ScriptRunner-Lizenz auf einen anderen Benutzer übertragen?

Ein Mitarbeiter ist aus unserem Unternehmen ausgeschieden. Wir möchten nun dessen Benutzerlizenz auf einen anderen Mitarbeiter übertragen.

Sie können die Lizenz des ausgeschiedenen Mitarbeiters sperren, so dass sie für einen anderen Mitarbeiter zur Verfügung steht. Hierzu verwenden Sie das mitgelieferte Tool LicenseViewer.exe (im Installationsverzeichnis des ScriptRunner Service).

  • Beenden Sie den ScriptRunner Dienst.
  • Öffnen Sie eine Eingabeaufforderung „als Administrator“, und starten Sie LicenseViewer.exe mit dem Parameter „-DL“:

LicenseViewer.exe -DL

  • Wählen Sie den ausgeschiedenen Mitarbeiter im Modul „Fullversion“, und klicken Sie auf „Sperren“.
  • Schließen Sie den LicenseViewer.
  • Starten Sie den ScriptRunner Dienst neu.

Die Lizenz steht jetzt für den neuen Mitarbeiter zur Verfügung.

Kann ScriptRunner auf Windows 10 installiert werden?

Können die ScriptRunner Team Apps und der ScriptRunner Service auf Rechnern mit Microsoft Windows 10 installiert werden?

Ja, sowohl die ScriptRunner Team Apps, als auch der ScriptRunner Dienst sind ab der Version 2015R2 (Buildnummer 2795) mit Microsoft Windows 10 kompatibel.

Meine Scripte verwenden unterschiedliche PS Module, kann ich diese Remote aufrufen?

Vor der Ausführung meines Skripts müssen verschiedene PowerShell-Module importiert werden.

Sie haben die Möglichkeit die benötigten Module mit Import-Module in Ihrem Skript zu importieren.
ScriptRunner bietet Ihnen aber auch die Möglichkeit beim Erstellen, Bearbeiten oder Ausführen einer Aktion, benötigte PowerShell-Module kommagetrennt anzugeben.

Diese Module werden dann vor dem eigentlichen Ausführen der Aktion importiert.

My PowerShell script uses several PS modules. How does this work in ScriptRunner?

Several PowerShell modules must be imported. How is this done with ScriptRunner?

You can use the Import-Module cmdlet in your script.

However, ScriptRunner provides the option to specify modules, that must be imported, in the action wizard (see figure beneath). Modules must be listed comma separated. These modules will be imported before the associated script is actually executed.

Capture.PNG

Nach einem Windows 10 Upgrade funktioniert die ScriptRunner Deinstallation bzw. das Update nicht

Nach dem ich ein Upgrade meines Betriebssystems auf Windows 10 durchgeführt habe, kann ich die Deinstallation von ScriptRunner nicht mehr ausführen.

Wie kann ich ScriptRunner deinstallieren bzw. updaten?

Die Unistaller von ScriptRunner sind vor der Version mit der Buildnummer 2795 nicht mit Windows 10 kompatibel. Um dennoch ein Update von ScriptRunner durchzuführen muss vor der Installation einer neuen ScriptRunner Version der jeweilige Registrierungsschlüssel im Registrierungs-Editor gelöscht werden.

Für den ScriptRunner Dienst ist dies der Schlüssel ‚AppSphere ScriptRunnerSvc‘ und für die ScriptRunner Team Apps der Schlüssel ‚AppSphere ScriptRunnerTeamEdition‘ im Registrierungspfad ‚HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall‘.

Bei der Installation des ScriptRunner Dienstes muss noch beachtet werden, dass dieser vor der Update-Installation angehalten werden muss. Dazu startet man die Dienste-Verwaltung mit ’services.msc‘, wählt den Dienst ‚AppSphere ScriptRunner Service‘ aus und beendet diesen.

Jetzt kann die neue Version von ScriptRunner ganz normal installiert werden.

Die Uninstaller von ScriptRunner sind ab der Version mit der Buildnummer 2795 mit Windows 10 kompatibel.

Permission denied – how can I reset the ScriptRunner Administrator role authorization settings?

Maybe I entered something wrong into the Authorization group settings for the Administrator role – anyway, now the Administrator App every time shows a message „ScriptRunner Administration: Permission denied.“

How can I get back into the Administrator App to correct the ScriptRunner Administrator role settings?

ScriptRunner will always grant local administrative access to local Administrators.

This is in addition to the Authorization settings for the ScriptRunner Administrator role, which also grant remote access.

This means, start the Administrator App locally on the ScriptRunner Service host and „as administrator“, and fix the Authorization settings of the Administrator role.

Permission denied after adding a user to the Authorization group

I added a new user to the permission group in Active Directory which we use in ScriptRunner Authorization to grant access.

However, the user still receives „Permission denied“ errors after starting a ScriptRunner App.

After you add a user to a group in Active Directory (or a local Windows group), Windows may not reflect this immediately for Integrated Windows Authentication. As a consequence, ScriptRunner will reject the user as „unauthorized“.

The user will have to logout from Windows and re-logon for the new group membership to take effect.

Rename, move, or delete a script in the file system

What happens if I rename, move or delete a script in the file system which is used in ScriptRunner?

ScriptRunner 2015 scans the script library in the script path regularly, and will detect renamed or moved scripts as new scripts.

Likewise, previous scripts that were renamed, moved, or deleted will be removed from the ScriptRunner scripts list, and if the script is referenced by an action, this action gets invalid because the reference into the script library is invalid. A red exclamation mark appears besides the action on the action table view, and a ScriptRunner status warning message will appear in the Windows Application Eventlog.

An invalid action can not be edited or executed anymore.

Warum kann ich keine Zielsysteme importieren?

Ich möchte meine Zielsysteme importieren die Schaltfläche wird aber nicht aktiv.

Für den Import der Zielsysteme wird HTML5 genutzt, im Internet Explorer 9 wird die HTML5 File API aber nicht unterstützt.

Benutzen Sie einen neueren Browser, um Zielsysteme zu importieren.

Was bedeutet „Direct Local Execution“ oder „Direct Service Execution“?

In ScriptRunner gibt es bei den Zielsystemen einen Eintrag „[.] Direct Local Execution“ oder auch „Direct Service Execution“. Was kann ich mit diesem Zielsystem tun?

Der Eintrag „Direct Local Execution“ bezeichnet das lokale System, auf dem ScriptRunner installiert ist. Wenn Sie eine Aktion mit diesem Zielsystem in ScriptRunner 2014 starten, wird das Skript direkt in einem lokalen PowerShell Host und unter dem aktuellen Benutzer ausgeführt. In ScriptRunner 2015 werden Skripte vom ScriptRunner Service ausgeführt; „Direct Local Execution“ bedeutet daher, dass das Skript direkt auf dem ScriptRunner Service Host und unter dem Dienstbenutzerkonto des ScriptRunner Service ausgeführt wird, und wird hier auch als „Direct Service Execution“ bezeichnet.

Mit „Direct Local Execution“ können Sie also Ihr lokales System für ScriptRunner gleichzeitig sofort auch als Zielsystem benutzen, ohne dass Sie PowerShell Remoting einrichten müssen. Dieser Eintrag eignet sich daher sehr gut für eine initiale Testphase.

Im Gegensatz dazu initiiert das Zielsystem „PS Loopback Remoting“ eine PowerShell Remoting Sitzung auf das lokale System (Microsoft nennt dies eine Loopback Session, von einem Rechner auf sich selbst) und startet dann das Skript auf dem lokalen System in dieser PowerShell-Sitzung, wobei Sie auch ein anderes Benutzerkonto verwenden können. Hierfür müssen Sie dann allerdings PowerShell Remoting auf dem lokalen System (ScriptRunner Service Host) eingerichtet haben, etwa über den ScriptRunner Installer oder das PowerShell-Kommando Enable-PSRemoting.

Was bedeutet „PowerShell Loopback Remoting“?

In ScriptRunner gibt es bei den Zielsystemen einen Eintrag „[localhost] PS Loopback Remoting“.

Was kann ich mit diesem Zielsystem tun?

Der Eintrag „PS Loopback Remoting“ bezeichnet das lokale System, auf dem ScriptRunner 2014 bzw. der ScriptRunner 2015 Service installiert ist.

Wenn Sie eine Aktion mit diesem Zielsystem starten, wird eine PowerShell Remoting Sitzung auf das lokale System initiiert (Microsoft nennt dies eine Loopback Session, von einem Rechner auf sich selbst), und das Skript wird in dieser Sitzung auf dem lokalen System gestartet.

Auf diese Weise können Sie also Ihr lokales System (ScriptRunner 2014) bzw. Ihren ScriptRunner Service Host (ScriptRunner 2015) gleichzeitig auch als Zielsystem benutzen, unter voller Nutzung der PS Remoting Funktionalität, also etwa unter einem anderen Benutzerkonto. Dieser Eintrag eignet sich daher auch sehr gut für die initiale Testphase.

Sie müssen hierfür nur PowerShell Remoting auf dem lokalen System eingerichtet haben, etwa über den ScriptRunner Installer oder mit dem PowerShell-Kommando Enable-PSRemoting.

Im Gegensatz dazu führt das Zielsystem „Direct Local Execution“ (unter ScriptRunner 2015 auch „Direct Service Execution“) das Skript direkt in einem lokalen PowerShell Host aus, ganz ohne PS Remoting, dafür aber immer nur unter dem aktuellen Benutzer (ScriptRunner 2015: Dienstbenutzerkonto des ScriptRunner Service).

Was bedeutet Online-Aktivierung im Startbildschirm bzw. Aktivieren unter Einstellungen->Lizensierung ?

Was benötige ich zum Aktivieren der ScriptRunner Lizenz?

Zur Aktivierung Ihrer Lizenz benötigen Sie einen Aktivierungsschlüssel, diesen erhalten Sie nach dem Kauf von ScriptRunner.

Nach der Eingabe der erforderlichen Daten und des Aktivierungsschlüssels werden die Daten an unseren Lizenz-Server übertragen und die Lizenz aktiviert.

Nach dem erfolgreichen Aktivieren der Lizenz steht Ihnen ScriptRunner uneingeschränkt zur Verfügung.

Bitte beachten Sie, dass zum Aktivieren der Lizenz eine Internetverbindung bestehen muss!

Was muss ich bei einem Backup / Restore der ScriptRunner Konfiguration beachten?

Damit die Skripte und die angelegten Konfigurationselemente (Aktionen, Zielsysteme etc.) bei einem eventuellen Systemproblem nicht verloren gehen, möchte ich ein Backup der Konfiguration erstellen können. Was muss ich dabei beachten?

Der Zustand der ScriptRunner-Anwendung wird nach der initialen Installation durch die folgenden Dateien und Systemzustände bestimmt:

  1. Skript-Dateien in der Skript-Bibliothek
  2. ScriptRunner Konfigurations- und Bewegungsdaten
  3. hinterlegte ScriptRunner Benutzerkonten in der Windows Anmeldeinformationsverwaltung

Die beiden ersten Elemente können Sie problemlos sichern, wenn Sie ScriptRunner zuvor stoppen. Für ScriptRunner 2014 liegen die Konfigurations- und Bewegungsdaten für einen Benutzer in

%AppData%\AppSphere\ScriptRunner

Für ScriptRunner 2015 liegen sie zentral auf dem ScriptRunner Service Host in

%ProgramData%\AppSphere\ScriptRunnerSvc

Nach der Wiederherstellung des Windows-Systems und ggf. Neuinstallation von ScriptRunner können Sie diese Daten wiederherstellen (auch hier ScriptRunner unbedingt zuvor stoppen).

Die hinterlegten Benutzerkonten in der Windows Anmeldeinformationsverwaltung (ScriptRunner 2014: des jeweiligen Benutzers, ScriptRunner 2015: des Dienst-Accounts des ScriptRunner Service) müssen Sie getrennt sichern und wiederherstellen.

Alternativ können Sie die Einträge nach der Wiederherstellung der Konfigurations- und Bewegungsdaten auch von ScriptRunner wieder anlegen lassen, indem Sie jeden Benutzerkonto-Eintrag in der Oberfläche öffnen, das zugehörige Passwort eintragen und OK klicken. (ScriptRunner hat die Passwörter wirklich nicht nochmal selbst irgendwo.)

Beachten Sie: Die ScriptRunner Lizenz ist mit einem Kopierschutz ausgestattet und gilt nach Produktaktivierung nur auf dem ursprünglichen System. Für eine Migraion auf ein neues System wenden Sie sich bitte an unseren Support.

Was passiert beim Skript-Import?

Wie werden die von ScriptRunner verwalteten Skripte eingelesen / gefunden?

ScriptRunner liest die Skripte regelmäßig aus dem Datenpfad der Skript-Bibliothek ein (ScriptRunner 2014: nur beim Starten) und versieht sie mit Tags. Diese initial zugewiesenen Tags entsprechen den Ordnernamen der Unterordner im Datenpfad. Gleichzeitig werden die Eingabe-Parameter des Skripts ermittelt.

Der Datenpfad kann über das Menu Einstellungen geändert werden, Änderungen wirken sich aber erst beim nächsten Start des ScriptRunner Service aus.

Was passiert wenn ich ein Skript im Dateisystem umbenenne, verschiebe oder lösche?

Wie wirkt sich das Umbenennen, Verschieben oder Löschen von Skripten im Datenpfad aus?

ScriptRunner 2015 überwacht die Skriptbibliothek im Datenpfad und liest regelmäßig die dort liegenden Skriptdateien ein. Umbenannte oder verschobene Skripte werden als neue Skripte eingelesen.

Die vorherigen, jetzt nicht mehr vorhandenen Skripte werden, wie auch nach dem Löschen eines Skripts, aus der Liste der Skripte entfernt. Wird ein solches Skript in einer Aktion verwendet, wird diese Aktion ungültig, weil seine Referenz auf die Skript-Bibliothek nicht mehr gültig ist. ScriptRunner markiert solche ungültigen Aktionen mit einem roten Warnzeichen in der Tabelle der Aktionen und schreibt entsprechende Warnungen in die Windows Ereignisanzeige (Application Eventlog).

Ungültige Aktionen können nicht mehr verwendet und nur noch gelöscht werden.

Welche Einschränkungen ergeben sich bei der Verwendung von Internet Explorer 9?

Ich kann keine aktuelle Version des Internet Explorers installieren. Welche Einschränkungen habe ich dadurch in ScriptRunner?

Die Einschränkungen im Internet Explorer 9 betreffen in erster Linie den Import von Zielsystemen, da die HTML5 File API von IE 9 nicht unterstützt wird.

Darüber hinaus kann es mit IE 9 zu Darstellungs- und Verhaltensunterschieden gegenüber aktuellen Versionen des Internet Explorers kommen.

Welche Einschränkungen hat die Evaluations-Version von ScriptRunner?

Ist die Evaluations-Version im Funktionsumfang eingeschränkt?

Die Evaluations-Version hat den gleichen Funktionsumfang wie die Vollversion. Lediglich Ihre Gültigkeit ist auf 30 Tage nach Installation begrenzt.

Im Laufe dieser 30 Tage können Sie durch Aktivierung jederzeit in eine Vollversion wechseln. Dabei bleiben Ihre konfigurierten Aktionen und Einstellungen vollständig erhalten.

Welche Einschränkungen hat die Freeware-Version?

Der Evaluationszeitraum von ScriptRunner ist abgelaufen. Was sind die Einschränkungen, wenn ich die Freeware-Lizenz aktiviere?

Die Freeware-Lizenz ist für ein Jahr gültig und beschränkt die Ausführung von Aktionen: Es können nur noch die ersten zehn erstellten Aktionen ausgeführt werden.

In ScriptRunner 2015 ist die Freeware-Version außerdem auf einen einzelnen Benutzer beschränkt und enthält daher keine Teamfunktionen.

Welche Informationen finde ich in einem Bericht?

Welche Informationen sehe ich wenn ich mir den Bericht einer Aktion ansehe?

Oben im Kopf des Anzeigefensters werden

  • der Name der Aktion, der Zeitpunkt der Ausführung und der Ausführende,
  • das Zielsystem und das für den Zugriff verwendete Benutzerkonto (PS Remoting), und
  • das Ergebnis (Fehleranzahl)

angezeigt. Danach folgen ggf. die übergebenen Parameter.

Im Bericht sehen Sie verschiedene grundsätzliche Angaben zum Zielsystem und die Ausgaben des Skripts während der Ausführung. Im Fehlerfall sind hier auch die detaillierten Fehlermeldungen aufgeführt.

Zuletzt wird die Ausführungsdauer und der Zeitpunkt angegeben, an dem die Ausführung abgeschlossen wurde.

Welches Authentifizierungsverfahren soll ich auswählen?

Für eine Aktion kann im Assistenten auf der Benutzerkonto-Seite eine Einstellung für den PS Remoting Authentifizierungsmechanismus ausgewählt werden.

Welche Einstellung soll ich auswählen?

Dieser Wert gibt das Verfahren an, mit dem die Authentifizierung des Remoting Benutzerkontos auf dem Zielsystem durchgeführt wird. Die Default-Einstellung sollte in den allermeisten Fällen korrekt sein, z.B. wird innerhalb einer Domäne automatisch Kerberos verwendet. Wenn das Zielsystem in einer anderen Windows-Domäne ist, kann man auch Negotiate verwenden, das neben Kerberos auch NTLM Authentifizierung beinhaltet.

Die Einstellung CredSSP wird nur benötigt für Credential Security Service Provider Authentifizierung, wenn das Skript das Benutzerkonto weiter delegieren können muss und dies auf dem Zielsystem entsprechend eingerichtet wurde. Allerdings gibt die Microsoft TechNet Dokumentation für das New-PSSession Cmdlet hierzu folgenden Hinweis:

“Caution: Credential Security Support Provider (CredSSP) authentication, in which the user’s credentials are passed to a remote computer to be authenticated, is designed for commands that require authentication on more than one resource, such as accessing a remote network share. This mechanism increases the security risk of the remote operation. If the remote computer is compromised, the credentials that are passed to it can be used to control the network session.”

Die übrigen Werte werden normalerweise für PowerShell Remoting zwischen Windows-Systemen nicht benötigt. Die Microsoft-Dokumentation in der MSDN (Microsoft Developer Network) enthält eine vollständige Beschreibung aller Werte, allerdings nur in englischer Sprache.

What are the limitations if I use Internet Explorer 9?

I am not able to install a current version of the Internet Explorer, and have to use IE9.

The feature limitations when running ScriptRunner with IE 9 chiefly affect the import of target systems. This is because IE 9 does not support the HTML5 File API.

Furthermore, issues related to the appearance and behavior of ScriptRunner may appear: The look and feel of the ScriptRunner GUI shown in IE 9 may be different to current IE Versions.

What are the limitations of the freeware version?

The evaluation periode of my ScriptRunner installation is expired. What are the limitations of the freeware version?

The freeware license is valid for one year. It limits the execution of scripts to a maximum of ten actions. This means, that only the ten first actions you have created will be executable. In order to run another action you have to remove one of your executable actions.

ScriptRunner 2015 limits the freeware license to a single user, so all team functionality is disabled.

What does „Direct Local Execution“ or „Direct Service Execution“ mean?

In ScriptRunner there is a target entry named “[.] Direct Local Execution” or „Direct Service Execution“. What is this target good for?

The target “Direct Local Execution” is the local system where ScriptRunner is installed. If you start an action with this target selected in ScriptRunner 2014, the script will run directly on the local system in a local PowerShell host, and in the context of the current user. In contrary, ScriptRunner 2015 will execute scripts in the ScriptRunner Service; therefore, „Direct Local Execution“ means running the script locally on the ScriptRunner Service host and with the service user account of the ScriptRunner Service, so we also call it „Direct Service Execution“.

With „Direct Local Execution“ you can utilize your ScriptRunner machine immediately as a target system, without enabling PowerShell Remoting. This is especially useful during initial testing.

There is another target, “PS Loopback Remoting”, that will run the script on the local system as well. However in this case, PowerShell will initiate a PS Remoting session to the local system (aka “loopback session” as called by Microsoft), and the script will run in this session on the local system. With „PS Loopback Remoting“ you have the additional option to run the script under different user credentials. Of course this target requires PS Remoting to be enabled on your ScriptRunner system / ScriptRunner Service host, e.g. using the respective option of the ScriptRunner installer or the PowerShell Enable-PSRemoting cmdlet.

What does „PS Loopback Remoting“ mean?

In ScriptRunner there is a target entry “[localhost] PS Loopback Remoting”.

What is this target good for?

The target “PS Loopback Remoting” is the local system where ScriptRunner 2014 / the ScriptRunner 2015 Service is installed. If you start an action with this target configured, PowerShell will initiate a PS Remoting session to the local system (aka “loopback session” as called by Microsoft), and the script will run in this session on the local system.

This way you can utilize your local ScriptRunner 2014 machine / ScriptRunner 2015 Service host as a target system at the same time, using full PS Remoting capabilities – e.g., with a different remoting credential. This is also useful during initial testing.

Of course this requires PS Remoting to be enabled on your ScriptRunner system, e.g. using the ScriptRunner installer or the PowerShell Enable-PSRemoting cmdlet.

There is another target, “Direct Local Execution” (also „Direct Service Execution“ in ScriptRunner 2015), that will run the script directly in a local PowerShell host, without using PS Remoting. However in this case, the script can run as current user only (which is the service user account of the ScriptRunner Service in ScriptRunner 2015).

What does Online Activation on the start banner / license view mean?

What do I need to activate the full version of ScriptRunner?

In order to activate the full license of ScriptRunner, you need an activation key, which you obtain when you purchase ScriptRunner. You can purchase ScriptRunner in ouronline shop.

Start ScriptRunner, click on the Online Activation… button on the start banner or go to Settings->License, and complete the required input form. This will unlock the Activate button. A click on the Activate button will send the information to the activation server, which will verify your activation key. This requires an online connection, of course.

If you are not able to access the Internet with your ScriptRunner system, please contact our support team.

What information do I have to provide with my ScriptRunner online support ticket?

What information do I have to provide with my ScriptRunner online support ticket?

ScriptRunner 2015 log files are stored in %PROGRAMDATA%\AppSphere\ScriptRunner\Log on the ScriptRunner Service host.

ScriptRunner also writes important status messages into the Windows Application Eventlog.

To receive informed support, you should provide:

  • Version of the operating system,
  • Version of your browser,
  • Detailed description of what went wrong, and what you did to get there, or tried to achieve,
  • The application log file.

Also, a screenshot of the UI can be very helpful, especially if there are error messages.

What information do I have to provide with my ScriptRunner online support ticket?

What information do I have to provide with my ScriptRunner online support ticket?

ScriptRunner 2015 log files are stored in %PROGRAMDATA%\AppSphere\ScriptRunner\Log on the ScriptRunner Service host.

ScriptRunner also writes important status messages into the Windows Application Eventlog.

To receive informed support, you should provide:

  • Version of the operating system,
  • Version of your browser,
  • Detailed description of what went wrong, and what you did to get there, or tried to achieve,
  • The application log file.

Also, a screenshot of the UI can be very helpful, especially if there are error messages.

ScriptRunner 2014 log files are stored in %APPDATA%\AppSphere\ScriptRunner\Log.

Where do I find more sample scripts?

Is there a repository of sample scripts?

You may browse to the Microsoft Script Center. You will find a huge repository of scripts and a lot of other scripting related topics there.

Where do I find technical information and manuals?

Where can I get more technical information about ScriptRunner, e.g., installation procedure, product overview, or user manuals?

More information and the documentation for ScriptRunner 2015 can be found in the subfolder doc of the ScriptRunner installation directory as well as on the ScriptRunner website.

Where do I find the ScriptRunner log files?

ScriptRunner support asked me for the product log files? Where are these files stored?

The ScriptRunner 2015 log files are stored in %PROGRAMDATA%\AppSphere\ScriptRunner\Log on the ScriptRunner Service host.

ScriptRunner will also write important status information to the Windows Application Eventlog.

Where does ScriptRunner store the remoting credentials?

Where does ScriptRunner store the remoting credentials I entered into a Credential configuration?

ScriptRunner does not keep any credential passwords, but stores configured user credentials in Windows Credential Manager of the local operating system.

ScriptRunner will never read the entries e.g. to show the passwords in the UI. Instead, a reference to the required entries will be given to the PowerShell host when a script needs to be executed. Likewise, if you want to change a configured credential entry in ScriptRunner, you will every time have to provide the password again.

The ScriptRunner entries in the Windows Credential Manager start with prefix „ASR:“. If you delete such an entry from Credential Manager, the credential can no longer be used in ScriptRunner without error. To re-create a credential in Windows Credential Manager,

  • open the credential entry in ScriptRunner,
  • input the password,
  • click OK to store the credential to Windows Credential Manager.

In ScriptRunner 2014, the credentials were stored as the current Windows user, so you could see them in your Windows Credential Manager store. However, in ScriptRunner 2015, the credentials are stored by the ScriptRunner Service and therefore into the Windows Credential Manager instance of the service user account of the ScriptRunner Service, so you won’t see them as a normal Windows user anymore.

Which authentication method should I select?

The action wizard in ScriptRunner has an authentication method setting on the Credential page.

Which method should I select?

This value specifies the mechanism that is used to authenticate the remoting credentials on the target system. The Default setting should work in all normal cases, and will automatically use Kerberos if the target is in the same domain as your ScriptRunner system. If your target is a windows system in another domain, Negotiate should also do the trick; Negotiate contains, besides Kerberos, also NTLM authentication.

The CredSSP setting is intended for Credential Security Service Provider authentication, if the script needs to delegate remoting credentials for a second hop. However, note the following caveat from Microsoft TechNet New-PSSession cmdlet documentation:

“Caution: Credential Security Support Provider (CredSSP) authentication, in which the user’s credentials are passed to a remote computer to be authenticated, is designed for commands that require authentication on more than one resource, such as accessing a remote network share. This mechanism increases the security risk of the remote operation. If the remote computer is compromised, the credentials that are passed to it can be used to control the network session.”

These are the values that are useful for PowerShell Remoting between Windows systems. The Microsoft documentation in the MSDN (Microsoft Developer Network) library at http://go.microsoft.com/fwlink/?LinkID=144382 lists all valid values:

 

Basic The connection is made using Basic authentication. This field is introduced in Windows PowerShell 2.0.
Credssp The connection is made using Credential Security Service Provider (CredSSP) authentication, which allows the user to delegate credentials. This type of authentication is designed for commands that require a second hop, that is, they run on one computer, but then they connect to other computers to collect data or run additional commands. This field is introduced in Windows PowerShell 2.0.
Default The connection is made using the authentication mechanism specified by the transport being used. In the case of Web Services for Management (WSMan) protocol, either Negotiate or Kerberos is used. This field is introduced in Windows PowerShell 2.0.
Digest The connection is made using Digest authentication. Digest authentication operates much like Basic authentication. However, unlike Basic authentication, Digest authentication transmits credentials across the network as a hash value, also known as a message digest. The user name and password cannot be deciphered from the hash value. In comparison, Basic authentication sends a Base 64 encoded password, essentially in clear text, across the network. This field is introduced in Windows PowerShell 2.0.
Kerberos The connection is made using Kerberos authentication.
Negotiate The connection is made using Kerberos or NT LAN Manager (NTLM). The server uses Kerberos to authenticate a domain account and NTLM for local computer accounts. The user name should be specified in the form domain\username for domain users or servername\username for a local users on a server computer. This field is introduced in Windows PowerShell 2.0.
NegotiateWithImplicitCredential The connection is made using the credentials cached on the PSSession computer. This field is introduced in Windows PowerShell 2.0.
Which information is provided within the action reports?

What for are the reports used?

The report header displays

  • the name of the action, the starting time, and the user who started the action,
  • the target system and user credential for the access (PS Remoting),
  • and finally the short result of the action (success / error count).

The next section displays the assigned input parameters of the associated script.

The last section contains the actual execution report. Here you will find some general information about the target system, and the output of the script execution. If an error occured you will also find the detailed error messages here.

Finally, the end time and the run-time is shown.

Why is the Import Button on the target page disabled?

I can not import target systems!

ScriptRunner uses the HTML5 File API to import target system. This API is not supported by InternetExplorer 9. You should update at least to IE 10 to be able to import target systems.

Wie aktiviere ich die Ausführung von PowerShell Skripten auf meinem System?

Ich sehe folgende Fehlermeldung nach dem Starten eines Skripts mit ScriptRunner. Wie kann ich die Ausführung von Skripten aktivieren?

ScriptRunner_error_aktivateScripts.png

Die Ausführung von PowerShell-Skripten ist in Windows zunächst aus Sicherheitsgründen deaktiviert. Ihre Einstellung können Sie sich mit dem PowerShell-Befehl Get‑ExecutionPolicy anzeigen lassen. Öffnen Sie dazu eine PowerShell-Konsole als Administrator.

PS C:\Windows\system32> Get-ExecutionPolicy -List

Scope                              ExecutionPolicy

—–                              —————

MachinePolicy                      Undefined

UserPolicy                         Undefined

Process                            Undefined

CurrentUser                        Undefined

LocalMachine                       Undefined

 

Skripten für alle Benutzer auf dem System können Sie am einfachsten aktivieren mit dem folgenden Befehl:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force

Sie können die Ausführung von Skripten auch nur für einzelne Benutzer aktivieren und beispielsweise nur signierte Skripte für die Remoteausführung zulassen. Öffnen Sie dazu unter dem entsprechenden Benutzerkontext eine PowerShell-Konsole und verwenden den Befehl:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

Ausführliche Informationen erhalten Sie mit dem Befehl:’Get-Help about_Execution_Policies‘ oder unter http://go.microsoft.com/fwlink/?LinkID=135170

Wie aktiviere ich die Ausführung von PowerShell-Skripten auf einem entfernten Zielsystem?

Ich bekomme eine Fehlermeldung, wenn ich versuche mit ScriptRunner ein Skript auf einer Remote-Maschine auszuführen.

Capture.PNG

Wie kann ich den Fehler beheben?

Stellen Sie sicher, dass das Zielsystem in der Liste der TrustedHosts eingetragen ist. Verwenden sie dazu den Befehl:

Get-Item WSMan:\localhost\Client\TrustedHosts

Um das Zielsystem in diese Liste einzutragen verwenden sie folgenden Befehl:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value <computer>.<domain>.<first-level-domain>

Stellen Sie sicher, dass der Benutzer, unter dem Sie das PowerShell-Skript ausführen möchten eine PowerShell-Sitzung zu dem Zielsystem aufbauen darf. Dazu können Sie den unten beschriebenen Befehl in der PowerShell-Konsole oder -ISE des Zielsystems verwenden – Sie werden dort aufgefordert Ihr Kennwort einzugeben.

PS C:\Windows\system32>New-PSSession -Credential <mydomain>\<user>

Id Name            ComputerName    State         ConfigurationName     Availability
— —-            ————    —–         —————–     ————
1 Session1        localhost       Opened        Microsoft.PowerShell     Available

PS C:\Windows\system32> Remove-PSSession -Id 1

Sollte dies nicht gelingen können Sie den Benutzer zu der Benutzergruppe hinzufügen, die die Microsoft.PowerShell Sitzungskonfiguration verwenden darf. Verwenden Sie dazu den folgenden Befehl und fügen den Benutzer der Gruppe hinzu.

Set-PSSessionConfiguration Microsoft.PowerShell –ShowSecurityDescriptorUI

Alternativ können Sie den Benutzer zur Gruppe der Remote Management Users hinzufügen.

net localgroup „Remote Management Users“ /add <domain>\<user>

Damit PowerShell-Skripte auf einer Remote-Maschine ausgeführt werden dürfen, muss auf dieser PowerShell-Remoting aktiviert sein. Öffnen Sie dazu auf dem Zielsystem eine PowerShell-Konsole oder -ISE als Administrator und starten den Befehl:

Enable-PSRemoting -Force

Stellen Sie zunächt sicher, dass die Maschine erreichbar ist. Dazu verwenden Sie am einfachsten den Befehl:

ping server.domain.local

Wie aktiviere ich PS Remoting auf einem Zielsystem in einer anderen Domäne?

Ich kann ein PowerShell Skript mit ScriptRunner nicht auf einem Zielsystem ausführen, das in einer anderen Domäne als der ScriptRunner Service Host ist.

PowerShell Remoting habe ich auf diesem Zielsystem aber doch bereits aktiviert, wie es in einem anderen FAQ-Beitrag beschrieben wird.

Was jetzt?

Wenn Sie PS Remoting auf dem Zielsystem bereits aktiviert haben, und Sie das Zielsystem vom ScriptRunner Service Host anpingen können, können Sie versuchen, eine Telnet Verbindung zum PowerShell Port des Zielsystems aufzubauen. PowerShell benutzt standardmäßig Port 5985 für PowerShell Remoting.

Natürlich können Sie keine gültige Telnet-Verbindung zum Port 5985 herstellen, weil dort kein Telnet-Server angeschlossen ist. Wenn jedoch Firewall-Regeln die Verbindung mit diesem Port verhindern, wird Ihr Telnet-Client entsprechende Fehlermeldungen anzeigen, die bei PowerShell Remoting nirgends sichtbar sind.

telnet <target-fqdn> 5895

Wenn die Maschine über Telnet erreichbar ist, probieren Sie in der PowerShell Konsole oder ISE eine PowerShell Remoting Verbindung:

New-PSSession -ComputerName <target-fqdn> -Credential <domain\user>

Wenn das nicht funktioniert, prüfen Sie die lokalen TrustedHosts Einträge:

Get-Item WSMan:\localhost\Client\TrustedHosts

Das folgende Kommando trägt das Zielsystem als TrustedHosts ein:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value <target-fqdn>

Die Session kann auch fehlschlagen weil Ihr Benutzer <domain\client> für das Zielsystem dort nicht die nötigen Berechtigungen hat.

Sie können den Benutzer auf dem Zielsystem der Gruppe hinzufügen, die die Microsoft.PowerShell Session Configuration verwenden dürfen:

Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI

Alternativ können Sie den Benutzer auch auf dem Zielsystem der lokalen Gruppe „Remote Management Users“ hinzufügen:

net LOCALGROUP ‚Remote Management Users‘ /ADD <domain\user>

Wir bieten ein PowerShell Skript, das die aktuellen Einstellungen der PowerShell Konfiguration analysiert. Das Skript liegt im Support Ordner des ScriptRunner Installationsverzeichnisses. Sie können das Skript auf einem Zielsystem unter Ihrem Remote-Benutzer laufen lassen; es wird einige der oben angegebenen Überprüfungen durchführen und die Ergebnisse ausgeben.

 

Wie kann ich den Support unterstützen? Gibt es Logfiles oder ähnliches?

Wie kann ich den Support unterstützen? Gibt es Logfiles oder ähnliches?

Die ScriptRunner 2015 Log-Dateien werden im Verzeichnis %PROGRAMDATA%\AppSphere\ScriptRunner\Log auf dem ScriptRunner Service Host gespeichert.

ScriptRunner schreibt wichtige Status-Informationen auch in die Windows Ereignisanzeige (unter Anwendungen). Diese Quelle eignet sich daher besonders für die Fehleranalyse.

Damit wir die Situation nachvollziehen können, benötigen wir regelmäßig die folgenden Informationen:

  • Version des Betriebssystems,
  • Version des Browsers,
  • Detaillierte Beschreibung des Problems, und was Sie gemacht hatten, bzw. was Sie erreichen wollten,
  • Die Log-Dateien des fraglichen Zeitraums.

Je nach Fehler können zusätzlich auch Screenshots hilfreich sein, besonders wenn darauf Fehlermeldungen zu erkennen sind.

Die ScriptRunner 2014 Log-Dateien werden unter %APPDATA%\AppSphere\ScriptRunner\Log gespeichert.

Wie kann ich den Support unterstützen? Gibt es Logfiles oder ähnliches?

Wie kann ich den Support unterstützen? Gibt es Logfiles oder ähnliches?

Die ScriptRunner 2015 Log-Dateien werden im Verzeichnis %PROGRAMDATA%AppSphereScriptRunnerLog auf dem ScriptRunner Service Host gespeichert.

ScriptRunner schreibt wichtige Status-Informationen auch in die Windows Ereignisanzeige (unter Anwendungen). Diese Quelle eignet sich daher besonders für die Fehleranalyse.

Damit wir die Situation nachvollziehen können, benötigen wir regelmäßig die folgenden Informationen:

  • Version des Betriebssystems,
  • Version des Browsers,
  • Detaillierte Beschreibung des Problems, und was Sie gemacht hatten, bzw. was Sie erreichen wollten,
  • Die Log-Dateien des fraglichen Zeitraums.

Je nach Fehler können zusätzlich auch Screenshots hilfreich sein, besonders wenn darauf Fehlermeldungen zu erkennen sind.

Wie kann ich die Schriftgröße in ScriptRunner ändern?

Lässt sich die Größe der Ansicht in der ScriptRunner Oberfläche anpassen?

Die ScriptRunner 2015 Apps speichern die gewählte Größe für den folgenden Start als lokales Cookie.

Die Schriftgröße lässt sich ganz einfach durch gleichzeitiges Drücken der Tasten STRG und + zum Vergrößern oder STRG und – zum Verkleinern ändern, oder genauso durch Drücken von STRG und Drehen am Mausrad. Durch STRG-0 wird die Schriftgröße wieder in die Standardeinstellung zurückgesetzt.

Dies kann allerdings von der verwendeten Internet Explorer-Version und dem Betriebssystem abhängen.

Wie kann ich meine Zielsysteme in ScriptRunner importieren?

Ich möchte meine bestehenden Zielsysteme in den ScriptRunner importieren.
Gibt es dafür eine Möglichkeit? Kann ich Computer aus meiner Domäne zuvor exportieren?

Es besteht die Möglichkeit, Zielsysteme mittels einer CSV-Datei zu importieren, diese Datei muss im ANSI Format angelegt sein.

Datei enthält die Eigenschaften für ein Zielsystem. Die Eigenschaften müssen mit Semikolon getrennt sein. Das Format für eine Zeile setzt sich zusammen aus:

  • dem FQDN,
  • den zuzuordnenden Tags in ScriptRunner (Komma getrennt),
  • SSL verwenden (0=Nein, 1=Ja),
  • der Portnummer von Remote PowerShell auf dem Zielsystem.

Beispiel:

testsystem.mydomain.com;Performance,System,Support;0;5985

Zum Erstellen einer solchen Datei für alle Computer einer Domäne liegt das Skript „Export_AD_Computer.ps1“ bei. Öffnen Sie das Skript und passen Sie es auf Ihre Umgebung an.

Dieses Skript kann lokal mit den entsprechenden Berechtigungen als Aktion in ScriptRunner ausgeführt werden.

Wie kann ich nur bestimmte Berichte im Dashboard anzeigen?

Wenn ich nur die Berichte sehen will, die von einem bestimmten Zielsystem stammen, oder alle Berichte eines bestimmten Skripts, wie mache ich das in ScriptRunner?

Die Ansicht im Dashboard lässt sich zunächst wie alle Ansichten nach Tag filtern, indem im Navigations-Submenü ein Tag ausgewählt wird.

Weitere Filter gibt es nach einem Zielsystem, Benutzerkonto, Skript oder einer Action, oder Kombinationen hieraus. Hierzu kann man im Dashboard für jede dieser Rubriken am unteren Rand der Rubriken-Kachel ein Element als Filter auswählen.

Alternativ kann man aus den Listenansichten einer Rubrik einen Eintrag direkt als Filter ins Dashboard übernehmen, indem man den Eintrag in der Liste auswählt und in der Aktionsleiste die Dashboard-Schaltfläche benutzt. Sind Sie etwa in der Ansicht Zielsysteme und wollen die Berichte zu einem bestimmten Zielsystem sehen, wählen Sie das Zielsystem in der Ansicht aus und wechseln mit der Dashboard-Schaltfläche ins Dashboard; der Filter wird automatisch aus dem Kontext übernommen.

Im Dashboard können Sie mit der Bericht-Schaltfläche in der Aktionsleiste jederzeit in die Berichtsansicht wechseln, wo dann nur die gerade gefilterten Berichte angezeigt werden.

Wie kann ich Tags in ScriptRunner verwenden?

Wozu dienen die Tags in ScriptRunner?

Das Zuweisen von Tags zu Aktionen, Zielsystemen, Skripten oder Benutzerkonten erleichtert Ihnen die Suche nach den jeweiligen Objekten. Sie können beispielsweise sehr schnell über die Subnavigation (blauer Pfeil in der linken Navigationsleiste) des jeweiligen Bereiches gezielt auf die Objekte zugreifen.

Zusätzlich können Sie über den Tag-Filter in der Tabellenansicht Objekte gezielt filtern. Es werden dann nur Einträge angezeigt, welche mit allen Tags des Tag-Filters verknüpft sind.

Tags dienen also der Strukturierung von Aktionen, Zielsystemen, Skripten und Benutzerkonten (Credentials).

Unter Einstellungen -> Tags erhalten Sie eine Übersicht aller momentan verwendeten Tags, die Sie dort bearbeiten oder löschen können. Ebenso können Sie dort neue Tags erstellen. ScriptRunner generiert automatisch Tags aus den Ordnernamen der Unterordner im Datenpfad der Skripte. Aktionen werden initial die Tags des mit Ihnen verknüpften Skripts zugewiesen. Anhand dieser Tags wird im Aktions-Assistenten später die Auswahlliste der Zielsysteme absteigend zu ihrer größtmöglichen Übereinstimmung sortiert.

In der ScriptRunner 2015 Delegate App wird für jedes Tag einer Aktion eine Registerkarte angelegt. Auf dieser Registerkarte werden alle Aktionen dargestellt, die dieses Tag haben und für den jeweiligen Operator berechtigt wurden.

Wie kann ich Zielsysteme zur TrustedHosts Liste hinzufügen?

Ich bekomme folgenden Fehler:
„Beim Verbinden mit dem Remoteserver „testmachine“ ist folgender Fehler aufgetreten: Die Anforderung kann von WinRM nicht verarbeitet werden. Der folgende Fehler ist bei Verwendung der Kerberos-Authentifizierung aufgetreten: Der Computer „testmachine“ konnte nicht gefunden werden. Stellen Sie sicher, dass der Computer im Netzwerk vorhanden ist und dass der angegebene Name richtig geschrieben ist.“

Um in ScriptRunner Zielsysteme außerhalb der Domäne des ScriptRunner-Systems verwenden zu können,
müssen Sie die Zielsysteme auf dem ScriptRunner-System in die TrustedHosts Liste eintragen.

Die aktuelle Liste der TrustedHosts können Sie sich mit folgendem PowerShell-Befehl anzeigen lassen:
Get-Item wsman:\localhost\Client\TrustedHosts

Sie können den folgenden Befehl verwenden, um Computer in die TrustedHosts Liste einzutragen:
Set-Item wsman:localhost\client\trustedhosts
Mit der Option -Value * für alle Computer oder –Value *.mycompany.com für alle Computer in mycompany.com.
Falls Sie einen bestimmten Computer eintragen möchten, verwenden Sie bitte die folgende Option:
-Value <Computer>.<Domäne>.<Company>.<top-level-Domain>

Wie richte ich ScriptRunner mit Internet-Proxy ein?

Wir verwenden in unserem Netzwerk einen Proxy-Server für Zugriffe auf das Internet.

Was bedeutet das für ScriptRunner?

Der ScriptRunner Dienst verbindet sich mitunter mit einem Lizenzserver im Internet (Aktivierungsserver), um den Lizenzstatus zu aktualisieren. Ohne Verbindung zu diesem Server treten Fehler auf („Kommunikationsproblem beim Zugriff auf den Aktivierungsserver“), zum Beispiel nach der initialen Installation von ScriptRunner beim Aktivieren der 30 Tage Test-Lizenz (siehe FAQ-Eintrag), und ScriptRunner lässt keine Benutzeranmeldung mehr zu.

Wenn Sie in Ihrem Netzwerk einen Proxy-Server für den Zugriff auf das Internet verwenden, gibt es je nach Situation verschiedene Möglichkeiten, die erforderlichen Proxy-Einstellungen für den ScriptRunner Dienst einzurichten:

  1. Wenn Sie den ScriptRunner Dienst unter einem angelegten Dienst-Account laufen lassen, genügt es, wenn die Proxy-Einstellungen in den Internet Explorer Internetoptionen für diesen Dienst-Account gesetzt sind (z.B. über Gruppenrichtlinie).
  2. Wenn Sie den ScriptRunner Dienst als LocalSystem laufen lassen, können Sie den Proxy mit dem NETSH Kommando als System-Proxy setzen. Der ScriptRunner Dienst wird diese systemweite Einstellung (die z.B. auch das Windows Update benötigt) auslesen und verwenden.
    Da der ScriptRunner-Dienst ein 32-Bit Prozess ist, wird der Eintrag im Wow6432Node erwartet; unter Windows 7 / Windows 2008 R2 müssen Sie hierfür explizit die NETSH.EXE aus C:\Windows\SysWOW64 verwenden!
  3. Wenn Sie den Proxy fest und unmittelbar nur für den ScriptRunner Dienst setzen wollen, ohne andere Prozesse oder Systemeinstellungen zu beeinflussen, können Sie den Proxy auch explizit in der ScriptRunner Registry konfigurieren.
    Hierzu legen Sie in der Registry unter
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\AppSphere\ScriptRunnerSvc\General
    einen REG_SZ Eintrag mit Namen InternetProxy an, und tragen als Wert den Proxy-Server und Port ein (in der üblichen Schreibweise mit ‚:‘, wie in: proxy.mydomain.com:8080).
Wie soll die Fehlerbehandlung in Skripten gestalten werden, damit ScriptRunner diese anzeigen kann?

Kann ich Fehler die im Skript auftreten im Ausführungsbericht sehen?

Grundsätzlich sollten Sie Fehler innerhalb des PowerShell-Skripts behandeln.

Dafür gibt es unterschiedliche Möglichkeiten z.B. trap, Try/Catch, ErrorVariable etc.

Geben Sie in Ihren Skripten Ablaufmeldungen oder Zwischenergebnisse aus, können Sie diese später im Report der Skriptausführung einsehen und den Ablauf nachvollziehen. Vermeiden Sie jedoch Write-Host in Ihren Skripten; je nach PowerShell Host kann es sein, dass die Meldung gar nicht ausgegeben wird, so dass sie auch nicht im ScriptRunner Bericht erscheint.

Verwenden Sie besser Write-Output für einfache Ausgaben, Write-Error um einen Fehler zu erzeugen, und Throw um das Skript mit Fehler abzubrechen.

Wie verwende ich Skript-Parameter in ScriptRunner?

Meine Scripte verwenden Parameter:
Wie kann ich diese im ScriptRunner anzeigen, verwenden und belegen?

Beim Erstellen, Bearbeiten oder Ausführen einer Aktion können Werte für die Skript-Parameter angegeben werden.

Skript-Parameter werden automatisch für die interaktive Verwendung in ScriptRunner erkannt, wenn sie im Skript als vorangestellter PowerShell PARAM Block ausgewiesen sind. Die Beschreibung des Parameters liest ScriptRunner aus dem .PARAMETER Eintrag des Skript-Kommentars aus.

Alternativ, wenn Ihre Skripte ohne PARAM Block geschrieben sind, können Sie die benötigten Variablen direkt im Skript explizit für ScriptRunner durch „#ASR“ Schlüsselwortzeilen deklarieren. Während Sie bisher im Skript die entsprechenden Variablen mit den Parameterwerten setzen, legt dann ScriptRunner die Variablen in der PowerShell Session an, bevor das Skript gestartet wird; mit den Werten, die Sie in der ScriptRunner App angeben.

Beispiele mit weiteren Details zu den beiden Alternativen finden Sie in der Hilfe zur Ansicht Skripte in der Administrator App und in den Beispielskripten.

Ergänzender Hinweis zu leeren Parametern:

Mitunter sind Parameter optional. Sollte es beim Starten einer Aktion noch einen offenen Parameter geben, zeigt der Ausführungsassistent immer erst die Parameter Karte an, bevor Sie das Skript starten können.

Wenn Sie in der Oberfläche dann etwa das Eingabefeld für den Parameter „$para“ leer lassen, wird ScriptRunner diesen Parameter überspringen. Im Fall einer „#ASR“ Deklaration wird die Variable $para dann nicht angelegt, was Sie im Skript mit „if ($para)“ auch überprüfen können.

Bei der Deklaration per PARAM-Block gibt es hier eine Besonderheit. Da PowerShell Remoting die Parameter für einen PARAM-Block per Reihenfolge und nicht per Name an das Zielsystem überträgt, kann ScriptRunner nur die hinteren leeren Parameter weglassen, vordere Lücken in der Parameter-Reihe füllt ScriptRunner mit $null. Im PARAM-Block angegebene Defaultwerte kämen daher bei PowerShell Remoting nur für hintere leere Parameter zum Zuge.

Ergänzender Hinweis zu PSCredential Parametern:

ScriptRunner 2015 wertet aus einem PARAM-Block die Parameternamen aus, ignoriert jedoch zurzeit alle anderen Angaben wie Datentypen, Mandatory oder Defaultwerte; mit einer Ausnahme: Wenn der Typ eines Parameters als [PSCredential] angegeben ist, bietet ScriptRunner bei der Parameterabfrage im Assistenten die hinterlegten Benutzerkonten zur Auswahl an. Die Credentials werden dann zur Laufzeit im PowerShell Host aus der Windows Anmeldeinformationsverwaltung geladen und dann als PSCredential an das Skript übergeben.

Dasselbe Verhalten bei „#ASR“ Deklaration wird durch Angeben von „Type: PSCredential“ erzielt, wie in folgendem Beispiel:

#ASR Parameter: MyCred Type: PSCredential Description: Credential to use

Wieso benötige ich ScriptRunner wenn ich Git-Hub nutzen kann?

Verwendung von GitHub mit ScriptRunner

Es gibt immer wieder Anfragen von Kunden und Unklarheiten über Git-Hub. Einige Interessenten kommen auch mal mit Aussagen „wir haben Git-Hub, brauchen keinen ScriptRunner“.

Was ist Git-Hub ?
Git-Hub ist eine Software-Versions-Verwaltung in der Cloud. Entwickler können also Skripte entwickeln und diese in Git-Hub speichern. Git-Hub unterstützt also ausschließlich die Funktion Versionsverwaltung und Versionshistorie von Skripten und überdeckt damit nur in einen kleinen Teil von ScriptRunner.

Was kann Git-Hub nicht ?
Die Funktionen im ScriptRunner für Verwalten, Ausführen, Überwachen und Delegieren können mit Git-Hub nicht abgedeckt werden.

Kann man Git-Hub mit ScriptRunner verwenden ?
Ein klares JA. Die Arbeitsweise von Git-Hub gibt vor, dass gültige Skripte in ein Verzeichnis ausgecheckt werden. Man legt also ein Git-Hub -Auscheck-Verzeichnis auf das ScriptRunner Backend. Über die globalen Einstellungen von ScriptRunner wird dieses Verzeichnis als Skriptverzeichnis für ScriptRunner konfiguriert.
Damit erscheinen nun die Skripte aus Git-Hub in SkriptRunner.

Zusätzlich überwacht ScriptRunner dieses Verzeichnis aktiv und bekommt so mit, wenn neue oder geänderte Skripte durch Git-Hub zur Verfügung gestellt werden

Wo finde ich die Log-Dateien für die Unterstützung von Supportanfragen?

Wo werden die ScriptRunner Log-Dateien im Dateisystem abgelegt?

ScriptRunner 2015

Die ScriptRunner 2015 Log-Dateien werden im Verzeichnis %PROGRAMDATA%\AppSphere\ScriptRunner\Log auf dem ScriptRunner Service Host gespeichert.

ScriptRunner schreibt wichtige Status-Informationen auch in die Windows Ereignisanzeige (unter Anwendungen).

 

Wo finde ich weitere technische Informationen und Handbücher?

Wo finde ich weitere technische Informationen zum Produkt, wie Installationsanleitungen, Produktübersichten oder Benutzer-Handbücher?

Weitere Informationen und die Dokumentation zu ScriptRunner 2015 finden Sie  im ScriptRunner-Installationsverzeichnis und auf der ScriptRunner Website.

Wo werden die Kennwörter der Benutzerkonten abgelegt?

Wie verwaltet ScriptRunner meine Kennwörter?

ScriptRunner selbst hält keine Kennwörter vor, sondern legt aus Sicherheitsgründen die konfigurierten Benutzerkonten mit den Kennwörtern in der Anmeldeinformationsverwaltung des Betriebssystems ab.

ScriptRunner liest die Kennwörter von dort nie wieder aus, sondern übergibt zum Ausführen von PowerShell-Skripten immer nur Verweise auf die Anmeldeinformationsverwaltung an den PowerShell Host. Daher muss bei jeder Änderung an einem Benutzerkonto in ScriptRunner das Kennwort jedesmal erneut eingegeben werden.

Sie erkennen die Benutzerkonten, die von ScriptRunner angelegt wurden, am Präfix ASR:. Sollte ein Benutzerkonto mit dem Präfix ASR: direkt aus der Anmeldeinformationsverwaltung gelöscht worden sein, kann dieses nicht mehr in ScriptRunner verwendet werden. Der ScriptRunner Service schreibt solche Fehler in die Windows Ereignisanzeige. Um das Benutzerkonto in der Anmeldeinformationsverwaltung wieder anzulegen,

  • öffnen Sie den Eintrag in ScriptRunner,
  • geben Sie das Passwort für das Benutzerkonto erneut ein,
  • klicken Sie OK.

Unter ScriptRunner 2014 waren die Einträge in der Anmeldeinformationsverwaltung unter dem aktuellen Benutzer angelegt. Da die Einträge in der Anmeldeinformationsverwaltung in ScriptRunner 2015 vom ScriptRunner Service angelegt werden, sind sie unter dem Benutzer eingetragen, unter dem der ScriptRunner Service läuft. Als normaler Windows-Benutzer sind sie daher nicht mehr zu sehen.

Zugriff verweigert bei neu in die Gruppe aufgenommenem Benutzer

Ich habe einen neuen ScriptRunner-Benutzer in die Berechtigungsgruppe im AD aufgenommen, die im ScriptRunner unter Berechtigungen angegeben ist.

Dennoch erhält der Benutzer beim Start der ScriptRunner App immernoch die Meldung „Zugriff verweigert“.

Nachdem Sie einer Gruppe im Active Directory (oder einer lokalen Windows-Gruppe) einen Benutzer neu hinzugefügt haben, der bereits an seinem Windows angemeldet ist, zeigt das in der Windows-integrierten Anmeldung mitunter noch keine Wirkung. Der Benutzer wird von ScriptRunner weiterhin mit der Meldung „Zugriff verweigert“ abgewiesen.

Der neue Eintrag zeigt erst Wirkung, nachdem sich der Benutzer an seinem Windows ab- und wieder angemeldet hat.