MED-V 1.0: Windows Installer Service Retriggers MED-V Client installation When Trying to Start Workspace

A while back, I encountered an issue on the forums that evolved into an incident. I had an issue where the MED-V client host is retriggering installation (self-healing) when trying to start the client. The Windows Installer Service also retriggers the MED-V Client installation when trying to start a workspace or an application that is dependent on the workspace. Also, the MED-V shortcuts appear with the default icon instead of the correct icon.

Upon further investigation, I found that the installation was only installed for the user instead of the entire machine (the MED-V Client.) The MED-V Client was deployed silently using SCCM. The command line in the package to install the MSI did not have the ALLUSERS=1 flag properly set.

The resolution was to redeploy the client using the ALLUSERS=1 Flag. Due to the way the Windows Installer properties handle installations, this is the only remediation.

Refer to the following article:

http://blogs.technet.com/b/medv/archive/2010/02/16/prescriptive-guidance-for-deploying-the-med-v-client-via-an-electronic-software-distribution-method-such-as-sms-sccm.aspx

 

SCCM 2007 R2/R3: Error when Streaming App-V Virtual Application from Distribution Point: 4xxxxxx-xxxxxx0a-00003004

On an App-V Client managed by Configuration Manager (SCCM), you may receive the following error when trying to launch a virtual application configured to stream from a distribution point.

The Application Virtualization Client does not support the authentication scheme requested by the server. Report the following error code to your System Administrator.

Error code: 4604EE8-24601B0A-00003004

You may get this error whether or not the application is 100 percent cached or not. In addition you will see one or more of the following errors in the SFTLOG.TXT:

[09/20/2010 11:14:57:287 AMGR WRN] {tid=58C}
Attempting Transport Connection
URL: http://serverfqdn:80/SMS_DP_SMSPKGD$/VirtualAppStreaming/<PKGID>/{GUID}/package.sft
Error: 24603B0A-40000191

[09/20/2010 11:14:57:366 TRAY ERR] {tid=58C:usr=username}
The Application Virtualization Client could not launch ApplicationName

The Application Virtualization Client does not support the authentication scheme requested by the server. Report the following error code to your System Administrator.

Error code: 4604EE8-24601B0A-00003004

The cause of this is the Client is trying to authorize the application upon launching in the same manner as it “checks for updates” in a traditional App-V server-based environment. This is due to the RequiereAuthorizationifCached client value being still set to 1.

To resolve this issue, make the following registry change and restart the App-V Client service:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration
 
RequireAuthorizationifCached = 0

SCCM (Configuration Manager) Installed Component Provider Binaries on SQL Clustered Drive (or other shared clustered drive) by Mistake.

Configuration Manager 2007 supports the Site Backup role on a clustered drive so long as the SQL cluster is Active/Passive.

The problem is the fact that the default largest NTFS drive is used to install the provider binaries and it is real easy for the SMS Component Provider in SCCM 2007 to be installed on a clustered drive by mistake when configured on a remote SQL cluster.

The scenario usually happens as follows:

1.) SMS/SCCM Site Server is installed selecting remote SQL instance and database on a clustered server as the location of the site database.

2.) Provider binaries then get placed on clustered drive that was currently owned by active node containing SQL server instance.

3.) As a result, the configuration of the SCCM/SMS backup differs on each of the database nodes. One node may be configured to run the binaries from the system drive and the other may be configured to run on a clustered drive (or even both.)

4.) Drive either becomes no longer available to the node (failed over to other node) or the drive resides on a LUN no longer presented to the cluster.

5.) You will see critical status messages related to the SMS_SITE_SQL_BACKUP and the site component manager.

The remedy for this was first devised in SMS 2003. it is mentioned in the article KB 871234:

http://support.microsoft.com/kb/871234

It is also mentioned here: http://technet.microsoft.com/en-us/library/bb632890.aspx

Now placing the file NO_SMS_ON_DRIVE.SMS on all clustered drives is a great way to prevent this from happening, how can you correct this issue after the problem has occurred?

The answer is a combination of several things including use of the NO_SMS_ON_DRIVE.SMS feature:

1. Create the following file on all clustered drives:

NO_SMS_ON_DRIVE.SMS

2. Stop the SMS_Site_SQLBackup_%SERVERNAME% on the problem node

3. Remove the following Registry Keys on the problem node:

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Components

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMS_SITE_SQLBACKUP_%SERVERNAME%

4. On the site server, browse to the fllowing registry key:

HKLM\Software\Microsoft\SMS\Components\SMS_SITE_Component_Manager\Multisite Component Servers\%SERVERNAME%

5. Change the install directory to the appropriate drive and then go to:

HKLM\Software\Microsoft\SMS\Components\SMS_SITE_Component_Manager\Multisite Component Servers\%SERVERNAME%\SMS_Site_Backup and change the value “Installed At Least One file” to 0.

6. Restart the SiteComp service on the Site server