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
   

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.

---

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 71 time(s).

Visual Cron Service setup


Thanks
McDevOps

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.

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

---

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

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

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!

---