CorradoGuy

So I gave this another try, I thought that I would do a build and capture on the IBM S50 and see if I could push this image out to the newer machines but it blue-screened during the build. I think my problem is with the hard drive controller drivers but oddly enough these are not listed on the Lenovo site. I will give it another try with just the Windows CD and see if it will take it that way.

When you use zero-touch with SCCM it will always look for an active advertisement otherwise it will not allow the machine to boot through the network adapter. As the machine boots through PXE it first checks to see if there is an active advertisement for the MAC or GUID and if it is not found SCCM instructs the machine to boot with the next item in the boot list. You can configure SCCM to boot with zero-touch using PXE boot which will image the machine based off of the collection that your image is based against. You can also use light-touch which will promt you for what image you want applied and this also uses PXE boot. You can also create bootable media such as CD/DVD or a USB device to get the machine to boot for a new image. All of these options can be configured so you have a wide choice of how to get the machine to image and it really depends on what you want to do. I use PXE boot with zero-touch and set the advertisement to never re-run the job no matter what and this way the machine will only take the one image and never try to re-image the machine if the boot order was changed. As long as you remove the machine from the imaging collection then it would not be an issue.

I use CCMClean.exe which was part of the SMS Toolkit 2 and this will clean it right out.

Reading through the log files I see that it can't find a network driver associated with the MAC address that was supplied. Then there are a bunch of errors saying that it can't find certain network shares and files. Have you successfully tried to image this machine hardware type before? I have some machines where I have to inject the Windows 7 driver for the hardware during the 'Install Operating System' to keep the network connection live. Unable to find Win32_NetworkAdapter where MACAddress = "78:2b:cb:9b:bc:2d" TSBootShell 7/1/2011 1:42:06 PM 796 (0x031C) Unable to find adapter during finalization TSBootShell 7/1/2011 1:42:06 PM 796 (0x031C) No valid network adapter found. TSMBootstrap 7/1/2011 1:42:07 PM 1984 (0x07C0) Failed to connect to "\\MTASCCM01.LACMTA.NET\SMSPKGD$\S010005F" (1231). Retry in 12 seconds. ApplyOperatingSystem 7/1/2011 1:43:31 PM 504 (0x01F8) Failed to find an available source location ApplyOperatingSystem 7/1/2011 1:45:09 PM 504 (0x01F8) Installation of image 1 in package S010005F failed to complete.. The system cannot find the file specified. (Error: 80070002; Source: Windows) ApplyOperatingSystem 7/1/2011 1:45:09 PM 504 (0x01F8) Failed to run the action: Apply Operating System. The system cannot find the file specified. (Error: 80070002; Source: Windows) TSManager 7/1/2011 1:45:09 PM 2028 (0x07EC) Check to make sure that the machine is getting a IP address and the network card is installing properly. If this checks then you may have a DNS issue or there may be a problem with MP but it looks like there could be a few issues.

Because you have a LAN connection you know this part is working but you did not mention if you were able to access the C: drive on the machine you were testing on. All SCCM needs is a working LAN and SATA/AHCI driver to access the machine to put the image on it. It does't really matter what image you are putting on it and whether it will work or not as long as SCCM can see the drive and access it through the network it will install. The machine may never boot properly but it will always apply the image. I would check to see if you can access the C: drive on your test machine and if you do add drivers make sure they are for Windows 7 when you are adding them to your boot image. SCCM only needs the LAN and AHCI drivers to boot the machine and they must be Windows 7 drivers and once the image has been applied you will add the OS specific drivers.

