Please note that VisualCron support is not actively monitoring this community forum. Please use our contact page for contacting the VisualCron support directly.


bweston
2015-09-29T13:54:13Z
I just upgraded from 7.7.4 to 7.7.6 now that it has been released, as I needed the fix for the issue with deleting files from SFTP after download.

I am now getting blocks of output from the beginning of all powershell tasks similar to the following:

Quote:


09:44:26: Is 64 bit process: True
09:44:26: Is 64 bit operating system: True
09:44:26: Current user: NT AUTHORITY\SYSTEM
09:44:26: .NET version: 4.0.30319.34209
09:44:26: AddExceptionHandlers
09:44:26: AddAssemblyLoadEvent
09:44:26: Argument(0): 1915213
09:44:26: CreateTaskServiceChannel
09:44:26: CreateTaskServiceChannel->Complete
09:44:26: pts.CreateService(UniqueAddressId)
09:44:26: pts.CreateService(UniqueAddressId)->Complete



How can I get rid of this? While it does look like it could be useful in some cases, I have job flows that this is going to break. If this output can't be disabled I have either my first attempt to downgrade an existing VisualCron installation or a major scramble to fix those flows ahead of me today...
Sponsor
Forum information
Support
2015-09-29T13:57:50Z
For now you can disable Extended debugging in Server settings.
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
bweston
2015-09-29T14:10:49Z
That doesn't seem to have any effect, even after restarting the service.

Edit: Any effect on the Powershell output, that is. I don't mean to imply it does nothing at all.
Support
2015-09-29T14:22:48Z
1. does your Task have output?
2. do you see the output?
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
bweston
2015-09-29T14:36:57Z
Yes to both. This is an example of what I have:

Output (Standard) wrote:


10:10:30: Is 64 bit process: True
10:10:30: Is 64 bit operating system: True
10:10:30: Current user: NT AUTHORITY\SYSTEM
10:10:30: .NET version: 4.0.30319.34209
10:10:30: AddExceptionHandlers
10:10:30: AddAssemblyLoadEvent
10:10:30: Argument(0): 1915396
10:10:30: CreateTaskServiceChannel
10:10:30: CreateTaskServiceChannel->Complete
10:10:30: pts.CreateService(UniqueAddressId)
10:10:30: pts.CreateService(UniqueAddressId)->Complete
31
123



Previously, it only output those last two lines.

I am sure I can adjust the places where my flow depends on output to accommodate this, assuming that it is consistently 11 lines (so far that appears to be the case), but then if it goes away later I'll have to change them back. I believe there are fewer cases where I have flows that depend on the exact powershell output than I thought I did, so that may not be too daunting an amount of effort after all, but it would still be more convenient if I could avoid those extra lines.
Support
2015-09-29T14:39:42Z
Strange. This output should only be shown if:

1. it fails in some way
2. or use of extended debugging

Does it fail in any way?
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
bweston
2015-09-29T14:43:00Z
Not as far as I can tell. All my powershell tasks seem to be doing this, even while reporting success, having no error output, and having all boxes unchecked in the "On Error" tab. Let me set up a super-simple test job.
bweston
2015-09-29T14:45:40Z
Preliminary testing with a brand-new job seems to indicate that it only happens when the task uses a credential. However, many of these tasks need to access network shares.
KJDavie
2015-09-29T21:01:42Z
Hi,

Confirming

