anyweb

make the advertisements optional instead of mandatory look at the multitask post i did for some ideas

did you create that package from definition and update it to distribution points ?

If separate NIC drivers are offered by an OEM manufacturer for use in Windows PE vs. the full Windows OS, the Task Sequence may fail if the Windows OS being deployed is Windows Vista or newer (Vista, Windows 7, 2008, 2008 R2) and if it is being deployed from an "Operating System Install Package" (Windows installation source files). We discuss the cause and solution here: http://blogs.technet.com/configurationmgr/archive/2010/02/09/nic-devices-that-require-a-special-driver-for-winpe-may-cause-a-configmgr-task-sequence-to-fail-if-a-vista-or-newer-os-is-being-deployed-via-an-operating-system-install-package.aspx J.C. Hornbeck | Microsoft If separate NIC drivers are offered by an OEM manufacturer for use in Windows PE vs. the full Windows OS, the Task Sequence may fail if the Windows OS being deployed is Windows Vista or newer (Vista, Windows 7, 2008, 2008 R2) and if it is being deployed from an "Operating System Install Packages" (Windows installation source files). Usually the OEM manufacturer offers separate NIC drivers for use in WinPE vs. the full Windows OS because of special characteristics of the NIC, such as it being a multi-tiered device. WinPE does not support multi-tiered devices, so the OEM manufacturer offers a "monolithic" driver for use in WinPE. An example of such a NIC device is the Broadcom NetXtreme II (based on the 5706, 5708, 5709, and 5716 chipsets) commonly seen on server class hardware. Please see the below link for additional information regarding the Broadcom NetXtreme II NIC: http://www.broadcom.com/support/ethernet_nic/netxtremeii.php Note: The monolithic driver for the Broadcom NetXtreme II NIC does not need to be loaded into the WinPE Boot Images of SP2 of SCCM 2007. SCCM 2007 SP2 utilizes WinPE 3.0 which already contains the NetXtreme II NIC monolithic driver. However it does need to be loaded in the Boot Images of SP1 of SCCM 2007. SCCM 2007 SP1 utilizes WinPE 2.1 which does not contain this driver. When the Task Sequence fails, the errors displayed both in the interface and in the SMSTS.log may be different depending on if the deployment was an SCCM 2007 SP1 vs. SCCM 2007 SP2 Task Sequence. It will also vary depending if the Advertisement for the Task Sequence is set to download and run locally ("Download content locally when needed by running task sequence") or run from DP ("Access content directly from a distribution point when needed by the running task sequence"). Below are example error messages for each scenario: SCCM 2007 SP1 & SP2 Run From DP SMSTS.log: Setupact.log and Setuperr.log: SP1: SP2: SCCM 2007 SP1 Download & Run Locally SMSTS.log: No errors in the Setupact.log or Setuperr.log SCCM 2007 SP2 Download & Run Locally Deployment runs successfully Cause The basic cause of the problem is that network connectivity is lost in WinPE when the NIC driver is installed. When running from DP, the Task Sequence will fail immediately after the NIC driver install takes place. When downloading and running locally, the Task Sequence will fail a few minutes after the the NIC driver install takes place and right after the initial Windows setup is complete. Loss of network connectivity is caused by how and when the NIC driver is installed by the SCCM OSD Task Sequence. In Windows Vista or newer (Vista, Windows 7, 2008, 2008 R2), drivers can be installed during one of several different passes during an unattended Windows installation. These passes are described in the below TechNet article: Add Device Drivers During Windows Setup http://technet.microsoft.com/en-us/library/cc766485(WS.10).aspx When either the "Apply Driver Package" task or "Auto Apply Driver" task is included as part of an SCCM 2007 OSD Task Sequence that is deploying an Operating System via an "Operating System Install Packages" (Windows installation source files), the Task Sequence will automatically generate and/or add to an unattend.xml file specifying for the drivers to be installed during the windowsPE phase. According to the above TechNet article, drivers installed during windowsPE phase are not only installed within WinPE, but also in the full Windows OS installation: "If you need drivers for Windows PE to see the local hard disk drive or a network, this configuration pass must be used to add the necessary drivers to the Windows PE driver store. The windowsPE configuration pass also configures settings that apply to installation. This means that drivers in the Windows PE driver store are also reflected into the offline Windows image or copied to the Windows image driver store during offline servicing." The problem with installing NIC drivers that are different for WinPE vs. the full Windows OS is that attempting to install such drivers during the windowsPE phase will cause network connectivity in WinPE to stop working and fail. This occurs because the incorrect drives are "reinstalled" while still in WinPE. The exact failure is different depending if SCCM 2007 SP1 or SCCM 2007 SP2 is being used. SP1 utilizes WinPE 2.1 and SP2 utilizes WinPE 3.0. In SP1, when the driver is attempted to be installed while in WinPE 2.1, the network connectivity is lost permanently. In SP2, when the driver is attempted to be installed while in WinPE 3.0, network connectivity is also lost. However, WinPE 3.0 handles the issue better and after a few seconds recovers and network connectivity is regained. If the Task Sequence is being run from the DP, in both SP1 and SP2, the Task Sequence will fail during the initial Windows Setup. When Windows Setup installs the NIC driver, the Task Sequence will fail immediately after the NIC driver has been installed. Specifically, when the failure happens, the Task Sequence is accessing the Windows installation source files directly on the DP. Since it cannot access these files anymore due to the loss of network connectivity, Windows Setup fails, which causes the Task Sequence to fail. If the Task Sequence is downloading and running locally, the Task Sequence will not fail immediately upon the installation of the NIC driver. Since the Windows installation source files have already been downloaded and are located locally on the hard drive, the Task Sequence will continue with Windows Setup using the Windows installation source files located locally on the hard drive even if there is no network connectivity. The initial Windows Setup will then succeed but once it completes, since network connectivity is needed once again to continue the Task Sequence, in the case of SP1 and WinPE 2.1 where network connectivity never comes back, the Task Sequence fails when it cannot access the network to continue. However, in SP2 that utilizes WinPE 3.0, since network connectivity has been regained by the point that the initial Windows Setup completes and network connectivity is needed again by the Task Sequence, the Task Sequence continues and completes successfully. so the issue does not occur. Resolution There are several solutions to the problem: 1) Upgrade to SP2 of SCCM 2007, and then choose the option to download and run the Task Sequence locally ("Download content locally when needed by running task sequence") in the properties of the Advertisement of the Task Sequence. 2) Capture a reference image of the Windows OS on another model PC that does not utilize the affected NIC, and then deploy Windows OS via a Task Sequence that deploys from an Operating System Image instead of an Operating System Install Package. The way drivers are injected and installed in an Operating System Image is different than an Operating System Install Package (drivers are injected directly into the Operating System Image's Driver Store) so the process completes successfully. 3) Install an additional NIC card that does not require separate drivers for WinPE vs. the full Windows OS into the PC . Disconnect the NIC that requires separate drivers for WinPE vs. the full Windows OS, and then use the newly installed NIC exclusively during the Task Sequence. 4) The affected NIC drivers need to be somehow installed during the offlineServicing pass instead of the windowsPE pass. However there is no way to change the default behavior of the SCCM 2007 OSD Task Sequence tasks "Apply Driver Package" and "Auto Apply Drivers" to install drivers during a pass other than the windowsPE pass.Although by default the pass used by and automatically generated by an SCCM 2007 OSD Task Sequence in the unattend.xml file cannot be changed, some additional tasks can be added to the Task Sequence that manipulates both the unattend.xml file and where the drivers are installed from. This process is described below: A) Open Notepad. Below, choose the appropriate architecture of the Windows OS being deployed, copy the lines below the architecture, and paste them into the Notepad: x86: <?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="offlineServicing"> <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DriverPaths> <PathAndCredentials wcm:action="add" wcm:keyValue="1"> <Path>C:\_SMSTaskSequence\Drivers2</Path> </PathAndCredentials> </DriverPaths> </component> </settings> </unattend> x64: <?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="offlineServicing"> <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DriverPaths> <PathAndCredentials wcm:action="add" wcm:keyValue="1"> <Path>C:\_SMSTaskSequence\Drivers2</Path> </PathAndCredentials> </DriverPaths> </component> </settings> </unattend> C) Save the Notepad file with the name unattend.xml When saving the file, make sure that "All Files (*.*)" is selected next to "Save as type:" so that it does not append the .txt extension to the file. D) In the SCCM 2007 Admin console, under the "Computer Management" -->"Software Distribution" --> "Packages" node, create a new package that contains the unattend.xml file created in Steps B & C. A Program does not need to be created for the Package. After creating the Package, make sure to copy the Package to the Distribution Points. E) In the SCCM 2007 Admin Console, under the "Computer Management" -->"Operating System Deployment" --> "Task Sequences" node, right click on the affected Task Sequence and choose "Properties". F) In the "Apply Operating System" task, check the option "Use an unattended or sysprep answer file for a custom installation". Next to the "Package:" field, click on the "Browse..." button and select the package created in Step D. Next to the field "Filename:", enter in unattend.xml G) Create a Driver Package that ONLY contains the drivers of the affected NIC device. Make sure to add the Driver Package to the Distribution Points after creating it. H) If applicable, create a second Driver Package that contains all of the other drivers that need to be installed on the PC during the Task Sequence. Do NOT include the affected NIC drivers in this second Driver Package. Make sure to add the Driver Package to Distribution Points after creating it. I) Remove any "Auto Apply Driver" tasks from the Task Sequence. J) Immediately after the "Apply Network Settings" task, add an "Apply Driver Package" task and point it to the Driver Package created in Step G that only contains the affected NIC driver. K) Immediately after the "Apply Driver Package" task created in Step J, add a "Run Command Line" task. In the "Name:" box, type in: Rename Drivers Directory In the "Command line:" box, enter in cmd /c move "%_SMSTSMDataPath%\Drivers" "%_SMSTSMDataPath%\Drivers2" L) Immediately after the "Run Command Line" task created in Step K, add another "Run Command Line" task. In the "Name:" box, type in: Recreate Drivers Directory In the "Command line:" box, enter in cmd /c md "%_SMSTSMDataPath%\Drivers" M) If applicable, immediately after the "Run Command Line" task added in Step L, add an "Apply Driver Package" and point to the Driver Package created in Step H that contains all of the rest of the drivers for the PC. It is possible to use solution #4 and the above steps using the "Auto Apply Drivers" task instead. Instead of creating two separate Driver Packages and two separate "Apply Driver Package" tasks, two "Auto Apply Drivers" tasks that utilize driver categories can be used instead. A special driver category would need to be created for the affected NIC driver, and a separate category would need to be created for all other drivers. For the first"Auto Apply Drivers" task , choose the option "Limit driver matching to only consider drivers in selected categories", and then select the special category created for the affected NIC driver. In the second "Auto Apply Drivers" task, also select the option "Limit driver matching to only consider drivers in selected categories", but this time select the category created for all other drivers. Make sure that the affected NIC driver is NOT included in the "all other drivers" category. NOTE: As a possible resolution, attempting to not install any driver for the NIC while in WinPE via the "Apply Driver Package" task and/or the "Auto Apply Drivers" task and instead trying to install the NIC driver later in the Task Sequence during the full Windows OS portion (after the "Setup windows and ConfigMgr" task), via an "Install Software" task, does not resolve the problem. Once the Task Sequence detects that it does not have network connectivity in the full Windows OS (due to the NIC driver not being installed), the Task Sequence will fail. It will never get to the "Install Software" task that installs the NIC driver. Additionally, even if the Task Sequence did get to the "Install Software" task that installs the NIC driver, there would be no way of reaching the DP and downloading the software package containing the NIC driver since there is no network connectivity. Frank Rojas | System Center Support Escalation Engineer

