Deployment Solution

I assume this is for Windows XP.  The password specified in your sysprep.inf file is incorrect.  You'll need to update this file.  This is in the [GuiUnattended] section of the file.

Sorry I left out that part.  The Host Server for DS7.1SP1 is Windows 2008R2 64Bit and capturing and deploying an image from Windows 7 Professional Laptops. 

This is probably located in the \windows\panther folder in the unattend.xml file.  You may need to rebuild this file.

I didnt create that unattend file.  I am guessing Altiris DS 7.1 SP1 creates it. I will dig into the file so more and look at the entries.  The password was correct in the attend.xml. 

I am thinking since we use GPO extensively to change the Administrator account name and password that may be part of the problem.  We have to conform to very strict security settings.

GPO's would only be an issue if the machine is already part of a domain.  You definitely don't want that.  You should always join a domain after imaging, not before.

I pretty much did my sysprep image separate from DS and then used DS to take the image.

Yes the Computers containing the master images are in a domain.

So your recommendation is to remove the master computer from the domain, Capture the Image either with DS7.1

Or Run the MS SYSPREP and import the image and then deploy to the the other workstations?

Do you leave the Symantec Management Agents on the image?

I will admit I have only been working on DS 7.1SP1 for a few weeks, learning on the fly.

I have to admit, we haven't made the leap to DS7.x yet.  We are still running at 6.9.  My practices in 6.9 are to build the source computer (again, not in the domain), then utilize the sysprep.  Take the image.

 

The agents get installed as a post script via Sysprep after the machine has been imaged.  It's been our experience it is better to install the latest version of the agent from the server rather than having to update the image everytime you do an update to Altiris.

Ok capturing the image from a computer that is not in the domain and then deploying the image to a computer in the domain resulted in the same result.  It still did not pick up the Password for the Administrator Account correctly since I get a user name or password incorrect error when the job tries to log onto the system.  When I type in the password it logs on and everything runs to completation.  I know it is just a matter of finding where in the unattend.xml that the job is creating I need to fix the password.  But since this unattend.xml is created during the deployment stage it is almost impossible to make changes to it without the use of a script.

Fortunately this is not a show stopper just a pain since the first time someone logs on the process completes and reboot the computer.

FYI DS7.1SP1 w/NS7.1 is a whole different environment than 6.9.

Wolfpack, I have the same issue as you. The question is, where is DS supplying the answer file info from? The only Windows 7 answer files I've found (so far) are located here:

\\altirisserver\NSCap\bin\Win32\X86\Deployment\Sample\SOI\AnswerFile\ 

There's two files here for each OS, an Unattend_Default and an Unattend_Inventory. I'm guessing DS uses these for Scripted OS Installs, but perhaps it uses them during the Prepare for Imaging job as well? I see that the password used in these files for the Administrator account is password. I'm going to try changing my local Administrator account to password and see if that fixes the issue. I have a group policy to change the local admin password upon joining the domain anyhow, so it doesn't matter much to me. Alternately, if this works, I can change the answer files.

I thought the administrator account was disabled by default on WIndows 7 after sysprep.  Could that be why its not working?

No, there are settings in the unattended answer file to enable the local Administrator account.

Also, it's apparent from the OP's first post that the Administrator account is already enabled, as he is able to log into it manually.

EDIT: After a little more thought, I'm not so sure anymore. If the OP is relying on Group Policy to enable the local Administrator account, then it's possible that Sysprep tries to Autologon prior to Group Policy Preferences actually enabling and setting the local Administrator password. This is precisely the behaviour I'm observing as well, and I am also setting the local Administrator account through GPP.

I'm going to explore that avenue and see what happens.

 

Okay, I've found a little bit more. Looking in the Security Event Log of an imaged computer, I see an Event ID 4648,

"A logon was attempted using explicit credentials."

The account attempted was my Altiris Application Identity Account, and not the account I specified in the Deploy Image task for joining the domain. Could this be what's causing that logon failure?

Wolfpack - do you have a similar entry in your Security Event Log of an afflicted imaged computer?

I remember when we were creating our first XP images with DS 6.9, we ran into a similar problem to this. In our imaging process, in order for DS to configure the machine, join the domain, install agents, etc., we had to give that domain account explicit access to the computer. That is, we joined our master image PC to the domain, then added that domain account into the master image's Local Administrators group, then removed the PC from the domain. I wonder if that would correct this issue as well.

It sure would be nice if Symantec had a document available that detailed the entire step-by-step process of what's going on behind the scenes when you send the tasks Prepare, Create, and Deploy an Image. I know that's a tall order, but there is just so much going on under the hood that I don't understand.

