PowerShell Extensions for Ivanti DSM

Loading as a module

With the current version 2.0 of Windows PowerShell, the new possibility of loading extensions as so called modules has been added. While in PowerShell version 1.0, the installation and registration of a Snap-In was necessary, it is sufficient for a module to provide the files required at a defined place in the filesystem. Using the cmdlet Import-Module the module is loaded and exposes its functionality to the current session.

Starting with version 2.0 of the PowerShell Extensions, it is also possible to leverage this possibility and use PSX without a real installation - all you need are the extracted sourcefiles. Since the PSX are provided as a packaged MSI, you have to extract its contents first. This is done during an administrative installation and is described in detail in chapter Administrative Setup.

After expanding the sourcefiles, you can copy the files required to any directory of your choice - the directory's name however must be 'PSX7'. It is highly recommended to create this directory in one of the module-paths of PowerShell. You can get the directories contained in the module-path via the environment-variable PSModulePath, for example through this command executed in a PowerShell window:

The following files are mandatory prerequisites for getting the module to work correctly:

• the assembly NwcServices.BlsAdministration.dll
• the type-definitionfile NwcServices.BlsAdministration.TypeData.ps1xml
• the format-definitionfile NwcServices.BlsAdministration.FormatData.ps1xml
• the module-definitionfile PSX7.psd1
• the licensefile NwcServices.BlsAdministration.dll.lic

The subdirectories de-DE and en-US contain help-files, that are displayed when starting this online-help, through calling the Get-Help-cmdlet or when displaying one of the "about_..."-topics. The are not required for successfully executing PSX-based scripts and can therefore be copied optionally.

In order to load the DSM 2022.2 as a module, start a new instance of PowerShell (remember: only PowerShell 2.0 or higher). Assuming you have copied the files mentioned above into the directory

 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PSX7' (one of the built-in module-path directories), just type the following command:

The module will now be loaded. A warning about unapproved verbs is displayed and can be ignored at this time. There is no negative effect on functionality. In order to load the module without getting this warning message, the DisableNameChecking parameter of the Import-Module cmdlet needs to be used:

Now the complete possibilities of the PowerShell Extensions for Ivanti DSM are available at your fingertips.

If you have chosen to not create the PSX7-directory in one of the standard-paths, you must specify the complete path to the module-directory. If you have, for example, created the directory under 'C:\Windows\Temp', you would have to use the following syntax:

It is even possible to access the module if it is stored on a network location via an UNC-path. This eliminates the need for distributing the module-files to all systems, where PSX-based scripts should be executed and allows central updating or maintenance. The downside of this approach lies in the strict security-settings of the .NET-Framework, which doesn't trust assemblies loaded over the network with the default security-settings in place.

In order to successfully load the module via an UNC-path, you have to add the path to the trusted places using the tool caspol.exe. Assuming the module resides in the Extern$-directory of the DSM$-share and the name of your depot is CHISV01, the following code enables successfully loading the module from there:

Note that these commands must be executed on every client accessing the module over the network. This somewhat neglects the advantages of the central module-store, but can nevertheless be beneficial in some situations.