1) this does seem credential related, uncredentialed Powershell tasks don't produce the output, one that uses credentials do;
2) The Logging is going to Output, not Server Log ? which will affect task processing, subsequent loops, condition logic etc;
3) We use Powershell in a number of spots to produce lists for subsequent VisualCron Loop Processing, this will break those sorts of jobs / use cases
4) Turning Off Extended Logging does not have any impact (which we don't want to do anyway)

We will need to get this fixed / some clarification of behavior before we can deploy this version to Production.

Will it log in the middle of our output in some circumstances or just at the start ?

We would perhaps need some delimiters / Prefix each logging line with a unique known value "[VCLogging]" or something that we could filter on to distinguish the Powershell Output Lines from the Logging Lines ?

Or Use Error Output ? <Though this might impact some folks also ?>

psinfo.exe from SysInternals is an example of this . . . . if you run this in a Command Task in VisualCron the Output of the Exe goes to Output, but the Logging goes to Error Output . . .

2015-09-30_psinfo_Output (Error).png

This would not be ideal, we really need to separate logging from Task Output (Perhaps visible in the Task Log)

Happy to Test Dummy a Beta Build

Kevin
Support
2015-09-29T22:06:26Z
Thanks for the feedback - we will either provide a beta or just fix this and push out a new build of 7.7.6 tomorrow. Will let you now.
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
Support
2015-09-30T08:08:45Z
Please re-download and re-install. We have updated the current download with just this fix. Thanks for the report!
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
bweston
2015-09-30T13:22:59Z
Thanks.

KJDavie and anyone else coming along, as a heads-up: specifically, it appears that with the new build, turning off Extended Debug Logging prevents this output.
KJDavie
2015-10-01T02:54:56Z
Hi Henrik,

I suspect we will need to do more work on the Powershell Task in the next betas / releases if we can.

If you run the simple 2 line script attached (Write-Output & Throw - Rename from txt attached to ps1) either as a script through the powershell task and then as an Execute Task using Powershell.exe you will hopefully see what I mean (This is with Extended Debug Logging Off).

2015-10-01_SCRIPT_JOBS_POWERSHELL_TASK_AND_EXECUTE_TASK.png

2015-10-01_01_SCRIPT_POWERSHELL_TASK.png
2015-10-01_02_SCRIPT_EXECUTE_TASK_POWERSHELL_exe.png

Basically what we want is a result from the PowerShell task as close to possible as if we executed that same script or commands outside of VisualCron / at a powershell command line.

2015-10-01_Commands Run via PowerGUI.png

This is why for us we do use this task for small powershell code snippets but any script is run through the execute task.

We are still seeing too much debugging / logging from VisualCron vs what our scripts / powershell code is actually doing, and its getting in the way of what we are trying to do via VisualCron.

2015-10-01_03_SCRIPT_POWERSHELL_TASK_OUTPUT_STANDARD.png
2015-10-01_04_SCRIPT_POWERSHELL_TASK_OUTPUT_ERROR.png

You will note if we use a Throw in a Script it appears we lose the Write-Output Data ? (Does not appear in Output Standard or Output Error).

I think a lot of work has been done on this task, and we are very much appreciative of that. The changes today to allow us to control this somewhat with the Extended Debugging switch has helped in a number of spots with the current 7.7.6 version (assuming all goes well with the script or code).

What I am communicating is how we would like to see the product move, to have powershell code in Visualcron behave as close to "Native" as possible (understanding it is server based) so that what is tested in Powershell outside of VisualCron is the result in VisualCron.

This would allow us to put more in VisualCron and reduce even further the scripting that goes on outside of VisualCron.

If logging stays at this level, can we request a switch for this task that lets us switch all the Visualcron Powershell task logging off and just give us what powershell returns ?

This also will allow us to make better use of the Powershell Task, in terms of as part of a larger job (with Loops, Conditions, Notifications etc) that make use of Powershell Output.

Many Thanks

K

  Powershell_Test_Script.txt (1kb) downloaded 49 time(s).
Support
2015-10-01T11:19:54Z
Originally Posted by: KJDavie 


I think a lot of work has been done on this task, and we are very much appreciative of that. The changes today to allow us to control this somewhat with the Extended Debugging switch has helped in a number of spots with the current 7.7.6 version (assuming all goes well with the script or code).

What I am communicating is how we would like to see the product move, to have powershell code in Visualcron behave as close to "Native" as possible (understanding it is server based) so that what is tested in Powershell outside of VisualCron is the result in VisualCron.



The limitation in exactly behaving like PowerShell.exe is that we use the PowerShell API and the "host" that comes with that. The difference is that the host works in other way than the exe. The advantages with the host is that we have more more control of the execution as it occurs within our process instead of in PowerShell.exe - also, more properties regarding execution are available.

I agree that we could add a specific logging option for PowerShell so we are not dependent on Extended debug settings. I will try to prioritize this feature for the developers.

We will also do some testing with THROW to see if we can make it work better.

Thanks for the feedback!

Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
Scroll to Top