This is quite simple to create a bootable ISO image to capture winXP or Win7.On the technician computer ,install WAIK tool Downlaod it from here .

1.On technician system launch ‘Windows PE Tools Command Prompt’ from ‘Microsoft Windows AIK’ on the Programs Menu. The entire CD build process is performed in this CMD window.

2.To begin building a Windows PE CD type: copype.cmd amd64 c:\winpe_x64

3.Now mount the Windows PE boot image as a folder on your machine so that it may be edited by typing the following: imagex /mountrw c:\Winpe_x64\winpe.wim 1 c:\Winpe_x64\mount

4.To copy servicing tools into the mounted PE image, type:
xcopy “C:\Program Files\Windows AIK\Tools\Servicing” c:\winpe_x64\mount\Windows /s

xcopy “C:\Program Files\Windows AIK\Tools\amd64″ c:\winpe_x64\mount\Windows /s /Y

5.To commit the changes made to Windows PE, type: imagex /unmount c:\winpe_x64\mount /commit

6.Copy the updated WIM to the ISO folder for creation:
copy c:\winpe_x64\winpe.wim c:\winpe_x64\ISO\sources\boot.wim /Y

7.Create your ISO image:
oscdimg -n -bc:\winpe_x64\etfsboot.com c:\winpe_x64\ISO c:\winpe_x64\winpe_x64.iso

Using your preferred CD creation software burn the disk image c:\winpe_x86\winpe_x86.iso to CD or CD-RW.

SCCM 2007 OSD is a fantastic way to deploy operating systems; however, like most things SCCM, issues can sometimes be difficult to resolve due to the sheer volume of logs to sift through and the dispersed nature of the blog posts that deal with some of these issues. This article will help SCCM OSD newbie’s with some of these issues.  

Integrating SCCM and MDT 2008
For our deployments, we always install MDT 2008 on our SCCM server and select Configure ConfigMgr Integration from the MDT area on the start menu. This gives us:  

• Templated task sequences we can import into SCCM
• Additional TS Variables for use in our task sequences
• Additional options and flexibility around computer backup, USMT etc.

For beginners, the template task sequences are a very quick way to get up and running while being guided through the process, while for more advanced users the additional functionality comes in handy when your task sequences become more complex.  

Setting yourself up
In order to have any chance at troubleshooting SCCM OSD issues, you need to do the following  

1   Install trace32.exe which is part of the SMS 2003 Toolkit 2
(download from Here)  

2   Enable command line support within your boot images:
a.   Go to the properties of your boot image(s) (right click and choose Properties)
b.  Go to the Windows PE tab and tick the Enable command support (testing only) option.
c.   When prompted, click on Yes to update your distribution points.
d.   From within your boot image (Windows PE) environment, you can now press F8 to
     open up a command window — very useful for troubleshooting  

3 Be familiar with your OS setup log files (e.g. WindowsXP has setupapi.log, netsetup.log etc.)
Log files
The root of all Task Sequence troubleshooting is called smsts.log — and this log is always the first step to troubleshooting any TS issue — if you have an issue, look in here first!  

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

Information is also logged as SCCM client events, which can be viewed by running the SCCM report:
     Last 1000 messages for a specific computer (Errors, warnings and information)  

As a general rule, the SMSTS.log provides more detail, however the SCCM client events are easier to read, and, for simple issues, can lead you to the root cause very quickly.  

PXE boot issues
In order to resolve PXE boot issues, there are two main log files we are interested in:  

• Pxecontrol.log — which is located in the installation logs directory (eg C:\Program Files (x86)\Microsoft Configuration Manager\Logs\pxecontrol.log)
• Smspxe.log — which is located in MP logs directory (eg C:\Program Files (x86)\SMS_CCM\Logs\smspxe.log)

If this is the first time you’ve setup a PXE service point, I recommend you check pxecontrol.log, there should be lines similar to the following:  

address to server list 192.168.00.117  $$Cen. Australia Standard Time>
adding address to server list 127.00.00.01  $$Cen. Australia Standard Time>
Sending availiability packet to: 192.168.0.117~  $$
Sent 274 bytes to 192.168.000.117:4011~  $$Cen. Australia Standard Time>
PXE test request succeeded.~  $$
Successfully performed availability check against local computer.~  $$Cen. Australia Standard Time>  

If you see otherwise, then, WDS or the PXE service point is not correctly installed.  Without going into too much detail in this area, as a catch-all fix:  

• Uninstall the pxe service point
• Uninstall WDS
• Reboot
• Install WDS, but DO NOT configure
• Install the pxe service point
• Re-check the pxecontrol.log

Another very common error is to see the following when trying to PXE boot:  

1:PXE-T01: The specified file was not found
2:PXE-E3B:TFTP error — File not found  

