btw, s: should be mapped to the data-store in the 'post-install' bit of the system package so you shouldn't need to map it again.
can you check to see if that is mounted? or is that what you are saying isn't mounted - i'm not sure because you say you are also manually mounting the datastore.
could there be a control character getting inserted into the passwd?
are you using a different datastore instance for r2 than your other system packages?
We probably don't strictly need to remap the drive. The sequence for us goes like:
map r: to datastore share (blade automagic)
install agent (blade automagic)
map t: to datastore share (post-install step we specify with share password in cleartext)
run script from share (vbs script that changes admin account name)
map s: to datastore share (blade automagic)
run bmiwin.exe (blade automagic)
When these fail, all three attempts to map the drive fail in rapid succession (can see this from the windows security logs on the datastore server). We can then log in, pick up the password in cleartext from the runonce.log, and map the drive and carry on using precisely the same commands that failed.
We only have two datastore instances and we use the same one on probably 95%+ of our provisions. I don't know that its ever happened on the other one but we may just not have done enough (or possibly any) r2 provisions on it to know.
When the problem occurs, it doesn't re-map drives so I don't think deleting mapped drives first would help. All of the mappings fail at once. Then when you log in to the server and try it, all of the mappings always succeed.
The password has numbers, letters, and a # sign. Could it be somehow interpolating that character?
The event log error (in the Security log) is:
Reason: Unknown user name or bad password
User Name: local_account_for_mapping
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: Server_Being_Provisioned
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: IP_Of_Server_Being_Provisioned
Source Port: 0
Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon account: local_account_for_mapping
Source Workstation: Server_Being_Provisioned
Error Code: 0xC000006A
(these 2 events in the log are from the same time)
Jim, if net use fails for wrong password and you are sure the password provided is right, there are couple of thing to check.
One is the timezone difference on the two servers, one that you are provisoning i.e., your physical server and the DataStore you are using. I guess you have a Windows datastore. I have seen such issues with net use in WinPE due to datetime difference.
Also, if you are having a script of your own and that too is not working for net use, try removing the domain name in the command and I suppose you might have already tried using IP instead of hostname if at all.
Can you attach the runonce.log file here, I would like to take a look at it.
I'll get one the next time this occurs - it is a sporadic problem and unfortunately does not generally occur on our test boxes that I can keep around to troubleshoot. I had considered the possibility that time skew was a problem as we've seen it cause errors in the provisioning process before, but I would think that the windows event logs would have a different error code if this were the case.