what has worked for us is just putting it in auditmode only, but it seems important that when you put it in auditmode that you make sure that you log into the machine at least once BEFORE injecting an unattend.xml into c:\windows\panther. Otherwise you'll likely get the "username or password incorrect" error, even when you know you have all that exactly right in your unattend.xml. It will take some work to get everything just so so with an unattend.xml. Many things are happening with this. Very important to understand is that by putting it in auditmode, and then using an unattend.xml in the arrangement that landesk needs it, sysprep is sort of running out of order as MS describes in their documentation which pretty much follows what is below:
Configures Windows PE options and basic Windows Setup options. These options can include setting the product key and configuring a disk.
If you require drivers for Windows PE to access the local hard disk drive or a network, use this configuration pass to add drivers to the Windows PE driver store and to reflect boot-critical drivers required by Windows PE.
Applies updates to a Windows image. Also applies packages, including software fixes, language packs, and other security updates.
During this pass, you can add drivers to a Windows image before that image is installed and processes out-of-box device drivers during Windows Setup.
Creates and applies system-specific information. For example, you can configure network settings, international settings, and domain information.
Enables you to minimally configure the sysprep /generalize command, as well as configure other Windows settings that must persist on your reference image.
The sysprep /generalize command removes system-specific information. For example, the unique security ID (SID) and other hardware-specific settings are removed from the image.
The generalize pass runs only if you run the sysprep /generalize command.
Processes unattended Setup settings while Windows is running in system context, before a user logs onto the computer in Audit mode. The auditSystem pass runs only if you boot to Audit mode.
Processes unattended Setup settings after a user logs onto the computer in Audit mode. The auditUser pass runs only if you boot to Audit mode.
Applies settings to Windows before Windows Welcome starts.
So with LANDesk you want to start at auditsystem which is used to get the hook for landesk's LDDriverStore, so that your drivers can be available at the right time and to establish the autoadmin logon creds to get audituser kicked, which immediately follows. In Audituser, this is the chance to do some things like maybe load drivers. You could theoretically kick pnpunattned.exe to load drivers from your own specific folder, if you have a way to identify your hardware. We're working with an all Dell shop, so we use dmidecode.exe to pull data from CMOS which allows isolating the hardware model, which we pre-placed individual driver folders for each hardware model that we needed. Becareful however, certain features may not be available in this mode of sysprep, such as wmi. If wmi were available you might figure out the model of machine in there, but alas it isn't. Most importantly audituser hooks sysprep again to call with generalize and oobe switches and a reboot, and then sysprep picks back up in the generalize section. Generalize needs to have the driver persistance flag, or you'll blast out all the drivers that the system as already previously loaded up from either LANDesk's HII or from your own clever method, but of course what generalize is ultimately going to need to do is reset everything so your machine is unique on the network (SID and all that blah blah - BORING!). Finally generalize chains to Specialize, which is where you can name the computer, join domain, as well as run other stuff if you wanted to. Keep in mind that LANDesk through OSD/provisioning needs to inject into your computername variable, whatever it is that you want the computername to be, but you probably know this. That would techinically have happened already during winPE mode, but its interesting to note that you COULD (as we have done), decide you want to name your computer during the Audituser section. While we were pullling model information in the earlier phase with the dmidecode tool, we also pulled the asset tag information, which we fuze with a prefix for our customer's agency. The result is a computer named from what is tattooed in the CMOS. This is possible because the unattend.xml file can be edited even though its sort of in use. The reason is because its in a different section, which has not been executed yet! That's kind of a fun trick. Finally after specialize reboots the machine, you're going to be in OOBE mode, and there you can run more stuff since it is again going to use autoadmin logon again if you want. Just all depends on your needs. For example, we do not use the sysprep join domain feature, and technically you wouldn't have to if you want to use provisioning to do that, but we wanted an image that can work with or without landesk, so that we can send an image to the manufacturer and have new machines come preloaded and work out of the box without needing to talk to a landesk system if need be. This meant we needed the basics to work within an image itself, like joining the domain, BUT if you use the join domain feature in sysprep its not very secure. The user account password used with it is in clear text only. No option to encrypt it. This is goofy, since the auto admin logon account can be encrypted, but whatever. So we have a special wrapped up executable that of course uses netdom to perform a domain join, which gives us the ability to join to specific OU, and all that. We also clear out an existing account first in case the computer was previously joined. Anyway, hoefully this clears up what is going on with the mode you want to go in, and the order of things with sysprep. Its a bit confusing, but once you get the hang of it, its not too bad. This is what is working for us. There might be a more streamlined approach that others can share, but this will get you working. Remember that your unattend.xml needs to be referring to 64bit and not 32bit stuff. Otherwise things will just NOT happen, so be sure that your unattend is getting those x86's replaced with amd64's You'll see other articles talking about that if you look around on here. You probably already know about it! :-)
I have updated this post