DarkShadows

What I tried Started with a legal Windows XP Pro SP2 OEM license with Genuine COA (not Royalty OEM), brand new out of shrinkwrap. Integrated an XPCD with all required hardware drivers for the target PC. Integrated only a few updates—new Windows installer version, WGA and other related updates. Installed XPCD on target PC, and inspected that all hardware was recognized and working properly. Activated Windows on target PC sucessfully. Copied wpa.dbl and wpa.bak from target PC and integrated them into the $OEM$\$$\System32 folder on XPCD. Integrated all other updates, software applications, tweaks, etc., into XPCD. Deleted Windows XP partition from Target PC and created a new empty one. Installed fully-integrated XPCD on Target PC. The Results As GUI Mode Setup was finishing, just before first user login, the Windows Activation screen appeared and said "You must Activate Windows", which I did. After I activated, installation continued and executed all RunOnceEx items. Questions Does anyone have any ideas of where I went wrong? Does wpa.dbl need to be copied after a reboot? Are there registry settings I should also copy? Might wpa.db_ on the XPCD be overwriting the wpa.dbl copied from $OEM$\$$\System32? I know that the volume ID of the Windows XP partition is going to be different, but that is only one vote out of like ten. the rest should be the same shouldn't it? Thanks in advance for any assistance.

You can find the FileVer.exe command tucked inside of Support.cab on the Windows XP and XP SP2 CD-ROMs. (I believe the version of FileVer.exe is the same on both CDs.) C:\> filever /? Prints file version information. filever [/S] [/V] [/E] [/X] [/B] [/A] [/D] [[drive:][path][filename]] /S Displays files in specified directory and all subdirectories. /V List verbose version information if available. /E List executables only. /X Displays short names generated for non-8dot3 file names. /B Uses bare format (no dir listing). /A Don't display file attributes. /D Don't display file date and time. Consider using the following syntax below. The command below is actually getting the file version of Filever.exe. C:\> filever /A /D filever.exe W32i APP ENU 5.1.2600.0 shp filever.exe So this is no hack command, it actually comes from Microsoft.

Q: Correct me if I'm wrong, but isn't the arrangement below the most complete and safe—allowing one To: Install all three .NET Framework packages: 2.0, 3.0, and 1.1 without issue. Install software packages requiring .NET Framework 2.0 to be installed prior without issue. Install everything in as few passes (i.e. PC reboots) as possible, while accomplishing the above. Text-mode Setup Loads Drivers Copies files required for Setup to the Hard Disk Copies the contents of your $OEM$ folders to the Hard Disk Automatic Reboot GUI-mode Setup Detached Program executes from winnt.sif at T-39 stage Installs Devices Installs Network Installs Start Menu Items Registers Components svcpack.inf executes at T-13 minute stage Install all Hotfixes (except DNF-related) Execute Chain.exe ... Install Apps unrelated to .NET Framework ... Install DNF20.exe here (or from cmdlines.txt later) [*] cmdlines.txt executes at T-12 minute stage Install DNF20.exe here (or from svcpack.inf earlier) Install Apps unrelated to .NET Framework Add registry settings to Default User Profile Create/rename user accounts ... [*] SetupParams executes from winnt.sif at T-9 minute stage [*] Saves Settings [*] Deletes temporary files [*] Automatic Reboot [*] First Logon Windows XP logs in Windows XP loads personal settings for logged in user account (Copied from Default User Profile). GUIRunOnce from winnt.sif and RunOnceEx both execute at the same time. Install any Apps that require DNF20.exe here (e.g. ATI Catalyst Control Center) Install other Apps unrelated to .Net Framework Install any Apps that require DNF20.exe here Install other Apps unrelated to .Net Framework ... Install DNF30.exe here Install DNF11.exe here [*] Windows XP Desktop and Task bar load [*] Manually Reboot the PC — This reboot needs to happen in order for applications that require DNF20 to function properly, since DNF11 installation will "deactivate" DNF20. This is mostly likely a smart thing to do in any case, since many software installations require a reboot in order to function properly. If this isn't feasible, or ideal, then please suggest some alternatives. I'm want to try to install ATI Catalyst Control Center from RunOnceEx, and it requires DNF20.