Step 1. Create a collection variable. In Configmgr expand the collections node and select your Deploy 7 x86 collection (if you don't have one, create one for the purpose of this test). Right click on the Collection and choose Modify Collection Settings, click on the Collection Variables tab. Create a new Collection Variable called MachineObjectOU by clicking on the yellow star. De-select the Do not display this value in the ConfigMgr console and enter the desired value in the Value field: OU=VirtualMachines,OU=Inf,DC=server2008,DC=lab,DC=local Click Ok to save your settings. Step 2. Edit The Task Sequence to use the %MachineObjectOU% Variable Now that you have set the Collection Variable it's time to modify your Task Sequence. right click on your Task Sequence and choose Edit, click on the Apply Network Settings step. Select Join a Domain and Enter your Domain values and then for the for the Domain OU: part input the following: %MachineObjectOU% Step 3. Deploy Windows 7 and verify Advertise your Task Sequence to the Deploy 7 x86 collection and add a computer to the collection, PXE boot, let the deployment finish and verify that the compuer ends up in the OU you specified. Here's a copy of the Task Sequence used in this example if you want to test it yourself. machineobjectou.xml Simply Import it and change the Domain settings and any references to boot image, operating system image and configmgr client from definition package. Troubleshooting notes: * TIP: to get the correct OU statement for the Collection Variable you can open the edit the task sequence step called Apply Network Settings, and click on browse for Domain OU part of join a domain, then copy everything after the LDAP:// statement * If you deploy Windows 7 and the computer doesn't join the domain or the correct OU then read the c:\windows\debug\netsetup.api log file to find out what the domain join error was. * Don't try and stick the computer into the Computers container, it will fail * The account that you use to join the domain (in my example it's domjoin) may need permissions delegated to it to allow it to create objects in the selected OU.

