Archive

Archive for May, 2011

App-V: Certain Database tables not updating or empty post upgrade from 4.1

May 31, 2011 2 comments

You may notice certain tables like ACTIVE_APPLICATIONS, APPLICATION_CAPABILITIES, or DISCONNECTED_EXPIRIES either not updating with information, empty, or missing when looking at an App-V datastore directly in SQL Management Studio or querying through T-SQL. 

The likely scenario is that the database was updated from Softgrid 4.1. During the upgrade process for whatever reason, the tables, views, and/or stored procedures that were deprectaed for App-V Server 4.5 were left in the database.

The following tables are deprecated as of 4.5. They may still appear in a database that has been upgrade from a pre-4.5 release, but they are no longer actively updated or accessed.

ACTIVE_APPLICATIONS
APPLICATION_CAPABILITIES
APPLICATION_EXTENSIONS
DISCONNECTED_EXPIRIES
MANAGEMENT_SERVERS
SOFTGRID_USERS

Deprecated Views

The following views are deprecated as of 4.5. They may still appear in a database that has been upgrade from a pre-4.5 release, but they are no longer actively updated or accessed.

VW_MANAGEMENT_SERVERS

Deprecated Procedures

The following procedures are deprecated as of 4.5. They may still appear in a database that has been upgrade from a pre-4.5 release, but they are no longer actively updated or accessed.

sp_SFTrpt_systemusagebyuser
sp_SFTrpt_usergroupusage
sp_SFTsetdbaccess

No action is needed. Manual deletion of these tables, views, and stored procedures can be done for the purpose of clarity although the fact they remain should have no bearing on the operation of the server or data store.
Categories: App-V Tags: , , , ,

This installation requires Windows 2000?!?!?!? Do What? Error when deploying MED-V Deployment Package . . . aka – did I just Travel back in Time?


Note. We are speaking of MED-V V1 here. ūüėČ
 
So, here is the scenario: You are creating a deployment package using the MED-V Deployment Packing Wizard. This is available in the MED-V v1 console. More information about this is found here:
 
 
The MED-V Deployment Package Wizard allows you to bind all of the binaries required for deploying a MED-V client along with a prestaged image into a single package. During the wizard, you have the option to specify the installers to include in the package. The trouble is, it does not verify that the installer you are choosing is the right one. For example, when you are specifying the MED-V installation file under “MED-V installation settings” it does not verify that that is, in fact, the client installer.
 
I recently encountered an issue where a customer was attempting to deploy the MED-V client to a Windows 7 host using the MED-V 1.0 SP1 Deployment Package methodology. It failed with the following error:
 
This installation requires Windows 2000 SP4 or Windows XP SP2/SP3

Needless to say, getting this error on a Windows 7 computer was confusing. Luckily, the customer did not attmept to cretae a Versionlie AppCompat shim as this could have yielded even more trouble.

