Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
I previously wrote a blog post listing the silent install, repair and uninstall command line parameters for the .NET Framework 4. Since then, I’ve gotten questions from a few folks who are trying to deploy the .NET Framework 4 in ways that require them to run the MSIs directly instead of using the setup executable (for example, via Group Policy or WMI). Here are some steps you can use to extract the .NET Framework 4 setup package and create administrative install points for the MSIs that are a part of the .NET Framework 4:
Once you’ve created the administrative install points described above, you should be able to install the MSIs in the administrative install point folders directly or use steps like the ones previously published for the .NET Framework 2.0 to create Group Policy objects to deploy the .NET Framework 4. When doing this, you will need to apply an additional transform to each of the MSI files to prevent the installation from blocking you and telling you to run setup.exe instead. I have created an example transform that you can download from here for this scenario. This transform changes the condition for CA_BlockDirectInstall to False so it will not be run during the installation process.
Important note: when creating administrative install points and installing the .NET Framework 4 MSIs directly, it is your responsibility to install all of the prerequisites for these MSIs onto the target computer prior to attempting to install the MSIs. This includes the OS prerequisites listed here plus the OS update (.msu) files that are packaged with the .NET Framework 4 if you are running setup on Windows Vista or higher. If you do not install these prerequisites, then installing the MSIs will fail.
<update date="6/17/2010"> Added a link to a transform that can be used to bypass the custom actions in the .NET Framework 4 MSIs that prevent installing the MSI drectly and tell you to run setup.exe instead. </update>
<update date="9/18/2014"> Fixed broken link to the transform. </update>
I have followed your recipe and created an installation point. However, when I run the msi directly or via GPO it gives me an error saying that this product should be installed via setup.exe. What am I doing wrong?
Hi Gooky - The command line parameter EXTUI=1 is what suppresses that error message. I was under the impression that passing that parameter when creating the administrative install point would cause it to be propagated through when creating a GPO from the MSI in the administrative install point, but I could be wrong. I'm not entirely sure how to get that property to propagate through into the MSI in a GPO because I don't think you can pass properties in when you create a GPO. I don't have this type of environment available to me to test this more deeply though.
Same issue as Gooky. I tried editing the MSIs with Orca, and it didn't work no matter how I did it. I tried adding EXTUI=1 to the Property table, and I tried removing the CA_BlockDirectInstall values from CustomAction and InstallExecuteSequence. No dice.
Why must this be harder than previous .NET Framework installs?
Hi Perpetually Frustrated MS Admin - I'm not sure why this scenario isn't working as expected. Previous versions of the .NET Framework had similar blocking custom action with properties that can be used to override them, they are documented in the deployment guides, and I haven't heard reports of this type of problem.
In general, I don't recommend directly modifying an MSI unless it cannot be avoided. In this case, it sounds like you may have missed modifying one of the places where this blocking custom action is triggered. You should be able to narrow this down further by enabling Windows Installer verbose logging and looking at the log file produced by a failing installation attempt.
Also, if you haven't yet, I encourage you to report a bug about this GPO deployment issue at connect.microsoft.com/visualstudio.
Hi Gooky and Perpetually Frustrated MS Admin - I've been looking into this scenario some more, and I found some differences in the conditions for the blocking custom actions in the various versions of the .NET Framework that I think explains why the steps that were documented for creating GPOs in previous versions of the .NET Framework do not work in the .NET Framework 4. Since you cannot pass properties in when installing an MSI via a GPO, the only ways I can think of to work around this issue are to hand-edit the MSIs or to provide a transform. I've updated the main blog post to provide a link to a sample transform that I created that will change the condition for the blocking custom action to False so it should not run during .NET Framework 4 installation anymore. You can find the transform at cid-27e6a35d1a492af7.office.live.com/.../netfx4%5E_aip.mst. Hopefully this will help in your scenarios. Please let me know how it goes for you if you get a chance to try it out.
If I try to apply the transform in Orca I get "Orca was unable to read the SummaryInformation from the transform. The transform cannot be applied. (MSI Error 1620)" Am I missing something?
Hi Perpetually Frustrated MS Admin - I'm not sure how to explain that behavior you're seeing. I tried applying the MST from Orca to all 4 of the MSIs in the .NET Framework 4 package (netfx_core_x86.msi, netfx_core_x64.msi, netfx_extended_x86.msi and netfx_extended_x64.msi) and it worked fine for me for all of them. I'm using Windows 7 and Orca version 4.5.6001.0 on my system, but I'm not sure if that matters or not in this scenario.
Do you get the same error if you try to apply the MST as a part of a GPO installation or by running msiexec.exe /i and passing it in manually via the TRANSFORMS property?
Huh, thanks alot, Microsoft: connect.microsoft.com/.../cannot-deploy-net-framework-4-msi-via-gpo No SCCM here... I assume everyone else reading this page is here because they also do not have SCCM. I'll probably end up running the silent install command per this page: msdn.microsoft.com/.../ee225240.aspx in a script.
I had submitted a comment a couple weeks ago but it must not have gotten through: I had an older version of Orca (3.1.4000.1830) that I was originally working with. I also tried it with a newer version - 5.0.7069.0, which came with the Windows 7 SDK. I didn't know where to find 4.5.6001.0. I got the same error with both versions, though. When I applied the transforms via GPO, they successfully applied but when it ran on a client, the same error was written in the Application Log.
Thanks for your help, though, Aaron. Looks like MS is continually trying to shovel us in to another expensive product...
Hi Perpetually Frustrated MS Admin - I'm not sure why your previous comment didn't come through. I was out on vacation for a week or so over the past couple of weeks and I had a backlog of comments to approve when I got back. It might have gotten lost in the shuffle due to that, and I apologize.
I'm still not sure why the transform isn't applying for you. I got the 4.5 version of Orca in the Windows Installer 4.5 SDK, which isn't available anymore because it has been replaced by the Windows 7 SDK. I will try to download the new SDK and get the new version of Orca and see if I can replicate this transform application error.
In the meantime, can you try to create your own transform for this scenario or manually update the MSI in Orca prior to deploying. The only thing I did in the transform was change the condition for CA_BlockDirectInstall in the InstallExecuteSequence table from its original value to False so that it would no longer run that custom action. You will need to change this in each of the .NET Framework 4 MSIs (core x86, core x64, extended x86, extended x64).
I'm aware of this workaround for installing .net Framework 4.0 using the MSI's and not the exe file. I have the opposite problem hence this comment. I can install the framework using the EXTUI property either on a command line or by blocking the MSI custom action using an MST. However, we deploy Microsoft updates using WSUS and we'd like to follow this standard with .net Framework 4.0 but can't because the exe file fails to unpack and then install. Do you have any advice, is there any troubleshooting steps or a guide you could recommend.
I have heard of the tool for gathering .net/Visual Studio configuration information and saw the link to it on one of your other pages. My question is if I run this tool would you be willing to have a look a the cab file output and give me the benefit of your advice?
Hi Brian - If you're running into a .NET Framework 4 installation failure, the first troubleshooting step is to find the root cause of the failure from the log files, and then go from there depending on what the logs say. Can you please use the tool described at blogs.msdn.com/.../6458047.aspx to gather your .NET Framework setup log files, post the file named %temp%\vslogs.cab that is created by this tool to a file server (such as http://skydrive.live.com) and then reply here with a link I can use to download the log files and take a further look?
Thanks, I've uploaded the cab file to the following link:
Hi, we've managed to identify what was preventing the installation. Offci 2003 installs some text to speech/handwriting features and if we removed these the installtion worked a-ok.
Thanks for the offer of assistance though.
I see the last commment was from 2011. I hope this is still monitored. I accidentally (stupidly) installed the 32 bit version on my 64 bit system. I can't believe it actually worked. I wish it wouldn't have. I've tried everything under the sun to remove it, but it tells me I can't run the uninstaller on a 64 bit system. Is there anyway to remove the original installation so I can install the correct (64 bit) version?