I am attempting to deploy a number of Win 7 instances (a mix of both 32- and 64-bit) all using Win 7 Enterprise. I'm using the Windows AIK to generate an unattend file.
I followed the guide here for the most part. Reading other places online I had come to believe that if I set the <ComputerName>
value to *
that would cause Windows to generate a random computer name when it came up. I also tried with that being an empty string: <ComputerName></ComputerName>
but had the same results of being prompted.
Windows 7 Forums is the largest help and support community, providing friendly help and advice for Microsoft Windows 7 Computers such as Dell, HP, Acer, Asus or a custom build. I created an answer file in Windows SIM. Sysprep Creator is designed to assist with the creation of unattend.xml answer files to be leveraged by Windows 7, Windows 8, Windows 8.1, and Windows 10. Instruction: Launch Sysprep Creator; You will be prompted with a UI, choose the OS and Architecture to build an unattend.xml. Note: If you delete all.xml files from the Vista/7/8/SVR2012/10, etc. Folders, then the default internal E2B unattend.xml will be automatically used and the user will not be prompted to select an xml file. As mentioned earlier, this online Windows Answer File Generator can be used to create Unattend.xml file for Windows 10, Windows 8, Windows 8.1, Windows 7, Office 2010, Office 2013, Server 2008/R2, and Server 2012/R2.
I seem, so far, to be unable to get it to ever respect that field in my unattend file. Whether I put *
or some other string like test_name
it always comes up and prompts me for the computer name, and always defaults to PC
.
Here is my unattend.xml file:
I also tried a stripped down unattend file that I was hoping would only set the computer name, but it also did not:
So what am I missing? (Also, the joining to the domain step doesn't seem to be working yet so I may have an error there too, but I haven't tried troubleshooting that symptom yet.)
To use the above file I am running:
1 Answer
Specify also the RegisteredOwner and RegisteredOrganization in the Windows-shell-setup section of the specialize pass.
Windows 7 Unattend File Generator
Also, realize that you cannot deploy the same image to multiple machines without also specifying the /generalize switch in sysprep. This resets SIDs.
Finally, realize that this is a 32-bit unattend file you showed. There is a different one required for 64-bit OS.
AppleoddityAppleoddityNot the answer you're looking for? Browse other questions tagged windows-7windowssysprepunattended or ask your own question.
-->You can use an answer file together with the System Preparation (Sysprep) tool to configure unattended Windows Setup settings. This topic describes some considerations and processes for using answer files together with Sysprep. For more information about Windows components and settings that you can add to an answer file, see the Unattended Windows Setup Reference.
Running Sysprep an Unlimited Number of Times
If you specify a product key, Windows is automatically activated, and you can run the Sysprep command an unlimited number of times. To automatically activate Windows by supplying a product key, specify a valid product key in the Microsoft-Windows-Shell-SetupProductKey
unattend setting during the specialize configuration pass. If you don't automatically activate Windows by providing a product key, Windows prompts the end user for a product key.
Applying Settings in the generalize, auditSystem, and auditUser Configuration Passes
Not all configuration passes run during Windows Setup. The generalize, auditSystem, and auditUser configuration passes are available only when you run Sysprep.
If you add settings to your answer file in these configuration passes, you must run Sysprep to apply these settings as follows:
To apply the settings in the auditSystem and auditUser configuration passes, you must boot in audit mode by using the Sysprep/audit command.
To apply the settings in the generalize configuration pass, you must use the Sysprep/generalize command. The generalize configuration pass removes the system-specific settings so that you can deploy the same image on multiple computers.
For more information, see How Configuration Passes Work.
Caching Answer Files to the Computer
If you install Windows by using an answer file, that answer file is cached to the system. When later configuration passes run, the computer applies settings in that answer file to the system. Because this answer file is cached, when you run the Sysprep command, the system applies settings in the cached answer file. If you use the settings in a different answer file, you can specify a separate Unattend.xml file by using the Sysprep /unattend:<file_name> option. For more information, see Sysprep Command-Line Options. For more information about how to use an implicit answer-file search, seeWindows Setup Automation Overview.
Windows Unattend File
Persisting Plug and Play Device Drivers During the generalize Configuration Pass
You can persist device drivers when you run the Sysprep command together with the /generalize option. To do this, specify the PersistAllDeviceInstalls
setting in the Microsoft-Windows-PnPSysprep component. During the specialize configuration pass, Plug and Play scans the computer for devices, and then installs device drivers for the detected devices. By default, the computer removes these device drivers from the system when you generalize the system. If you set the Microsoft-Windows-PnPSysprepPersistAllDeviceInstalls
setting to true in an answer file, Sysprep doesn't remove the detected device drivers.
Displaying RunSynchronous Actions in an Answer File
In audit mode, you can view the status for Microsoft-Windows-DeploymentRunSynchronous
commands that run during the auditUser configuration pass. The AuditUI window displays the status for commands and provides these:
Visual progress to indicate that an installation is continuing and not suspended.
Visual indication of when and where failures occur. This provides a quick diagnosis if the command doesn't create log files.
If the answer file contains Microsoft-Windows-DeploymentRunSynchronous
commands in the auditUser configuration pass, a list of the commands appears in the AuditUI window. The commands appear in the order that the Microsoft-Windows-DeploymentRunSynchronous
RunSynchronousCommand
Order
setting specifies. Each list item in the user interface is the string from one of these:
Microsoft-Windows-Deployment
RunSynchronous
RunSynchronousCommand
Description
(if present)Microsoft-Windows-Deployment
RunSynchronous
RunSynchronousCommand
Path
Sysprep processes all RunSynchronous
commands in order. If the command succeeds, its related list item receives a green check-mark annotation. If the command fails, its related list item receives a red X annotation. If the command requests a reboot, the AuditUI window appears after the boot, but only unprocessed list items appear. Previously processed items no longer appear in the AuditUI window. If the list of items in the AuditUI window exceeds the height of the display, the list is truncated to the display and doesn't scroll. As a result, you may not be able to see some items.
Windows Setup interprets the return codes as status values in the AuditUI window. A zero value indicates a success. A nonzero value indicates a failure. The return value of the command might affect the behavior of Windows Setup, depending on the value of the Microsoft-Windows-DeploymentRunSynchronous
RunSynchronousCommand
WillReboot setting.
If the WillReboot
command is set to Always:
If the command returns 0, its related list item receives a green check-mark annotation. A reboot immediately occurs.
If the command returns a nonzero number, its related list item receives a red X annotation. A reboot immediately occurs. A nonzero return value isn't treated as a fatal error when
WillReboot
is set to either Always or Never.
If the WillReboot
command is set to Never:
If the command returns 0, its related list item receives a green check-mark annotation.
If the command returns a nonzero number, its related list item receives a red X annotation. A nonzero return value isn't treated as a fatal error when
WillReboot
is set to either Always or Never.
If the WillReboot
command is set to OnRequest:
If the command returns 0, its related list item receives a green check-mark annotation.
If the command returns 1, its related list item receives a green check-mark annotation. A reboot immediately occurs.
If the command returns 2, its related list item temporarily receives a green check-mark annotation. A reboot immediately occurs. After the reboot, the related list item appears again in the AuditUI window without annotation because the command is still in process.
If the command returns other values, a fatal error occurs and a blocking dialog box appears. If the Errorhandler.cmd file is present, no dialog box appears. For more information about the Errorhandler.cmd file, see Add a Custom Script to Windows Setup.