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
- :
- Re: Detecting and Installing Windows Role & Features
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Nov 04, 2013
05:34 PM
Detecting and Installing Windows Role & Features
Some background - our installer needs to install Windows Roles & Features as part of the installation process. We've implemented this using custom actions for different versions of Windows Server.
All the custom actions use LauchAppAndWait, and we call Servermanagercmd.exe for Windows Server 2008 and call powershell.exe for Windows Server 2008 R2, Server 2012 and Server 2012 R2.
This is working well. However, we now want to improve the custom action so that it checks if the Windows Roles & Features we require are already installed, and then only installs them if they are required.
For Windows Server 2008 and 2008 R2 I think I can use "Win32_ServerFeature" within the custom action, but has anyone else done this and if so would you be willing to share your InstallScript code?
I'm at a loss for how we can achieve this in Server 2012 now that "Win32_ServerFeature" has been deprecated...
I know PowerShell commands will give the answer, but how can we pipe the result back into InstallScript? Or is there another method I've missed...
All the custom actions use LauchAppAndWait, and we call Servermanagercmd.exe for Windows Server 2008 and call powershell.exe for Windows Server 2008 R2, Server 2012 and Server 2012 R2.
This is working well. However, we now want to improve the custom action so that it checks if the Windows Roles & Features we require are already installed, and then only installs them if they are required.
For Windows Server 2008 and 2008 R2 I think I can use "Win32_ServerFeature" within the custom action, but has anyone else done this and if so would you be willing to share your InstallScript code?
I'm at a loss for how we can achieve this in Server 2012 now that "Win32_ServerFeature" has been deprecated...
I know PowerShell commands will give the answer, but how can we pipe the result back into InstallScript? Or is there another method I've missed...
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Nov 04, 2013
07:27 PM
What kind of project are you using?
In a Suite project you can install Roles/Features per package. See
Organization
Packages
Common tab
Windows Features
In a Suite project you can install Roles/Features per package. See
Organization
Packages
Common tab
Windows Features
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Nov 04, 2013
09:25 PM
A few quick thoughts... fist is that the EXE you mention is obsolete and not recommended anymore. The second is that the last time I checked InstallScript doesn't have a collection enumerator so doing the WMI queries and iterating the results is tricky. The only way I know to do it is to use a C++ DLL found on InstallSite that can be used in a get first | get next type loop.
Personally I write most of my custom actions in C# these days. If I need to call a PowerShell CmdLet that I can't find a managed API for I use System.Management.Automation to create a PowerShell runspace and invoke my commands through it.
Personally I write most of my custom actions in C# these days. If I need to call a PowerShell CmdLet that I can't find a managed API for I use System.Management.Automation to create a PowerShell runspace and invoke my commands through it.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Nov 05, 2013
04:16 AM
Thanks for your replies.
rguggisberg - The project type is Basic MSI and we use this extensively so would prefer to avoid the Advanced Suite project.
Christopher - Which EXE is obsolete? We only Servermanagercmd.exe when the installer is run on Windows Server 2008. For later OS versions we use powershell.exe.
I couldn’t find anything specific on InstallSite. Did you mean the “Sample Custom Action DLL Written in C++”?
Longer term, over the next year, I can look into the C# route, but is there any other methods to achieve what I’m looking for in the short term?
rguggisberg - The project type is Basic MSI and we use this extensively so would prefer to avoid the Advanced Suite project.
Christopher - Which EXE is obsolete? We only Servermanagercmd.exe when the installer is run on Windows Server 2008. For later OS versions we use powershell.exe.
I couldn’t find anything specific on InstallSite. Did you mean the “Sample Custom Action DLL Written in C++”?
Longer term, over the next year, I can look into the C# route, but is there any other methods to achieve what I’m looking for in the short term?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Nov 19, 2013
01:28 PM
I don't know if this will help you or not: http://community.flexerasoftware.com/showthread.php?206578-Enabling-Windows-Features-and-Roles
For an InstallScript Only project, we were able to utilize an elaborate workaround working using DISM (hardcode a list of features you require to be installed, pipe DISM output to a file, read that file into a list, compare with the list you require - checking for "Disabled"). The main issue is that the Enabled/Disabled status listed in the output of DISM is in the language of the OS (I don't think it cares about MUIs) - so if you're installing on customer's computers in multiple countries, this probably won't work either. I don't recommend it, but without the benefit of the Suite project, this is what we deal with.
HTH
For an InstallScript Only project, we were able to utilize an elaborate workaround working using DISM (hardcode a list of features you require to be installed, pipe DISM output to a file, read that file into a list, compare with the list you require - checking for "Disabled"). The main issue is that the Enabled/Disabled status listed in the output of DISM is in the language of the OS (I don't think it cares about MUIs) - so if you're installing on customer's computers in multiple countries, this probably won't work either. I don't recommend it, but without the benefit of the Suite project, this is what we deal with.
LaunchApplication( WINSYSDIR64 ^ "cmd.exe", "/c DISM /Online /get-features /format:table>" + szMyFileName, "", SW_HIDE, LAAW_PARAMETERS.nTimeOut, WAIT | LAAW_OPTION_CHANGEDIRECTORY | LAAW_OPTION_FIXUP_PROGRAM );
HTH
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)