What I wonder about is the title that's showing in the title bar. Is this a modified version of Silent .NET Maker?Not that it's important at this stage, but the XPS update named as xpsepsc.exe is not supported. You should keep at least "xpsepsc-x86-en-us" in the name. The Command Prompt title is different because I selected some text for the screen grab—Cmd.exe prepends the word "Select" to the prompt's title, whenever you select some text. Other words get prepended as well for other actions. For example, in Vista you will see "Administrator:" prepended to an elevated Command Prompt. The files not being accessed as shown in my screen grab seems to happen a lot on my system for some reason (not just with your script); I think it may have to do with RAID array or HDD write caching or something. It seems to happen a lot when deleting a large number of files or a folder full of files. Renaming xpsepsc.exe to "xpsepsc-x86-en-us" fixed the missing update issue. Your script seems like it is hard coded to execute only "XPSEPSC-x86-en-US.exe". It would be nice if it supported the format: "xpsepsc-KBnnnnnn.exe". That would allow one to eyeball their SNM folder to inventory which knowledge base numbers they are using. You tend to support this convention on most of the files already. I think I also got my wires crossed and tried to install DNF30.exe by mistake from SVCPack, which of course does not work. I have gotten everything working fine now, really nice job on your script!

KB890859: Required. KB931784 replaces some (but not all) of its files, which may be why Windows Update does not flag it for you. authz.dll 5.1.2600.2622 - Current ntkrnlmp.exe 5.1.2600.2622 - Replaced by KB931784 5.1.2600.3093 ntkrnlpa.exe 5.1.2600.2622 - Replaced by KB931784 5.1.2600.3093 ntkrpamp.exe 5.1.2600.2622 - Replaced by KB931784 5.1.2600.3093 ntoskrnl.exe 5.1.2600.2622 - Replaced by KB931784 5.1.2600.3093 user32.dll 5.1.2600.2622 - Current win32k.sys 5.1.2600.2622 - Current winsrv.dll 5.1.2600.2622 - Current Other Updates KB890859: See 1 above KB891781: Required, nothing has replaced this update. No clue why it's not flagged for you. dhtmled.ocx 6.1.0000.9232 - Current KB899587: Required, nothing has replaced this update. No clue why it's not flagged for you. kerberos.dll 5.1.2600.2698 - Current KB899589: Replaced by KB923980--Removed from this list November 14, 2006 (see first post). KB900725: Required. KB928255 replaces some (but not all) of its files, which may be why Windows Update does not flag it for you. linkinfo.dll 5.1.2600.2751 - Current shell32.dll 6.0.2900.2763 - Replaced By KB928255 6.0.2900.3051 shlwapi.dll 6.0.2900.2753 - Current winsrv.dll 5.1.2600.2751 - Current xpsp3res.dll 5.1.2600.2764 - Replaced By KB928255 5.1.2600.3051 KB902400 Required. And it is listed in the first post in this thread: KB914389: Required, nothing has replaced this update. No clue why it's not flagged for you. mrxsmb.sys 5.1.2600.2902 - Current rdbss.sys 5.1.2600.2902 - Current KB939373: Windows Update doesn't list this one for me either. However it has a newer .dll version. w3svc.dll 5.1.2600.3163 - Current (stock version is 5.1.2600.2180) KB917953: Required, nothing has replaced this update. No clue why it's not flagged for you. tcpip.sys 5.1.2600.2892 - Current KB918118: Required, nothing has replaced this update. No clue why it's not flagged for you. msftedit.dll 5.41.15.1514 - Current riched20.dll 5.30.23.1228 - Current KB891122: I'm still testing if installing WMP11 makes this obsolete. I'll post back when I leanr more. [*] Myself, I rely on three lists: Windows Update Downloader (WUD) This Thread Microsoft/Windows Update I also sometimes resort to extracting updates and comparing files. There are also many updates not listed on any of these lists which, IMO, are important. I found a list of some of these a long time ago (can't remember where now). But I have verified through file version comparison, that many are still valid today. Most of these fix specific issues where a combination of things must conspire to trigger an issue. In the end, it is your computer, so do your home work!

Is it possible to install IE7 from svcpack.inf, followed by the cumulative IE update (also from svcpack.inf)? Or is a reboot required before the IE7 updates can be installed?

I'm aware that the latest IE 7 download doesn't pose any RunOnceEx issue, since WGA is no longer required. But this doesn't answer my question. If there is an IE7 Cumulative Roll-up to install (which there is), then when are you installing it? You aren't integrating it into SVCPack.inf at T-13 are you? Wouldn't that mean that IE7 would install (from RunOnceEx) after its updates at T-13? So can IE7 be added first in svcpack.inf, before its hotfixes? Has anyone done this successfully?

When you folks install IE7 at the end of RunOnceEx, how are you integrating the IE7 updates? Or, are you?

I'm wondering if someone can help me out here. I'm using the default SNM.ini file. I downloaded everything to a folder path with no spaces. Below is a Tree report of my folder listing. I have no search indexers running or search engines installed. I have ensured I have nothing else accessing these files, by closing all non-essential processes in Task Manager. I have only a copy of Windows Explorer open, when I click on the SNM.cmd file. M:\SLIPSTREAM\DOTNET\SMN | SNM.cmd | _SNM.ini | _SNM - Backup.ini | 7za.exe | 7zS.sfx | dotnetfx.exe | dotnetfx2.exe | dotnetfx3.exe | hidcon.exe | msistub.exe | msxml6-KB933579.exe | NDP1.1sp1-KB867460.exe | NDP1.1sp1-KB886903.exe | NDP1.1sp1-KB928366.exe | NDP20-KB928365.exe | NetFX30-KB932471.exe | readme.txt | xpsepsc.exe | +---DNF2 | \---DNF20 | \---Win | \---Microsoft.NET | \---Framework | \---URTInstallPath | \---ASP.NETWebAdminFiles \---OUT1 DNF11.exe (11,300KB) DNF20.exe (39,004KB) DNF30.exe (21,969KB) As you can see in the attached screen grab, SNM.cmd cannot access one of the files above, apparently for .Net 3.0. When I install the resulting DNF30.exe, Windows Update still reports that I require KB933579. So I'm assuming that is the file that does not get slipstreamed into the installer correctly. I have tried re-downloading all the files, ensuring each was for Windows XP SP2 (x86). I have run this script several times and each time it chokes on the same file. Am I do something wrong, or is the script in a race condition? Any help is appreciated, Thanks!

Then again, perhaps not. According to this KB article, MSXML 6.0 is added with .Net Framework 3.0. One would think that the earlier DNF versions might use an earlier version of msxml, but apparently not. BTW, your script simply rocks!

The first post in the thread only lists: Am I wrong, or shouldn't SNM also support the following? msxml4-KB936181.exe (released in August 2007)

ATI NOTES: Catalyst 7.4 does not support X1600 Pro with HDMI, please continue to use Catalyst 7.3. 32-bit XP drivers 64-bit XP drivers 32-bit Vista drivers 64-bit Vista drivers

Catalyst Drivers v4.7 are out! My Sapphire X1950 GT is up and running Vista Aero finally (two months after I purchased it).

Just an advisory for others who might own an ATI Radeon 1950GT video card (by ATI or other ATI-based brand). The Catalyst v7.2 release notes on the ATI-AMD web site indicated that the ATI Radeon 1950GT cards were not supported by Catalyst v7.2, but would be supported by Catalyst v7.3 drivers. Catalyst v7.2 will not even install on Vista with my Sapphire ATI Radeon 1950GT installed. Catalyst v7.3 installs, but on the reboot it errors, stating a compatible video card is not installed. I placed a technical support call to ATI last week, on which a technician informed me that the 1950GT is not actually supported by Catalyst v7.3 drivers. Yet the current release notes on the ATI-AMD web site do not warn of this.

I just noticed that every Program Files group I've created with an .inf file is user-based, not under All Users. Q: Using an .inf file, how can you create program groups/shortcuts under each of these? All Users Profile Default User's Profile Current User's Profile I know if the .inf is run at a certain point of Windows Setup, that Default User will be the current user, so groups and shortcuts will end up under each new user account created afterward. But I'm looking for an .inf file syntax answer here. Thanks in advance for any ideas!

Thanks Yzöwl! I thought about using short file names too. But I was wondering if there was a means to handle file names with spaces. I guess not. I tried sticking multiple quotes everywhere to no avail. It seems that .inf file conventions can not handle file names with spaces (though they do handle long file names without them). Short names get tricky if one has a folder full of files with similarly named files. On the plus side, the Windows XP shortcut ends up pointing to the long file name, even though the short name was specified.

Q: Does anyone know how to create a shortcut.inf, where the target file has spaces in its file name? Here's the Shortcut.inf: [Version] Signature=$Windows NT$ Provider=%INF-Creator% [DefaultInstall] ProfileItems = UL_PI_11_PDF.Shortcut,UL_GA_5_PDF.Shortcut,UL_Album_11_PDF.Shortcut [UL_PI_11_PDF.Shortcut] Name = %UL_PI_11_Name% CmdLine = 16422,"%UL_PI_Man_Dir%","%UL_PI_11_PDF%" SubDir = "%UL_PI_Man_Grp%" InfoTip = "%UL_PI_11_Tip%" [UL_GA_5_PDF.Shortcut] Name = %UL_GA_5_Name% CmdLine = 16422,"%UL_PI_Man_Dir%","%UL_GA_5_PDF%" SubDir = "%UL_PI_Man_Grp%" InfoTip = "%UL_GA_5_Tip%" [UL_Album_11_PDF.Shortcut] Name = "%UL_Album_11_Name%" CmdLine = 16422,"%UL_PI_Man_Dir%","%UL_Album_11_PDF%" SubDir = "%UL_PI_Man_Grp%" InfoTip = "%UL_Album_11_Tip%" [Strings] INF-Creator = "Kenneth R. Alcock" UL_PI_Man_Dir = "Ulead Systems\Ulead PhotoImpact 11\Manual" UL_PI_Man_Grp = "Digital Imaging\Ulead PhotoImpact 11\Manuals And Help" UL_PI_11_PDF = "PI-11 MANUAL.pdf" UL_PI_11_Name = "PhotoImpact 11 Manual" UL_PI_11_Tip = "Ulead PhotoImpact 11 User Manual" UL_GA_5_PDF = "GA-5 MANUAL.pdf" UL_GA_5_Name = "GIF Animator 5 Manual" UL_GA_5_Tip = "Ulead GIF Animator 5 User Manual" UL_Album_11_PDF = "ALBUM-11.pdf" UL_Album_11_Name = "Album 11 Manual" UL_Album_11_Tip = "Ulead Album 11 User Manual" Both of the .pdf files whose names contain spaces get messed up. For example, this is what happens to the target for the file named "PI-11 MANUAL.pdf": "C:\Program Files\Ulead Systems\Ulead PhotoImpact 11\Manual\PI-11" MANUAL.pdf Notice that Windows XP SP2 places the closing quote in the middle of the file name, before the space in the file name. By the way, I didn't name the files with spaces, they get installed that way. Any help is appreciated!

Yeah Yeah. This is my brain... and this my brain on next to no sleep Thanks Yzöwl!

Arrrrrgggggggggggggh! Whew, that felt good! I'm having exactly the same issue as the first post in this thread, and it is baffling me. This is my shortcut.inf file: [Version] Signature=$Windows NT$ Provider=%INF-Creator% [DefaultInstall] ProfileItems = DOpusExe, DOpusHelp [DOpusExe] Name = %DOpusExeDescription% CmdLine = 16422,%DOpusExeFolder%, %DOpusExe% SubDir = %DOpusGroup% InfoTip = %DOpusExeTip% [DOpusHelp] Name = %DOpusHelpDescription% CmdLine = 16422,%DOpusHelpFolder%, %DOpusHelp% SubDir = %DOpusGroup% InfoTip = %DOpusHelpTip% [Strings] INF-Creator = "DarkShadows" DOpusGroup = "TEST-File Management\Directory Opus" DOpusExe = "dopus.exe" DOpusExeDescription = "Directory Opus" DOpusExeFolder = "GPSoftware\Directory Opus" DOpusExeTip = "The ultimate Windows Explorer replacement, and a while lot more!" DOpusHelp = "dopus.hlp" DOpusHelpDescription = "Directory Opus" DOpusHelpFolder = "GPSoftware\Directory Opus\Help" DOpusHelpTip = "Contains most syntax-related information." What happens is that only the DOpusHelp shortcut gets created. But here's what's even more weird: if I comment out the DOpusHelp section entirely, then the DOpusExe works fine. It's as if I can only create one shortcut per .inf file? I have already tried moving the DOpusHelp section before the DOpusExe section—same results. Can anybody see what I might have done wrong here? I should add that I am merely testing this file by right-clicking it and selecting Install from the context menu in Windows Explorer.

KB885835 & KB885250 Have a conflict KB912812 also has a similar conflict with several other hotfixes. These conflicts each involve a file that an earlier hotfix also has an updated version of. That means an earlier hotfix will update a given file and the later one will also try to update it. Normally, this works okay. However, with these two Hotfixes, Microsoft messed up in their /Integrate code. If you installed the hotfixes, there would be no problem. But it is integrating them that is the problem. When you try to integrate KB885835 it sees a that an updated version of one of its files is already listed inside of HFINT.DAT file in i386\svcpack, and it decides not to integrate. A similar thing happens with KB912812. You have to trick out the /integrate code as described in the linked posts above.

@cancerface Man have you been busy! I take a few days off and you've got your own thread on here! I just skimmed the other thread. I try out your utility tomorrow or the next day, but from what I see it looks great! I'll jump over to the other thread now.

I'll look forward to what you can come up with. Jotnar's code and mine are doing the same things. He has added some password rules as well to those accounts, which is a good idea. I'll add similar code to my script. When I asked about disabling from the command line, I was thinking of the disable this account option on the Usersandpasswords2 dialog (accessible from Start Menu > Run). However, when I looked through the help on all of the Net commands, I did not see a command line equivalent.

Try QFECheck from Microsoft.

Let me first say, thanks for all the great ideas you two! Second, it's a shame Microsoft doesn't support encrypted password with Autologon. I'm sorry but that is so short-sighted to me. If they could justify the development of encrypted passwords they must've acknowledged that as a reasonable business security requirement. But Microsoft seems to think that all PCs are built on a network. But this is simply not the case in a small office home office environment. Actually, as I was typing my last post, I was thinking in the back of my mind about a process that was something along these lines. However, I kept hitting stumbling blocks (reasons it might not work). Forgive me, for being laborious here. I'm going to just think-out-loud-and-type through the steps to you've suggested to ensure I accurately envision how this would all work, or see if I can identify and/or mitigate any concerns I had before (when I was thinking of a similar process). Run unattended using an encrypted password in winnt.sif I was about to say that there is no real point to encrypting this password if AutoLogon is used. But then, upon further review of the subsequent steps, I realized the PC would never actually autologon using this account. So this password is encrypted only to secure (as in lock everyone out of) the default Administrator account (which will also be renamed to say "OldAdmin" and moved inside of a non-privileged group later). Since we are never going to log on with this account, this password should be very long and strong (lots of special characters) and of course encrypted. (It's too bad this password can only be produced with Setup Manager, else it is just begging to be randomized as well.) No need to code this, this is done within Setup Manager and winnt.sif. Q: Should winnt.sif include the AutoLogon setting for the purpose of your program? Delete or rename the default Administrator (and the default Guest account) @T12. I think I'm going to opt for renaming this user account and locking it down, mainly because I don't want to "break" Windows XP. There is no need to develop something new in order to rename the user account; renuser.exe does this already. Furthermore, since this account is essentially being disabled, it can be randomly renamed from PC to PC, and randomly assigned a password; both easily done with the Net LOCALGROUP and Net USER commands respectively, both with the aide of the Environmental Variable %RANDOM% (which generates a semi-random number). Q: Is there a command to disable an account via the command prompt in Windows XP? Run a script to create the new administrator account (e.g. "NewAdmin") @T12. Since this user account's password will be reset later (and would be stored in the registry unencrypted) anyway, there is really no point to even setting a password at this stage. Thus creating this user and granting it administrator privileges is easily done with the Net USER and Net LOCALGROUP commands respectively. I'm also not-at-all concerned about the customers building their own computer with this account when it does not have a password—only when the technician's password is set do I care to protect it. Thus far we have been able to do every stage with existing technology, which at this point is setting an encrypted password in winnt.sif, and running a script like this below::: Create an unprivileged security group. Set Disabled=D%RANDOM%I%RANDOM%S%RANDOM%A%RANDOM%B%RANDOM%L%RANDOM%E%RANDOM%D Net LOCALGROUP "%Disabled%" /ADD /COMMENT:"This group contains all default Windows user accounts that have been disabled. Do not grant this group any permissions on your system!" :: Move the default Administrator and Guest accounts to the unprivileged group. Net LOCALGROUP "%Disabled%" "Administrator" /Add Net LOCALGROUP "Administrators" "Administrator" /Delete Net LOCALGROUP "%Disabled%" "Guest" /Add Net LOCALGROUP "Guests" "Guest" /Delete :: Set semi-random and difficult passwords for default Administrator and Guest accounts. Net USER "Administrator" "#%RANDOM%@%RANDOM%*%RANDOM%~%RANDOM%&%RANDOM%$" Net USER "Guest" "#%RANDOM%@%RANDOM%*%RANDOM%~%RANDOM%&%RANDOM%$" :: Rename the default Administrator account (requires Renuser.exe). :: NOTE: the new name must always be enclosed in quotes! Renuser.exe Administrator "A%RANDOM%D%RANDOM%M%RANDOM%I%RANDOM%N" Renuser.exe Guest "G%RANDOM%U%RANDOM%E%RANDOM%S%RANDOM%T" :: Create a new System Administration account, and add it to the Administrators group. Net User NewAdmin /add /fullname:"System Administrator, Fabrikam Co." Net LOCALGROUP "Administrators" NewAdmin /Add :: Create any other New User Accounts here. :: ------------------------------------------------------------------------ Set Autologon to NewAdmin account @T12. Q: This I do not know how to do. Can you help with this one? I tried to figure out what the registry settings governed this using RegSnap, but I don't think I got it correct. Now it should be easier, without a password requirement. First Boot into Windows Full GUI Windows logs on as NewAdmin – Windows should do this automatically, assuming the previous step works as planned. Execute RunOnceEx and GUIRunOnce – Windows should do this automatically, assuming the systems engineer (that would be me) builds the XPCD correctly. Execute any other cleanup scripts – Windows should do this automatically, assuming the systems engineer (that would be me) builds the XPCD correctly. Change NewAdmin's password to something new and more secure. Q: This I do not know how to do. Can you help with this one? I can code, but I have yet to play with Windows Scripting Host. So I could use the help here. Here are some ideas I have thought about: This code should be "seeded" with an secret portion of the password (changeable upon compilation, or through some other method). The other portion of the password should come from an environmental variable. The name of this environmental variable should be passed as a parameter when the program is executed. The program should write a log file detailing what happened and when (minus the new password of course, perhaps with version or build # so as to give a clue of the password seed value). Write a status code to a registry key somewhere that can be referenced that each step succeeded. [*] Clear out the autologon details for NewAdmin – This should be a simple registry file import. [*] Hide NewAdmin from the Welcome screen – This should be a simple registry file import. [*] Reboot the PC, ready for customer to logon – Windows should do this automatically, assuming the systems engineer (that would be me) builds the XPCD correctly. Any subsequent system administration duties performed after this stage, are assumed to be entirely manual operations. I believe this would have the best case (given all of the requirements and constraints). The critical success factor would be how securely the password seed is stored in the code that assigns it.

Rename default admin before first GUI logon – correct, this is the best time to rename this because you rename the associated folders as well, and before installing a bunch of software. Enable autologon – correct, but this will be disabled after all software is installed, and before the next reboot. Login with that (the renamed default Administrator, or the newly created NewAdmin) account – correct, one time only. Do whatever (create users etc) – execute installations from GUIRunOnce and RunOnceEx without having to manually logon. However, all user accounts are created in a script launched from CmdLines.txt at T-12. Disable Autologon and hide the default Administrator account (and/or the newly created NewAdmin account) on the Welcome Screen – correct I plan to have this first Autologon automatically disable itself before it reboots the PC again (but after all the software is installed). In other words, I plan no human-interactive actions during the AutoLogon session. Because it presents a security risk.The Admin password must be unencrypted in the winnt.sif file to support AutoLogon. If someone new what they were looking for, they would have easy access to this password, by simply opening winnt.sif. It is already fairly easy to tell what the New Administrator's user name is by looking at the folders in %SystemDrive%\Documents and Settings. So you would also have easy access to the password, so there goes security out the window. While the Admin password can be encrypted in winnt.sif, doing so disables AutoLogon. I wanted both an encrypted password and AutoLogon. What you are working on sounds very impressive, but it seems it might have a similar vulnerability, though in the registry. From what you said before, using your code stores the password for NewAdmin unencrypted in the registry. Thus during rebuilding the PC from the XPCD, this password is once again accessible, if a user knows what to look for. (I do not know this is the case in your solution, it just sounded like it might be to me). So either way, the winnt.sif autologon, or your solution, the rebuild CD would go to my customers with an unencrypted system administrator password on it. I want them to have the XPCD, but not the System Administration account password. I create their own account (at T-13), with Admin privileges, but I do not want them to have access to the System Administration account that is created for the people who maintain the PC. This way we can ensure that one account remains pristine. Of course, the customer could always go in and reset the password on this account from their own account, or even delete this account altogether. But this is okay with us. Customers are free to change this password, or even delete the account itself—doing so means that they have severed their support contract with us. We just do not want them (or anyone) to learn what our system administrator password is, since it is somewhat standard across different customers. For those customers who maintain service contracts with us, we want unfettered access to their PCs so we can perform software upgrades, maintenance, etc. This is all for customers in small businesses where we are not connected by a single Domain. A technician walks up to the PC to perform maintenance. We want the techs logging into a system administration account, and leave the customer accounts alone. Conversely, we want the customer in their own account and leave the system administration account alone. This would be okay if we always installed the XPCD. However, the customer gets a copy of the XPCD to rebuild their PC (in case something terrible happens and we cannot get out to them, or they do not retain support services from us). Thus if/when they re-install XPCD onto the system, our password would be out in the open, unencrypted, during that first reboot. We do not mind that customers can build the system from the XPCD using our System Administration account (the default MS one or a newly created one). We do not care that they can change this System Administration account password, or even delete the account. If they decide to lock out our support techs (by changing our System Administrator's password, or by deleting our account), they are severing their support relationship with us, which is fine—it is their PC. We just do not want them to know our password, that is for our support techs. So we want the XPCD to configure the system for us to support the PC, but hide our password from the customer.