locked
DISM Error:5 error when building boot ISO with WADK 8 and MDT 2012 sp1 RRS feed

  • Question

  • Hi

    Environment: Windows server 2008 R2(VM), 2GB RAM, WADK 8, MDT 2012 SP1

    When I try to build a boot ISO using either MDT or ImageX, I receive an error when DISM is used to add packages.

    Processing 1 of 1 - Adding package WinPE-HTA-Package~31bf3856ad364e35~x86~~6.2.9200.16384
    An error occurred - WinPE-HTA-Package Error: 0x80070005

    Error: 5

    Access is denied.

    This repeats for all WINPE packages being added by DISM. 

    I have rebuilt the server and reinstalled but the same affect. I have tried running it as admin, editing rights and making the name of the packages lower case but cannot seem to get anywhere. Any help would be great.

    Thursday, September 20, 2012 3:03 PM

Answers

  • The issue here was McAfee VirusScan 8.8 Access protection. While there was no log of it preventing any activity, when disabling the 'access control', it added the packages successfully. I will have to dig through the access control modules to exactly what is getting blocked
    • Marked as answer by Zain Richards Thursday, September 20, 2012 3:43 PM
    Thursday, September 20, 2012 3:43 PM

All replies

  • The issue here was McAfee VirusScan 8.8 Access protection. While there was no log of it preventing any activity, when disabling the 'access control', it added the packages successfully. I will have to dig through the access control modules to exactly what is getting blocked
    • Marked as answer by Zain Richards Thursday, September 20, 2012 3:43 PM
    Thursday, September 20, 2012 3:43 PM
  • Hi,

    I have the exact same issue on my MDT server (2008 R2, ADK, VirusScan 8.8, MDT 2012 U1) and my conclusion is the same as yours.

    For now, I have disabled Access protection but I can't find exactly what is causing the issue on the Access Protection module. Nothing appears on the logs.

    Please share any information that you may have about this.


    • Edited by JFD7 Monday, September 24, 2012 8:20 AM
    Monday, September 24, 2012 8:17 AM
  • As a test, I disabled all Access control modules and enabled logging for them and tried to create images. This still failed with with Access control is enabled. It therefore seems that McAfee has default access protection on something in ADK. I say ADK as the issue only appears ADK and not waik. I have logged an SR with McAfee and hopefully they'll get it sorted
    Tuesday, September 25, 2012 10:10 AM
  • Ok thanks for the update. Please let me know what McAfee said about this.
    Wednesday, September 26, 2012 8:13 AM
  • Any news ?
    Thursday, October 4, 2012 9:34 AM
  • Not yet. The SR has been escalated to McAfee tier 2 support and I await their response
    Thursday, October 4, 2012 9:39 AM
  • Hi,

    Have you found a solution with McAfee ?

    Wednesday, October 17, 2012 9:02 AM
  • The issue has been escalated to McAfee Tier 3 support. Will post if we find a resolution. In the meantime, disable access protection when creating the ISO
    Wednesday, October 24, 2012 8:59 AM
  • Same problem here.  Hope you find out what's the underlying cause.
    Monday, November 5, 2012 9:50 PM
  • We experience the same problem here when we try to add updates to an OS image in SCCM 2012 RTM. With McAfee Acceess Protection enabled the adding of updates fails. As soon as AP is disabled the updates are added successfully.

    I hope there is a permanent solution to this problem because I don't like to disable AP manually whenever we want to patch an image. And disabling it permanently is no option for the IT  Security Officer.

    Thursday, November 8, 2012 8:54 AM
  • The issue has been escalated to McAfee Tier 3 support. Will post if we find a resolution. In the meantime, disable access protection when creating the ISO
     Still no solution found with McAfee support ?
    Monday, December 3, 2012 8:26 AM
  • The issue has been submitted to the developer team so it will only be resolved using during the next VSE patch or hotfix.
    Monday, December 3, 2012 8:29 AM
  • FYI, McAfee investigated this issue at the code level and found the behavior of DISM.exe is not within their control.

    i.e. Access Protection is not actively causing DISM to fail - McAfee is taking no action on anything DISM is doing, but DISM is taking some code path to fail seemingly just because McAfee's code is present. Thus McAfee will be releasing a KB article advising folks to use the workaround if they want a McAfee resolution, or to engage Microsoft to find out why DISM is behaving the way it is.

    Monday, December 10, 2012 5:46 PM
  • Check this blog:

    http://donnystyle.wordpress.com/2013/01/13/mcafee-causes-boot-image-action-problems-configuration-manager-2012-sp1-sysctr/

    • Proposed as answer by -_Muffy_- Friday, January 18, 2013 12:07 AM
    • Unproposed as answer by -_Muffy_- Friday, January 18, 2013 12:07 AM
    Wednesday, January 16, 2013 11:48 PM
  • The solution we used was to identify the WAIK and MDT exes and make exceptions in McAfee. The hit is on the YUNSIP32 virus heuristic as a usp10.dll is being written on the drive in a location other than C:\Windows\System32.  Once the exception is set MDT2012 runs without error. I discovered the heristic using Beyond Compare to sync the DeploymentShares. Once BC.exe found the error I ran a manual copy (explorer.exe)without issue but once a third party tool copies the file McAfee pulls its triggers.
    Friday, January 18, 2013 12:18 AM
  • FYI, McAfee investigated this issue at the code level and found the behavior of DISM.exe is not within their control.

    i.e. Access Protection is not actively causing DISM to fail - McAfee is taking no action on anything DISM is doing, but DISM is taking some code path to fail seemingly just because McAfee's code is present. Thus McAfee will be releasing a KB article advising folks to use the workaround if they want a McAfee resolution, or to engage Microsoft to find out why DISM is behaving the way it is.

    McAFee KB Posted:  https://kc.mcafee.com/corporate/index?page=content&id=KB76867&actp=search&viewlocale=en_US&searchid=1366808442071

    Johnnnie

    Wednesday, April 24, 2013 3:30 PM
  • Does this solution works ?  There is no way we can just disable On access / HIPS on our Servers.  We could create exceptions if needed.

    Can you just give all details on exceptions you created to have a MDT 2012 working as supposed on a server with VSE and HIPS.

    Thank you,

    Monday, June 3, 2013 1:46 PM
  • McAfee has updated the KB.

    https://kc.mcafee.com/corporate/index?page=content&id=KB76867&cat=CORP_PRODUCTS&%20actp=LIST

    After working with Microsoft, it is apparent that Microsoft is unable to address the two known issues in the registry API, due to the complexity and ramifications to the operating system.

    As such, Microsoft worked with McAfee to help identify an alternate workaround that McAfee has plans to implement.

    McAfee has reviewed Microsoft's proposal and plans to adopt it in a future release. However, this is not a small code change and has complexity and ramifications for VSE. This article will be updated when a release is available that includes this code change.


    Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.


    This forum post is my own opinion and does not necessarily reflect the opinion or view of my employer, Microsoft, its employees, or MVPs.

    Twitter: @alexverboon | Blog: Anything About IT

    • Proposed as answer by Scoobysnax Thursday, January 16, 2014 7:52 AM
    Monday, July 22, 2013 6:31 PM
  • https://kc.mcafee.com/corporate/index?page=content&id=KB76867&actp=LIST

    There are 10 kinds of people in the world. Those who understand binary and those who dont.

    Thursday, January 16, 2014 7:41 AM
  • Has anyone found a solution or at least heard an update?  I cannot get it to work even with the work-around of disabling Access Protection.
    Monday, July 28, 2014 4:58 PM
  • FYI, the issue has been fixed in VSE 8.8 Patch 5 :

    https://kc.mcafee.com/corporate/index?page=content&id=KB76867

    Tuesday, February 2, 2016 2:24 PM