A Different OSD Task Sequence Error 0x80040102
The reason I picked this error message as something to blog about is because I ran into a situation where this error code was a little bit misleading at face value. As a result more time was spent on this issue as we tried to isolate the root cause and resolve it. The funny thing about this error is that it can lead you on a bit of a goose chase as you try to fix your OSD task sequence if you don’t properly read your log.
At face value this error is nothing more than a simple problem with a package missing from a distribution point. The problem for me was that I was dealing with a bunch of issues straightening out the OS deployment piece where I was at so I wasn’t exactly trusting the infrastructure health. No matter what I did with the problem package the error would persist but if I recreated the problem package from scratch the error went away. Unfortunately once I fixed one package a new package became a problem. I then went about replacing all my packages until the task sequence started complaining about my installation source for the second time. At this point I knew I was in some sort of loop and recreating all my packages again wasn’t going to fix anything.
To make the situation even more confusing my 64-bit task sequence was using the problem packages without issue but my 32-bit task sequence was generating errors saying the content wasn’t available. At this point I was pulling out my hair trying to find out what the root cause of this mess was. Well it turned out the problem wasn’t SCCM but VMware Workstation. And to be fair it wasn’t VMware’s fault it was my mistake as to how I configured the virtual machines for imaging. So how could the VM configuration make such a big difference?
When I was reading my SMSTS.log it was very clear that package INI00027 wasn’t being found by the SCCM client environment.
But it wasn’t available for the usual reason which is usually missing files on the distribution point. When I looked at my only distribution point the files were happily waiting to be used. After another dive into the logs I realized that I wasn’t properly reading the SMSTS.log! If I look up a few lines I found the critical message.
My operating system deployment client thinks that the distribution point is not local and determines the package is not available which is a good behaviour. Most people wouldn’t want SCCM to deploy operating systems over a WAN link so this is why this is a default behaviour inside SCCM. So why it this virtual machine not appearing to be local to the distribution point? Easy, after looking at my virtual machine configurations in VMware Workstation I realized the mistake I had made configuring the virtual machines. The working 64-bit VM had its network interface set to bridged so it was getting an IP address off of the corporate network.
However the broken VM I had left the default of having the VM on a NATed network making the SCCM task sequence think the PC is not on a local network to the distribution point.
You might not see the specific situation I’ve encountered but hopefully this sheds more light on the logging and another possible cause for this error code. Also look at this blog post for the more common situations which this error can occur.
http://brothertu.blogspot.com/2008/09/failed-to-resolve-selected-task.html