Offline Servicing Errors

[DaveP]

I've been having problems injecting drivers into my install.wim file successfully using scheduled updates. The failures seem to happen at completely random intervals, and it doesn't appear to be caused by any specific update in particular. For example, a security update with ID 1837 might be the first update to fail during a scheduled update attempt, and then install fine upon a second attempt. I have found a few interesting entires in my OfflineServicingMgr.log and disk_sccmAMD64.log however, and I was hoping I could get some clarification on a few things.

 

1. (Review OfflineServicingMgr1.png) After the first driver install failure, there are many rampant errors proceeding that point in my OfflineServicingMgr.log file, and you end of looking at a sea of red. The first install error is always ErrorCode = 5. Every failure beyond that is ErrorCode = 2096. I made note of the exact time of the first install error in my log and opened my dism_sccmAMD64.log

 

2. (Review DISM1.png) You can see an E_ACCESSDENIED and an ERROR_FILE_NOT_FOUND at the same time offline servicing broke during the scheduled updates. Thinking it's a permissions issue, I ran a search for KB2691442 (referenced in the OfflineServicingMgr1.png before the first failure) on the C:\ drive of my primary site server to see what I could find. The results of my search all pointed to C:\Windows\Servicing\Packages (Directory.png). It would be helpful if anyone could provide information on the relevance of this directory and whether or not this is the location offline servicing is looking in when it's attempting to install a selected update.

 

3. (Review DISM2.png) It appears that DISM is smart enough to recognize that an update failure damages the image. I assume all subsequent errors in my OfflineServicingMgr.log (ErrorCode = 2096) can be attributed to this. This is also why it's good to deselect 'continue on error' when running scheduled updates.

 

 

All that being said, I'm not convinced it's permissions, despite the access denied error I received. That doesn't explain why 50 updates will fail to install during a scheduled update, and then those exact same updates will install successfully on a seperate attempt. Scratching my head on this one...

 

 

 

 

[DaveP]

I'm currently testing a workaround. I select roughly 50 updates at a time and watch the OfflineServicingMgr.log file. I'll wait until the first failure and select only the successful updates from the log file for a second attempt at updating the .wim. I then repeat this process over and over again; eventually including the updates that had failed during a previous scheduled update run. I'll let you all know if this ends up being a viable workaround.

[DaveP]

I managed to get all 180 updates injected, and verified the integrity of the .wim by running PXE. Everything looks good. Even though I've been unable to find the exact cause of my errors, albeit a slow process, this is a viable workaround.

[anyweb]

apologies for missing this, i was going to suggest looking at the dism logs created during offline servicing in C:\Windows\Logs\DISM\dism_sccmAMD64.log to see does it reveal any more info about the failure ?