I know that Alan and I have talked about this scenario since he posted it, but I saw that 3 others had also selected the "same question" flag, so I thought I would put my response out here for those that would like it. I hope it helps.
This is an example of power shell scripts that I have setup within one of my virtual machines:
First, this help file is invaluable in the initial setting up of the Remote Host Connections to be able to utilize the PowerShell scripts:
I followed the online help guide for the most part, but I also set my WinRM service to be “bypass” connection policy so that I did not have to worry about certificates. The PowerShell command to do this is - set-executionpolicy bypass – and you may need to restart both the Windows Remote Management and WMI services after running that script to refresh the policy changes.
1. First, follow the online help to get WinRM installed and configured on the remote server.
2. Second Create a Remote Host Connection within Heat: (Admin UI >> Integration Tools >> Remote Host Connections >> New)
3. Then create a Run Program quickaction to call the connection we just created and path to powershell script:
4. Run the QuicAction from the within the Heat UI and see if your PowerShell was triggered and performed.
-make sure that the path of the powershell script is shared. I have also heard other say it must be the C drive, but I have not confirmed this.
-make sure you use the “Run Program History” logs in the Heat admin side to see any errors that occur when the action fires.
-This was all setup on my virtual machine which is why localhost is used; substitute servername where needed.
-The txt within my Powershell example is very simple just - net stop spooler – but make it as complex as you want, it will trigger the same.
I have set one up in a Dev environment. The steps that David mentioned were correct. You really want your remote host connection to the server or workstation that will run the PowerShell scripts. Depending on how much your script is doing will determine where you may want to put the script. After we got the arguments setup properly it worked out nicely. We tested with extending a contractor account in active directory. We embedded it into a workflow using the run program action. We also had it return data to us and used the output field in the run program to capture it. If you create a field for the BO then you can use that for your output field and have it trigger other actions within your workflow.
It took a lot of back and forth of testing to get it all figured out and to get the PowerShell script right but when it worked it was great to have the ability for automation.
we use powershell to automate heavy stuff which we had no chance to do with HEAT itself. also we do not use remote host because it's not working with HTTPS enabled. our team developed a heat extension service wich exposes some methods to execute powershell scripts, add parameters, define return values.
i'm going to write kind of heat powershell module with some default methods like search query generator, insert, update stuff.
We built several Quick Actions that utilize PowerShell scripts. Within our CI Workspace, we built a Quick Action that will go out to a selected CI Server and restart the Discovery Services for us instead of having to do manually. It comes in handy.
we're actually working on our powershell module for heat (PSHeatSM). At the moment we're in a beta state and testing it with some customers.
- fetch data from heat (single object by recid, single object by field, multiple objects, search)
- insert data
- update or upsert data
- remove heat objects
- add heat attachments (binary or from file path)
as previous mentioned, we're in development state and new features arrive quickly at the moment.
- log feature (to logfile, to HEAT object)
- Features you may think they would be great to implement!?
Having that kind of module would be great for what I'm hoping to do. Namely any time a PC with HEAT is decommissioned, we have to manually and individually remove it. I'm assuming we could automate that using Remove-HeatObject. Any way to get my hands on that?
Unless there's some other way to accomplish that I don't know of.
i can give you an early version in a week if you want. there could be issues or problems, because it won't be fully tested. also there are some missing features but if you can live with it
This still being worked on? Would love to test this out!
Looks good andiexer.
Does this work with the product development instance of SM fo you know? PS Automation would help me keep our (on-prem) TFS instance aligned with the SM instance we use for our customer bugs.
Also is there a "User Voice" type vote for new SM features? I really would like a way to link directly to various objects represented in SM (e.g. link directly to a Resolution or KB).
yes, the module is still in development (sorry i had a longer break in australia )
we used it the last months in multiple customer projects and it worked out great. there are also some new features like search with joins, add/remove related objects etc.. we try to implement as much as possible (and what we can find in the official documentation from heat ).
about a dev release: i have to discuss that with my boss in which way we release that "product" (maybe not for free, sorry guys). I let you know whats happening if you're still interested in it.
Yes, it definitely works with the dev instance of SM. Basically, you can connect to every instance of SM (on prem, cloud) if you have am user for it
That looks like a great tool! May I ask how you actually fetch information from HEAT? I wanted to create a script which unlocks users AD accounts, but need to get the username out of HEAT into the script. I have everything except that. Think you could maybe help me out a bit?
2 of 2 people found this helpful
I used the getsrpvalue expression to get the username for a script i was trying out. I just made a SR then selected it and ran this quick action, it passed the username to my script to unlock/reset the password. I haven't tried it in a workflow yet but i think it would work the same way.
2 of 2 people found this helpful
Passing Parameters from Heat to the script:
You can also pass parameters to the powershell script from Heat. I have an example of this on my virtual environment where I auto-generate an AD user from a New Employee setup request from the Service Catalog:
In the Quick Action below Each of these values are being passed from a Service Request (which is why GetSRPValue is used) - FirstName, LastName, DisplayName, AccountName. When fetched into the PowerShell Script they will be referenced as args, args, args, args respectively by default, but you can set different values within the powershell header if necessary.
Screenshot of the quick action that will trigger the powershell script:
Arguments: "$(GetSRPValue(RecId, "FirstName"))" "$GetSRPValue(RecId, "LastName"))" "$(GetSRPValue(RecId, "DisplayName"))" $(GeteSRPValue(RecId, "AccountName"))"
The text within the powershell would then look something like this for the example of creating an AD user:
Example text within the powershell script to create the AD user:
New-ADUser -Name $args -GivenName $args -Surname $args -SamAccountName $args
Hope this helps!