please attach the smsts.log file and i'll take a look

i dont get it, did you use a deployment template that allowed the system to reboot ? that is why you should have at least two deployment templates one for servers (no reboot) and one for workstations (reboot ok) the little group policy tip merely gets rid of the windows update ICON from appearing, it doesn't stop windows updates from being deployed via configmgr, can you explain what happened in your situation please ?

i havnt tested it with that one, maybe that could be the issue, is it sp1 or sp2 or ? also, did you do this part > Part 2a - add Capture file to WDS ?

and here's yet another post about how to do it (hardlinking etc) http://myitforum.com/cs2/blogs/nbrady/archive/2010/01/26/migrating-windows-xp-to-windows-7-using-hardlinking-setting-up-a-demo.aspx

hmm what DVD did you pull the boot image from ?

please provide DETAILS of your problem, there's a capture windows 7 guide here, did you try it ? did you see if adobe whatever (because you never told us) is in add remove programs after the capture ? can you give us some actual details of the actual problem ?

System Center recognizes that technology has evolved since you first deployed your SMS 2003 environment. New platforms have become available, you are supporting new working styles, and security is more important than ever. We want you to benefit from the latest platforms and security features available, and to achieve this we want to help you migrate to our latest management platform. http://www.microsoft.com/systemcenter/configurationmanager/en/us/sms.aspx Can you spot Wally in the video ?

