Running SMlets in Orchestrator as a user with privileges in SCSM

As described in SMlets on server without the SCSM console you can use the SMlets from codeplex on a server without the SCSM console. Particullary useful on an Orchestrator server used to automate different parts of Service Manager.

You can use your PowerShell scripts in a '.Net Activity'.

The question is if the Orchestrator service account has the permission to do anything in ServiceManager as the script default will run with this user account.

To come around this issue simply add Orchestrator variables containing the username and password of a service account with suitable privileges in Service Manager. In your .Net Activity you add the following lines of code to make all the cmdlets in the SMlets run under this account:

$RemoteUsername = '{RunAsUser_SM}'
$RemotePassword = {ConvertTo-SecureString 'RunAsPassword_SM}' -AsPlainText -Force
$SMCreds = New-Object System.Management.Automation.PSCredential($RemoteUsername, $RemotePassword) -ErrorAction:Stop
$PSdefaultParameterValues.Add("*SCSM*:Credential", $SMCreds)

The next obstacle might be your PowerShell ExecutionPolicy which will stop your script at importing the SMlets module. The ExecutionPolicy can be changed on the server by running PowerShell (x86) as an administrator and run the command

Set-ExecutionPolicy Unrestricted

This will be a global change on the server and might be against your companys policy. If you do not want to do this, you can add two more lines in your .net activity to bypass this

$var = Powershell -ExecutionPolicy Bypass {
  ....
  <your script here>
  ...
}

Your script will work, but you will loose the feedback from the script unless you pipe it back to $var

Cireson Self Service portal not working after hotfix 5.0.5

After upgrading a Cireson Self Service portal to hotfix 5.0.5 the site did not start as expected. So I logged in on the server and opened the the site to review the error there.

It said

Could not load file or assembly 'LicenseManagement.Client, Version=1.0.5882.21425, Culture=neutral, PublicKeyToken=98ba2176e2a9efbc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Turns out that the changes to the Cireson licensing has made some changes that requires a newer version of the LicenseManagement.Client.dll different from the version I had (1.0.0.8). This file is located under C:\inetpub\CiresonPortal\bin\LicenseManagement.Client.dll

I contacted Cireson support and they came with the solution quickly enough.

Download the updated installer from https://support.cireson.com/software/#/ reinstall and apply the hotfix again.

Seems there still is an issue with some NavigationNodes disappearing when you do a new install. So be sure to insert those again after your have re-installed to 5.0.1. and applying hotfix 5.0.5

My upgrade path before this hotfix was 5.0.0 > 5.0.2  > 5.0.5.
I think the dll was updated in 5.0.1, since that was the version it reported after a reinstall.

SMlets on server without the SCSM console

I use the SMlets from https://smlets.codeplex.com/ in my everyday work with ServiceManager. A very helpful set of cmdlets that originally requires to be installed on a system with the Service Manager Console installed. This is not something you always want to do. So here is the workaroud to avoid that.

Download and install SMlets from codeplex.

Copy the files Microsoft.EnterpriseManagement.Core.dll and Microsoft.EnterpriseManagement.ServiceManager.dll from c:\Program Files\Microsoft System Center\Service Manager 2010\SDK Binaries\ to your server.

Run Powershell as admin and run the following code to register the dlls

[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")       
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\sources\Microsoft.EnterpriseManagement.Core.dll")
$publish.GacInstall("C:\Sources\Microsoft.EnterpriseManagement.ServiceManager.dll")

Configure the module to run on a server without the console installed. Open C:\Program Files\Common Files\SMlets\Smlets.psml as administrator.

Comment out line 4, 5, 6 and 46
Add the following on line 47 to point to your SDK server:

$GLOBAL:smdefaultcomputer="scsmservername"

Note:
This will break your scripts that use the -ComputerName parameter in the SMlets. If you want to continue using this parameter if you manage several ServiceManager instances from one server, you can skip the last line addition.

Note2:
If you skip the last line, you can avoid using the -ComputerName parameter on all SMlets cmdlets by adding a default parameter at the beginning of your script like this:

$PSDefaultParameterValues.Add("*SCSM*:ComputerName","your.scsm.server")