anyweb

try setting the wds service to start with delayed start

what do you need to run once ? have you looked at any of the built in commands via unattend.xml check this post on msfn.org http://www.msfn.org/board/topic/139150-working-unattendxml-and-applications-installs/ and I quote: also checkout this from Technet > about SetupComplete.cmd > http://technet.microsoft.com/en-us/library/cc766314%28WS.10%29.aspx Add a Custom Script to Windows Setup You can add custom scripts to Windows Setup that can be configured to run in different circumstances. You can run a custom script: * Immediately after Windows Setup completes. * If Windows Setup encounters a fatal error. Run a Custom Script after Windows Setup Completes You can make further customizations after Windows Setup completes by adding commands to the %WINDIR%\Setup\Scripts\SetupComplete.cmd file. This file enables you to install additional applications, run custom Windows scripts (cscript/wscript), or make other modifications to the system before a user logs on. Note Commands in the Setupcomplete.cmd file are executed with local system privilege. After Windows is installed, but before the logon screen appears, Windows Setup searches for the SetupComplete.cmd file in the %WINDIR%\Setup\Scripts\ directory. If a SetupComplete.cmd file is found, the file is executed. Otherwise, installation continues normally. Windows Setup logs the action in the Setupact.log file. Note You cannot reboot the system and resume running SetupComplete.cmd. Setup does not verify any exit codes or error levels in the script after executing SetupComplete.cmd. The functionality of Setupcomplete.cmd differs from the RunSynchronous and RunAsynchronous commands in that Setupcomplete.cmd runs after Windows Setup completes while the RunSynchronous and RunAsynchronous commands run during Windows Setup. Run a Custom Script if Windows Setup Encounters a Fatal Error If Windows Setup encounters a fatal error, you can configure Setup to automatically launch a script that contains custom commands or actions. A fatal error is an error in which Windows Setup is prevented from completing the installation. This functionality is useful when you automate the installation of many systems at the same time. By enabling this functionality, you can immediately detect when an error occurs during Windows Setup and run custom actions. If Setup encounters a fatal error and is prevented from completing the installation, Setup searches for a command script in the following directory: %WINDIR%\Setup\Scripts\ErrorHandler.cmd. One of two actions will occur, depending on whether the script is found. * If the script is not found, a dialog box is displayed with the error text. A user must dismiss the dialog box before Setup exits. * If the script is found, the script executes synchronously. No dialog box or error text is displayed. After the ErrorHandler.cmd script completes, Windows Setup exits. Depending on the phase of Windows Setup, the computer will return to the environment from which Setup was executed (for example, a downlevel operating system or Windows PE). There are several ways that you can add the ErrorHandler.cmd file by using the $OEM$ directory structure. * Create a Sources\$OEM$\$$\Setup\Scripts folder in the Windows distribution. Copy the ErrorHandler.cmd file to this directory. For more information about using $OEM$ files, see Add Content to $OEM$ Folders. * Create a temporary folder that contains a $$\Setup\Scripts folder structure. Copy the ErrorHandler.cmd file to this directory, and then run Windows Setup with the /m:temp_folder parameter. For example, if you create C:\Temp\SetupFiles\$$\Setup\Scripts\ErrorHandler.cmd, use the following command: setup.exe /m:C:\temp\SetupFiles For more information about the setup.exe /m parameter, see Windows Setup Command-Line Options. There may be instances when Windows Setup encounters more than one error and runs the ErrorHandler.cmd script more than once. When developing the code for ErrorHandler.cmd, ensure that you can run this script multiple times. Sample SetupComplete.cmd file here's a sample Setupcomplete.cmd file from srvops SetupComplete.cmd @echo off cd\ start /wait regedit.exe /s c:\windows\setup\win7regsettings.reg exit win7regsettings.reg Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] "ConsentPromptBehaviorAdmin"=dword:00000000 [HKEY_CLASSES_ROOT\Folder\shell\Cmd Here] @="Command &Prompt" [HKEY_CLASSES_ROOT\Folder\shell\Cmd Here\command] @="cmd.exe /k pushd %L" [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management] "DisablePagingExecutive"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL] "SkipRearm"=dword:00000001 ;1st setting - Turn off UAC Prompt for Admin Elevation ;Next 2 settings - Create a Command Prompt entry on the right click menu ;4th setting - is to put the Windows Kernel in memory. Only do this if you have more than 512MB of RAM ;5th setting - setting this to 1 allows for 8 "rearmings of activation" in Vista Business and Ultimate editions. ;A setting of zero allows for only 3 rearms. cheers niall

Just in case any of you try this, if you have a task sequence with a 64 bit boot image assigned to it, and you try to deploy an X86 (32 bit) image, the task sequence will fail, as it's not supported. It will fail in the Apply Operating System step with an error simlar to the following: To resolve, simply change the boot image for the task sequence to X86 and try again.

you dont need to configure WDS, is dhcp server and wds on the same machine ? or different ? is sccm on the same server as wds ?

I actually came across the \boot\bcd error today myself on my home lab, restarting the Windows Deployment Service resolved it

post the new smsts.log file here

it couldnt be easier, either use the capture windows 7 task sequence i already pointed you to, and advertise that to the windows vista machine complete with all it's apps, and when you see the ts popup in RAP then click on it, the system will be rebooted into windows PE and it will start capturing the image. or create a brand new build and capture task sequence, disable the build part, advertise it to a collection, add the computer to that collection and as above let the ts kick off... or create a capture CD (right click on task sequences node in osd and choose create task sequence media, choose capture..

