That's not a bug, that is design by default. The scheduler runs as a system service and only has access to local drives. Change the account the service runs with to a user with network admin rights and restart the service. Now you still cannot "see" network drives in the oversight window when you want to create an action in a scheduled task, but you can enter the UNC path to the share you want to reach like "\\servername\sharedfolder\subfolder\" and then you can use it as a source or target for moving files.
I have this same problem. I have changed the service to run as a domain user account, but you wrote that it should run as a user with "network admin" rights, but that wasn't clear. Did you mean that it should be a user with "Domain Admin" rights? If so, that would be extremely dangerous. Can you please be more specific as to exactly what rights the user account should be granted that runs the FTP Voyager Scheduler service so that it can see 2012 server share UNC paths?
FTP Voyager Scheduler still DOES NOT work with UNC shares / paths on server 2012 R2.
I have the FTP Voyager scheduler service running as a DOMAIN USER on a Windows 7 Pro 64-bit PC that is a member of a domain. The domain user used to run the service has full access to the UNC share, but FTP Voyager Scheduler still shows an error whenever I try to browse a "local path" that is a UNC path (e.g., \\SERVER1\SharedFolder).
Can someone please help??
There's nothing dangerous about using a domain admin account for this service. This only allows the service to use domain resources as a target or source for moving files.
And there is nothing to browse. Just enter the UNC path and let the scheduled task use it, that's all. Check that with a test account and let it pull and push files and you will see that it works.
Pardon my candor, but you can't be serious in saying "there's nothing dangerous about using a domain admin account for this service." Since 2006 and before, Microsoft themselves have said:
"Whenever possible, services should be redeployed using the Local Service, Network Service, or Local System accounts...
Efforts to correct usage of administrator equivalent accounts by services should be particularly focused on the following situations:
- User accounts with administrator equivalent privileges that log on as a service.
- Built-in administrator accounts that log on as a service.
- Domain administrator accounts that log on as a service on low-security computers"
This is quoted over and over by many IT professionals:
"It is a common mistake for entry-level Windows systems administrators to associate a local or domain Administrator account with Windows services and applications. I hope that you can see how dangerous a practice this is. If a malicious user were to compromise a service account, then that malicious user accesses your domain up to and including all level of privilege of the associated service account." (4sysops,.com,Service Account best practices ).
Statements such as these aren't made lightly. A windows service account can be compromised more easily that one would expect. It's the equivalent of providing a potential infiltrator the keys to the kingdom if a service running as Domain Admin were compromised, and this is why it should never be done.
To your other point about: "there is nothing to browse. Just enter the UNC path and let the scheduled task use it, that's all." This is completely false. I need to be able to at least browse to the correct path and select it. Even accepting your "just go on blind faith" that the path will work doesn't function. I had the UNC path inserted into the upload event, and I watched while both the scheduled task and manually ran task were unable to copy the files from the UNC. The MFT live user data showed a connect/immediate disconnect. The FTPV Scheduler log showed a no access to the LOCAL directory.
If ought to tell you something that if the FTPV Scheduler program in application mode can't even browse the UNC (even though the Windows File Explorer shows the files with the UNC correctly), something is not working correctly within the program.
I've since switched to a superior product: BatchSync FTPS. This product has no trouble pulling and browsing a UNC for the local files.
I wrote "for this service" and this is not a public request to follow my suggestion. Of course I am aware of the security risk using a domain admin account and I use that only in rare cases on secured machines where not everybody can put his hands on. Ok, I should have clarified that in my posts.
For the browsing part, you are right. I believe that this is a bug in this software, too. The "blind faith" describes it exactly, but in my case it works. To me it looks like something is wrong with the path you have entered.
Anyway, after discovering that the DST bug still exists I will switch to another software, too. There are to many glitches in the FTP Voyager and I do not like having that in a commercial used software.