Thanks for the input, I use VMWare Workstation for Windows 7/Vista and it works great but Windows XP is a pain to get configured. I have set-up a TS to do a build and capture on VMWare and it blue-screens as well so I thought a physical machine would make life easier. The physical machine works pretty well and it is the oldest machine we have that is still running a SATA drive. I may try a build and capture with one of my old machines to see how well that works with the newer hardware. When I built the T60 for the master image it is a basic Windows XP build with only the network and AHCI driver installed and no hardware drivers other than those that come with a default Windows XP build. I did check the 'C:\Windows\inf' folder on the master machine and there are no subfolders under the main one and the same with the Wim. I had read people had issues with HAL and VM's so I decided I would avoid it for now by basing the machine off of the physical machine and not virtual. I decided to try creating a Mass Storage list in sysprep but the machine doesn't make it to Sysprep so this is not really going to work either. I copied my working TS and have made a few changes and when I go through the SMSTS logs it looks like the ATA driver is not making on the M52 which I just started testing... Driver "Intel® N10/ICH7 Family Serial ATA Storage Controller - 27C0" has already been installed. OSDDriverClient 6/30/2011 1:31:15 PM 1764 (0x06E4) Preparing to install driver "Intel® N10/ICH7 Family Serial ATA Storage Controller - 27C0". OSDDriverClient 6/30/2011 1:31:16 PM 1764 (0x06E4) Resolving content for driver "Intel® N10/ICH7 Family Serial ATA Storage Controller - 27C0" OSDDriverClient 6/30/2011 1:31:16 PM 1764 (0x06E4) Successfully installed driver "Intel® N10/ICH7 Family Serial ATA Storage Controller - 27C0". OSDDriverClient 6/30/2011 1:31:19 PM 1764 (0x06E4) Driver "Intel® N10/ICH7 Family Serial ATA Storage Controller - 27C0" has already been installed. OSDDriverClient 6/30/2011 1:31:19 PM 1764 (0x06E4) Failed to resolve content for driver "Intel® 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller - 27C0". Code 0x80040102 OSDDriverClient 6/30/2011 1:31:20 PM 1764 (0x06E4) Preparing to install driver "Intel® 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller - 27C0". OSDDriverClient 6/30/2011 1:31:20 PM 1764 (0x06E4) Resolving content for driver "Intel® 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller - 27C0" OSDDriverClient 6/30/2011 1:31:20 PM 1764 (0x06E4) Failed to resolve content for driver "Intel® 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller - 27C0". Code 0x80040102 OSDDriverClient 6/30/2011 1:31:20 PM 1764 (0x06E4) It would seem it finds the base driver but isn't finding the advanced driver and the error message I am getting is a content error but I don't have any packages built for this. The ATA driver comes in the chipset package on these machines as there is no AHCI drive available but it is not seeing it. I think the end of life is around 2014 for Windows XP so it will still be around for a bit so it would be nice to get this all working. I still have MDT going so it is not like I can't image them machines but it would be nice to get 1 image working with all machines. I will have to dig a little deeper on the driver side and see if I can import the chipset drivers for the desktops and see what happens. Thanks for the feed-back and I will post what I find.

I am pretty sure this issue is with the ATA controller and how it is implemented on these older systems. My image was based off of an IBM/Lenovo T60 and I looked at the HAL on the T60 and the S50, S51, and M52 (this machine fails as well, I tested it yesterday with the same results) and they all use the same one. On each machine the HAL being used is 'acpiapic_mp' so I do not think this is the issue. I am sure if I created another image based off of the machine listed above it would work for these three problem machines but I have gotten 15 machines to work off of the same image so I would like to add these as well instead of having a second image for 3 machines. The machine will reboot after the image is applied and then blue-screen really quickly and go through a constant boot-blue screen-reboot sequence over and over. because it is not seeing the drive it is not leaving dump files I can go through and I tried boot logging with the same result, no drive - no useful information. I have tried searching high and low for information the S50, S51, and M52 with OSD and there are few threads because these machines are so old.

You can capture the machine in a few ways, one way is to build a Task Sequence to take your raw Windows files you have on your SCCM server and then use these files to build a reference machine through SCCM. SCCM will install Windows XP onto your reference machine (physical or virtual) and then it will install the SCCM agent which will allow any software packages you have built into your TS to be installed and then it will capture the machine and upload a .Wim file to the specified location. You need to ensure that the machine has not been added to the domain as this adds extra files and it is not good on your reference machine. In this TS you will have created a Sysprep package and your custom sysprep.inf file will go in this package so SCCM can sysprep the machine before it captures an image. Not all of the software I want to have on my base image will install through SCCM so I use a build TS and then I remove the capture part so SCCM does most of my work. Once this completes I have a base machine with a lot of my needed software on it and then I log in (make sure to use no password on the Administrator account or sysprep will fail) and install whatever extra software I need. I make all of my customizations to the Administrator account to create the default account (add 'UpdateServerProfileDirectory=1' without the quotes under [unattended] to capture the default profile) and then I run sysprep.exe and have it seal the OS and shut the machine down. I then boot the machine with my Windows PE CD and then use Imagex to capture the image which I manually upload to the server. That's the short of it, I leave the SCCM agent in the machine and when it gets pulled down from SCCM it re-configures the agent and no problems with it after this. If you don't want the agent in the reference machine just use 'ccmclean.exe' from the SCCM toolkit to clean out the agent.

