High level Task Sequence Steps for Windwos Xp to 7
PXE-E53: No boot filename received
everythink ok.. when checked
- Both the Boot Images are sent to WDS
Found one red Event in the application Events with event ID 258
executed below command to resolve the issue..
wdsutil /initialize-server /REMINST:"E:\remoteinstall"
PXE Client How will find the PXE Server
The process is roughly as below:
1. Client powers on
2. NIC initiates PXE process
3. NIC acquires DHCP address
4. NIC contacts PXE server (WDS)
5. PXE server delivers NBP to client
6. NIC TFTPs boot image (from WDS)
4 This can be couple of different ways. If the DHCP request returned options 66 and 67, then the NIC BIOS will directly use the information in these options to contact the PXE server.
If options 66 & 67 are not specified, then the NIC BIOS will send a broadcast request to find a PXE server.
If the PXE server is not on a local subnet, then something needs to forward the broadcast request to the PXE server: iphelpers (there are other possibilities but this is the primary solution to this).
Once the PXE server is contacted, it sends back the info to the client so the client can directly contact the PXE server.
Enable RDP in the Task Sequence
Const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
strComputer & "\root\default:StdRegProv")
strKeyPath = "SYSTEM\CurrentControlSet\Control\Terminal Server"
strValueName = "fDenyTSConnections"
dwValue = 0
oReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,dwValue
How to disable the UAC in Windows 7 Deployment
In fact we might get more errors if you have the UAC enabled while deploying the Windows 7, You can include one step in the task sequence as run a command line and fill this below in the command line box
“CMD /C REG.EXE ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f”
Note: Not required any options in the options to configure however you can record with a optional Success Code “0 3010”
How to set the Timezone
How to set the Timezone with in one task sequence… like you have more than one location and all these locations has different time zones…
To do this under the task sequence Apply Windows Settings in the options TS Variable is ADSite name equals is “WhateverTheSite” and in the Properties Time Zone choose the time you wanted…
OSD import permission Issue
We might get when we are looking for only import permissions for a user or Group..
or
even when we setup the permissions at the end of the wizard we may get this error..
Errors
·You do not have security rights to perform this operation.
·ConfigMgr Error Object:
·instance of SMS_ExtendedStatus
·{
· Description = “User \”*************\” does not have permission of the current site to import machines.”;
· ErrorCode = 1112017920;
· File = “e:\\nts_sms_fre\\sms\\siteserver\\sdk_provider\\smsprov\\sspsite.cpp”;
· Line = 766;
· ObjectInfo = “524288″;
· Operation = “ExecMethod”;
· ParameterInfo = “SMS_Site”;
· ProviderName = “WinMgmt”;
· StatusCode = 2147749889;
};
The actual permissions required at SCCM Console level is:
- On SCCM Root Collections we must grant read & read Resource
- and for the target of the collection we need to give the permissions to add or whatever you wanted
- at computer Association level we must give permissions for importing
- (The most common mistake or un- mentioned step ..this one we may forget most of the time)
On the top of the Site ==Properties=> Security Tab => Class Security rights and we must choose here read,Import Computer Entry (below screenshot)
PXE error: PXE-T01:File not Found & PXE-E3B: TFTP Error – File Not Found
You might get the below error..
The above problem will come When you don’t Have the files in DriveLetter:\RemoteInstall\SMSBoot\
In fact the below article address the issue, However I have approached in different way as just copy the Missing files & folders from other Remote Install Folder and past on the Problem system.
Confuse - USMT & MDT & SIM
MigApp:- To migrate the Application settings like Outlook dictionary
2) In MDT: - Will have this file
3) What is SIM? System Image Manager
SCCM + MDT Driver Management - Good Info To Read
Below are the options that i could see to automate the Drivers for different models...
For DELL
http://en.community.dell.com/techcenter/enterprise-client/w/wiki/client-deployment.aspx
http://en.community.dell.com/techcenter/os-applications/w/wiki/dell-business-client-operating-system-deployment.aspx
FOR IBM Lenovo
http://scug.be/blogs/sccm/archive/2011/01/18/configmgr-2007-osd-using-lenovo-update-retriever-to-install-all-your-drivers-without-importing-them-in-the-configmgr-driver-catalog.aspx
http://forums.lenovo.com/t5/ThinkVantage-Technologies/Use-THIN-INSTALLER-silently-to-install-updates/td-p/218895
Official Lenovo Deployment Guide Download Page http://support.lenovo.com/en_US/downloads/detail.page?DocID=UM006719
http://blog.itminutes.net/?p=266
For Hp
http://h20331.www2.hp.com/Hpsub/cache/509658-0-0-225-121.html
and other steps to manage the Drivers like we do it in MDT...
http://myitforum.com/cs2/blogs/cnackers/archive/2010/04/29/configmgr-driver-management-good-info-to-read.aspx
Take a read:
http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx
http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-2.aspx
http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-3.aspx
http://www.deployvista.com/Home/tabid/36/EntryID/132/language/en-US/Default.aspx
-Enjoy
Error information 0xC1030104
When the error i encounter i executed below and resolved this error.
This error was appeared after i configured my SCCM PXE server not to USE DHCP ports
wdsutil /initialize-server /REMINST:"D:\remoteinstall"
OSD Task Sequence failing every Time with one or other package
If your Task sequence if keep on failing and getting some packages are missing even though you distributed them…
Solution: Check for Network account is configured and the password you types is correct….
Step by Step 4 part guide to Deploying Windows 7 Enterprise.
Deploy Windows 7 part 1.
Build and Capture
Part 1 is the longest part of the 4 part guide and covers the steps required to successfully Build and Capture Windows 7 RTM. It was tested successfully on both X86 and X64 Enterprise RTM releases.
Step 1. get the ISO
Step 2. Add Operating System Install Package
Step 3. Create Distribution Point for the Image
Step 4. Update Distribution Point
Step 5. Create the Build and Capture Task Sequence
Step 6. Advertise the Build and Capture Task Sequence
Step 7. Add a system to the Build and Capture 7 collection
Step 8. PXE boot the newly added Windows 7 client
Deploy Windows 7 part 2.
Add the captured WIM file
Step 1. Add the Captured Wim file as an Operating System Image
Step 2. Distribute the Captured WIM file
Deploy Windows 7 part 3.
Create a new Task Sequence
Step 1. Create a new Task Sequence
Deploy Windows 7 part 4.
Advertise the Task Sequence
Step 1. Advertise the Task Sequence
Step 2. Last Actions
enjoy !
cheers
OSD Task Sequence : Formatted the drive, dropped the image on the PC
Issue: When trying to perform an OSD Task Sequence using SCCM 2007, the deployment fails, usually after it has successfully formatted the drive, dropped the image on the PC, and scanned for drivers.
Looking at the SMSTS.log, the following error is logged:
Task sequence cannot continue after reboot because TS Manager is not configured to auto-start or GINA is not installed TSManager
CheckForRebootRequest(&bRebootInitiated), HRESULT=80004005 (e:\nts_sms_fre\sms\client\tasksequence\executionengine\engine.cxx,274) TSManager
Fatal error is returned in check for reboot request of the action (Restart Computer).
Unspecified error (Error: 80004005; Source: Windows TSManager
An error (0x80004005) is encountered in execution of the task sequence TSManager
Cause: This issue is caused because the "Setup windows and ConfigMgr" task has either been removed, disabled, or has been moved to the wrong place in the Task Sequence.
The "Setup windows and ConfigMgr" task performs several tasks that prepares the PC from going from WinPE to the Windows Setup, including modifying boot managers to boot to the correct partition. Once it finishes preparing the PC, this task then reboots the PC at the proper time to start Windows Setup or Mini-Setup. If this task is removed, it will cause the deployment to fail because the PC was not properly prepared.
Resolution: For these reasons, the "Setup windows and ConfigMgr" task should never be removed, disabled, or moved to another place other than the default in the Task Sequence. Moving it to another place in the Task Sequence may cause the PC not to be prepared or rebooted at the correct time, causing the deployment to fail.
The "Setup windows and ConfigMgr" task should also not be marked as Continue on Error because if this task does error out, the deployment will probably fail anyway.
Good Posting for Multicasting for OSD : End to End
you can find here http://tinyurl.com/289ho4y
Multicasting is a new feature of R2 in SCCM and is a welcome addition to the OSD feature. Multicast allows for image deployment with a much reduced network load. If, for example, you are deploying a 500 MB image to 20 workstations that have just arrived from the OEM then with normal OSD imaging you would see network traffic equal to around 10 Gig! Using multicasting would result in a significant decrease in network utilization. Depending on the configuration, as little as about 500 MB of traffic required to deploy to all 20 machines! This is the same amount of network traffic you would consume deploying to just a single imaging system using typical OSD imaging before multicast!
How do you setup multicast? Let's walk through the configuration that is required step by step.
First, we need to enable multicasting. Multicast requires a distribution point and the 'transport server' component of WDS installed on a Windows 2008 server. From there select the properties of the distribution point site system role and make sure the option for BITS, HTTP and HTTPS transfer is selected as shown
Note the new multicast tab that is added when R2 is installed. Select the multicast tab and enable multicasting.
There are two options when using multicast - autocast and scheduled multicast.
To enable autocast just select to enable multicast. In this configuration the multicast session starts as soon as the first machine powers up and requests the image. As additional machines are also booted up for imaging they will 'join' the current multicast session already in progress and consume the remainder of the stream. When the stream ends it will start again and the systems that joined late will consume the parts they missed. While autocasting isn't as efficient as scheduled multicast it is still significantly more efficient that standard OSD image delivery.
Scheduled multicast allows for more control of the multicast session. Here you choose either a time delay before starting the multicast session or a minimum number of clients that must join the session before it starts. The multicast session will start whenever either of the two requirements are met. The idea here is to allow the administrator time to get all of the systems started and ready and then all systems can load the image simultaneously - providing the best usage of network resources. Scheduled multicast is enabled by selecting the 'enable scheduled multicast' check box.
There are other configuration options on this screen but no extra configuration is required unless by your network. The 'out of the box' settings work fine for most environments.
In addition, while DHCP and Windows 2008 based WDS (transport component as noted earlier - the PXE boot piece does not need to be on the same server) are needed, there is no special configuration requirement for either to make use of multicasting.
The next step is to configure the image package to be deployed by multicast. In properties of the imported image, select the 'distribution settings' tab as shown
Select the option to allow the package to be deployed by multicast and optionally select the other two options. In my testing I tried to select to only allow the image to be transferred via multicast but this didn't seem to work. When I disabled multicast the image would still deploy, even with this option set.
in addition to enabling multicast for the image, you can also enable multicast on any package that is part of the image deployment. On each package select properties and then select the 'distribution settings' tab. the same options are available here as were on the image package as shown
As shown on both the image and the package, multicast is something that takes place in Windows PE only. So, setting these options per package will not result in the package being delivered via multicast through normal software distribution.
Finally, enable the task sequence advertisement to deliver the image via multicast. On the properties of the advertisement select the 'distribution points' tab as shown.
To enable multicast MAKE SURE you have selected to 'download content locally when needed by running task sequence'. This requirement isn't documented and I spent hours trying to understand why my multicast sessions weren't starting up before realizing this setting was required.
Thats it - we are now ready to go for delivering images via multicast. Let's walk through a couple of scenarios using autocast and scheduled multicast. In our scenarios we will use PXE booted systems but multicast also works fine when booting from media - the experience is just slightly different when in Windows PE.
Autocast - single machine
To test multicast generally you will use a single machine. So, what is your indication that multicast is actually working? When the image begins to deploy you will see that a multicast session is requested, the image is downloaded locally via multicast and then reassembled as shown in the following three screenshots.
Autocast - two machines
As mentioned, in autocast the first requesting machine will start the multicast as shown above. Any subsequent machines that boot up during the existing multicast session will join in progress and then loop back to the start and request the initial bits again. The screenshots below show two sysems - the one on the left was started ahead of the one on the right but both are downloading the same image. The one on the right started mid-stream.
After downloading the image the one on the left proceeds to extract while the one on the right finishes up getting the image.
Scheduled multicast works similarly except here the multicast session will not start until either time has expired or the minimum number of machines have joined the multicast session. The screenshot below shows a system waiting for either more systems to join or the timeout to expire.
So, while this is all going on - what is happening in the background to make this all work? The SMSTS log varies slightly in each scenario but the core details are the same. The SMSTS log section below is from a machine participating in an autocast multicast session.
In the log snip below we see the imaging system flag the multicast enabled distribution point that it wants to use for the multicast session, construct details for the multicast session request and then send the request to the multicast point
Continuing in the log we see the request information submitted to the multicast point followed by a reply with information the imaging system needs to join the multicast session. Once we get the proper information back from the multicast point we then request and establish the multicast session
Next we see the response from the multicast server, the session get setup and the download begin
Once downloaded we begin to reconstruct the wim file and start applying the image.
When initially setting up the multicast session we say reference to sending information to the multicast point. If we look in the mcsisapi log we see the request received, processed and the resulting reply sent back to the imaging agent as shown
There is certainly more 'behind the scenes' detail that takes place but this give a good picture, end to end, of how to configure, use and understand the process of using multicasting in R2.
wds.txt
Option 66: "2k3-wds.domain.local"
Option 67: "boot\x86\wdsnbp.com"
sysprep -mini -quiet -factory -reboot
c:\windows\system32\sysprep\sysprep.exe /quiet /generalize /shutdown /oobe
Troubleshooting WinPE and task sequence issues
You can troubleshoot some common WinPE and task sequence issues.
WinPE never starts the task sequence
Check the SMSTS.LOG file at X:\windows\temp\smstslog\smsts.log. If a package never downloaded, it is likely that you simply do not have the appropriate network drivers installed, which prevents the machine from communicating with Configuration Manager.
Check your driver catalog to ensure you have the right network drivers available and installed into the boot image, and update the boot image to your distribution points.
Additional network or storage drivers might be needed in the boot image to enable the WinPE boot to function correctly. You should add those through Drivers in the Operating System Deployment node.
The right drivers have been added to the boot image, but are not loading
The original boot.wim file (WinPE boot image) created during Configuration Manager installation is copied and modified with IBM-specific drivers and other files. Your task sequences that use the IBM Deployment Pack must use this boot image or the tools might not work properly.
Check to make sure the image into which you loaded the drivers is the same image being used by the task sequence.
This is a common error for administrators who maintain multiple boot images.
Servers will not boot using PXE
PXE is an extension of DHCP, which uses a broadcast type of communication. Broadcast communication uses standard timeout values that are not readily changeable. As a result, a computer waits for a default timeframe to receive a DHCP or PXE response before timing out and causing a failure condition.
Each time a server is rebooted, it must renegotiate the connection to the switch. Some network switches arrive configured with default settings that might incur connectivity delays. That is, the settings on the switch might cause a DHCP or PXE timeout because they fail to negotiate a connection in time.
One of the features that can be affected by this issue is Spanning Tree Protocol (STP). STP is a protocol that prevents loops and provides redundancy within a network. A networking device using this algorithm might experience some latency as it collects information about other network devices. During this period of information collection, servers might boot to PXE and time out while waiting for a response from Windows® Deployment Services. Disable the STP or enable PortFast on end-node ports for the target server to prevent such occurrences. Refer to the manufacturer’s user guide for further information.
Another feature that can be affected by this issue is the EtherChannel or Port Aggregation Protocol (PAgP). EtherChannel allows multiple links between devices to act as one fast link that shares the load between the links. Running the EtherChannel Protocol in automatic mode can cause a connectivity delay of up to 15 seconds. Switch to a manual mode or turn off this feature to eliminate this delay.
Speed and duplex negotiation can also play a role in negotiation timeouts. If auto-negotiation on the switch is set to off, and the server is not configured to that speed and duplex setting, the switch will not negotiate with that server.
For more information, see the Cisco Web site and the following Cisco documents:
- Cisco: Using PortFast and Other Commands to Fix Workstation Startup Connectivity Delays
- Cisco: Configuring and Troubleshooting Ethernet 10/100Mb Half/Full Duplex Auto‑Negotiation
Default boot order does not allow PXE to boot when a valid drive exists
When an active partition is created on a hard drive, it automatically becomes a bootable device if a valid operating system has been installed. If your PXE NIC is after the hard drive in the boot order, the hard drive tries to boot before PXE and boots to Windows, or causes an Invalid System Partition error if Windows is not installed.
To resolve this issue, be sure that PXE is placed before the hard drive in the boot order. Keep in mind that even if PXE is first in the boot order, the computer does not actually boot to PXE unless Configuration Manager has a task sequence for it to run.
When using a “Reboot” action after initializing an array controller, the task sequence fails
Configuration Manager 2007 does not allow a task sequence to reboot back to PXE. It can reboot back to WinPE or to an installed operating system, both of which require a disk partition and the appropriate installed software.
Without a disk partition, Configuration Manager will fail when attempting to reboot during a task sequence because it expects to copy WinPE to the disk. Additionally, the management point tracks when a machine has booted to PXE to run a task sequence, and once a machine has booted to PXE for a task sequence, it cannot use PXE as a boot method again for that task sequence unless the advertisement is reset.
To perform a reboot to PXE if you need to within a task sequence, use the custom action called “Reboot To PXE." This custom action, written using C# and VBScript, connects to the Configuration Manager 2007 SDK, and contains custom code to drive actions in the admin console as well as the machine being deployed. This custom action performs all the steps necessary to perform the reboot to PXE and allow for proper program flow when it occurs.
The only other way to accomplish a reboot to PXE is to use more than one task sequence, let the computer “fall off the end” of the first task sequence and manually reset the PXE advertisement for the computer.
Task sequence fails with “Failed to Download Policy” and code 0x80093102 or 0x80004005
This error code typically refers to a certificate validation issue.
The SMSTS.LOG file will show an entry with the following text:
CryptDecryptMessage ( &DecryptParams, pbEncrypted,
nEncryptedSize, 0, &nPlainSize, 0 ), HRESULT=80093102
or
no cert available for policy decoding
Possible causes are:
- Misconfiguration of your domain or a site server, such as DNS not pointing to the site server, or the site server not specifying a valid FQDN (which is referred to by the DNS listing).
If your site server does not specify a FQDN (and only specifies the NETBIOS name), and your DNS server refers to the FQDN, a faulty lookup might cause this error.
- The certificate being used for PXE and boot media.
Check the certificates under the Site Settings node and see if any certificates are blocked or missing. Open the certificates and ensure that they are actually installed into the certificate store. If not, install them.
If these actions do not work, try removing the package from the distribution point (via Manage Distribution Points) and adding the package again to regenerate the package hash.
Task sequence fails with “Failed to Download Policy” and code 0x80004005
This error code typically refers to a certificate validation issue.
The SMSTS.LOG file will show an entry with the following text:
failed to download policy
Check the certificates under the Site Settings node to if any certificates are blocked or missing. Open the certificates to ensure that the certificates are installed into the certificate store. If not, install the certificates.
Task sequence fails because the package is not downloading
In WinPE, the default option of “Download content locally when needed by running task sequence” will not work. When in WinPE, the task sequence engine will ignore (and fail) all actions that have packages set for this option.
Set all packages needed for use in WinPE to “Access content directly from a distribution point when needed by the running task sequence.”
Task sequence does not run again even after clearing the PXE advertisement
You must set the advertisement to “Always rerun” so that any time you reset the PXE advertisement, the advertisement is applied to the computer regardless of whether it ran the task sequence before.
Task sequences fail or act incorrectly after an upgrade
When upgrading from a previous version of this product, existing task sequences using these custom actions are not automatically updated.
To function correctly, open each task sequence action that uses a custom action in an editor. Add a “.” to the description and remove it to enable the Apply button. Click Apply to refresh the properties of the custom action and save any new automatic data or formatting that is required to function with the new version.
Files and logs are not being returned from the client
A number of issues can prevent the task sequence from returning files or logs from the client.
Among the possible issues that might prevent the task sequence from returning files or logs from the client are:
- Failure of the client-side script prior to the file copy, which is usually evident in the log file.
Repeat the task and press F8 during the task to get to a command prompt, if you selected the check box for Enable command support on the boot image properties > Windows PE page.
Then open the SMSTS.LOG file. The location varies. In WinPE via PXE, the location is at X:\Windows\Temp\Smstslog\smsts.log.
- Malformed XML in the IBM Deployment Packconfiguration file.
- The command being executed actually has an error but exits with code 0.
This can occur when a severe error is encountered in the script while the script is set to ignore errors and use programmatic error handling. Then the error handling did not catch the same error.
Report such issues to the IBM® support site, as described in Getting help and technical assistance.
- The task sequence cannot access the share or mapped drive that is the target drive for copying the files or logs.
Logs are being returned but not output files
A number of issues can prevent the task sequence from returning output files while allowing the task sequence to return log files.
Among the possible issues that might prevent the task sequence from returning output files from the client are:
- No return file parameters are specified in the configuration XML.
- Return file parameters in the configuration XML are incorrect.
- An error is occurring with the operation of the utility that generates the output file.
- A null variable is causing an error in the file name of the file to be returned.
Task step execution does not automatically change after a change to the configuration XML file
If you change the configuration XML, previously existing task steps do not automatically change unless you edit them.
To fix the existing task steps, open the task sequence editor and make a minor edit to each custom action step in the sequence. You can simply add a “.” to the description and then delete it to enable the Apply button. Click Apply. The task sequence steps are now saved with the automatically updated information from the new XML file.
Task sequence fails at “Apply Operating System” with “Failed to make volume X:\ bootable”
Several problems can cause this error.
This issue is indicated by log content similar to the following text:
MakeVolumeBootable( pszVolume ),
HRESULT=80004005
(e:\nts_sms_fre\sms\client\osdeployment\applyos\installcommon.cpp,759)
Failed to make volume E:\ bootable.
Please ensure that you have set an active partition on the boot
disk before installing the operating system.
Unspecified error (Error: 80004005; Source: Windows)
ConfigureBootVolume(targetVolume),
HRESULT=80004005
(e:\nts_sms_fre\sms\client\osdeployment\applyos\applyos.cpp,326)
Process completed with exit code 2147500037
This issue can be related to two different scenarios:
- If you are using a Format & Partition action in your task sequence to partition the hard drives, make sure that you select the check box for Make this the boot partition on one of the partitions.
If you do not make a drive bootable and the computer has only the single drive, the task sequence engine automatically makes one of the partitions the boot partition. But if there are multiple drives, the task sequence engine cannot determine which drive should be bootable, and you see this error.
- If you upgraded from the Configuration Manager RTM to SP1, you might have a problem if both hard drives are completely raw. If you have never partitioned the drives, a known bug in Windows PE prevents Windows PE from determining the drive where it was booted, and you see this error.
This situation is likely on a server with a RAID controller where you have just formed two or more RAID sets. The new RAID sets are completely raw because they have never existed before.
The only workaround to the problem of multiple raw drives is to manually boot into Windows PE and run "diskpart" to partition at least one of the drives. Then run the task sequence again. The task sequence should work.
The known problem with Windows PE is fixed in Windows Vista SP1 and hence in the Windows PE that is derived from Vista SP1.
- Install Configuration Manager 2007 SP1
- Configuration Manager 2007 SP1 includes the SP1 version of the Windows Automated Installation Kit (WAIK). Download and install Configuration Manager SP1 to get the new version.
Upgrading to Configuration Manager 2007 SP1 automatically updates your default boot images, but does not automatically upgrade the IBM boot images.
Upgrade the IBM boot images by rerunning the IBM Deployment Pack installer and selecting “Modify”. You must also update your distribution points so that the new images are used. You should also update the distribution points for the default boot images as well.
The product installer detects the version of WinPE that is currently in use by the default boot images. If the default boot images are not Vista SP1, the product cannot install.
- How to tell if your boot images are upgraded to Vista SP1
- Boot image properties contain an identifier for “OS Version.”
Perform this procedure to see the version of WinPE in your boot images:
- Click Computer ManagementOperating System DeploymentBoot ImagesIBM Deployment.
- Right-click the boot image and select Properties.
- Click Images.
- Check the OS Version property for a value of 6.0.6001.18000 or greater.
- Click Computer ManagementOperating System DeploymentBoot ImagesIBM Deployment.
- What to do if your boot images are not upgraded to Vista SP1
- You can manually recreate your boot images using the Windows AIK and following the steps listed in Technet: How to Add a Boot Image to Configuration Manager.
If your Configuration Manager processes permit, you might find it easier to remove the old boot image packages using the Admin Console, delete the files in the OSD\boot directories, and rerun the SP1 upgrade installation.
- How to tell if WAIK was upgraded to Vista SP1
- Click Start > Run; then run the Regedit command.
- Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ComponentStudio.
- There should be a single key under this key, which is named with the number of the Windows AIK version.
Note: Only one version of Windows AIK can be installed. However, an uninstall operation might have failed to remove the registry key.
In such a case, the registry key with the highest version number should be the correct version number.
- Click Start > Run; then run the Regedit command.
- What to do if Windows AIK was not upgraded to Vista SP1
- Configuration Manager is supposed to automatically upgrade the Windows AIK version during an upgrade to Configuration Manager SP1. If that did not occur, try manually uninstalling Windows AIK and rerunning the Configuration Manager SP1 upgrade.
To download Windows AIK, see the Microsoft Download Center: AIK page.
System environment variables are not carried over to the next action in the task sequence
When a task sequence runs, commands run in a command shell. When the task ends, so does the command shell environment, which causes the loss of any system variables that are defined in the task.
To pass variables between tasks, set the variables as “Task Sequence variables,” “Collection variables,” or “Machine variables.”
OSD Log Files Location
Unfortunately, the smsts.log can be stored in one of 7 locations, depending on the stage of the build and the architecture of the OS:
- WindowsPE, before HDD format:
x:\windows\temp\smstslog\smsts.log
- WindowsPE, after HDD format:
x:\smstslog\smsts.log and copied to c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
- Full version windows, before SCCM agent installed:
c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
- Full version windows, after SCCM agent installed:
c:\windows\system32\ccm\logs\Smstslog\smsts.log
- Full version x64 windows, after SCCM agent installed:
c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log
- After Task Sequence has finished running
c:\windows\system32\ccm\logs\smsts.log
- After Task Sequence has finished running(x64)
c:\windows\sysWOW64\ccm\logs\smsts.log
Sysprep parameters
Sysprep parameters
You can use the following optional parameters with the Sysprep command in Windows XP:- -activated - Do not reset the grace period for Windows product activation. Use this parameter only if you have activated the Windows installation in the factory.
Important The product key that you use to activate the Windows installation must match the product key that is located on the COA sticker that is attached to that particular computer. - -audit - Restarts the computer in Factory mode without having to generate new security IDs (SIDs) or process any items in the [OEMRunOnce] section of the Winbom.ini file. Use this command-line parameter only if the computer is already in Factory mode.
- -bmsd - Populates all the available mass storage devices in the [SysprepMassStorage] section.
- -clean - Clears the critical devices database that is used by the [SysprepMassStorage] section in the Sysprep.inf file.
- -factory - Restarts in a network-enabled state without displaying Windows Welcome or mini-Setup. This parameter is useful for updating drivers, running Plug and Play enumeration, installing programs, testing, configuring the computer with customer data, or making other configuration changes in your factory environment. For companies that use disk imaging (or cloning) software, Factory mode can reduce the number of images that are required.
When all the tasks in Factory mode are complete, run the Sysprep.exe file by using the -reseal parameter to prepare the computer for end-user delivery. - -forceshutdown - Shuts down the computer after the Sysprep.exe file finishes.
Note Use this parameter with computers that have an ACPI BIOS that do not shut down correctly with the default behavior of the Sysprep.exe file. - -mini - Configures Microsoft Windows XP Professional to use Mini-Setup instead of Windows Welcome. This parameter does not affect Microsoft Windows XP Home Edition, where the first-run experience is always Windows Welcome.
Note that if you plan to use the Sysprep.inf file to automate Mini-Setup, you must either run the Sysprep tool by using the -mini switch, or click to select the MiniSetup check box in the GUI interface. By default, if you do not choose to run Mini-Setup, Windows XP Professional runs the Windows Welcome. - -noreboot - Modifies registry entries (SID, OemDuplicatorString, and other registry entries) without the computer restarting or preparing for duplication. This parameter is mainly used for testing, specifically to see if the registry is modified correctly. Microsoft does not recommend this option because making changes to a computer after the Sysprep.exe file has run may invalidate the preparation that was completed by the Sysprep.exe file. Do not use this parameter in a production environment.
- -nosidgen - Runs the Sysprep.exe file without generating new SIDs. You must use this parameter if you are not duplicating the computer where you are running the Sysprep.exe file or if you are preinstalling domain controllers.
- -pnp - Runs the full Plug and Play device enumeration and installation of previous devices during Mini-Setup. This command-line parameter has no effect if the first-run experience is Windows Welcome.
Use the -pnp command-line parameter only when you must detect and install previous, non-Plug and Play devices. Do not use the sysprep -pnp command-line parameter on computers that only use Plug and Play devices. Otherwise, you will increase the time that it takes for the first-run experience without providing any additional benefit to the user.
Note When unsigned drivers are unavoidable, use the UpdateInstalledDrivers=yes parameter in conjunction with OemPnPDriversPath= and DriverSigningPolicy=ignore instead of the -pnp command-line parameter to provide a more seamless installation. - -quiet - Runs the Sysprep.exe file without displaying onscreen confirmation messages. This is useful if you are automating the Sysprep.exe file. For example, if you plan to run the Sysprep.exe file immediately after the unattended Setup program finishes, add the sysprep -quiet command to the [GuiRunOnce] section of the Unattend.txt file.
- -reboot - Forces the computer to automatically restart, and then starts Windows Welcome Mini-Setup, or Factory mode, as specified. This is useful when you want to audit the computer and verify that the first-run experience is operating correctly.
- -reseal - Clears the Event Viewer logs and prepares the computer for delivery to the customer. Windows Welcome or Mini-Setup is set to start the next time that the computer restarts. If you run the sysprep -factory command, you must seal the installation as the last step in your preinstallation process. To do this, run the sysprep -reseal command or click the Reseal button in the Sysprep dialog box.