Allows remote task creation when forcev1 = true ONLY

Topics: Errors
Sep 16, 2014 at 8:20 AM
Hello,

I am using Windows 7 computer, .NET 4.0 application running as administrator.

Now the process is running using MyUserAccount and from this account I can connect to computer MyRemoteComputer using the Task Scheduler GUI that comes with Windows 7 and I can create Windows 7 compatible tasks (>v1) using the GUI.

Now if I use new TaskService(MyRemoteComputer) it fails with an access denied exception. If I call TaskService(MyRemoteComputer,MyUserAccount,MyDomain,MyPassword, false) same thing. If however I cange false to true (so force v1) it works!

I can also call TaskService(MyRemoteComputer,null,null,null,true) and that works as well so it is not an issue with credentials as you can see it is successfully creating a v1 task remotely, so why will it not allow v2 given that MyRemoteComputer is WIndows 7 and I can do this via the GUI?
Coordinator
Sep 16, 2014 at 7:14 PM
Look in the Documentation area for information on connecting and how permissions work with UAC and within containers like ASP.NET. I think you may find your answer there.
Sep 16, 2014 at 11:34 PM
Edited Sep 17, 2014 at 1:06 AM
Hello, I had a look however I am not using IIS, I have a WPF application, and the process is not being interrupted by UAC definitely.

Also it works if I forcev1.

So I can't see any reason why it would allow connection forced as v1 but not as newer? I have looked at the documentation, what reason can there possibly be to only allow legacy connection? Especially as I can remote to computer using the GUI and create tasks that send emails manually, I clearly have permission so why is your code giving me an access denied exception?

Systems supports version 1.3 btw
Coordinator
Sep 17, 2014 at 3:20 PM
Have you tried launching the process using the "Run as Administrator" for either the actual .EXE or launching Visual Studio that way and then running your process? Let me know what errors you see when you run it that way.
Coordinator
Sep 17, 2014 at 3:21 PM
V1 and V2 have completely different connection models at the core Microsoft library level. This wrapper library hides those differences. The forceV1 parameter literally forks the code to run a V1 connection routine.
Sep 17, 2014 at 11:58 PM
dahall wrote:
Have you tried launching the process using the "Run as Administrator" for either the actual .EXE or launching Visual Studio that way and then running your process? Let me know what errors you see when you run it that way.
Yes I had done, but I found what the issue is today.

The McAfee firewall that we are using seems to block v2 requests from my code! It allows v1 fine but not newer!

If I disable the firewall (or create a rule) then it works, so this is interesting why McAfee will allow v1 connection but not v2!

Anyway at least I now know the problem thanks!
Mar 18, 2015 at 8:14 AM
I have seen that if forceV1 is true, then the Server service in the client needs to be running, else it gives a "network path not found..." error.

But if forceV1 is false, Server service dependency is not there?

Can you pls confirm this and why is so?

Also, how to dynamically determine what value to use in forcev1?
Coordinator
Mar 19, 2015 at 11:40 PM
Thashiznets: V1 runs as a local process that acts on remote files. V2 runs as a COM+ service that passes messages back and forth via the network. This likely is the reason the firewall behaves differently between the two.

koushikc: I think this relates to my response above about how the two versions interact over the network. To dynamically determine which to use I would start with V2 and then try V1 if it fails. Since XP and Server 2003 are now out of support, it is a rarer case that a system will only support V1.
Marked as answer by dahall on 4/20/2015 at 8:13 AM