please stop raising new topics for the same problem, we need more details about what you've done, and how you are doing it. is this still the same problem as before, adobe software not appearing after the capture ? cheers niall

does the software show up in add/remove programs

of course it's possible, did you see this post ? http://www.windows-noob.com/forums/index.php?/topic/1543-how-can-i-capture-windows-7/

A 17-year-old bug in Windows will be patched by Microsoft in its latest security update. The February update for Windows will close the loophole that dates from the time of the DOS operating system. First appearing in Windows NT 3.1, the vulnerability has been carried over into almost every version of Windows that has appeared since. The monthly security update will also tackle a further 25 holes in Windows, five of which are rated as "critical". Home hijack The ancient bug was discovered by Google security researcher Tavis Ormandy in January 2010 and involves a utility that allows newer versions of Windows to run very old programs. Mr Ormandy has found a way to exploit this utility in Windows XP, Windows Server 2003 and 2008 as well as Windows Vista and Windows 7. The patch for this vulnerability will appear in the February security update. Five of the vulnerabilities being patched at the same time allow attackers to effectively hijack a Windows PC and run their own programs on it. more > http://news.bbc.co.uk/2/hi/technology/8499859.stm

then you probably need to load the network drivers for windows 7 into the windows pe boot image, or something else, we need to see your SMSTS.LOG file from the client to be sure..

glad you sorted it and thanks for posting the resolution