This error is caused because you are missing files from your \remoteinstall\smsboot\x86 or x64 directory and is generally caused by one of two things:  

1.The x64 boot image has not been added to the PXE service point.
“But I’m only deploying an x86  boot image and OS,” I hear you say.  It doesn’t matter.  If the machine is x64 architecture (which all today’s new machines are), the boot ROM requested will be x64. This in no way effects your ability to use an x86 boot image; this boot ROM process is completely independent.
 The solution is to add the x64 image to your PXE DP and update. You will then see the directory \remoteinstall\smsboot\x64 populated with files, and your good to go.  

2.Even after you update your PXE DP, the files still don’t show up.
This is a common issue.  When updating the DP, the WIM file is mounted (under C:\windows\temp), all your modifications injected (such as drivers, custom backgrounds etc) and then packed back up into the boot wim pushed to the DP.  At the same time, the boot ROM files were interested in are extracted to C:\Windows\temp\Pxebootfiles before being copied to \remoteinstall\smsboot\x86 or x64.    

Sometimes the C:\Windows\temp\Pxebootfiles directory has something funky happen to it and doesn’t clean itself up correctly.  So the difficult fix is — Delete the directory and re-distribute the package. (The directory is hidden, so make sure you set the option in Explorer so you can see it).  You can also have a look at pxecontrol.log to see the extraction process and/or the error occurring.  

On some computers, you might PXE boot, proceed to see a screen which indicates that the PC is talking with SCCM, followed by a line which indicates a boot ROM called abortpxe has been used.  This indicates one of two things:  

1   This computer has already been built via PXE.
If you want to run this advertisement again, you must go into the console, right click on the computer record and select clear pxe advertisement  

 2   There is no advertisement for this machines mac address or SMSBIOS GUID in the database.
This can be confirmed by viewing the smspxe.log.  In this case, you should ensure that
a. The computer record has the correct MAC address
b. The computer record is in a collection which has the task sequence advertised to it
c. The task sequence advertisement is available to PXE boot (a property of the advert)  

Software Update issues on reference build
While creating the reference build, the target machine must not be a member of a domain (and therefore must only be in a workgroup).  Because of this, the machine cannot use AD to lookup SCCM server location details and software updates will fail (after a 20 minute wait). 

To work around this, in your reference build TS, navigate to the step setup windows and configmgr, and in the installation properties add  :

This will allow the client to locate the software update point and download the appropriate updates. (Note: this assumes you have installed the Server Locator Point role on your server).
In the case that there are a large number of updates to be downloaded, you may also find that this task fails. This is caused by an issue documented in this TechNet blog entry about error 0×80244010.  Due to this issue, I recommend you create a number of software update tasks (I use 3), each with continue on error checked.  This will get around this issue, but will not cause any significant delay even if this issue does not occur. 

Drivers
The deployment guys have a fantastic blog post on how to handle drivers in this TechNet Driver Management blog entry.
  

wfsdafjkhk sdfhsdf   

Boot image drivers
SCCM boot images are customised windows PE 2.x images used to boot the computer and contact the SCCM server. There are a couple of basic rules when working with boot images:  

1   SCCM boot images only require network and local disk access (as they need to grab data from the SCCM server and apply it to the local disk) so these are the only drivers that ever need to be added to a boot image. (adding additional drivers will only bloat the image, slowing down your installs).  

2   SCCM boot images are based on Windows PE 2.x, which is based on Vista.
You must add Vista drivers to your boot images only.  Even if you’re deploying on XP, it doesn’t matter, the boot environment is completely separate to your final OS. 
The way I find out if I need to add additional boot wim drivers is to simply boot any new machines into a OSD TS, boot, press F8 to get a command prompt, then run 

1.ipconfig 

If there is no ip address (we don’t have NIC drivers and they need to be added), then run

If there are no disks listed, then we need to add mass storage drivers to the boot WIM.

Windows XP 07B stop issues
If you’re building Windows XP or 2003, these operating systems do not allow dynamic injection of mass-storage drivers. So, you have a few options: 

• Move to Windows 7 — which after 6 months of betas/RCs and now running RTM – I’m willing to say is brilliant.  …or…
• Change the disk controller mode from AHCI or RAID to IDE in the BIOS (quick, but not recommended for a long term solution).  …or…
• Use the appropriate AHCI mass storage drivers:
  a. Import the drivers into SCCM, using categories etc. (see the deployment guys blog post on
      best practices for this)
  b.  Add a task to the task sequence: Apply driver package
  c.  Select the appropriate driver package
  d.  Check the box: Select the mass storage driver within the package.…..
  e.  Select the appropriate driver.
  f.  Add a condition via a TS variable <model> or WMI Query (again, covered in the deployment guys post)

