I'm attempting to copy a file to a mapped drive. The mapped drives already exist because we use them in other software (sql server, scripts, ect...). When I browse to the mapped drive the GUI automatically changes this to use a UNC path. I don't want UNC path names hardcoded. We have a system setup so we can easily fail our process over to the backup by simply modifying the mapped drives. When I create a new mapped drive within VC using a different drive letter it works fine. I can't create the same mapped drive within VC because it already exists. Please help. This is a critical issue in determining whether VC is the solution we need for our processes. Thanks.

Details:

Version 5.7.4
Build: 26370
License Status: Trial
Service is logged in using my local domain account which as mapped drives.
Downloading file from Linux via sftp connection.


I have the service running as my local domain user name

Mapped drives are not shared across users. You could try changing the user that runs the VisualCron service to the same user that has this mapped drive. That should probably work.

However, UNC paths is always to recommend as mapped drives may be disconnected or taken away.

---

I did in fact change the VC service use run under the same account as the user with mapped drives.

I appreciate your recommendation not to use mapped drives. This is not an option. We have alot of software and code written to use mapped drives. We have a solid solution in place and we never have any issues with the mapped drives. The reason we prefer mapped drives is if the server goes down we can easily remap the drives to the backup.

Why does the GUI change the mapped drive to UNC? I type in x:\path\ and the GUI automatically changes this to \\serverx\path. The only way it works is if I map the drive using VC. But then I can't use the drive letters that are already mapped.


Jason

I can't speak for the VisualCron guys, but mapped drives are part of a user's interactive profile. While it is possible to have a windows service use them, Microsoft's guidance states that you shouldn't, and (i think, don't quote me) it is an unsupported operation, so automation system really shouldn't allow it, even if they can/could.

You can probably use a batch script loaded with specific credentials and loaded with profile to get the UNC path from a mapped drive, put it in a variable, and use that throughout the job. Make sure VisualCron's service is setup to logon interactive (the default). Use at your own risk.

Btw, even though you have your setup all working with mapped drives... generally for failover, a simpler solution that doesn't depend on stuff like mapped drives is to simply point an alternate A record to your server holding the shared drive. In the event of a crash, you just change the A record to point to the backup and all is good and you can still use UNC paths. Works flawlessly except for the fact you need to configure the server to accept connection from alternate names.

We have to do that here because we have countless scripts and systems that require access to shared folders and stuff, and our server and server names get rotated a little too frequently for comfort, and VisualCron is far from being the only system that will not easily use mapped drives.

I did in fact change the VC service use run under the same account as the user with mapped drives.

I appreciate your recommendation not to use mapped drives. This is not an option. We have alot of software and code written to use mapped drives. We have a solid solution in place and we never have any issues with the mapped drives. The reason we prefer mapped drives is if the server goes down we can easily remap the drives to the backup.

Why does the GUI change the mapped drive to UNC? I type in x:\path\ and the GUI automatically changes this to \\serverx\path. The only way it works is if I map the drive using VC. But then I can't use the drive letters that are already mapped.


Jason

If you really want to use your mapped drives you could use Foreground execution mode. It is only available for Execute Task and requires that the desktop is activate (no background execution). Still, we don't recommend this.

The reason why we change to UNC paths from mapped drives is that this cross user/desktop causes problems and that mapped drives can externally easily be modified/deleted.

---

I'm not sure how your environment is set up, but we have been migrating (and re-training our users) to DFS in our 2003/2008 Active Directory environment.

We have a \\DOMAIN\Shares\Sharename format where 'DOMAIN' is our domain name, 'Shares' is a DFS Root which lives on a few of our domain controllers (high availablity for the 'shares' piece anyway, and then within DFS, 'ShareName' has the specifics a to where the share REALLY lives. So 'ShareName' actually points at \\ServerXYZ\Share123

Users (and subsequently, VisualCron) could be pointed at \\DOMAIN\Shares\Sharename and in actuality its sending them to \\ServerXYZ\Share123

All you do in a failure state... is update DFS to point 'ShareName' to a different \\ServerABC\Share123 path. We do DFS to keep people from hard coding server names in their scripts, mapped drives, etc... which allows us to migrate shares from one server to another (due to space concerns, server retirement, etc..) and not have to worry about updating user mappings. We sync the data with a new server, set up the share.. update DFS.. and bam, done. User is none-the-wiser.

Just a thought. DFS is awesome :)

Brian