This¬†was simply¬†caused by the wrong MSI being selected during the packaging wizard. When you select the option to run the MED-V packaging wizard (From the Management Console ‚Äď select Tools ‚Äď Packaging Wizard.‚ÄĚIn the MED-V Installation Settings, dialog box, the installation binary selected should be MED-V_1.0.105.MSI.

In this particular scenario where the above error occurred, the MED-V_Workspace_1.0.105.MSI was selected and used instead of the client installer (MED-V_1.0.105.MSI.) The MED-V_Workspace_1.0.105.MSI is only one used to install the workspace guest binaries inside the virtual machine.
Categories: MED-V Tags: , , , , , ,

App-V: Here’s an example of “don’t do that – but if you must, here’s how.”


Here’s an example of “don’t do that – but if you must, here’s how.” Access 97 and the¬†Access 97 run-time module¬†is no longer supported by Microsoft. Therefore, custom applications that use the Access 97 run-time module¬†are also¬†technically unsupported. Virtualizing it with App-V does not change that fact although the isolation has led to some unintended positive consequences. Always remember that it is still a risk to use App-V in this manner as future releases and patches cannot be guaranteed to be regression free in terms of how it will affect an unsupported technology.

However, if you insist on sequencing an application that uses it, the following can be done to allow you to sequence Access 97 Run-time modules in versions 4.5 or later:

First, the registry key:

HKEY_CLASSES_ROOT\Licenses\8CC49940-3146-11CF-97A1-00AA00424A9F will be missing. This will result in a license error.

To rectify this, add the following registry entry

  • HKEY_CLASSES_ROOT\Licenses\8CC49940-3146-11CF-97A1-00AA00424A9F
  • [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW]
    “DefaultSeparateVDM”=”yes”

This must be done and rebooted on the sequencer prior to the start of sequencing.

Install to a Mount Drive during sequencing

Upon completion of the installation, DO NOT STOP MONITORING.

Open a command prompt rename %WINDIR%\fonts\hatten.ttf to hatten.xxx

Launch Application again.

Click Stop Monitoring.

Categories: App-V, Office Tags: , , , ,

App-V 4.5: Failed to Start App-V Management Server: Error 268480357

May 17, 2011 4 comments

Here is the scene. An attempt to start App-V Management Server 4.5 fails with the following error:

“Windows could not start the Application Virtualization Management Server on “servername.” For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 268480357.”

You also then see the following in the SFT-SERVER.LOG file when it is set to VERBOSE:

[2010-07-10 15:23:21.909] - 4020 4080 SW_MessageHandler::Open - - - - 5 65535 "Initialization complete."
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SQLDataConnection::MapError - - - - 5 65535 "Got unknown error code: 5701."
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SQLDataConnection::HandleError - - - - 5 65535 "Error 0x1645, State: 01000, Text: [Microsoft][ODBC SQL Server Driver][SQL Server]Changed database context to APPVIRT."
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SQLDataConnection::MapError - - - - 5 65535 "Got unknown error code: 5703."
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SQLDataConnection::HandleError - - - - 5 65535 "Error 0x1647, State: 01000, Text: [Microsoft][ODBC SQL Server Driver][SQL Server]Changed language setting to us_english."
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SQLDataConnection::HandleError - - - - 5 65535 "Error 0x0, State: 01004, Text: [Microsoft][ODBC SQL Server Driver]String data, right truncation"
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SQLDataConnection::MapError - - - - 5 65535 "Got unknown error code: 229."
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SQLDataConnection::HandleError - - - - 5 65535 "Error 0xe5, State: 42000, Text: [Microsoft][ODBC SQL Server Driver][SQL Server]The SELECT permission was denied on the object 'SYSTEM_OPTIONS', database APPVIRT, schema 'dbo'."
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SQLDataConnection::MapError - - - - 5 65535 "Got unknown error code: 16945."
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SQLDataConnection::HandleError - - - - 5 65535 "Error 0x4231, State: 42000, Text: [Microsoft][ODBC SQL Server Driver][SQL Server]The cursor was not declared."
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SQLDataConnection::SearchInternal - - - - 5 65535 "Failed to execute statement. [SELECT * FROM SYSTEM_OPTIONS]"
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SQLDataConnection::GetRecord - - - - 5 65535 "No records found."
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_DataAccess::Initialize - - - - 5 65535 "Unable to retrieve value for system options record"
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SystemDispatcher::init - - - - 1 44901 "System dispatcher initialization error [-1]. System dispatcher startup will stop.
"
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SystemDispatcher::fini - - - - 5 65535 "Shutting down System Dispatcher version 4.5.1.15580 (4020)"
[2010-07-10 15:23:22.018] APPV01 4020 4080 SW_SystemDispatcher::fini - - - - 0 44952 "Successfully shut down Microsoft System Center Application Virtualization Management Server Version 4.5.1.15580 (4020)
"
[2010-07-10 15:23:22.018] APPV01 4020 1860 SW_MessageHandler::Close - - - - 5 65535 "Shutdown complete."
You will see this occur often when you try to point the 4.5 server (Application Virtualization Management Server) to a database created by a lower version. In this particular case, the 4.5 server was trying to connect to a database previously used by a 4.1.3.16 server.
This often happens in scenarios where a 4.5 server cannot connect for some reason to a 4.5 datastore and an older copy of a previous version of the database maybe restored in error or out of desperation.
 
Regardless, this error will happen immediately upon startup. If you point to a pre-4.5 database during installation, however, the installation program will try to update it.

The best solution is to either stand up a new installation that creates a new installation or uninstall the App-V 4.5 server and install a 4.1 version of the Softgrid Virtual Application server and point to this database. Then proceed to attempt to upgrade the 4.1 server to 4.5 which in turn should upgrade the database from 4.1 to 4.5.

PLEASE NOTE: This is predicated on the fact the database is in a usable state.

Categories: App-V Tags: , , , ,

App-V: 4.5 SP2 Server Fails to Connect to Failover Database Instance

May 13, 2011 3 comments

Beginning with 4.5 Service Pack 2, the Microsoft App-V server now provides support for SQL Server mirroring. This allows for datastore redundancy via mirror failover in an enterprise environment. It also allows you to switch from native OS ADO over the SQL native client 10.0.

Information on how to configure this can be found here:

http://technet.microsoft.com/en-us/library/ff660790(printer).aspx

However, many have noticed that in spite of following these instructions, they were still having issues with the App-V server connecting to the failover instance.

When this failure occurs, you will see this in the server’s¬†SFT-SERVER.LOG file:

[2011-4-07 16:33:29.212] APPVSERVER 2600 4100 SW_SQLDataConnection::PopulateConnectionString – – – – 5 65535 “Constructed ODBC connection string: DRIVER={SQL Server};DATABASE={APPVIRT};Network={DBMSSOCN};Server={APPVSQLM2,1433};”
[2011-4-07 16:33:29.259] APPVSERVER 2600 4100 SW_SQLDataConnection::MapError – – – – 5 65535 “Got unknown error code: 4060.”
[2011-4-07 16:33:29.259] APPVSERVER 2600 4100 SW_SQLDataConnection::HandleError – – – – 5 65535 “Error 0xfdc, State: 42000, Text: [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot open database “APPVIRT” requested by the login. The login failed.”
[2011-4-07 16:33:29.259] APPVSERVER 2600 4100 SW_SQLDataConnection::Open – – – – 5 65535 “Failed to load requested driver.”
[2011-4-07 16:33:29.259] APPVSERVER 2600 4100 SW_SQLDataConnection::Open – – – – 5 65535 “Unable to open ODBC data source.”
[2011-4-07 16:33:29.259] APPVSERVER 2600 4100 SW_DataConnectionPool::Open – – – – 5 65535 “Failed to open connection.”
[2011-4-07 16:33:29.259] APPVSERVER 2600 4100 SW_DataConnectionPool::Close – – – – 5 65535 “Close () called on closed object.”
[2011-4-07 16:33:29.259] APPVSERVER 2600 4100 SW_DataAccess::Initialize – – – – 5 65535 “Failed to open configuration pool.”
[2011-4-07 16:33:29.259] APPVSERVER 2600 4100 SW_SystemDispatcher::init – – – – 1 44901 “System dispatcher initialization error [-1].

You will also see the following in the SQL ERRLOG file:

2010-12-29 13:55:27.18 Logon       Error: 18456, Severity: 14, State: 38.
2010-12-29 13:55:27.18 Logon¬†¬†¬†¬†¬†¬† Login failed for user ‘domain\machineaccount$’. Reason: Failed to open the explicitly specified database. [CLIENT: x.x.x.x]

Cause

Microsoft had a small but serious DOC bug that took me doing an iDNA trace to find. Truth be told, I over-troubleshot it as a simple Process Monitor would have revealed it.  The SQL Failover registry keys defined here:http://technet.microsoft.com/en-us/library/ff660790.aspxwere previously listed as:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Softgrid\4.5\Server\SQLFailOverServerName
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Softgrid\4.5\Server\SQLFailOverServerPort

and we are told to create them in Steps 7 and 8.

Problem is the value SQLFailOverServerName should be SQLFailoverServerName.  That one lower case letter was preventing auto failover from occurring.

Change the registry value to SQLFailoverServerName. Since this happened, the document has been modified. The alternate languages versions of the document are also in the process of being corrected.
Steve Thomas
Categories: App-V Tags: , , , , , ,

MED-V V1.0 SP1: Error when trying to open the MED-V Management Console: ‚ÄúThe MED-V Management application was unable to initialize.‚ÄĚ

May 11, 2011 1 comment

When you attempt to open the MED-V Management console, you may get the following error:

‚ÄúThe MED-V Management application was unable to initialize.‚ÄĚ
‚ÄúThe type initializer for ‚ÄėKidaro.Foundation.Profile.UserProfile‚Äô threw an exception.‚ÄĚ

This is caused by either a blank or corrupt XML file containing the user settings:  (WIndowsUserSettings.xml)

To resolve this, delete the %LOCALAPPDATA%\MED-V\ directory and restart the application.

Categories: MED-V Tags: , ,

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

 

Categories: MED-V, SCCM Tags: , , , , ,