Russ Rimmerman - ConfigMgr Guy

Russ Rimmerman - Microsoft Sr. Premier Field Engineer - ConfigMgr / Configuration Manager

Deploying the App-V 5.0 Client Using Configuration Manager 2012 SP1

Russ Rimmerman - ConfigMgr Guy

Russ Rimmerman - Microsoft Sr. Premier Field Engineer - ConfigMgr / Configuration Manager

Deploying the App-V 5.0 Client Using Configuration Manager 2012 SP1

  • Comments 15
  • Likes

Whether you’re currently an App-V 4.x shop or just starting to get your feet wet with App-V 5.0, one of the questions you may have is how best to deploy the App-V 5.0 client using Configuration Manager 2012.

If you aren’t yet on ConfigMgr 2012 SP1, you’ll need to upgrade to SP1 first (see my other blog post on the SP1 install topic here) as the App-V 5.0 client requires PowerShell 3.0, and PowerShell 3.0 will cause health-check related issues for your clients if you aren’t on SP1, so you’ll need to upgrade your 2012 clients to 2012 SP1 before deploying the WMF 3.0 update package.  WMF v3 should be set as a pre-requisite within the App-V 5.0 application so that it will automatically install it if it is not already installed on a specific client.

If you’ve done some research on the App-V 5.0 pre-requisites, you’ll notice that you need to set the .NET Framework 4 (Full Package) as the first pre-requisite.  If you look at your clients and notice they have “Microsoft .NET Framework 4 Client Profile” and/or “Microsoft .NET Framework 4 Extended”, these are not sufficient, as you must install the full package version of .NET Framework.

Creating & Prepping the App-V 5.0 Client for Deployment

 

Preparing the Prerequisites

.NET Framework 4.0 (Full) - If you don’t already have a package or application for .NET Framework 4 Full, download it here, and create a script installer application for it, adding /q /norestart switches for the install command-line, and /uninstall for the uninstall.

image

If you’re using an application (versus a package) to deploy it, you can have it detect installation by looking at the registry key HKLM/Software/Microsoft/NET Framework Setup/NDP/v4/Full and the registry value “Install” with a Data Type “Integer”.

image

There are many ways you could detect .NET Framework Full being installed, but this is one viable option.

Windows Management Framework 3.0 – PowerShell 3.0 which is a component of Windows Management Framework (WMF) 3.0 is also a required pre-requisite on Windows 7 SP1 and 2008 SP2/R2 SP1 clients.  WMF 3.0 is downloadable from http://www.microsoft.com/en-us/download/details.aspx?id=34595.  Create a new package for WMF 3.0 using the Installation command line:  c:\windows\system32\wusa.exe “Windows6.1-KB2506143-x64.msu” /quiet /norestart and the Uninstall command-line: c:\windows\system32\wusa.exe /uninstall “Windows6.1-KB2506143-x64.msu”.

image

For the Detection Method, select “Use a custom script to detect the presence of this deployment type:

image

Click “Edit…” and paste this small PowerShell script I put together into the window:

$osresult = $null
$os = (Get-WmiObject Win32_OperatingSystem).Name
if ($os -like "*Windows 8*") {$osresult = "True"}
if ($os -like "*Server 2012*") {$osresult = "True"}
$hfchk = Get-WmiObject -Query "select HotFixID from Win32_QuickFixEngineering where HotFixID like 'KB2506143'" | foreach-object{Write-Host $_.HotfixID}
$osresult

What the PowerShell script does is first checks the currently running OS Name in WMI by querying the WMI class Win32_OperatingSystem to see if it’s Windows 8 or Server 2012.  If it is, it won’t find KB2506143 since it’s not applicable (nor required), so it sets the variable $osresult to equal “True” and will echo “True” at the end of the script so the result of the detection type will be a success.  Note: I could’ve set $osresult to equal “Foobar” here and the end result will be the same - any value echoed by the script which also completes with an exit code of 0 is considered a successful application detection.  If the OS is not Windows 8 or Server 2012, it will instead have to pass the HotFixID query check which looks for a hotfix within the Win32_QuickFixEngineering WMI class containing a HotFixID value containing “KB2506143”.  If $osresult ends up being NULL AND KB2506143 is NOT found, nothing will be written to STDOUT, so the requirement check will not pass, and KB2506143 will therefore be installed.  For more information on how to use a script to determine the presence of a deployment type, see http://technet.microsoft.com/en-us/library/gg682174.aspx.

Next, go to the Requirements tab of the WMF 3.0 x64 application, and Add a Category: Device, with the Condition: Operating System, and an Operator: One of and select Windows 7 SP1 64-bit, Windows 2008 SP2 64-bit, and Windows 2008 R2 SP1 64-bit as these are the only supported OSes WMF 3.0 x64 will successfully install and are applicable on.

image

 

If you need to also deploy the 32-bit WMF 3.0, be sure to add another deployment type to call the 32-bit version of the MSU, and set it for 32-bit requirements of the 32-bit Win7 SP1 and 2008 SP2/R2 SP1 OSes.  The same PowerShell script should work just fine to check for the existence of the WMF 3.0 hotfix on these.

Finally!  Creating the App-V Client Application