I am having the same problem and it is because this machine (and for me the S50 & S51) do not use AHCI drivers as they use ICH5 & ICH6 ATA controller. Because of this there is no pull-down menu as you would see in the newer drivers (IHC7 and newer). At this point I am not sure where the problem is, I can see the drivers in the Chipset drivers but it doesn't inject them into the image or at least the ATA driver isn't picked up. I have another thread on this very topic so maybe you will see a reply there before here..... http://www.windows-noob.com/forums/index.php?/topic/3854-windows-xp-gold-image-not-working-on-all-machines/

I am having a problem with my Windows XP image and I was hopeful someone could help me with this. We ise a mix of Lenovo machines and Dell T3400/T3500 machines so I wanted to build a base image to work on all machines. I have looked at all of our machines and they all have ACPI BIOS's so I thought I could use a basic machine to use as they seem to use the same HAL. We are using Dell T3400/T3500 machines and Lenovo T60, T61, T400, T410, T420, X200, and X201 laptops and Lenovo S50, S51, M52, M55, M57, M58, M90 and M91 desktops. I decided to use a T60 laptop to create my base image and loaded no drivers and used SCCM to build the image and inject our default software such as Office and so forth. I had to manually add some software so I didn't use SCCM to capture the image and instead used Imagex to capture it. So here's the problem, all of these machines work great with the exception of the oldest machines which are the S50 and S51. All of the other machines use newer SATA controller drivers starting with the ICH7 and in the BIOS I can set all machines to either AHCI or Compatability mode through the BIOS with the exception of the S50 and S51. On these three machines I only have the choice of enabling 'Serial ATA' and choosing Native Mode Operation with 'Automatic' or 'Serial ATA.' I know my problem is with the hard drive driver as the machine will take the image and once it reboots the OS starts to load and then it blue-screens and reboots. I am not sure how to get these older guys to image, I don't think it is a HAL issue although I may be wrong on this one. After reading a lot of different posts I created my task Sequence for these machines as per most guides but I had to partition the disk in Compatability Mode using MDT variable 'OSDDiskpartBiosCompatibilityMode' and then force the AHCI driver as per this thread.... http://usjensen.wordpress.com/2008/12/08/how-i-handle-boot-critical-drivers-mass-storage-drivers-for-windows-xp-in-configmgr-os-deployment/ I have tried to get these 2 machines to boot in Serial ATA mode or in regular mode and it fails to boot after the image is applied. There are no specific ATA drivers on these machines so I tried to force the chipset drivers into these machines as the ATA drivers are included in there and same thing. I know I am missing something so I was hopeful that someone could help. The machines use the following Ultra AHA Storage controllers.... S50: Intel 82801EB S51: Intel 82801FB Thanks, Dennis

