Archive
App-V 4: Factors that can cause Performance Issues with App-V 4.x Servers
For those of you still using App-V 4 (hopefully at least App-V 4.6 on the client side and 4.5 SP2 on the server side due to supportability) you may have been reading about how App-V 5 resolves a lot of limitations of App-V 4 – especially those that revolve around scalability. I dealt with many customers in support and still get questions on existing App-V 4.x deployments. The most common one revolves around keeping the existing 4.5 server(s) running optimally. I figured I would let the users out there (who are still using App-V 4.5 servers) know that I know they are still out there and remind them of the key factors that lead to performance issues
Watch the Cores and Dispatcher
App-V 4.5 runs usually on four instances of the core process (SGHWVR.EXE or SQLQVR.EXE if using the lightweight streaming server) as well as the dispatcher service. These are usually the key processes to monitor for CPU spikes. In normal operation, utilization should be evenly dispersed. In some cases you may see one or more spiked out due to likely one of the related issues listed below:
Update 4.5 Server to at least 4.5 SP2 plus these Hotfixes.
You should be running at the very least HF2 for App-V 4.5 SP2 with this hotfix being applied:
“Hotfix Package 2 for Microsoft Application Virtualization 4.5 SP2: March 2011” http://support.microsoft.com/kb/2507096/en-us
The App-V 4.5 Management Server should be updated to at least version plus the following should you be working with SQL database mirroring:
“FIX: An App-V 4.5 SP2 server cannot recover when an application virtualization database fails over” http://support.microsoft.com/kb/2873468/en-us
In addition to these hotfixes, you may want to also include this out of band fix which involves adjusting the back end database. I personally worked on this issue while I was in support and I can tell you that this fix makes a tremendous impact but must be done with caution:
“A publishing refresh might time out and return the 0A-10000005 error code on an App-V 4.5 client” us
Check the Database Values of Server Objects
If you are running with a less than optimal amount of cores or suspect performance issues after pre-creation of server objects prior to scaling out, you could be falling victim to the default limited values that come with pre-creating server objects. Check out this article to resolve it: http://blogs.technet.com/b/appv/archive/2010/05/10/pre-creation-of-server-objects-may-yield-certain-sub-optimal-values-in-the-app-v-sql-database.aspx
Large SFT-Server.LOG file
When the server log gets too large or is set to a high verbosity level, it can impact performance. Regular maintenance of the log files (planned purging) as well as setting an optimal verbosity level (2 likely) will prevent this from occurring. The logging level for the Application Virtualization Management Server can be changed in the registry at:
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\SOFTGRID\4.5\SERVER\SOFTGRID_LOG_LEVEL
Keeping it at a level no greater than 3 is recommended.
Large APPLICATION_USAGE and MESSAGE_LOG tables
These tables can grow very large if unchecked, be it intentionally (i.e. no SQL agent running, running SQL Express) or unintentionally. The background of this long standing issues can be found here: http://blogs.technet.com/b/appv/archive/2008/08/04/troubleshooting-softgrid-database-growth-issues.aspx
The trouble is that you might be encountering this issue because the SQL jobs are not running properly or at all. Especially if you are running a more recent version of SQL Server or have just migrated databases. The Technet gallery has some scripts that can help you fix these jobs should they be failing:
SQL script that creates the SQL 4 Jobs that are required by the App-V DB: http://gallery.technet.microsoft.com/SQL-script-that-creates-b6345446
SQL script to allow App-V Check Usage History job to run on SQL 2008: http://gallery.technet.microsoft.com/SQL-script-to-allow-App-V-959bc1d4
SQL script to allow App-V Check Usage History job to run on SQL 2008 #2: http://gallery.technet.microsoft.com/SQL-script-to-allow-App-V-f656ac69
Limitations of Ephemeral Ports Used for RTSP
Delays in launching and launch timeouts can be traced to a defining limit in the amount of service requests an App-V management or streaming server can hold. This is due to the ephemeral port range defined by the default App-V 4.5 server configuration – http://blogs.technet.com/b/gladiatormsft/archive/2011/08/31/how-to-adjust-increase-reduce-the-rtcp-rtp-port-ranges-for-use-with-rtsp.aspx
Streaming Performance due to improperly configured Offloading or Block Size
Both the Underlying TCP offloading stack configuration and the block size for RTSP can be factors to slow streaming performance:
TCP Offloading Information: http://support.microsoft.com/kb/951037
RTSP Streaming Issue with block size: http://blogs.technet.com/b/gladiatormsft/archive/2011/11/28/the-default-block-size-of-64kb-in-app-v-4-6-and-later-may-cause-slow-streaming-with-certain-network-configurations.aspx
As App-V 4.5 is in extended support, the likelihood of new problems is low but not impossible with App-V 4.6 SP3 running on modern operating systems. However, I would recommend you verify the above before contacting support.
MED-V V1 Disaster Recovery
Disaster recovery in MED-V v1 is a very straight-forward and seamless process. Offline access is available for those clients who have already cached their MED-V client authentications. One of the first steps in ensuring a good disaster recovery plan for this version of MED-V is to establish continuity through offline access. This will assume all images that the users need will have been downloaded. Information on MED-V v1 credentials and offline access can be found here:
For the MED-V server, since the configuration is all XML-based, the process for backing up crucial data is very easy and does not even require a system state backup. In my MED-V v1 environments, I simply backup the XML configuration, the reporting database, and the server-side images. This process is outlined in the following article:
http://technet.microsoft.com/en-us/library/ff433607.aspx
The article is pretty straightforward on the key locations for images and configuration:
\Med-V\Med-V Server Images
\Program Files\Microsoft Enterprise Desktop\Servers\ConfigurationServer
It also goes through the restoration process which is just as straight forward. The article does not mention the reporting database. While true, reporting is an option in MED-V V1 and is not required for the server to be operational, most organizations still using MED-V v1 are making use of the reporting database. If the database is locally available on the MED-V server (i.e. though SQL Server Express) please ensure that you are backing up the database (defaults to “medv”) manually using SQL Management Studio Express or through whatever means your database administrators backup databases.
– Steve Thomas
Decommissioned or Unreachable Domains: How the App-V 4.5 Management Server handles them differently from Softgrid 4.1 Virtual Application Servers
Here is the scenario: You are leveraging an App-V Management Server that will be assigning groups from trusted domains to applications and/or provider policies. Often there are organizational changes (mergers, spin-offs, domain flattening, etc.) that will warrant domains going offline or trust removals with the current domain for which the App-V management Server belongs.
How does that affect the App-V management server in the event that these domains are no longer reachable? What will happen is those groups will not be able to resolve and “ghost” SIDs will display where the groups formerly displayed.
For example, in the example below, there are groups from two domains (SECUREPKI and CONTOSO) assigned to a default provider policy on an App-V 4.5 management server.
Once the domain CONTOSO becomes offline and no longer reachable, the Provider Policy will simply show ghosted SIDS as in the example below. Provider functionality will not be affected.
The same will also occur for application access permission assignments. The groups from the offline domain will simply display as “ghost SIDs” and the other user’s access will not be affected.
This allows for the App-V management server to remain functional while administrators clean up the decommissioned data.
How this was different with the Softgrid 4.1 Virtual Application Server
The process for previous releases of the Softgrid Virtual Application Server (what the App-V management server used to be called) resolving and accessing Active Directory was different. A special browsing account was required to access Active Directory. Account Authorities had to be configured as well. The group references were also stored in a different format within the database (see below.)
4.5 and later
Pre 4.5
Using the same example with a 4.1 server, we will see the difference in the example below:
Like with the 4.5 server, the groups are unable to resolve their SIDs. However, we have found that unresolved groups within provider policy group assignment as well as application access permissions, may cause delays.
This delay can lead to “A Network Operation did not Complete in Time” error (xxxxxx-xxxxxx0a-10000005)
With 4.1, if you have a series of applications that have many groups assigned to the application that are no longer resolvable, then you may want to provide temporary remediation for your existing users while you clean up the ghost SIDs. You can simply de-select “Enforce Application Permission Settings” in the Provider Pipeline tab in the Provider Policy dialog box.
What to look for in the SFT-SERVER.LOG file
When this issue is happening, you will likely see entries similar to below upon service start in the SFT-SERVER.LOG
[2011-11-09 19:41:13.599] APP-V-SRV1 4512 4932 SW_ADSDataConnection::FillGroupRefToSIDMap – – – – 5 – Caching(LDAP://contoso.com/<GUID=f80b836b317f7f45afb437ff7db8e741>)->(S-1-5-21-6776287-1952083785-2110791508-36630)
[2011-11-09 19:41:18.161] APP-V-SRV1 4512 4932 SW_ADSDataConnection::DomainNameToType – – – – 5 – “Domain (CONTOSO.COM) error (1355)”
When a client tries to launch an application, you will also see entries similar to below:
[2011-11-9 19:44:24.685] APP-V-SRV1 3836 4436 SW_ADSDataConnection::DomainNameToType – – – – 5 – “Domain (CONTOSO.COM) error (1355)”
[2011-11-9 19:44:42.762] APP-V-SRV1 1984 4272 SW_ADSDataConnection::FillGroupRefToSIDMap – – – – 5 – “Could Not Get Group(LDAP://CONTOSO.COM/<GUID=857fed02a9a42b4d89b7879066f327fd>)”
A slew of these entries may be present if there are a slew of unresolved groups for many applications.
Management Console Issues in Softgrid 4.1
You may also encounter the following error ” A referral was returned from the server” when trying to add groups to the Provider Policy in the Softgrid 4.1 management console. You can resolve this by changing the ASP.NET configuration of the Softgrid Management Web Service. You can change the ADReferralChasingOption to “None.” Per the following KB article:
http://support.microsoft.com/kb/930974
App-V: Intermittent DC Refresh and/or Launch Failures may be tied to Intermittent SQL Connectivity
DC Refreshes and Application Launches may fail intermittently in the case of an unstable SQL Server connection. This can happen when the threshold for connectivity to overall service connectivity to SQL has not been reached but the authentication and/or authorization of a user actually timed out on the back end connection to SQL.
In essence, overall connections to the App-V server may still be maintained and the clients will not go into DO (Disconnected Operations Mode.) Authentications may fail due to intermittent availability of a remote SQL server.
While some have recommended modifying connection timeouts to the SQL datastore, but in my opinion, this would not be addressing the underlying issue. If connectivity is problematic to SQL, first find the root cause of the connectivity.
The error that commonly appears in this scenario is:
“A Network operation did not Complete in Time”
Error: xxxxxxxx-xxxxxxx0a-10000005
I have also seen this issue pop up when the back end SQL Server’s CPU Utilization was maxed out at 100% making the service temporarily unavailable.
App-V: Arithmetic Overflow Error (0000B065) when Running System Utilization Report
Administrators can use the System Utilization Report to graph the total daily system usage. You can use this report to determine the load on your App-V Server.
This report tracks the usage over time during the reporting period for the specified server or for the server group.
The System Utilization Report also graphs the following system usage:
• Usage by day of the week
• Usage by hour of the day
The System Utilization Report also includes a summary of the total system usage for specific users and total session counts.
There is an issue, however that you may run into when you try to run a System Utilization Report by session count where you may get the following error:
Error: 0000B065
The SFTMMC.LOG (Management Console log) will also show the following:
2011-10-14 04:35:31 https://steveth-appv/
ManagementConsole.MCException: Arithmetic overflow error converting expression to data type int. —> SoftGrid.Management.GetReportDataFailedException: Arithmetic overflow error converting expression to data type int. —> System.Data.OleDb.OleDbException: Arithmetic overflow error converting expression to data type int.
at System.Data.OleDb.OleDbDataReader.ProcessResults(OleDbHResult hr)
at System.Data.OleDb.OleDbDataReader.NextResult()
at SoftGrid.Management.DataAccess.ReportDataAccess.GetSystemUtilizationBySessionData(DateTime startTime, DateTime endTime, Int32 serverGroupID, Int32 serverID, RptSystemDailySessions[]& dailySessions, RptSystemDayOfWeekSessions[]& dayOfWeekSessions, RptSystemHourOfDaySessions[]& hourOfDaySessions, RptSystemSessionUsageSummary& usageSummary)
at SoftGrid.Management.Reports.GetSystemUtilizationBySessionData(DateTime startTime, DateTime endTime, Int32 serverGroupID, Int32 serverID, RptSystemDailySessions[]& dailySessions, RptSystemDayOfWeekSessions[]& dayOfWeekSessions, RptSystemHourOfDaySessions[]& hourOfDaySessions, RptSystemSessionUsageSummary& usageSummary)
— End of inner exception stack trace —
Server stack trace:
at SoftGrid.Management.Reports.GetSystemUtilizationBySessionData(DateTime startTime, DateTime endTime, Int32 serverGroupID, Int32 serverID, RptSystemDailySessions[]& dailySessions, RptSystemDayOfWeekSessions[]& dayOfWeekSessions, RptSystemHourOfDaySessions[]& hourOfDaySessions, RptSystemSessionUsageSummary& usageSummary)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at SoftGrid.Management.IReports.GetSystemUtilizationBySessionData(DateTime startTime, DateTime endTime, Int32 serverGroupID, Int32 serverID, RptSystemDailySessions[]& dailySessions, RptSystemDayOfWeekSessions[]& dayOfWeekSessions, RptSystemHourOfDaySessions[]& hourOfDaySessions, RptSystemSessionUsageSummary& usageSummary)
at ManagementConsole.ManagementSession.GetSystemUtilizationBySessionData(DateTime startTime, DateTime endTime, Int32 serverGroupID, Int32 serverID, RptSystemDailySessions[]& dailySessions, RptSystemDayOfWeekSessions[]& dayOfWeekSessions, RptSystemHourOfDaySessions[]& hourOfDaySessions, RptSystemSessionUsageSummary& usageSummary)
— End of inner exception stack trace —
This is caused by the system exceeding a limit of calculation. When running the system utilization report the system calculates the total session duration in seconds for all users for all of the applications that have been used during the specified time period. This total must not exceed the current limit of 2,147 million seconds.
Reduce the time period used to generate the system utilization report so it falls within the current allowed limit. 30 Days will usually be a safe maximum.
Error when you Attempt to Delete a Package using the XenApp Connector for Configuration Manager 2007 R2
The following issue may occur when you are using the XenApp Connector for Configuration Manager 2007. When you click to delete a package under the System Center Configuration Manager node – Site Database – Computer Management – Software Distribution – XenApp Publications, you get the following error:
ConfigMgr cannot delete the specified object. Please verify that you have delete access to the selected object and refresh the ConfigMgr Administrator console to verify that another administrator has not moved or deleted the object.
This error occurs in spite of the permissions being correct. In addition, the SmsAdminUI.log will show the following error:
[3][8/31/2011 1:21:04 PM] :Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryExceptionrnFailure deleting management objectrn at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlResultObject.Delete(ReportProgress progressReport)
at Microsoft.ConfigurationManagement.AdminConsole.ConsoleView.ConsoleFormView.DeleteResultItems(Object sender, ActionDescription actionDescription, Status status, IResultObject selectedResultObject, PropertyDataUpdated dataUpdatedDelegate)rnConfigMgr Error Object:
instance of SMS_ExtendedStatus
{
CauseInfo = “4”;
Description = “CSspPkgProgram: Unknown offer error!”;
ErrorCode = 2152205061;
File = “c:\qfe\nts_sms_fre\sms\siteserver\sdk_provider\smsprov\ssppkgprogram.cpp”;
Line = 541;
Operation = “DeleteInstance”;
ParameterInfo = “SMS_Program.PackageID=”SBT00153″,ProgramName=”Microsoft Office Professional 2007″”;
ProviderName = “WinMgmt”;
StatusCode = 2147749889;
This can happen if the assets related to this XenApp package are deleted but the database record has not been deleted. These packages are stored in the same manner as other packages and advertisements. You can connect to the SQL Configuration Manager database and run a SQL statement to delete these records. You will need to know the Advertisement and Package ID’s. You can find this information out for sure by running a SQL Profiler trace while reproducing the issue as shown in the following profiler trace output:
Once you know what needs to be removed, you will need to run the SQL scripts to remove the entries. If you only need to worry about the package, we can simply ignore the advertisement steps and use the package steps.
To remove the stale advertisements, run the following SQL statement:
Select * from programoffers where offerid = ‘advertismentID’
Delete from programoffers where offerid = ‘advertismentID’
– where advertisementID refers to the ID you found in the above trace.
To remove the stale packages, run the following SQL statement:
Select * from smspackages where pkgid = ‘PackageID’
Delete from smspackages where pkgid = ‘PackageID’
– where PackageID refers to the ID you found in the above trace.
Once these are deleted, additional SQL triggers will remove the other remaining references and entries related to these records in other tables.
App-V: Recommended Upgrade Preparations and Rollback procedures when upgrading from App-V Management Server 4.5 RTM or SP1 to SP2.
Before Upgrading to App-V 4.5 SP2 on the management server, it is recommended to first review the release notes for added features such as SQL mirroring support.
App-V 4.5 SP2 Release Notes
http://technet.microsoft.com/en-us/library/ff699130.aspx
Also, you can download the installation for SP2 here:
http://www.microsoft.com/download/en/details.aspx?id=25291
Pre-Upgrade Recommendations
The following are recommendations for preserving information and critical data to ensure a proper rollback is available in the event of an upgrade failure or a desired rollback to a previous version of the App-V server.
1.) Backup a copy of the App-V management SQL datastore. In SQL this is the APPVIRT database by default.
2.) If .NET 4.0 is installed and you are using Windows Server 2003, The current work around is to:
a. Remove the .NET 4.0 (temporarily as it will be re-added later.)
b. Restart the server.
c. Perform the Upgrade. Restart the server.
d. Reinstall the .NET 4.0 Framework.
Potential Upgrade Failures
The following are recommended options for rollback should an error occur during upgrade.
In the event of a 25109 error, please use Rollback Option #1 for rolling back the server to its previous state.
In the event of a 25119 error (or any error not otherwise mentioned), please use Rollback Option #2 for rolling back the server and data store to its previous state.
In the event of a 2512* error, please use rollback option #3 for rolling back the AppVirt management Service (ASP.NET Web Management Service) to its previous state.
In the event that the installation completes successfully and you decide for reasons otherwise not mentioned here to roll back the server to its previous state, please refer to Rollback Option #2 for rolling back the server to its previous state.
Rollback Option #1
A 25109 error indicates failure to connect to the database. In the event of this error, all that needs to be rolled back are the binaries on the App-V Management Server.
1.) After the installation rolls back, very connectivity to the App-V Management server.
2.) If the binaries list version numbers at SP2 (4.5.3.XXX) uninstall the App-V Management server and reinstall your previous version.
Rollback Option #2
A 25119 error or a successful completion of the upgrade means that both the App-V Management server binaries and the SQL data store have been upgraded. The rollback procedure requires both the server binaries and the data store to be reverted back to its previous version.
1.) Restore the previously backed up version of the App-V data store on the SQL server back to its previous version.
2.) The App-V Management Server will likely be rolled back to its previous version during the installation. If this as a rollback following a successful installation then the existing version will need to be uninstalled and the previous version will need to be reinstalled.
Rollback Option #3
1. Manually uninstall ONLY the AppVirt Management Service (Service – not server.)
2. Restart the server.
3. Reinstall AppVirt Management Service component from SP2 media.
– Steve Thomas
App-V The solution in Knowledge Base article 959459 did not work. What did I do wrong?
Do you have the App-V 4.5 management server installed on the same server as your SQL server? Are you getting the following error every time you try to start the App-V Management Server service?
System error 1075 has occurred.
The dependency service does not exist or has been marked for deletion.
This may also occur frequently after implementing changes outlined in KB 959459.
In KB959459, there are instructions to configure a service dependency for the AppVirtServer service registry key.
When you add a REG_MULTI_SZ value named DependOnService to the key and put in MSSQLSERVER as the default, it is assuming that you are working with a default instance of SQL Server instead of a named instance.
However, if you are using a named instance, the SQL Server service entry will not be named MSSQLSERVER, therefore this dependency will be invalidated upon startup and this message will display.
To fix this, instead of placing the value MSSQLSERVER in the DependOnService key, place the name of the instance registered (i.e. MSSQL$VIRT or MSSQL$APPV, etc.)
This will require a full reboot of the server to take effect.
Steve Thomas
App-V: Certain Database tables not updating or empty post upgrade from 4.1
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
App-V 4.5: Failed to Start App-V Management Server: Error 268480357
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."
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.
madvirtualizer
The Mad Virtualizer at Microsoft 