locked
OSD works, but client never installs. No errors... RRS feed

  • Question

  • I'm hoping someone can help...

    When i create a task sequence to deploy and image, and i use the base install.wim that i copy from a Microsoft Windows 7 x64 ISO, the task sequence will run through the steps and successfully setup windows and install the client.  There are no issues what so ever.  However, if i take that same task sequence and swap the install.wim with a custom thick image (.wim) file we have used through MDT, the client never installs.  Everything seems to complete fine, the system reboots and goes through sysprep, but the task sequence never resumes to install the client.  No client in control panel, no ccmsetup folder in C:\Windows, the logs in C:\_SMSTaskSequence\Logs don't continue to update after the reboot... nothing.  The logs have zero references to anything failing or error'ing, and all exit status's are 0.  I'm trying to figure out what i should look for next.

    The image in question has been built in a VM, sysprepped using a custom sysprep file, then captured with imageX.  And to re-iterate, we've never had a problem with the image in any way deploying it through MDT, and it seems to work find through SCCM with the exception of the client install.  The task sequence just doesn't continue after the reboot.  Looking at the logs, i see it's setting some hooks that i assume are for re-starting the task sequence or installing the client after the restart, but this part i'm not clear on. 

    I'm running SCCM 2012 R2 SP1 CU1, and the problem existed even before the SP1 and CU1 upgrade yesterday.  I'm new to SCCM and i've been scouring forums and blogs, but i can't seem to find this particular issue.  It must be something in the image, but short of rebuilding it step by step while testing another imageX capture and another deployment at each step (really time consuming), i'm at a loss.  The image is up to date on patches, includes MS Office 2013, and it does have an Altiris client on it i'll try removing next, but other than that just standard small programs.

    Thanks for any help,

    Ian

    Friday, September 25, 2015 8:44 PM

Answers

  • Well, it was something with the image.  I took the same image that failed and uninstalled VMTools, SCEP, the Altiris client, and ran it through sysprep before re-sysprepping it and now it works.  Unfortunately i can't say which of those actually fixed it, but i'm back in the game now.

    Ian

    Monday, September 28, 2015 11:57 PM

All replies

  • I've recreated the boot image and boot disk a few times, and the version number is 6.3.9600.16384, so i'm not sure this applies.  I don't get an error either.  I'm switching to x86 to see if that has any affect, but since everything worked on a simple oem install image, i'm pretty sure it's not the boot image.
    Monday, September 28, 2015 5:13 PM
  • Well, it was something with the image.  I took the same image that failed and uninstalled VMTools, SCEP, the Altiris client, and ran it through sysprep before re-sysprepping it and now it works.  Unfortunately i can't say which of those actually fixed it, but i'm back in the game now.

    Ian

    Monday, September 28, 2015 11:57 PM
  • Why do you have you have all of that in your image? Particularly the VMTools. Images should be hardware agnostic and in general should tend to be lighter to avoid specific issue like this. That's the whole point of having a powerful task sequence engine: to avoid having to cram everything into a monolithic, error prone image.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Tuesday, September 29, 2015 2:32 PM
  • VMTools was there because it made life easier, and it never posed a problem imaging with Symantec Ghost or Altiris.  Traditionally it was removed by the SetupComplete.cmd script post sysprpep, but SCCM seems to want to overwrite that (but that's another issue i need to figure out).   Unfortunately in our environment, thick images save a ton of time.  Imaging anywhere from 10 to 100 machines a day, while waiting for each one to step through post imaging task sequences to install updates and packages would take 3 or 4 times as long.  They are hardware agnostic except for the VMTools, all drivers are installed via the make and model query.
    Tuesday, September 29, 2015 3:16 PM
  • The technology used to perform the imaging is irrelevant as that's not the source of the issue -- as mentioned, having a hardware agnostic image should be the goal thus allowing the image to be used on different platforms. Placing the VMTools in the image makes the image hardware specific and doesn't really make anything easier -- it actually makes life more difficult because now your image is also tied to a specific version of that component meaning you need to rebuild the image if that component updates.

    Deploying VMTools to all of your systems is a bad idea. As mentioned, not necessarily the source of the issue, but doing it during deployment is so much easier. There simply is no reason to have this in your image.

    Updates should be injected into the image or you should rebuild your clean base image periodically to eliminate them having to be deployed during the deployment TS. Eliminating the updates and just leaving applications will still add some time, but it won't be anything overly significant particularly compared to the time you have wated and are wasting managing images.

    Also, why are you "waiting"? Kick them off and go do important things.

    SetupComplete is used by the task sequence process and is why using it doesn't work.


    Jason | http://blog.configmgrftw.com | @jasonsandys


    Tuesday, September 29, 2015 3:27 PM