Sign in
 
HomeLibraryWikiLearnGalleryDownloadsSupportForumsBlogs
Resources for IT Professionals >
> 
> 
> 
DISM Error:5 error when building boot ISO with WADK 8 and MDT 2012 sp1

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

  • Thursday, September 20, 2012 3:03 PM
     
     
    Sign In to Vote
    0

    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.

     

All Replies

  • Thursday, September 20, 2012 3:43 PM
     
     Answered
    Sign In to Vote
    1
    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
    •  
     
  • Monday, September 24, 2012 8:17 AM
     
     
    Sign In to Vote
    0

    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
    •  
     
  • Tuesday, September 25, 2012 10:10 AM
     
     
    Sign In to Vote
    0
    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
     
  • Wednesday, September 26, 2012 8:13 AM
     
     
    Sign In to Vote
    0
    Ok thanks for the update. Please let me know what McAfee said about this.
     
  • Thursday, October 04, 2012 9:34 AM
     
     
    Sign In to Vote
    0
    Any news ?
     
  • Thursday, October 04, 2012 9:39 AM
     
     
    Sign In to Vote
    0
    Not yet. The SR has been escalated to McAfee tier 2 support and I await their response
     
  • Wednesday, October 17, 2012 9:02 AM
     
     
    Sign In to Vote
    0

    Hi,

    Have you found a solution with McAfee ?

     
  • Wednesday, October 24, 2012 8:59 AM
     
     
    Sign In to Vote
    0
    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
     
  • Monday, November 05, 2012 9:50 PM
     
     
    Sign In to Vote
    0
    Same problem here.  Hope you find out what's the underlying cause.
     
  • Thursday, November 08, 2012 8:54 AM
     
     
    Sign In to Vote
    0

    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.

     
  • Monday, December 03, 2012 8:26 AM
     
     
    Sign In to Vote
    0
    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 03, 2012 8:29 AM
     
     
    Sign In to Vote
    0
    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 10, 2012 5:46 PM
     
     
    Sign In to Vote
    0

    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.

     
  • Wednesday, January 16, 2013 11:48 PM
     
     
    Sign In to Vote
    0

    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
    •  
     
  • Friday, January 18, 2013 12:18 AM
     
     
    Sign In to Vote
    0
    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.
     
  • Wednesday, April 24, 2013 3:30 PM
     
     
    Sign In to Vote
    0

    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