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.
try re-entering the passwd in the datastore instance and make sure there are no extra characters. it looks like you have a bad password. (even though the cleartext is ok)
I don't see how. We use the same datastore for provisioning 2003, 2008, and 2008 R2 servers. 2003 and 2008 servers never have problems and 2008 R2 failures are not consistent. If the password were entered wrong, we would not be seeing only sporadic failures with only one type of OS.
Have you tried passing in “net use * /delete /all” in your script before it re-maps the drives.
I know - it's weird that it happens only in R2. what's the error in the event log on the share say?
does the passwd have any special characters in it ?
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)
# should be ok, but just for kicks take it out of the passwd and see what happens.
also, take out any net use commands that you manually put in, and see if s and/or r get mounted
did you ever resolve this?
No, we've just learned to live with it.
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.
what is your datastore server - samba, 2003, 2008 ? was the account ever getting locked?
could this be some kind of UAC issue on the outbound side?
The datastore is 2003x86. The account is not being locked.
By outbound, you mean on the server that is being provisioned? We disable UAC but not until the first step of the post job so it would still be enabled on the server at the time the drive mapping is performed.