DS7.1 Scripted OS Install - product BUG

[Migration User]

I've run into an issue with DS 7.1 where, upon doing a Scripted OS Install of Windows 7, the Autologon portion of Sysprep will fail when using a custom answer file. My answer file is pretty basic, but a couple particulars about it are below:

* I'm using many of the tokens taken from the sample SOI unattend files, such as @Display, @license, @DiskID, etc.

* I'm creating only a local Administrator account, no secondary account (bypassing the user accounts creation process)

* The local Administrator account has special characters in it, specifically @ and 0 (i.e., p@ssw0rd)

This is indeed a problem with DS 7.1 SP1, and not with my answer file. When I enter automation and take a look at the X:\unattend.xml answer file, I see that where my password used to be, it has been truncated to the following:

           <AutoLogon>
          <Password>
                 <Value>p  >
                 <PlainText>true</PlainText>
              </Password>
          <Username>Administrator</Username>
          <Enabled>true</Enabled>
          <LogonCount>2</LogonCount>
           </AutoLogon>
            <UserAccounts>
                <AdministratorPassword>
                    <Value>p  </Value>
                    <PlainText>true</PlainText>
                </AdministratorPassword>

Well, after writing this, a big lightbulb went off in my head. I know exactly why these values are being truncated. Deployment Server has got to be interpreting the @ in my passwords for another token and then garbling up the value. One way I have found to circumvent this flaw is to use an encrypted password for the <AdministratorPassword> value, with the <Plaintext>False entry. Unfortunately, I haven't been able to get an encrypted password to work for the Autologon entry as well. So while my Administrator password ends up being correct in the unattended install, it still tries to logon unsucessfully as local Administrator.

So, here's my question: is there a way to use quotes or the like around the value in an answer file so that DS passes the value AS-IS, and doesn't try to "interpret" it?

Ah, the joys of using Altiris! :o)

[Migration User]

You should open a ticket with support to address this issue.

[arjain]

Could you share the DS version you are using, this is working fine on latest release

[Migration User]

I have this same type issue and have logged it under another discussion.  When I push a SYSPREPed image out the autologon doesnt complete. I have to type  in the password manually and then SYSPREP completes and the systems restarts and all is fine.

I am using DS7.1SP1 with NS7.1. 

[Migration User]

Altiris DS 7.1 SP1 7.1.1895 on NS 7.1 as well, all products are current according to SIM. It's definitely happening in my environment, my passwords, which are correct in my custom unattend.xml answer file, are being converted to "p  ". It isn't precisely p@ssw0rd, but similar enough. Using a simple password of password does bypass the problem.

I intend on contacting support ASAP, but I won't be able to do so until the coming Monday at the very earliest.

[Migration User]

Do you have DeployAnywhere checked on the deploy image? DeployAnywhere could be causing the issue.

[Migration User]

Please update this as and when you here from Support.

Thanks

[Migration User]

I ahve an open ticket with SYMANTEC the issue I mentioned above. " Same Problem I am having deploying a SYSPREPed Image.  I talked to 2 Symantec Techs today and they are off exploring it.  I referred them to this posting and mine.  Will inform when I get more info.

[Migration User]

What is the version of DS?  the latest one is DS 7.1 SP1a I believe is build 1895.

[Migration User]

Nelo - According to my testing, Wolfpack's problem does appear to be the result of DeployAnywhere. While I experience his same issue, I'm now inclined to believe it is a completely separate issue from my SOI problem, and we only confused the two because I reported that I experienced his problem and my problem at the same time. (Gee, that would make that the fourth separate bug I've stumbled upon in this product in the last 3 weeks. WHY this product was released out of beta, I don't know. I guess there weren't enough beta testers to test it fully? All I know is that I've spent so much time troubleshooting this product, it's a wonder I haven't been fired yet.) But given the fact that I've run into nearly every other problem with this product that Wolfpack has reported, it's a pretty good bet that our Autologon problems are related.

DS6.9 Users: Upgrade at your own risk! Seriously. :-|

</END RANT>

Okay, So if DeployAnwhere is the culprit, where do we go from here? DeployAnywhere in DS7.1 was supposed to be the Holy Grail. Are we to go back to manually FIRMing drivers into our images? If that is indeed the case, I've got a DS6.9 server that will serve that purpose wonderfully.

[Migration User]

I spoked to Symantec support today - they confirmed that this is an issue with DS 7.1 SP1a using @'s and other special characters in the answer file, for the reason that I mentioned. DS sees the @ in the password and thinks it's a wildcard. I forget the other special characters they said not to use - probably %. Your best bet is to just use a simple, a-z,0-9 password for deployment and then change it later through Group Policy.