using the DCCU is really really easy, download it, create a package to apply the bios setting you want (eg: boot order in bios) save that EXE file, create a package in sccm and deploy it to a test box, verify it works, deploy it to more boxes. i don't know how IBM handles this cheers niall

1. smspxe.log file is on the server hosting the pxe support point role. 2. start the capture within Windows by kicking off the capture task sequence via the Run Advertised Programs, it can then prestage windows PE and reboot, then capture Vista...

ok, well this topic is about Capturing Windows 7, so really you should only be asking about Capturing Windows Vista in the vista section, this is to avoid confusing the topic, confusing others, confusing me.....

ok have you tried capturing it using the task sequence provided in this topic ?

it's most likely picking those names up from your chosen DISCOVERY methods, is Active Directory discovery enabled ? are those objects in AD ?

what OS are you trying to capture ?

no I don't work for Microsoft, I work as a Technical Consultant for Logica, my point is simply this, why re-invent the wheel when there are solutions out there already, plus any custom solution you figure out will only be supported by you and no one else,

any updates for SCCM SP2 R2 should be listed here, but they are usually only hotfixes http://blogs.technet.com/configurationmgr/default.aspx

yes of course it can be done and the answer is this topic, try it ! cheers niall

click on the SCCM 2007 Guides link and scroll down to Capturing OS if you have a new problem, please raise it in the appropriate section cheers niall

hi there Jordan and welcome via > http://technet.microsoft.com/en-us/library/bb680929.aspx cheers niall

here's your problem verify what boot image is attached to your task sequence cheers niall

enable F8 support and then post the SMSTS.log file here read this > http://www.windows-noob.com/forums/index.php?showtopic=546

well i'm sure what you are doing makes sense to you but seriously if you want to ease your own pain then look at MDT 2010 using task sequences so its EASY even for a customer, it will do all of those things and more for free, much less need to script things and hack isos/winpe. SCCM is just the icing on the cake and well, then some cheers niall

In Part 1. We created the Update List for Windows XP Security Updates and we created a Deployment Management Task. In this Part we will target the deployment management task to our Test XP collection and then we will verify the updates are deployed. Step 1. Select our Deployment Management Task Expand the Deployment Management node and select the Windows XP Security Updates - March 2010 Deployment Management task we created, right click and choose Properties. When the Properties window appears, click on the Collection tab click on Browse and browse to your XP test collection, Note: In the screenshot below I have linked to the All Windows XP Systems collection, but in a Production environment you should have a defined set of computers to test patches on in their own separate collection. It is entirely up to you how to set that up. We have already set the schedule on the Deployment Management Task so understand that as soon as you click Apply then those updates will be made available to that Collection. Step 2. Verify that your updates are deploying Just before the deadline occurs, your XP machines should start receiving the new Update Policy. You can verify this easily in the lab because you'll see it But to verify/troubleshoot updates being deployed remotely you'll need to familiarise yourself with the following logs on the Clients. Software Updates Client Computer Log Files * CAS.log - Provides information about the process of downloading software updates to the local cache and cache management. * CIAgent.log - Provides information about processing configuration items, including software updates. * LocationServices.log - Provides information about the location of the WSUS server when a scan is initiated on the client. * PatchDownloader.log - Provides information about the process for downloading software updates from the update source to the download destination on the site server. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates. * PolicyAgent.log - Provides information about the process for downloading, compiling, and deleting policies on client computers. * PolicyEvaluator - Provides information about the process for evaluating policies on client computers, including policies from software updates. * RebootCoordinator.log - Provides information about the process for coordinating system restarts on client computers after software update installations. * ScanAgent.log - Provides information about the scan requests for software updates, what tool is requested for the scan, the WSUS location, and so on. * ScanWrapper - Provides information about the prerequisite checks and the scan process initialization for the Inventory Tool for Microsoft Updates on Systems Management Server (SMS) 2003 clients. * SdmAgent.log - Provides information about the process for verifying and decompressing packages that contain configuration item information for software updates. * ServiceWindowManager.log - Provides information about the process for evaluating configured maintenance windows. * smscliUI.log - Provides information about the Configuration Manager Control Panel user interactions, such as initiating a Software Updates Scan Cycle from the Configuration Manager Properties dialog box, opening the Program Download Monitor, and so on. * SmsWusHandler - Provides information about the scan process for the Inventory Tool for Microsoft Updates on SMS 2003 client computers. * StateMessage.log - Provides information about when software updates state messages are created and sent to the management point. * UpdatesDeployment.log - Provides information about the deployment on the client, including software update activation, evaluation, and enforcement. Verbose logging shows additional information about the interaction with the client user interface. * UpdatesHandler.log - Provides information about software update compliance scanning and about the download and installation of software updates on the client. * UpdatesStore.log - Provides information about the compliance status for the software updates that were assessed during the compliance scan cycle. * WUAHandler.log - Provides information about when the Windows Update Agent on the client searches for software updates. * WUSSyncXML.log - Provides information about the Inventory Tool for the Microsoft Updates synchronization process. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates. In Part 3. of this series, we will look at how we can use the reporting function within SCCM by using our Update Lists. This will give us an overview of the Software Update Compliance of our targetted systems.

are you saying with issue 1 that you cannot boot winpe 3 ? i'm not following you exactly...

yes of course, look in the Deploy 7 section, there's a post there that shows you how to capture windows 7

correct