Run Locally

If you select the “Run Locally” button, you will get a Path and Arguments textbox instead of the script selector.

These tools will run on the users’ local computer in the local users context. The tool must either be installed on the users’ computer or accessible from a network location.

In the following example, we will create a tool that launches an already installed program, Notepad, on a users’ computer.

Arguments

Any arguments in the “Arguments textbox” will be added after the file path, exactly as writing. Please note that arguments are passed as clear text to the client.

Parameters

You can choose between 5 types of predefined parameters.

Computers- will add a drop-down box where the user can select a computer. The parameter is passed as

/ResourceID <value>

For SCCM devices, the value is an integer. For Intune devices, the value is a string and the ID is the Managed device ID.

Users - will add a drop-down box where the user can select a user. Note that the user list comes from the SCCM user discovery and not the Active Directory. The parameter passed as

/Username <value>

The value is a string in the format “domain\username” for on premise active directories. For Azure AD, it is the user principal name.

Packages - will add a drop-down box where the user can select a package or application. The parameter passed as

/PackageID <value>

The value is a string with the SCCM/Intune package id.

Text- will add a textbox where the user can type any parameter. Any text written by the user in this textbox, will be passed after the path and the arguments.

You can additionally add any Software Variable to your tool. The name and the value of the variable will be passed on to the script.

The order the Software Variables will appear to the user can be changed by dragging the variables in the listbox.

PowerShell Scripts

If you wish to launch a PowerShell script, you must write the path to PowerShell.exe on the local machine in the Path textbox and the path to the powershell script in the Arguments textbox:

%windir%\System32\WindowsPowerShell\v1.0\powershell.exe

Note that execution of powershell scripts must be enabled on the local computers running this tool. Remember that there are two powershells in Windows, one for for 32 bit processes and one for 64 bit processes. The "normal" powershell is the 64 bit, but SoftwareCentral will launch the 32 bit powershell if the browser is a 32 bit program. You should enable execution of powershell scripts on both powershell versions.

Note that if your script requires one or more of the parameters, e.g. the resource id, you must call your parameter in the script the same as the parameter that is passed.

The following example demonstrates how to get the computer name from the ResourceID that is passed to the script:

PowerShell Example	Copy Code
Param( [Int32]$ResourceID ) # Web Service Parameters Start [String]$strSiteCode = "[String]" # Web Service Parameters End # The object that will make the call to the Web Service $proxy = New-WebServiceProxy -Uri "http://softwarecentral/Api/WS_Devices.asmx" -Class "Proxy" -UseDefaultCredential # Call the Web Service $result = $proxy.GetResourceNameById($ResourceID,$strSiteCode) # Print the result if any Write-Host $result

PowerShell Example

Copy Code

Param(
[Int32]$ResourceID
)
# Web Service Parameters Start
[String]$strSiteCode = "[String]"
# Web Service Parameters End
# The object that will make the call to the Web Service
$proxy = New-WebServiceProxy -Uri "http://softwarecentral/Api/WS_Devices.asmx" -Class "Proxy" -UseDefaultCredential
# Call the Web Service
$result = $proxy.GetResourceNameById($ResourceID,$strSiteCode)
# Print the result if any
Write-Host $result

Note, that use the above example, you must provide grant the users calling the tool permissions to call the web service.