Now, you’ll need to create a new Manually specified application using the "Script Installer” deployment type in order to deploy the App-V client.  If you’re thinking of piecing the installation out into individual MSIs, I’d recommend reconsidering that plan and following the KISS principle by using the provided appv_client_setup.exe within the App-V clients directory on the MDOP 2012/2013 ISO.  The reason for this, is that this wrapper install will take care of most of the pre-requisites, namely the very version specific C++ installs required.  It will also automatically detect whether you’re installing on a 32 or 64-bit OS and install the matching architecture version of the App-V client.  Save yourself some headaches and don’t over-complicate things by importing the App-V client MSIs directly.  DO, however, use the MSIs to create the detection method within the deployment type of your application.  The 32-bit and 64-bit MSIs have different product codes, so if you have both 32 and 64-bit OSes in your environment, you have a little extra work to do. 

Language Packs - If you install using the .exe, the installer will also automatically install any language packs which match the language of the OS running on the client.  If you want to deploy any additional language packs, you can deploy the appv_client_LP_xxxx_x86.msi or appv_client_LP_xxxx_x64.msi for each language to each client as needed. 

Creating the deployments - You can create two deployment types, one for each processor architecture, and add the MSI Product Code clause for each individually.  The primary advantage to doing it this way, is you also get the benefit of importing the MSI product code for windows installer source management in the event the installation ever needs updated or repaired on your clients. 

If you decide you don’t need this benefit, you could do a single deployment type with no x86 & x64 requirement separation, and then you can combine the detection method into an OR’ed clause within your detection method as follows:

image

I personally recommend breaking them out into two deployment types, one for each OS architecture if you do have to support both x86 and x64 clients.  The windows source management is a nice feature to leverage, so it’s worth the small effort.  Assuming you take my advice and create separate x86 vs. x64 deployment types for your clients, your programs screen should appear something like this for the x64 type:

image

As you can see, I’ve imported the x64 product code into the Windows Source management blank by browsing to the appv_client_msi_x64 for self-healing sake. 

Your Requirements tab should look like the snip below if you’re supporting XP, Windows 7, and 8:

image

For dependencies, just add the .NET Framework 4.0 (Full) and WMF 3.0 applications you created above, and they will install if they aren’t already installed on your clients when you deploy the App-V client.

image

When you’re all done, open the App-V Client and click “View Relationships” and it should look something like this (assuming you had to follow both the 32 and 64-bit paths).

imageimage

Now you can successfully deploy the App-V client to your clients and verify the prerequisites and App-V 5.0 client installs successfully. 

In an upcoming blog post, I’ll cover how to sequence the Configuration Manager 2012 SP1 Admin Console using App-V 5.0.  Stay tuned!

Comments
  • Switch for App-V install must have /ACCEPTEULA for it to work

    appv_client_setup.exe /q /ACCEPTEULA /norestart

  • I'm having issues getting WMF 3.0 to detect/deploy using your powershell script. It never shows up in my software center (I created a deployment for it alone) nor does the AppV deployment (I'm assuming because there's a problem with WMF 3.0.

  • Hi Russ, thanks for the post, very helpful.

    Just one thing I noticed which might be helpful for others. If deploying app-v using the exe (appv_client_setup.exe) it seems to present an issue when trying to uninstall. If using the .exe method above the uninstall fails with the following error on win 7 clients: "Setup failed while scanning the system for prerequisites. Unknown property". Additionally you're also unable to uninstall using programs & features. The only way I was able to overcome this was to deploy using the msi rather than the exe and both install and uninstall worked without error.

  • Would that powershell script work with a windows 7 system?

  • Powershell works brilliantly on windows 7, infact its written for windows 7 basically since WMF is not required on Windows 8.

  • hi.. can i install the app-v 5.0 client on sql server 2008 r2? if yes what are the pre requirements needs to be installed.

  • Depends on the OS version. See http://technet.microsoft.com/en-US/library/jj713458.aspx.

  • Not sure if the WinRM piece actually works. If I use the command line c:\windows\system32\wusa.exe “Windows6.1-KB2506143-x64.msu” /quiet /norestart I get an error 2 or file not found. If I make a batch file to locate the update correctly (C:\Windows\System32\wusa.exe "%~DP0Windows6.1-KB2506143-x64.msu" /quiet /norestart) I get a puzzling exit code of 2149842967 out of Windows Update. If I manually install WinRM I get no issues.

  • Ok, it looks like the error 2149842967 might be due to my client's environment. I did some more testing and if I manually run the update it says it is not applicable even though Powershell 3.0 is not present on the system. I guess I have a non-CM issue to chase.

  • Kevin, do you have dot Net 4 installed on that system?

  • Hi Russ,

    Nice article... Two questions any reason for the hotfix detection powershell script why not just Get-Hotfix command? Also why not also included 2758857 as a prereq?

  • Simpler powershell script would be: Get-Hofix -ID KB2506143

  • You should update your blog to include adding Hotfix 4 as part of the dependency chain. In addition, I think its better to nest .NET Framework as a dependency of WMF 3.0. The reason is that WMF cannot install without the .NET pre-req. If other applications have dependencies on WMF 3.0, you won't have to remember to add both.

  • HI,
    I need help. Installation getting failed
    Error : Evaluation failed
    Actually power shell script error : script is not signed

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment