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


McDevOps
2017-07-04T20:20:37Z
We have a large number of VisualCron instances, these run a lot of Windows Processes (Task Process Execute.) These tasks access stored AD credentials to authenticate against a range of resources DBs, File Shares, Services, APIs etc.

Upgrading to 8.2.7 caused any of the above tasks to fail to access any authenticated resources eg file shares. This may or may not result in an actual VC task failure dependent on the program logic. Further investigation showed: tasks were no longer being executed with the supplied AD credentials but run as the SYSTEM user. This behaviour occurred for separate upgrades for 7.7.5, 8.02 and 8.1.2.

Turning on extended debugging showed that the credentials has all been switched from CreateProcessWithLogonW to CreateProcessAsUserW silently on upgrade.

If this is correct it presents us with a number of problems

  1. It looks as though we will need to check the credentials for every execute task check the settings before the update and restore back to CreateProcessWithLogonW. then individually verify that tasks are still working.

  2. We now need to keep verbose debugging enabled to view/alter the credentials settings. This exposes a whole range of additional settings we'd rather end users went nowhere near as these can lead to even more issues. I'm not sure what the constraints are here, but I think it would be useful to have the WIN32 Execution option displayed/modifiable without having to enable extended debugging ie
    API/CreateProcessWithLogonW
    API2/CreateProcessAsUserW
Sponsor
Forum information
Support
2017-07-16T12:48:49Z
Thanks for your feedback!

What we did for 8.2.7 was that we set CreateProcessAsUserW as default for new Credentials (not changing existing).

Based on what you describe about previous upgrade problems it sounds more like it has to do with the user that runs the VisualCron service. Maybe you had another user than SYSTEM running it before.
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
McDevOps
2017-08-01T17:26:14Z
Hi Henrik,

Thanks very much for your reply.

I've double checked my test VM and unfortunately the issues we are experiencing don't appear to match your explanation?


  1. Installed fresh instance of VisualCron 8.0.2 on Windows 7 Test VM - VC is installed to run as service with SYSTEM account
  2. Created test job using V1 API credentials
  3. Upgraded box to 8.2.8 release - credentials are switched to use v2 API
NB This matches the same behaviour we saw on the live Server 2012 R2 box.

As previously mentioned there is no way to view which API version the credentials are using, without turning on extended debugging.

Jobs and Credentials before and after upgrade

  Diff.jpg (494kb) downloaded 72 time(s).

Visual Cron Service setup
Service.jpg

Thanks
McDevOps

Originally Posted by: Support 

Thanks for your feedback!

What we did for 8.2.7 was that we set CreateProcessAsUserW as default for new Credentials (not changing existing).

Based on what you describe about previous upgrade problems it sounds more like it has to do with the user that runs the VisualCron service. Maybe you had another user than SYSTEM running it before.

Support
2017-08-02T08:31:49Z
Can you try the following;

1. turn on extended debugging in server settings
2. edit the Credential and select combination CreateProcessAsUserW + LOGON_BATCH
3. try to execute - if that does not work try combination CreateProcessWithLogon + LOGON_NEW_CREDENTIALS
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
McDevOps
2017-08-02T13:51:30Z
Hi Henrik,

I followed up on your suggestion

  1. CreateProcessAsUserW + LOGON_BATCH - Fails
  2. CreateProcessWithLogon + LOGON_NEW_CREDENTIALS - Succeeds

But this still leaves us with the issues I originally raised

  1. The VC upgrade silently switches the Credential WIN API method on upgrade.
  2. Having to reset and test hundreds of credentials from CreateProcessAsUserW to CreateProcessWithLogon is not feasable.
  3. The VC API method being used by the credentials is only (indirectly) surfaced on the UI by turning on Extended Debugging. We don't want users to have to deal with the full range of WINAPI options.


Thanks
MCD

Originally Posted by: Support 

Can you try the following;

1. turn on extended debugging in server settings
2. edit the Credential and select combination CreateProcessAsUserW + LOGON_BATCH
3. try to execute - if that does not work try combination CreateProcessWithLogon + LOGON_NEW_CREDENTIALS

Support
2017-08-10T15:51:10Z
After investigation we have found that API v2 does not support the same network access as v1. v2 solves another problem though (permission error -10XXXXXXXX) - which was the reason we created it in the first place. We will revert to v1 as default and keep v2 as alternative for those with permission errors -10XXXXXXXX. Thank you for your patience and feedback!
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
Scroll to Top