Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

Mailbag: How can I deploy the .NET Framework 2.0 using Group Policy?

Mailbag: How can I deploy the .NET Framework 2.0 using Group Policy?

  • Comments 19

Question

You previously posted a set of instructions that can be used to run the .NET Framework 2.0 setup by calling the MSI directly.  The instructions in that post describe a command line parameter named ADDEPLOY that needs to be passed to msiexec.exe to allow the MSI to install correctly.

I want to deploy the .NET Framework 2.0 in my network using Group Policy.  I cannot specify a command line parameter like ADDEPLOY in the Group Policy deployment package creation UI.  How can I deploy the .NET Framework 2.0 MSI on my network using Group Policy?

Answer

The following example steps can be used to create a Group Policy object to deploy the .NET Framework 2.0 in a network:

  1. Click on the Start menu, choose Run and type cmd
  2. Create an administrative install point for the .NET Framework 2.0 by running dotnetfx.exe /c:"install.exe /a" and stepping through the wizard UI
  3. Add the netfx.msi that is created in the administrative install point created above to the Group Policy object.  The path to netfx.msi must be located on a share that is accessible from all computers where it will be deployed to, not on a local path (example - \\server\share\netfx20\netfx.msi not C:\netfx20\netfx.msi)

It is important to note that the .NET Framework 2.0 only supports deployment by machine assignment, not by user publishing. This is because the user may not be an administrator on the machine in the advertised scenario, and because the .NET Framework is a per-machine and not a per-user application.

Behind the scenes, the .NET Framework 2.0 MSI has a custom action named CA_BlockDirectInstall_GUIH_SKU_URT that is used to prevent users from installing by double-clicking on the MSI directly.  This custom action has the following complex condition statement in the InstallExecuteSequence table:

( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1) ) AND ( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1) )

The ADVERTISED property will be automatically set if you create a Group Policy object to deploy the .NET Framework 2.0 MSI to a network by machine assignment.

 

  • Installing apps through group policy should be standardised so that all apps can be administratively installed the same way. Nowadayson Windows it is very easy to install any app if you are a single home user: just double-click on the downloaded setup file or put in the cd. No make install, no compilations, no other obscure environment setup before install.
    However, admin installs are complicated. Office needs its own procedure which is different from .NET, which is different from Norton, which is different from God knows what. The command-line options are different, even for Microsoft products. It seems that even in Microsoft, software groups cannot agree on a single way of doing administrative installs, let alone in 3rd products. Different installer technologies make things even worse.
    Please mae admin installs consistent, just like single user setups are: click Next, Next, Finish and done. Why cannot it be the same for admin installs?
  • Недавно я рассказывал о нанесении тяжких душевных повреждений разработчику, то е
  • I was very thankful to find your post, but when I try to deploy this via machine assignment, I get errors in the application log that the installation source is not available.  I followed the steps exactly as described above, and I verified that the distribution point is accessible and that all references are in the form of "\\server\share\netfx20\netfx.msi".
    I don't knonw if this helps, but attempting to launch this MSI file directly results in a dialogue box which says "To install this product please run Install.exe".
  • Hi Vaughn - Can you paste in the exact text of the error message in the application event log on this system?  Also, can you verify that the account that is attempting to run the setup on the target machine when it is assigned via machine assignment has permission to access the UNC path where the MSI exists?

    Note - if you run the MSI directly and do not pass in one of the properties listed in the condition above, it is expected that you will get an error dialog stating that you should run install.exe to install the product.
  • Question
    You previously posted instructions for how to create an administrative install point (AIP)...
  • Thank you for your post. It helps me to plan how to deploy .Net framework in my network.

    I have one question about setting security.
    Can I preset the security level of clients environment?

    Thank you,
  • Hi Eric - I am not an expert at tweaking .NET security settings, but I believe you could accomplish this by creating some customized .config files and installing them onto your systems after you install the .NET Framework 2.0.  Microsoft internal IT does something similar for computers that are connected to our corporate network
  • This guide is intended to serve as a collection of links to articles, tools, tips and tricks that explain...
  • I previously posted a set of instructions for creating an administrative install point for the .NET Framework

  • This guide is intended to serve as a collection of links to articles, tools, tips and tricks that explain

  • Are there instructions to install .Net Framework 3.5 through Active Directory.  Attempting the above doesn't seem to work.

    Thanks

  • Hi Scotthellewell - The instructions for deploying the .NET Framework 2.0 SP1, 3.0 SP1 and 3.5 are different than the ones listed here.  The documentation for how to do this is currently still being reviewed, but it should be posted and available on MSDN soon.  I will create a new blog entry with a link to the updated documentation once it is available.  I'm sorry for the hassles in the meantime.

  • We're looking at developing a generic external ui handler for our suite of products. Group Policy deployability is big concern for our company.

    Can you please explain how the ADVERTISED property is being set when a GPO is created to deploy the .NET Framework 2.0 MSI? Is this standard Group Policy behavior for any MSI, or functionality your team had to implement?

    Thanks

  • Hi Pmcclosk - We did not have to do anything specific in .NET Framework setup to allow Group Policy deployment.  Following the steps listed in this blog post should work fine without taking any additional action in your Group Policy objects.  One thing to note there - Group Policy requires creating an object for each MSI.  That means that even if you have an external UI handler, if a user wants to deploy your product via Group Policy, they will have to create a separate GPO to deploy the .NET Framework 2.0 MSI prior to deploying your product MSI.

    It looks like my explanation in this blog post is not correct though - I had thought that the ADVERTISED property was something standard in Windows Installer, but I can't find it in the documentation anywhere.  I'm not sure exactly what gets set during a GPO deployment, but we have verified that this CA_BlockDirectInstall_GUIH_SKU_URT custom action does not run during GPO machine assignment scenarios, and therefore does not block you from running the MSI directly in that type of scenario.

  • Thanks Aaron. I've found that by querying the ProductState of the running installation when it is assigned by machine through group policy will return INSTALLSTATE_ADVERTISED.

Page 1 of 2 (19 items) 12
Leave a Comment
  • Please add 8 and 8 and type the answer here:
  • Post