How to deploy .Net 4.0 using Active Directory

[dutch_tuga]

We are going to upgrade UCA server to the latest version. For the clients we would like to deploy the uca client software through GPO. The problem we face now is that prior running UCA 4.1.x the pc's need to have .Net Framework installed. We cannot find any msi version of it.

Did someone bump onto this? Is there a way to deploy .Net Framework?

[martyn]

You don't have SMS/SCCM or any other tools like that?

You could also do it via a startup script using a vb script or batch file, this would be simple enough. Just make sure that you do it as a startup script, not a logon script as logon scripts run as the logged on user which wont have the privileges probably to install software!

Check out AppDeploy.com for info on how to deploy various programs. I've used it plenty of times and it usually gives me the answers pretty quickly, and often also has a script on there that you can use. 

[akuhn]

What a timely question.  I'll trade answers with you.

The answer is that you can deploy this package via WSUS.  Now, I recognize that you might not have a WSUS server setup, but it's a free package from MSFT and I use it to patch my approximately 65 desktops and laptops.  We just started playing with UCA and I too want to use GPO to deploy the unifiedcommunicator.msi file and hit this requirement of .Net being installed first.

You need to enable the "Feature Packs" check box in WSUS to make it available to deploy.  I did so and pushed it out to a test Windows 7 machine and it installed without a reboot (not sure about other OSs).  To validate the install, I then executed the UCA.msi install, and it went right by the .Net check and went right into the MSI install.

Now for the info I need.  Is there a readme with an argument / switch list so I can pass through the name of my UCA server to the MSI install?  Because what happens is that UCA installs without the server name and comes up off-line.  Furthermore, you cannot enter the server name after the install.  At best, you need to go to Programs&Features and select "Change" and then enter your UCA Server name.

This ruins the whole point of an MSI file install. 

Thanks in advance if you have any hints for my question.  Here's more info on .Net deployment if you don't have a WSUS server.

http://msdn.microsoft.com/en-us/library/ee390831.aspx

Adam in DC

[DevAudio]

@dutch_tuga: If you have questiong about deploying .NET, you should always look at Aaron Stebner's blog. He's part of the Windows installer team at Microsoft, and always has good info about deploying .NET. In your case, I think you'd find this blog entry valuable:
http://blogs.msdn.com/b/astebner/archive/2010/06/04/10020299.aspx

@akuhn: You are dabbling with the Deep Magic. What you want is to learn about Windows Installer logging, and how to create Windows Installer transforms and a nifty little tool called ORCA that you'd use to view the contents an MSI and create transforms (MST files.) The Orca tool is part of the Windows Installer Platform SDK which is available as a free download from Microsoft. Chances are, the solution to your problem will go like this:
1. Log the manual installation
2. View the log and find the name of the property or properties that is set that controls the server name
3. Open the MSI in orca, choose to generate a transform that modifies that property to the desired value.
4. Feed both the MSI and the MST into the GPO (you have to choose advanced when adding the MSI to the GPO to have the option to apply a transform.)

I know I didn't provide much detail, but if you found your way here, you obviously have a fair amount of brainpower.

[dutch_tuga]

We have found a way to deploy it.

Just have your GPO call this .BAT file "\\network\GPO Software Installs\DotNetFx4\dotnetfx4.exe" /q /norestart

It worked like a charm.

Thanks guys.

[martyn]

We have found a way to deploy it.

Just have your GPO call this .BAT file "\\network\GPO Software Installs\DotNetFx4\dotnetfx4.exe" /q /norestart

It worked like a charm.

Thanks guys.

Just make sure you run it as a startup script rather than a logon script unless you users have local admin rights to their machine.