Enabling Windows Features and Roles

[donald_gardner]

Hi there

I'm currently in the process of upgrading one of our installers. Our software requires various Windows roles and features to be enabled. At the moment, we are achieving this by using ocsetup, and calling it via a simple custom action to call the program.

However, ocsetup is deprecated, and will not be supported ongoing. After a bit of research, it appears that the favoured approach is to use PowerShell, and to install new features using Add-WindowsFeature. And fortunately, because IS2012S supports the PowerShell custom action type, I figured it would be easy.

So, I have a very simple Powershell script:

Import-Module Servermanager
Add-WindowsFeature -Name Web-Server

which should import the required module, and then install the Web-Server role. I have tested the script in Powershell, and it works fine; the only caveat is that the PowerShell session must be elevated to have Admin rights. So far, so good. However, when I add the script to a custom action in InstallShield, nothing happens. No role added, no error messages, nothing in the log; just nothing!

I have added some basic commands to the script to display a message box, and that works fine, so I'm getting as far as executing the script; I just don't know why this piece doesn't work. I suspect it is to do with UAC elevation, but that's only a guess, as there is no built-in logging, and my pitiful PowerShell skills don't extend to logging (yet).

So, long story short, a few questions:

1) Does anyone know why the script isn't working? Is it UAC like I think? And if so, how can I tell InstallShield to run the script in an Admin-elevated session?

2) How come the outcome of the script isn't logged to InstallShield? Is there something simple I am missing, or is this not supported?

3) Is this the best way to be doing this at all? The official documentation says ocsetup and ServerManagerCmd are both deprecated, and PowerShell replaces them, but is there a better way to be doing this?

Thanks in advance for any feedback!

Cheers, Don.

[rguggisberg]

Upgrade to IS 2013 and it is easily done as part of a Suite project.

[phill_mn]

I launch dism.exe /online with additional switches depending on what I am doing.

http://technet.microsoft.com/en-us/library/dd744582(v=ws.10).aspx

http://technet.microsoft.com/en-us/library/ee441260(v=ws.10).aspx

I believe that DISM.exe is the preferred method over scripting (which may be disabled) and over deprecated tools like pgkmng.exe.

Phill

[donald_gardner]

Thanks for the feedback!

Unfortunately, upgrading to 2013 turned out not to be an option. 2013 requires an advanced suite project to install Windows features, and our current 2012 installer is only a basic MSI project. And since there doesn't appear to be any easy way to convert from one to the other, and the time-frame I'm working to, I have to pass on that option.

Thanks for the DISM links. I had considered using DISM, but all the documentation recommended PowerShell instead. However, looking at those links, and playing around with DISM a little, it seems to be the perfect replacement for ocsetup, so I think we'll give that a try. One question; how do I stop DISM running in a command window? It's not a deal-breaker, but I'd prefer not to have that ugly screen pop up in the middle of the installation if possible 🙂

Thanks again!

[phill_mn]

In installScript I use LaunchAppAndWait with the LAAW_OPTION_HIDDEN option

Here is a thread that I found quickly on that topic.
http://community.flexerasoftware.com/showthread.php?183728-Hide-command-prompt-launched-with-LaunchAppAndWait

[KHilker]

Donald - Just as an FYI:
Suite/Advanced UI projects aren't designed as a replacement for basic MSI projects. They can be used as a wrapper/bootstrapper around your current MSI project to add functionality; such as installing multiple packages and prerequisites, installing windows roles and featuers, and enhancing the installation UI.

[donald_gardner]

Well, it's been a long time since my original post, but having revisited this problem recently, I have finally found the source of the problem. So, I thought I'd post it here, in case it helps somebody else with the same issue 🙂

After considerable investigation, I found that the cause of the problem was that my Installshield project was 32bit, due to the requirements of our product. This meant that the PowerShell script was being run in a 32bit instance of PowerShell, which apparently was unable to correctly install the components in a 64bit operating system.

Luckily, after some additional searching, I found the following article:

http://www.nivot.org/blog/post/2012/12/18/Ensuring-a-PowerShell-script-will-always-run-in-a-64-bit-shell

It contained the following code snippet, which detects if the script is running in 32bit, and re-runs it in 64bit instead:

# am I running in 32 bit shell?
if ($pshome -like "*syswow64*") {
write-warning "Restarting script under 64 bit powershell"

# relaunch this script under 64 bit shell
# if you want powershell 2.0, add -version 2 *before* -file parameter
& (join-path ($pshome -replace "syswow64", "sysnative") powershell.exe) -file `
(join-path $psscriptroot $myinvocation.mycommand) @args

# exit 32 bit script
exit
}

# start of script for 64 bit powershell

write-warning "hello from $pshome"
write-warning "My original arguments $args"

This fixed the problem for me; the script detected it was 32bit, ran a 64bit instance of itself, and then correctly installed the Windows Features. Problem solved!