How to create an administrative install point for the .NET Framework 4
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:
- Download the .NET Framework 4 standalone installer and save it to your hard drive
- Run the following command to extract the contents of the .NET Framework 4 installer: dotNetFx40_Full_x86_x64.exe /x:c:\dotnetfx4
- Run the following command to create an administrative install point for the .NET Framework 4 core x86: msiexec /a c:\dotnetfx4\netfx_Core_x86.msi EXTUI=1 TARGETDIR=c:\dotnetfx4\AIP\netfx_core_x86
- Run the following command to create an administrative install point for the .NET Framework 4 core x64: msiexec /a c:\dotnetfx4\netfx_Core_x64.msi EXTUI=1 TARGETDIR=c:\dotnetfx4\AIP\netfx_core_x64
- Run the following command to create an administrative install point for the .NET Framework 4 extended x86: msiexec /a c:\dotnetfx4\netfx_Extended_x86.msi EXTUI=1 TARGETDIR=c:\dotnetfx4\AIP\netfx_extended_x86
- Run the following command to create an administrative install point for the .NET Framework 4 extended x64: msiexec /a c:\dotnetfx4\netfx_Extended_x64.msi EXTUI=1 TARGETDIR=c:\dotnetfx4\AIP\netfx_extended_x64
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>
Comments
Anonymous
June 12, 2010
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?Anonymous
June 12, 2010
The comment has been removedAnonymous
June 15, 2010
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?Anonymous
June 15, 2010
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.Anonymous
June 17, 2010
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.Anonymous
June 21, 2010
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?Anonymous
June 21, 2010
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?Anonymous
July 06, 2010
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...Anonymous
July 06, 2010
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).Anonymous
November 23, 2010
The comment has been removedAnonymous
November 24, 2010
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?Anonymous
November 24, 2010
Thanks, I've uploaded the cab file to the following link: cid-b31b06d5831c3b04.office.live.com/.../.PublicAnonymous
November 28, 2010
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.Anonymous
October 19, 2011
ThanksAnonymous
August 19, 2012
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?Anonymous
August 20, 2012
Never mind. Once again I'm an idiot. I found your cleanup tool. Worked like a charm. Thanks for being a genius and putting this stuff online.Anonymous
November 30, 2012
Hi Guys, Sorry but I am little weak on this. I ran the commands in the instructions but I am unsure on which MSI I am suppose to use now. I have multiple MSI files in multiple locations. I am wanting to put the MSI in a GPOAnonymous
November 30, 2012
Hi Trev - I'd suggest referring to the .NET Framework Deployment Guide for Administrators for instructions about how to deploy the .NET Framework to a network of computers. You can find this deployment guide at msdn.microsoft.com/.../ee390831(v=VS.100).aspx.Anonymous
November 30, 2012
The comment has been removedAnonymous
November 30, 2012
Hi Aaron, I followed your previous advise and removed the block from the MSI and its working great. Thanks again. Your awesome!Anonymous
October 28, 2014
While installing the Setup.exe as prompted by the MSI installation file, I get another error of Blocking IssuesAnonymous
October 29, 2014
Hi Romit - What is the exact error that you are seeing when you try to install in this scenario? If you are installing the .msi file directly, please make sure that you download and apply the transform that I described towards the end of the blog post.