Video Screencast Help

Executing DISM from a custom action

Created: 16 Jan 2013 • Updated: 21 Jan 2013 | 8 comments
This issue has been solved. See solution.

I want to create a custom action that executes DISM to enable .Net 3.5 on Windows 8 or Server 2012

The action will be run when a user clicks a button on the 'Installation Prerequsities' dialog.

The instructions that work if you do this action manually are:

  1. Run Command Prompt with elevelated privlidges
  2. Use the following command:
    DISM /Online /Enable-Feature /FeatureName:NetFx3 /All

However, i cannot seem to replicate this process as an Action in Wise. I have tried using 'Execute Program from Destination' the following 2 ways, but both dont work:

  1. Working Directory: SystemFolder
    Exe and Command Line: CMD.EXE "DISM /Online /Enable-Feature /FeatureName:NetFx3 /All"
  2. Working Directory: SystemFolder
    Exe and Command Line: DISM /Online /Enable-Feature /FeatureName:NetFx3 /All

The first one brings up the command prompt, but with no command, just C:\Windows\System32. The sesond one doesnt do anything.

Two questions:

  1. Any ideas on what i am doing wrong?
  2. How do i ensure the CMD.exe runs with elevated privlidges in this action?
Discussion Filed Under:

Comments 8 CommentsJump to latest comment

EdT's picture

When calling cmd.exe you should include /C to ensure that the command window closes again when the command is complete.

If you look at the available attributes for custom actions, you will find that there are attributes to determine whether a custom action runs in system or user context. However, do not run the custom action in the UI sequence. Instead, set a public property based on the user input, and then use that property as a condition on a custom action that is sequenced for deferred execution in the InstallExecute sequence.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

Anthony Lisbona's picture

Thanks for the reply. 

I got it almost running, however because i set the 'Working Directory' to "SystemFolder" in the custom action, on a 64bit machine it is trying to run CMD.exe from C:\Windows\SysWOW64. 

When passing in the command line as per my custom action, this gives an error:

"You cannot service a running 64-bit operating system with a 32-bit version of DISM.

Please use the version of DISM that corresponds to your computer's architecture."
I know that regardless of the OS, you need to use the DISM in the C:\Windows\System32 folder, and therefore i need to use CMD.exe from such folder to call the correct DISM.
What is the best way to force the installer to use the correct CMD.exe?
I tried getting this registry value in 'System Search' and set it as a property:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\ComSpec
According to an MS KB article i found, it should return the cmd.exe i require. If i manually search for this registry value on my target PC, the value is exactly %SYSTEMROOT%\system32\cmd.exe
I then used the 'Execute Program from Path' custom action and used that property as the location of the cmd.exe.
HOWEVER, it still fails, and when i check the logs its shows that the property  has a value of C:\Windows\SysWOW64\cmd.exe ?
For some reason the system search in Wise is returning a different value than what is in the registry?
AngelD's picture

Refer to the ComSpec env. variable in your custom action instead [%ComSpec]

Anthony Lisbona's picture

Hi AngelD

Your suggestion doesn't work, as such environment variable returns: C:\Windows\SysWOW64\cmd.exe

AngelD's picture

You could always try \\[%computername]\C$\Windows\System32

However; 32-bit processes doesn't have access to the 64-bit "environment".

Anthony Lisbona's picture

Yes, thats what i ended up sort of doing.

I just hardcoded the path in the Property to C:\Windows\System32, betting on the fact that that's where 99.9% of users would have their system 32 folder.

EdT's picture

I would point out that you cannot have a single MSI that handles both 32 bit and 64 bit installs, as the Summary Information Stream needs to specify the processor architecture. As a consequence of this setting, the directory table either recovers the correct SYSTEM32 folder location for a 32 bit operating system or a 64 bit operating system.

To get this working correctly, you will have to write a custom action that identifies whether the operating system is 32 bit or 64 bit and then explictly call DISM from the correct location - vbscript can handle this for you.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

Anthony Lisbona's picture

Thanks for the suggestion.

I have ended up hardcoding the path in the meantime, and will look at finding someone to write the appropriate vbscript for me to make it 100%