I don't see any specific errors that can cause this but if you search on the error message 'sending with winhttp failed; 80072ee7' I do see other issues with network card driver errors. When you build an image it is best to use a image that has been built on a VM or a machine with minimal drivers installed, I use a IBM T60 laptop for my images and it works well (it was too hard to VMWare to work and this way I don't have to worry about HAL types). Imagex simply captures the image from the machine so this isn't really going to be part of the issue as I use this or the SCCM build and capture depending what I am doing. Depending on the version of SCCM you are using (SP1 or SP2 or R2 and so on) you will need to load two things to make this work. You will need Windows 7 network drivers and Windows AHCI drivers and these need to be in your boot image no matter what OS you are deploying. SCCM needs the Windows 7 drivers to get the image pushed onto the machine and then it needs the OS specific drivers to be installed as the image is applied so it can communicate with the machine. - Your first step is to make sure the the boot image matches the OS architecture that you are pushing out. If you are pushing out Windows XP x86 then use the x86 boot image. - Your boot image should only include the LAN and AHCI drivers for Windows 7 matching the hardware you are using (x86 or x64 but don't mix both on either boot image). - You should check the properties of your boot image and make sure the 'F8 command line support' is enabled. Once you have checked/adjusted this then boot your machine again and when SCCM first starts up click the F8 key so the command prompt comes up. Once the command prompt comes up the machine will not reboot until it is closed so this will allow you access to the machine to check things out. First, type in 'ipconfig' to see what if any IP address has been assigned and if it is coming up blank you know you have to add the machine specific network driver for Windows 7 to the boot image. If the machine is getting a IP address then type in 'c:' to see if you can get to the C: drive and access any files/folders on this drive. If the drive is not formatted then stick it in another machine and create a partition and put some files and folders on it and repeat to see if you can see this through the F8 command prompt. Once you have gone through these steps you should be able to figure out where the problem is, at the point you are stuck at it usually comes down to AHCI drivers or LAN drivers.

Hi Dexter31,depending on the security you use on your AD you may never be able to get this working during OSD. We are CIS compiant and this will not work on our network, we have to run this after the image has completed and an authenticated user has logged onto the machine. When you are running this on the machine manually are you using the default Administrator/local account or is this an authenticated domain account? In our business the Lenovo ThinInstaller will not work through any account unless it is a domain account and this is due to CIS (Center for Internet Security) baseline settings. I have never taken the time to go through the settings to see which one is blocking. When I test this in our test domain with no security it works and when the exact same thing is tried on our production enviroment it fails. You will need to go through the security logs of the machine the repository is on and see if this is what is blocking causing the updater to fail.

I would agree with the hard drive controller driver, I went through this when I was getting Win XP moved over to SCCM and for me it was the AHCI drivers. I had to force each AHCI driver in similar to what was done in this thread.... http://usjensen.wordpress.com/2008/12/08/how-i-handle-boot-critical-drivers-mass-storage-drivers-for-windows-xp-in-configmgr-os-deployment/ You may also find that the HAL is different on the VM you are using when compared to the HAL on the machines you are trying to deploy to. I use a VM for Vista and Windows 7 but for XP I use an old laptop with a ACPI HAL and use this for my image with the AHCI drivers forced in through the Task Sequence. Your blue-screens may be from the AHCI drivers or the HAL type at a guess.

The general rule of thumb is to use the boot image that matches the operating system you are trying to deploy. Your boot image should only contain the drivers for the machine to boot which would be the LAN driver and the AHCI/SATA drivers. The SCCM drivers on your boot image should match the OS you are installing, if you are installing any 32 bit operating system you should be using Windows 7 32 bit drivers and if you are installing a 64 bit OS then you should be installing a 64 bit Windows 7 drivers. These are only used to get the machine to boot into SCCM and once you are in SCCM then you will load the OS specific drivers (such as Windows XP, Vista, or 7) in your Task Sequence and you are good to go.

SCCM is simply a method of deployment, if it will deploy with Ghost then it should deploy with SCCM. If you are using AHCI for the drives you may need to make some changes to the Task Sequence to make it work properly. Why not load it in SCCM and give it a shot, the worst that may happen is a blue-screen if the hard drive drivers are not loading properly. Currently I am using a single Windows XP image for about 15 different machines and they are all working fine. I use Dell and Lenovo machines and with Dell they have nice driver Cab files which loads in all of the different drivers and for the Lenovo machines I use the Thin Installer to install the drivers. This means I use a really thin image with just base apps and no drivers or machine specific software.

I know this is a really old thread but I was looking for something else and ran across this so I thought I would update it in case it helped anyone else. When you want to run a query using WMI a good starting place is to use a machine with a Windows image on it and use msinfo32.exe to see what the information stored on each machine is like to be used in your query. For Lenovo machines I find the best way to query is to use the machine model number, my Lenovo laptop is a X201 which has the model number 3626F7U. When I create a WMI query for Lenovo machines I use the first 4 digits of the model number and create a query like this.... For a single model type: SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "2522" For multiple model types: SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "5143" or Model LIKE "3623" or Model LIKE "5485" This will pick up any model numbers that contain the numbers above so you may want to use SMS/SCCM to query all machine model numbers to ensure you don't pick-up the incorrect machine as it contains part of the model number you are looking for. I only have to deal with Lenovo and Dell so I have not had any issues with conflicting machine model numbers.