via > Nexus SC: The System Center Team Blog Hi everyone, recently we recorded a look into the new scale and performance improvements we will ship in ConfigMgr 2007 R3. There are 3 main areas of enhancement being made to the core capabilities of ConfigMgr. These are as follows: Delta Active directory Discovery – AD discovery has 2 main tasks. Discovering changes to users or machines that may effect targeting. Also, periodic full scans capture users and machines last logged time, ensuring active users or systems are not made obsolete. The AD queries that this is supported on include User, User Group, System and System Group. Fast Collections – Combined with Delta AD Discovery is a concept called ‘Fast Collections’. When a Collection Membership Rule is configured to dynamically add new resources, a few things happen. This applies to a few resources. Those that are initially discovered, OSD provisioned systems, HW inventories scanned systems, or ConfgMgr Client version upgrades. When Fast Collections are configured, a Resource ID is inserted into the change tracking table where a separate collection evaluator thread is run (5min) and evaluates collections marked for fast evaluation. This setting does not apply to known machines , and full evaluations are still processed the same way. The result is significant gains of time savings to get advertisements to users and systems. Admin Console Improvements – There have also been some improvements to the Admin console, helping the Administrator save time in their daily tasks. For example, new right click options off a resource to add to collection (existing) add to new collection, remove from collection and add resources, are all designed to save console steps. Here is a short video demonstrating these improvements. http://blogs.technet.com/systemcenter/archive/2010/02/04/scale-and-performance-improvements-in-configuration-manager-2007-r3.aspx

here's the solution http://www.windows-noob.com/forums/index.php?/topic/1672-solution-status-0xc0000001-when-deploying-windows-7/

When deploying Windows 7 via OSD in SCCM 2007 SP2, upon rebooting from the WinPE stage to Windows 7 Mini-Setup, Windows may not start and the following error occurs instead: Status: 0xc0000001 Info: An unexpected error has occurred. Examining the following logs may reveal the following errors: SMSTS.log PkgMgr.log This issue can occur if you are attempting to use a WinPE 2.x based Boot Image created with the WAIK 1.x for a Windows 7 deployment. Windows 7 deployments require a WinPE 3.0 or newer based Boot Image created with the WAIK 2.x or newer. Examining the logs reveals that the deployment is trying to use Pkgmgr.exe (Package Manager), which is a WinPE 2.x/WAIK 1.x tool, to try to inject drivers into Windows 7. PkgMgr.exe is not compatible with Windows 7 and it has been replaced with DISM.exe in WinPE 3.x/WAIK 2.x. DISM.exe is required to inject drivers properly into Windows 7. Using the incorrect Boot Image causes the deployment to try to use a combination of PkgMgr.exe and DISM.exe, and ends up causing it to fail. Resolution Check to make sure that the Task Sequence deploying Windows 7 is using a WinPE 3.x based Boot Image. To check the Boot Image that the Task Sequence deploying Windows 7 is using: 1. In the ConfigMgr 2007 console under the "Operating System Deployment" --> "Task Sequences" node, right click on the affected Task Sequence and choose "Properties". 2. Click on the "Advanced" tab 3. Under the option "Use a boot image:", make sure that the Boot Image selected is a WinPE 3.x based Boot Image To check the version of the Boot Image to verify that it is a WinPE 3.x Boot Image: 1. In the ConfigMgr 2007 console under the "Operating System Deployment" --> "Boot Images" node, right click on the Boot Image as determine in the above steps and choose "Properties". 2. Click on the "Images" tab. 3. Click on the "Reload" button. 4. Check the value of the field "OS version". For WinPE 3.x based Boot Images, the version number should at least be at 6.1.7600.16385. If the version number is 6.0.6001.18000 or older, this is a WinPE 2.x based Boot Image which will not work with Windows 7 deployments. Frank Rojas | Configuration Manager Support Escalation Engineer

verify that the key can be used with the actual iso you are using, ie: verify they match up regardless of it actually activating after the install

leave out the key or get a version of the ISO that will work with the key you are trying to use, are you using KMS ?

good info, was it SEP 11 ?

did you try restarting the dhcp and wds services ?

read this post and use the same method, ie: make your desired changes in unattend.xml using Windows SIM cheers niall