in 7.3 the password was passed in the clear, or the Guest user was used which didn't require a password.
i believe the encryption issue is known - it seems to be because we don't have a 'full' agent running at the time of the winpe install so we can't decrypt the property value. you can use a non-encrypted property type here but you'd still see it.
if you can, submit a ticket to our support group for this.
I actually already have a ticket open, but wanted to pose the question to the community at large.
The BL client in WinPE apparently has the ability to map the K drive using the same syntax I am (password shows up as ***** in the cmd-line), so there's got to be a way I can do the same.
can you put what you need on the k: drive? it should be available once bmi starts going on the winpe image...
We are running 32-bit utilities for build automation from several folders on the datastore.
In previous versions we could not count on the same drive being mapped through each step of the build so we were mapping Z to do our work.
If the K drive is the same throughout the build process, we can use that to do what we need I would think (and can try).
However, I would still like to understand how the BL client is able to do what I apparently cannot.
k will always be k afaik (maybe unless you had a bunch of drives and cdroms)...
support will have to give the definitive answer on your last question there.
i got a reply from another customer who ran into this...here are his comments and workaround:
I just setup a very low privledge domain account to map to the pxestore - the password is clear text but the account has no rights. The problem is that NSH is not available in WINPE. Therefore, the encrypted string password property cannot be utilized in the pre-os - the string cannot be decrypted. If you echo the password you see a really long string of characters.
I encountered this in 7.4.2 as well while trying to connect to a Win2k3 datastore server.
The solution that I found was to change the datastore username to include the datastore server (server\username)
??DATA_STORE.USERNAME?? = SomeServer\UserToUse
the k: drive is consistent. its the drive letter that we always use to map to the data store for windows builds to execute the windows installer. however, it's not always mapped, so it will depend on where in the install process you're trying to do the mapping from. this being said, you should be able to consistently map a drive through the appropriate scripting.
the password issue bill mentioned above is, in fact, a known issue. the reason the provisioning infrastructure can achieve this where you cannot, is because bmi talks to the appserver, the appserver generates the appropriate script for the next section of the install process, hands it to bmi, who parses the data and places the script onto the ram drive of the bare-metal machine. in that situation, the encrypted value of the password is properly parsed out and is written in the clear in the final script. this is a script that only exists on the ram drive, so even though we write it in the clear, you never see it since it goes away the second you reboot the bare metal machine.
I tried using K and it's not available when I need it (in custom scripts and post-disk part). I sincerely hope this is being addressed in future releases, but for now we'll just have to suffer through.
I do this all the time. The network credentials are instantiated during every phase of provisioning whether the drive is mapped or not. You should be able to just insert the following at the top of your custom piece:
net use k:
It should map as the password file has already been created.
Add this to the top:
net use Z:
then save the system package and run a provisioning. when it pauses, press CTRL+C to break out of provisioning. If you got no error messages make sure you can change to the k: drive and do a dir on it. other wise try and manually map it with the netuse syntax. Let me know the results.
i think this may have been addressed in a recent hotfix for 7.4.1 - check w/ support on that (the passwd not being encrypted).
Adam, this is exactly what I tried and it did not work in Win PE.