Resource Credentials shows Incorrect Server...
I am using BExec 2010.
I have 1 media server loaded. Normally, when I do any type of job, the "Resource Credentials" portion of the job properties will show:
1. The correct local media server by name and..
2. It will list the drive letter (in this case drive letter E:\ ) and...
3. It also shows the Logon Account to be used along with the test results.
Interestingly, I am attempting to do a Duplicate to Tape operation where this interface is presenting different information. Instead of the normal UI as described earlier...on this particular job, the resource credentials GUI is showing:
1. A different server name of a server that never was a media server (although it did have the agent installed upon it.)
2. Drive letter E:\ and drive letter E:\ again!
And when I do a 'test' of credentials, the test results show error of "A communications failure has occurred." Yet, when I look at the 'Account name' and 'User name' properties, it is correct information as expected which is used for other jobs that do not fail.
Here is what is particularly strange and what I did most recently which forms the basis and is the crux of my question
I had just performed a B2D on 7 tapes. (These tapes were pulled from archive and dated early 2011). The job created about 400 .bkf files. When I create my Dup to Tape job, if I select about a dozen of these .bkf files, the system presents the incorrect "Resource Credentials" info as previously descibed.
However, if I choose the 'other' .bkf files, the proper "Resource Credentials" is in fact presented to me.
And lastly, if I select all of the .bkf files, then the "Resource Credentials" UI shows BOTH the correct AND incorrect server name and drive locations.
As I see it, I have to walk away from the dozen .bkf files that are trying to use a different server name.
Why is it using a different server name\Resource Credentials for a handful of .bkf files?
Hi JustTryingToGetItToWork,
check to see if it is possible the data has become inconsistent because of one of the scenarios listed in this link: http://www.symantec.com/docs/TECH176061