(EDIT: I found a document similar to what I was looking for. It's pretty indepth on a lot of DS, but it seems to gloss over a bit in the imaging process. Hopefully there will be a future revision?)

No I dont have that error code in my event log.

It is trying to log on using the local Administrator account but not getting the password correct.

The only thing the GPO does is rename the administrator account

I am still trying differnent scenarios but no luck so far.

The computers being imaged are members of a domain so the imaging process collects that data and then adds them back into the domain and OU, that part is working, it is just that since this is a SYSPREP Image it needs to do some clean up and for some reason requires a log on to do that.

 

Yes there are special characters in the passwords.

How are you changing the password with Group Policy?

With our Group Policy Passwords have to be 16 char, 2 Upper case, 2 lower case, 2 numbers and 2 special characters. So setting a password as password would only work if the computer is not a member of the domain which would be the case of a Master Image.  I could remove it from the domain and set the password.

Please read this post. If your situation is similar to mine, my guess is that when the unattend.xml answer file gets created on the fly by DS, Deployment Server interprets your @ sign (assuming you have an @) in the value for the Autologon password and thinks it's a token and not the actual value.

https://www-secure.symantec.com/connect/forums/ds71-scripted-os-install-product-bug

I'm setting the password through Group Policy Preferences. Matter of fact, I'm doing ALL my Windows 7 customizations through Group Policy, I'm done with making manual modifications to an image.

Do you have rights in AD to set up an OU with Blocked Inheritance so it doesn't receive all your group policies? Then you could keep it on the domain and set the password as you like without it getting changed.

Wolfpack, are there special characters in your local Administrator password? I'm having a problem when doing a Scripted OS install, DS truncates the password when passing it to automation. I then end up in your same situation, where Autologon tries to log in as Administrator, but the password has been mangled, and the login fails. I've gotten past this error by making my master image's local Administrator password "password", then I change it later through Group Policy. I hate having such a simple password for any length of time, but at least it's working.

Well, special characters don't seem to be the culprit, but DeployAnywhere does. I tried a Deploy job with a simple password - same problem. Turn off DeployAnywhere, however, and the problem goes away. Well - that's a real problem as we NEED DeployAnywhere. So what next? Anything from support yet?

edit: Thought I had this problem fixed; I was working with tech support on this issue and thought we had it resolved. It's not. Problem is still ongoing; I have a ticket open with Symantec as well.

I am so frustrated with Symantec tech support, I could scream. It turns out that I WOULD have had this problem resolved on June 30th when I thought I did, had I received correct instructions from tech support. Instead I issued my hasty, embarrassing, and incorrect retraction. Here's what happened:

Originally, tech support gave me a replacement deployanwhere.exe file, and instructed me to replace the file at this location:

C:\Program Files\Altiris\Altiris Agent\Agents\Deployment\Task Handler\ghost

I tried a test image job – it worked! I got excited, and posted online that the problem was resolved. Then, I came to realize I actually had turned DeployAnywhere OFF in my Image task. I tried the job with DA turned on, and the problem still existed. So, I issued my retraction that what I thought had fixed the problem actually didn’t.

Symantec said they’d get back to me, but time progressed and there was little word from them. I started digging around the Deployment folder, and I noticed there was another deployanywhere.exe, located one folder below the original in the x86 folder. There’s also a deployanywhere64.exe in the x64 folder. So, we have 3 deployanwhere.exe’s located in the following folders:

C:\Program Files\Altiris\Altiris Agent\Agents\Deployment\Task Handler\ghost

C:\Program Files\Altiris\Altiris Agent\Agents\Deployment\Task Handler\ghost\x86

C:\Program Files\Altiris\Altiris Agent\Agents\Deployment\Task Handler\ghost\x64

I asked my Symantec support rep in an e-mail if I needed to replace those deployanywhere’s as well. My question went unanswered. Meanwhile, they sent me a second deployanywhere.exe. I tried using that at the location they told me, and of course it failed as well. Finally, today out of desperation, I tried replacing the deployanywhere.exe located at \Ghost\x86 as well. What do you know? The problem was solved! 

I just tried running a 32-bit and a 64-bit imaging job. The 32-bit one worked; my 64-bit one is still broken. This behaviour is completely consistent with the facts above. I could have had this problem solved nearly two weeks ago, if only Symantec support had given me the correct instructions when I was speaking to them.

So, now all that's left is to call Symantec and ask them for a replacement deployanywhere64.exe for the x64 folder as well.

This thread has spread out a bit, so here are a few things to consider.

 

1)

As someone mentioned, we have problems with using some special characters in passwords (anywhere really) that can really muck things up.  @xxxxx is how we identify special tokens to be replaced in these files, and if you have an @ symbol in there, we end up blanking it out, obviously screwing up the password. There is NO WORKAROUND for this at this time.  You'll have to use a different password.  For instance, you could create an account with almost no rights at all with a really generic password just for deployments and then push out some sort of change after-the-fact, which isn't pretty, but is all we can offer right now.

2)

We also have had issues (depending on the release) with complex OU's.  Long ones specifically.  We truncate, and things get all messed up.  I don't know exactly where that problem stands at this time (eg, has it been fixed?  if so, what release?), and I know we were hammering it pretty hard a while back, so it could be fixed, but that was a problem before.

3)

We have problems with DeployAnywhere when you've added drivers that are not NIC/Mass Storage.  The recent release that allows support for other driver types has created new issues with DA that we're following and trying to find/dig-up.  I don't know where those stand other than they're current.  If you've added special drivers, try disabling DA just to see if you can get the imaging to work.  Just be sure you're going to like systems (or same system) in your testing.

THUS

To help troubleshoot this kind of thing, build a test environment (should have one anyway) and try imaging using a small OU and a simple password to see if the problem persists.  Then try a complex password and/or deep OU and see if it recurs.  Oh, and test without DA.  Need it or not, we need to KNOW if that is the culprit.

 

Because the thread has spread out a bit (3 possible issues now?), you may consider new threads to help get to the bottom of whatever specific issue you're seeing, or a 4th that may not even be on the list. ;-)

We have the same problem. For some reason Deployment job tries and fails to log in with Ghostuser credentials. We are using "Generate Sysprep configuration file using inventory data" option. Problem only occurs when Deploy Anywhere is chosen.

We have not long Ou-names or special characters in password. Anybody has any succestions?