R:\WSF2\Operations & R:\WSF2\Specialreports\allreps are not UNCs, they are explicit (absolute) file references and in your case they are probably mapped network drives. The issue is probably that the drive mappings may or may not exist at the time the job runs in Monarch. It is always far better to use the UNC (specifing the
servername\sharename) as you are no longer dependant on the drive mapping through the OS. Just ensure that the user running the Monarch Datapump Service has the appropriate right the share. I have had this problem and switching to the UNC works everytime. All models and projects should reference UNCs, makes upgrading servers easier and allows you to more easily create a project on Monarch at your workstation and then load it on Datapump on a different server without having to worry about similar driver mappings.
Hope this helps.
The user is me, and the machine has the drive mapped. In fact the logon script assigns the drive letter. (R:\)
I just thought it was odd that it would work fine until we switched from NT to Active Directory.
So , I had massive failures on the Monday following the cut over. All the errors said the JOIN was missing or the password was incorrect... something like that.
Took about a hour for the old brain to figure an answer.
The reason is that NT Services cannot use mapped drives when using user credentials, they can only use UNC paths, i.e.
If you set a service to run as Local System, with the "Interact with desktop" option, then you can see mapped drives, e.g. "R:\", but you lose the ability to use UNC paths, which are probably the better choice.
You can use the Monarch Utility to search through all your Projects and Models and change the external references to the new safer UNC references en masse.
Here's Microsoft's take on this: http://support.microsoft.com/kb/180362/EN-US/[/url]
They essentially say that services should use UNC paths.