I can't help you on this issue directly (because I don't know the exact details nor can I remember what others were saying about it) but this is a know issue and Microsoft is working on a correction. If you have Microsoft support you can ask them to help you but I believe the correction was to delete the package and re-create which you have done and this did correct it for some people. I think it has something to do with the version of SCCM you are using or something along this line. You can also try managing the distribution point and then 'update all distribution points with new package source version' instead of just updating the distribution point. I know this doesn't really help you but it is a problem that a number of people mentioned at MMS 2011 and there is not a direct fix for it so you are not alone. Have you tried posting this on the Microsoft forums to see if someone there knows what the problem may be? I wish I could help more but I just remember people mentioned it but I don't recall the exact details, sorry about that.

I fought this one for days and days and followed so many different posts and in the end I did not win. When I went to MMS 2011 this was one of the things that I wanted to get a handle on and what I found was not really what I wanted to hear. There are different ways to create a default profile and it depends on the mechanism you use. First, using the Unattend.xml to create the default profile with SCCM doesn't work and this is a known issue. Unlike MDT SCCM uses the system account whereas MDT uses the local administrator account so according to Microsoft the proper way to do this is as follows. If you use SCCM you will not be able to properly capture a default account because of the way SCCM integrates MDT and the whole account thing. When I tried this in SCCM as soon as I used the 'copy profile' tag in the Unattend.xml I would get failures and error messages. I take this one line out and everything worked properly so I asked the people who created this and the ones who put a lot of time into it and this is what they said. When you use SCCM to deploy operating systems you are supposed to develop your image (fat/thin and all of that stuff) and then capture it without the default image. When you deploy the image you push it out to your target machine and then you use GPO to set the default profile for the first logon and this is the approved way of creating a default profile. If this is not for you then you will need to find another way to do it and I have seen a lot of posts where people use the 'copy profile' feature and over-write the default profile with your custom profile. There are a number of issues related to this and I still see them even in Windows XP where you didn't have to fool the OS to allow you to do this. Without going into the details the copy profile didn't work 100% because you are also copying SID's from the original profile over the new default profile which can cause problems with redirection and so on. Here's what the pro's had to say about this, in short SCCM is a mechanism used to push software and operating systems but it is not very flexible when it comes to modifying operating systems. MDT on the other hand is a supported technology through Microsoft and it is designed to manipulate operating systems. It is script driven (uses VB Script) and very configurable and this is what should be used to modify the operating system image. The supported way to modify operating systems is to use MDT to do all of your customizations and then capture your default profile which is what MDT is designed for. Once you have captured your basic operating system with your customizations you then use SCCM to push it out after the capture. I have configured SCCM to install my drivers and any machine specific software with zero-touch and currently I have two images, one 32 bit and one 64 bit. I use WMI queries to see what machine it is and then add different drivers or software as the machine is being imaged and this has worked out really well. We currently have a mix of Dell and Lenovo machines and still I am able to push out just two images (which I could reduce to one with some scripting or customizations to the task sequence) for these machines. With Dell they have Driver CAB packages which makes life really easy and for Lenovo I use the Update Retriever and Thininstaller to get the drivers on the machines. The Lenovo Thininstaller isn't working with SCCM at this time but it is a fault of our security settings and Lenovo as such but I haven't had the time to work on this part yet. I don't know if this really helps with this question but this is what I found through first-hand tests and just asking those in the know. SCCM is great for pushing software and MDT is great for OS manipulation. Currently I am doing a build and capture of Windows 7 with all of my default software being installed during the build using SCCM packages and then capturing the results. Once this is complete I am pushing the image out to the machines using SCCM and it is working great other than no customizations to the default profile. At this point I don't know if I will use GPO to create a default profile or if I will use MDT to create the default profile. I have a number of offices that will be using slightly different profiles so I wanted to automate this as much as possible but the default profile is the one that stumped me.