Host OS is Windows Server 2012 R2 Standard.

I upgraded this morning from 8.4.1 to 8.5.5 and now, even after trying a restart and a reboot, I have multiple tasks that had previously been working fine for accessing the Visualcron API from Powershell (for a long time - I am using the same technique with a 6.2.2 server) that are now returning the following error:

Exception calling "Connect" with "2" argument(s): "Method not found: 'Void CommClientCore.Messages.Message.set_Content(VisualCron.MessageClass)'."

I do not get this error when running the same code in Powershell ISE on the same server as the same user.

This is the "powershell script text" from a sample task that is failing. It fails the same way whether the credential used is set to local login, local login/load profile, or neither; and whether executing in x86 mode or not.

Edit: I have also now gotten the same error providing the script as a file instead of as script text.

Extended debug logging doesn't tell me anything the error output didn't.

I do not know if this may be related: when I run the code below in Powershell ISE, it connects and executes successfully, but the first time it is run, I get an error as follows:

add-type : Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
At line:2 char:1
+ add-type -Path "c:\Program Files (x86)\VisualCron\VisualCronAPI.dll"

The LoaderExceptions are:

Could not load file or assembly 'Microsoft.Win32.TaskScheduler, Version=2.8.10.0, Culture=neutral, PublicKeyToken=c416bc1b32d97233' or one of its
dependencies. The system cannot find the file specified.
Could not load file or assembly 'Microsoft.Win32.TaskScheduler, Version=2.8.10.0, Culture=neutral, PublicKeyToken=c416bc1b32d97233' or one of its
dependencies. The system cannot find the file specified.

Searching for relevant information led me to this  thread.

However, since in ISE the code still works, it seems to me that even if the assembly error is happening and is the underlying cause, the error message implies a problem in the handling of that error.

I'm stumped. I will probably have to roll back by end of day if there isn't some other solution.



Of course, please go ahead and move this to the API forum if it would be more appropriate there. The reason I put it in General Problem Solving was because using the API in this manner seems to be working if it isn't done from a Visualcron Powershell task.

Further update: I just put together a partial proof of concept replacement as a C# ".Net Code Execute" task, and once I figured out it had to do "Local Login/Load Profile" to use the credential for Active Directory authentication, it works. So the issue seems to be isolated to Powershell tasks.

Further update: I just put together a partial proof of concept replacement as a C# ".Net Code Execute" task, and once I figured out it had to do "Local Login/Load Profile" to use the credential for Active Directory authentication, it works. So the issue seems to be isolated to Powershell tasks.

Could you please try our 8.5.6 beta build and see if you can reproduce this there?

---

I wasn't able to try this with the 8.5.6 beta, but I am getting the same result on 9.1.5, which means since I haven't converted them to the less convenient C# approach, my downtime-recovery jobs are presumably still broken.

The problem somehow seems to lie specifically with Visualcron's internal Powershell host. If I change the settings on the task to tell it to run remotely, but on localhost (obviously, with powershell remoting enabled and an appropriate credential), it works. If I have the powershell script call powershell.exe and run the desired command, it appears to work. I have not yet tested using an Execute task to call powershell the same way, but I imagine that would likely also work. So does running it from my local machine or a remote session to the Visualcron host (so far I haven't seen the same error I previously got in ISE, but I also don't use ISE anymore and haven't tested it again).

For what I assume are reasons at least partly related to Visualcron's incomplete support for .Net Core, it only works in Windows Powershell and not in Powershell 7, but that's not really an issue for me.

It seems to work only with Load Profile unchecked on the credential (whereas calling the Powershell executable only works with it checked), and still does not solve several of my use cases on its own, because most of my use-cases involve network shares, and remoting to the local machine introduces the well-known Powershell double-hop problem. By comparison, invoking powershell.exe doesn't introduce the double-hop problem, but it does make the task more awkward to maintain, especially ones where I would prefer to use parameters.

...I was about to close this message with the question of whether any of this helps identify the problem and if there might be a possible fix without having to wait for a release cycle, and then I was doing a last bit of poking around and noticed the copies of VisualCron.dll and VisualCronAPI.dll in the Powershell directory of the Visualcron installation, next to the TashPowerShell executables.

Remembering the issue some people had reported with needing to include CommClient.dll, CommClientCore.dll, and CommServer.dll in their .Net programs to use the API, I took a shot in the dark and tried copying those three DLLs into that Powershell directory...

And so far, it looks as if it's working, despite the fact that every combination I tried of setting the environment current directory to the VisualCron installation folder and trying to load those DLLs with Add-Type (to try to make sure the objects the provided were available) did not.

Interesting side note: It only works with Local Login+Load Profile, and is the first case I can remember encountering where a specific combination of those checkboxes is needed and I get different errors depending on which of the other two combinations I use. Neither checked results in the call to Connect() telling me the active directory user doesn't exist; Local Login but not Load Profile gives me two cryptic lines of "Access Denied."

On further inspection, it appears that with my current solution in place, the Add-Type calls are actually unnecessary.

I don't know if that means that the Visualcron task invocations somehow retain loaded types across executions, or if the Visualcron powershell host automatically loads those DLLs by default for some reason, or whether the behavior would persist across a server restart - I'll probably test that last question later in the week.

Just thought I'd add a quick note that this still seems to be necessary on 9.3.0.

I have changed from copying the files to pointing at them with symbolic links, so that updating Visualcron shouldn't break things again like it did this time, and it seems to be working.