Task Sequence Variables
Task sequence variables are really what give task sequences a bucketload of power, as you can have one TS which accounts for all the variations in your environment. 

One of the most common questions is:
      How do I know what TS Variables are available?
Well, there is a list in this article:  Operating System Deployment Task Sequence Variables, or you could read the documentation (Toolkit Reference.doc from the MDT 2008 documentation), or search through the script which gathers the variables (ZTIGather.vbs), or dump them all out using another useful script from the deployment guys (See Logging All the Configuration Manager Task Sequence Variables).

The advantage of dumping them all is that the output actually has meaning, so you can see what variable has what value — as opposed to just looking at a bunch of variables that might not mean much to you without values assigned to them.

In addition to the built in variables, you can add custom variables to computer objects or to entire collections. 

sdfsdf  

SCCM Client Version
If you are using SCCM 2007 SP1, there is a hotfix, KB955955 available here, which you should apply, as it removes a delay between tasks, which, for long task sequences can significantly reduce build time.  The article also includes instructions on how to implement the hotfix during your bare-metal builds.

Thre are many methods which you can achive this task but i like this way in doing  for prompting the computer name in MDT SCCM when deploying an image would be using the below simple VB script.It deals with known and unknown computers.

set env = CreateObject(“Microsoft.SMS.TSEnvironment”)

‘Set the OSDComputerName variable to the detected name assuming this is a known computer

env(“OSDComputerName”) = env(“_SMSTSMachineName”)

‘If the detected name contains “MININT” then this is an unknown computer so ask for a name

If InStr(1,env(“OSDComputerName”),”MININT”,1) then

    Name = inputbox(“Rename Computer” ,”Please enter the new Computer name below:”,env(“OSDComputerName”),400,0)

    env(“OSDComputerName”) = Name
    env(“ComputerName”) = Name
    env(“HostName”) = Name

End If

Copy the script and paste in note pad and save it as .vbs.Add this script to your MDT tool kit package in scripts folder(if you have integrated MDT with SCCM else create a package for this script and a program with command line as cscript VBscript.vbs which have not tried).

Update the DP and make sure,the script should be avilable in  in the DP share.

Now create a new Task  after ’Use Toolkit Package’ step in the ‘Initialization’ phase (group) in your TS with the command line(in mycase it is cscript.exe %deployroot%\scripts\Prompt-CN.vbs).

Below are the simple tasks which can be used to deploy OS:

1. Restart in Windows PE
2. Partition disk
3. Use Toolkit Package
4. Set OSDComputerName
5. Apply Operating System 
8. Apply Windows Settings
9. Apply Network Settings
10. Setup and configure

Below is the sample Task Sequence which you can downlad it from here Win7_X86_Computer Prompt .edit the Task sequence to change the boot image ,Wim Image and other packages as well.

Thanks to Mark for original script.

You can also do this by creating a collection variable called OSDCOmputername to the computer collection and advertise the Task sequence to the collection. More Via Technet and Via windows-noob

when I advertise the TS on computers ,it failes because of various reasons and could not able to identify the reason for the faliure.So i decied to look into the SCCM default report for the particular Task sequence.the report doesnt give you all the full information just the task name where it failed.So later someother day fould an easy way to look into the smsts.log .Whenyou advertise the any Task sequence onto the computers in WIN PE environment ,you may encounter some of the tasks which fails in the begining.How do you identify the reason for the failure of Task.you can do the in the WIN PE session starts.But to view the logs and other stuff ,you should have enable “enable command prompt support (for testing only)” on theboot image that you select in booting up in SCCM.

Once the WINPE session starts ,press F8 and it gives you the command prompt support with the default path like x:\windows

Usually the logs will the stored in X:\Windows\Temp\SMSTSLog\ or C:\SMSTSLog or C:\_SMSTaskSequence.Now i want to see the smsts.log which is present in x:\windows\temp\smstslog.

Type cd temp\smstslog command prompt looks like below now x:\windows\temp\smstslog If you want to open the smsts.log which is present in smstslog folder ,just do notepad smsts.log,it will open the .log file in notepad which is not good to read /identify the errors.Lets move onto the next step by connecting the network share to copy the log files onto.

on the command prompt x:\windows\temp\smstslog  just type net use k: \\192.168.10.15\soft (Where k: drive letter to map and soft is folder on the share to copy the log files) .It prompt you for the use name and password. Provide user name(ex:eskon\xoluser) and password (which is invisble) where xsoluser should have write permission to the above share and eskon is a domian.when you enter the credentials,it gives you maessage connected successfully.In the commnd prompt i.e x:\windows\temp\smstslog type copy smsts.log  K:\ .you will see 1 file copied sucessgully.You can open the smsts.log with trace32.exe which you can get if you install SMS/SCCM tool kit from microsoft.