We were having issues writing to a shared directory at customer site when running from the agent. We isolated the problem by running an iTest 6.0 writeFile command via iTest running as administrator and then trying it via the Velocity agent. The test passed, writing data to a file, when running from the desktop but failed when running via the agent. At that time I knew it was a permission issue.
By default the Velocity agent service uses “local system account” which gives you access to all local machine resources. However, it’s not a domain account and you can’t write files to network share – e.g. //<remote computer>/<file path>/…
There are two ways to combat this. We got this to work by logging on as the local admin which should give you the same rights as the local system account (the downside, you have to keep up with password changes). The other way we didn’t test is sharing via computer name – see 2nd screenshot below for more details.
I didn’t test this so it’s unproven but you could give your agent machines access to the share if you know the computer names. This would keep the install the same (local system account) on all the machines but adds a little overhead keeping the shared directory up-to-date. Either method should work assuming the computer is part of the domain. I don’t think this works for a system off the domain.
Note: Computer sharing is disabled by default.
