anyweb

are you doing this on the actual server that you are going to deploy from or via an SCCM console ?

I use the GP and my servers update fine, same for desktops, i'd advise you to test in the lab first to verify, always test everything

take a look at this post http://www.windows-noob.com/forums/index.php?/topic/1660-customising-windows-7-deployments-part-1/

if you get it working post how you did it here please

well can you contact the sql server/service ? what version of sql server did you install ?

the supported method from microsoft is to reinstall the latest service pack, or do a site reset read this post for more info

When running a SCCM 2007 SP2 Task Sequence with a "Capture User State" task that utilizes USMT 4, files are properly captured and restored but settings may not be. The SMSTS.log will not show any errors, however the scanstate.log will show the following error: <Date> <Time>, Info [0x000000] Downlevel Manifests folder is not present. System component settings will not be gathered. Settings that may not be captured include printers, mapped network drives, and wallpaper. The cause and solution is discussed here: http://blogs.technet.com/configurationmgr/archive/2010/02/10/solution-when-using-usmt-4-in-an-sccm-2007-sp2-osd-task-sequence-files-are-captured-successfully-but-not-settings.aspx J.C. Hornbeck | Microsoft

this would make a great post Peter, hint hint, if you have time, please do one

here it is http://support.microsoft.com/kb/978754/en-us

adding the following link ConfigMgr 2007: How to move the Site Database

office 2003 and office 2007 are packaged very differently so i'd say no, perhaps Peter can chime in ?

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/