I would like to request that the capability be added to all the running of Powershell Script Jobs in Foreground. This will make it consistent with running .bat,.exe, and .cmd files.

I would like to request that the capability be added to all the running of Powershell Script Jobs in Foreground. This will make it consistent with running .bat,.exe, and .cmd files.

I might be wrong here, so Henrik feel free to tell me if I am... but I think what you're requesting it would be more involved than what you're thinking.

The Powershell task type within VisualCron is not launched using a traditional 'console' environment, it's got no console to show you. It has to do with how PowerShell is being executed. When you launch powershell yourself, you're launching via the PowerShell.exe, which uses the ConsoleHost host. This host allows interaction.

As I said, likely not the best explanation, and I do agree it would be a nice feature.

So currently to satisfy your need, my suggestion would be to do what we do. Instead of using a PowerShell task, save your script and do the following as an EXECUTE task:

64-bit (if on a 64-bit OS), or 32-bit if on a 32-bit OS:



32-Bit (if on a 64-bit OS)


My addition to the feature request for this would be as follows:

I would love it if VisualCron had the ability to choose whether or not to launch a powershell script the current way or via an Execute style like i did as a workaround above. The PowerShell task already has an option to select a file, maybe an additional checkbox could be available when that radio button is selected so you could shell it out to PowerShell.exe (along with the option to run hidden). AND, while we're at it... if you do this... it would be beneficial if a selection for 32-bit or 64-bit powershell was available.

However that could be accomplished, would be awesome 🙂


Brian

Not wanting to Hijack your request, but I requested something similar recently also in the Powershell space. . . .

http://www.visualcron.co...sts&t=4054#post18189 

We use a Command Wrapper . . . . and often we need to use this with an Execute task to get powershell scripts to work from VC exactly like they did when we developed and tested them (we use PowerGUI) (rather than the existing PowerShell Task).

My issue boils down to Brian's comment. I want a(n enhanced or new) powershell task that runs *exactly* like it would if I did it on the command line or the Powershell ISE or PowerGUI !


Would be nice if we could consolidate some requirements here and get a result that helps us all . . . . .

Kevin

Not wanting to Hijack your request, but I requested something similar recently also in the Powershell space. . . .

http://www.visualcron.co...sts&t=4054#post18189 

We use a Command Wrapper . . . . and often we need to use this with an Execute task to get powershell scripts to work from VC exactly like they did when we developed and tested them (we use PowerGUI) (rather than the existing PowerShell Task).

My issue boils down to Brian's comment. I want a(n enhanced or new) powershell task that runs *exactly* like it would if I did it on the command line or the Powershell ISE or PowerGUI !


Would be nice if we could consolidate some requirements here and get a result that helps us all . . . . .

Kevin

I'm bumping this 4-month old thread because I share the exact same thoughts as KJDavie on this subject.

All our current scheduled powershell jobs have write-host elements to them. Granted, they don't run in interactive mode and run in the middle of the night so nobody sees that output..however we are not interested in re-writing them just to be able to use the powershell task type in Visual Cron.

We are currently evaluating this product and won't be purchasing a site license until this glaring omission is rectified. Sor the duration of our eval we are just using the execute workaround and pointing to the powershell.exe and passing it some parameneters (-file c:\crons\powershellfile.ps1)

The Execute Task *should* behave exactly as using Powershell.exe. Only problem might be that paths may vary because of 32 or 64 bit version of Windows and version of Powershell.

What about just adding 32/64 bit option for Execute Task? Then you would be able to do everything. Only difference is that you have to paste preferred path for the Powershell version you want to run.

---

What about just adding 32/64 bit option for Execute Task? Then you would be able to do everything. Only difference is that you have to paste preferred path for the Powershell version you want to run.

I'm assuming your question is based on the fact that the underlying powershell task code would need some major overhaul to accomodate our request of both the 'current' PowerShell task type along with basically an 'execute' method... only via the PowerShell task type.

Here's the reason why i'd like to see the PowerShell task have an option for the API method being used currently along with an option to 'Execute' via powershell.exe, but again... all contained within the 'Powershell task'. From a user's perspective, it's just plain ease-of-use. They wouldn't need to know the full path to PowerShell.exe (for 32bit or 64bit).

What if the person scheduling jobs for a company is not a programmer and does not know the ins/outs of PowerShell. Lets say a developer in that company wrote/tested a script on their machine, delivered the file to the 'scheduler person', and said "I need this ran on Tuesdays at 6pm. Here's the PS1 file, make it happen." ALL testing was likely done via the PowerShell.exe or a script editor like PowerGUI or PrimalScript/PowerShell Studio, etc... That Scheduler would then take that file, look and see a PowerShell task and think automatically that 'yep, that'll work great'. Only to find out that it likely won't if there's anything remotely fancy going on inside the script.

It would be beneficial to have an option to... when pointing directly at a PS1 file, to pass that along to PowerShell.exe just like the execute task would do anyway (with option for arguments). I'm sure there are other perfectly legitimate scenarios, including those already mentioned by others (everyone tests with the ConsoleHost via PowerShell.exe), but this is one scenario i can think of.

Brian

Hi Henrik,

Unfortunately which Powershell version (x32 / x64) you run is not the issue. . . . ?

http://www.visualcron.co...sts&t=4054#post18189 

Here are the bullet points from the link above:

1 - Run a PowerShell script in PowerShell
2 - Pass Arguments (preferably just like a command line / Execute task, rather than via 'Parameters' abstraction)
3 - Nominate the Working Directory (Critical for calling other scripts & include files)
4 - Set the Execution Privilege for the script (Run as). Note this is not the File Access Privilege, but what the script needs to Run as.

Without this a number of Powershell features - includes, calling scripts, modules, and executing as a particular credential will not work. i.e. it does not run like it does in powershell or at the command line. There are things I can do to make scripts work better from the VisualCron task . . . . and what commands I use . . . . but I as WSG notes I don't really want to start enforcing PS coding standards, or rewrites of scripts that have in some cases been working for years just to fit in here.

This change actually helps the utility of the Powershell Task for scripts as when powershell versions / changes come along now you are isolated from it. For Scripts, all you need to do is be able to capture and execute the right command line, with the right credential and we are good.

I am not too stressed myself as our site has matured around the code snippets / single commands we run in the powershell tasks and the 'proper' PS scripts we run as an Execute task, but really this is a fudge to get around the current Powershell Task limitations, and it would be nice to be more consistent and have all the powershell executed from VisualCron in the one place. The people it catches are the more casual users.

I have had the 'you can't run it there you have to run it here *like this*' with Powershell Folks who less frequent users of VisualCron . . . . its a frustrating conversation to have (for us both!).