[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 5028
  • Last Modified:

MDT update failure with OS Packages

Hi All,

We have a working WDS/MDT System in place and are now trying to reduce the Task Sequence time by importing the OS Packages offline to help with this.

I have installed WSUS and also uses WSUSOffline to see if it was package based but it seems to be an MDT and DISM issue.

So I import the CAB/MSU file into MDT Packages section and update the deployment share. When DISM tries to import the Packages into the WIM I get the following error:

Deployment Image Servicing and Management tool
Version: 6.3.9600.16384

Image Version: 6.3.9600.16384

Processing 1 of 1 - Adding package Package_for_KB2888049~31bf3856ad364e35~amd64~~6.1.1.1

Error: 0x800f081e

The specified package is not applicable to this image.

The DISM log file can be found at C:\Windows\Logs\DISM\dism.log

Exit code = -2146498530

DISM /Add-Package failed, rc = -2146498530.
Injected package package_for_kb2888049 neutral amd64 6.1.1.1

Open in new window


Anyone know of how to fix this or work around this?

Thanks.
0
Jo-Beth
Asked:
Jo-Beth
  • 3
  • 2
1 Solution
 
Mike TLeading EngineerCommented:
Hi,

Error code 0x800f081e means "this patch is not applicable". What OS are you patching.
The patch KB2888049 is only for Windows 7 SP1 according to the download page:
http://www.microsoft.com/en-gb/download/details.aspx?id=40611.
(but the 32-bit page says the same)
http://www.microsoft.com/en-gb/download/details.aspx?id=40576.

So, I'm guessing the patch you have is the wrong bit size, or you don't have SP1. Neither sounds right though.

If you've already organised MDT nicely to have 32-bit and 64-bit (if you have 32-bit machines) then make sure you have profiles set to only include 64-bit patches.

Mike
0
 
Jo-BethAuthor Commented:
Hi Mike

The patches in the original post are just an example of a large list, and was easier to just test with a few.

The OS, is Windows 7 x64 and we do not install 32-bit version. The OS wim was taken from a SP1 disc. Also only the x64 packages have been downloaded, using wsusoffline which I have found to be a lot nicer to use.

I am going to guess that the wim is not SP1, and requires packages to update to SP1...but I would still expect MDT to allow you to import said packages into the WIM to allow this during deployment.

Do you know of a way I could get this working?
0
 
Mike TLeading EngineerCommented:
Hi,

MDT will happily import any patch but it doesn't care what OS it will apply to. That's down to your choice and ability to set WMI filters in the task-sequence etc. The problem comes if you import an OS WIM - say XP 64-bit and import patches for Vista and then don't use some method of filtering MDT will indeed deploy Vista patches to XP because you didn't tell it not to.

I just found someone with the same error here: http://social.technet.microsoft.com/Forums/es-ES/528953de-13f2-4b1c-ac5c-29f7d34a7060/mdt-2012-add-updates-to-windows-7-sp1-is-build-61760117514?forum=mdt

If you check in MDT, under the OS node the version for SP1 should be 6.1.7601.17514 to clear up any mystery there.

As for the import, if you already have WSUS up and running I would use that instead and enable the Windows Update steps in the latter stage of the TS to create a new master image (WIM). Then just use that to replace the WIM you have now.

It does seem the error is just that MDT doesn't like Updating in this scenario.

Mike
0
 
Jo-BethAuthor Commented:
Right so I have done some testing and it seems even though when you update the deployment with packages added and it moans that it does not work... It actually does.

I have added over 120 packages (which have been downloaded with WSUSOffline) to MDT and updated with them giving that error, yet when I do my deployment the Package still gets added and has saved us around 2hours per deployment.

Must just be a bug with the updating of the deployment, and reporting packages. There is a few packages that caused the Deployment to crash, but a bit of trial and error allowed for these to be removed, and once removed all worked fine.

Thanks for the help and advice Mike, we may look at including WSUS in the end and using the customsettings.ini way of deploying the updates.
0
 
Jo-BethAuthor Commented:
Solution that has the resolved information.
0

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now