Following. 

I worked with the (then) FD API a few years ago with Powershell…  

Of interest--using Execute Command Using Inline Connection seems to work fine locally and remotely. I used the default configuration. So that’s good news. Just one problem….this method requires credentials be entered in the UI, which are not masked after saving. Is there a workaround for this?

So--Execute Command has issues apparently. Or, perhaps it works, but requires configuring credentials, etc. in a config somewhere (which goes back to my question about what the Configuration options are with the PowerShell app)

Ikeyes,

Still no reply from support, or even my client’s FS account rep (when I asked why there’s no support). Google links to community posts about the PoSh app might offer insight or a workaround, but the community says I have no access to the posts. This app has 3 reviews in marketplace. 2 indicate it works, the third says it does not, and there are known issues with it. Which is it?

It is also baffling that the one piece that works--Execute Command w/inline connection, does not integrate with the FS credential store. If that exists, I can do what my client needs and Execute Command is not needed.

It’s a shame b/c my client needs this integration, and it should not be stymied because of lack of support.

Hello, 

My experience is that the orch server isn’t the most stable product. 
 

Do the script on the server side need credentials ? 
I found if I convert the password to string a on the server and read that in the script it works well, 
The file can only be read on the server/user it was created as far as I understand it.
 

Create
$securePassword = Read-Host -AsSecureString
$securePassword | ConvertFrom-SecureString | Set-Content "C:\path\to\password.txt"

Use
$encryptedPassword = Get-Content "C:\path\to\password.txt" | ConvertTo-SecureString
$credentials = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "dummyUser", $encryptedPassword

 
//Daniel

Thank you for the interest!

Unfortunately that trick won’t work here. Execute Command w/Inline connection forces you to populate the account/password fields in the UI, and those fields are unmasked after saving. Anyone with rights to look in workflow automation can see it. Such a simple thing to overlook in the design...but it works every time in testing.

Execute Command flat does not work most of the time, even for a simple command run locally, and it will not write to disk. Half the time it provides no output when clicking the test app button.

Hmm, the solution I was working on was to e-mail enable accounts. We created a script on the server that used the way I posted above when we imported the exchange command lets. 

We didn’t get any feedback so my next step was going to do a API call back from the script. 

Ya need to be a non-iterativa command. 

Daniel--you seem to have something working reliably using Execute Command. Did you have to do anything extra on the Windows server host to make it work? Is it an older version of Windows?

Part of me wonders if there is something unique to running on Server 2022 Datacenter. Maybe it will be necessary to directly assign permissions to the runas account (I did not install this, but understand you provide a runas account during installation that is used to execute actions) despite it being a member of Local Administrators. This is necessary with Azure Hybrid Runbook Workers to read the directories where authentication tokens are stored and work is performed. However, I would expect permissions errors to be logged every time something runs.

If nothing else, it continues to disappoint that the FS folks have yet to offer any advice on two tickets after the initial response.

Will your server write to file (i.e. get-service | export-csv c:\temp\file.csv -notypeinformation)?

It was a customer here as well who set it up. The account need access to run the service. If you use just normal commandlets it’s the run as accounts access you use. If you import from example AD or Exchange it’s that account, don’t need to be the same. Just as long as you don’t have any internal proxy that blocking the traffic. They followed the guide on FW support portal.  I think it was a 2022 server as well. 

The customer have setup a local logging to a text file and it works. 

 

Have you checked / asked for the log files from the Orch server ? 


 

Hmm--thank you for replying. No reason why this environment should not work then. The runas account used during install is a local admin. Should be able to run anything and write to c:\temp

I have full rights on the orchestrator servers and been looking at the logs for clues to help.

Folks--mainly for any FS employees/moderators watching

This morning I received an email stating user benzzliski responded to my question here. It starts out as (italics below), However, I cannot see this post here on the site. Please correct whatever permissions are necessary for me to be able to read this.

I'm sorry to hear that you're facing issues with your ticket and seeking assistance for your FS automation development. It seems like you're experiencing problems with executing commands and writing to a .csv file on a remote server. You've already checked various configurations, including services running and WinRM settings. For further troubleshooting, you'd like documentation on the Configuration setting's purpose, the difference between "default" and "FreshService PowerShell Config," and advanced troubleshooting like analyzing the broker...

Did you ever find a solution for this? I get an error “ Key not valid for use in specified state” whenever I try to use something like the following: Get-Content "C:\path\to\password.txt" | ConvertTo-SecureString

If you could just use the credential manager in Freshservice to pass credentials to powershell, this entire issue would be moot.

Did you generate the password with the same account and on the same server  as the Orch server are on? 

Yep, perhaps I’m doing something else wrong but it works fine running it locally from the server. Running it from freshservice gives me that error.

And it’s the same account that running the Orch server ? 

Same account connects to the orch server and generated the password stored on the orch server.

Ah, I think I fixed it! Needed to be the UPN and not just the username. Or, for whatever reason, it is working that way but was not working the other way. Thanks!

Hello @TomC 

If you think you have arrived at the best solution/work around, please mark it “Best Answer” so that others can easily find it! Thanks in advance :)

Hey @TomC 

I’m having the same issue with running scripts that work locally but fail when using the powershell orch. I get the following error: “ClientCertificateCredential authentication failed: Key not valid for use in specified state”. The only way my scripts work from the workflows is if my user account is logged in to the server at the time to automation runs, what were some of the things you did to fix it?