This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Enabling Windows Features and Roles
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Jul 01, 2013
11:09 PM
Enabling Windows Features and Roles
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.
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.
(6) Replies
‎Jul 02, 2013
07:00 AM
Upgrade to IS 2013 and it is easily done as part of a Suite project.
‎Jul 02, 2013
07:45 AM
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
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
‎Jul 03, 2013
05:54 PM
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!
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!
‎Jul 03, 2013
06:27 PM
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
Here is a thread that I found quickly on that topic.
http://community.flexerasoftware.com/showthread.php?183728-Hide-command-prompt-launched-with-LaunchAppAndWait
‎Aug 27, 2013
11:14 PM
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.
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.
‎Oct 28, 2014
08:59 PM
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!
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!