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
Viser innlegg med etiketten SCSM. Vis alle innlegg
Viser innlegg med etiketten SCSM. Vis alle innlegg
mandag 2. mai 2016
tirsdag 26. april 2016
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.
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")
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")
onsdag 24. september 2014
SCSM Self Service Portal MaximumInstanceCount
Challenge:
You create a request offering in Service Manager which contains a Query Result prompt that returns a large result set. The Self Service Portal that ships with Service Manager (SMPortal) will only return 2000 values. If you are lucky you will find your value there, but otherwise you are out of luck.Solution:
Extend the value that limits the result set
1. Open IIS Manager on your web server that contains SMPortal
2. Extend Sites > SCSMWebContentServer > ServiceHost
3. Double click on Application Settings
3. Create a new application setting by pressing Add in the task pane
4. Enter MaximumInstanceCount with your desired value
Please note that this will slow down/halt your silverlight application in the web browser until it is finished loading the result from the query. Consider changing your query or splitting the request offering into multiple offerings.
Etiketter:
MaximumInstanceCount,
Query Result,
SCSM,
SMPortal
Abonner på:
Innlegg (Atom)


