Archive

Posts Tagged ‘SQL’

App-V 4: Factors that can cause Performance Issues with App-V 4.x Servers

July 20, 2014 4 comments

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.

Advertisements
Categories: App-V Tags: , , , , , ,

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:

http://blogs.technet.com/b/medv/archive/2010/09/22/med-v-v1-connection-settings-and-credential-management.aspx

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

Categories: MED-V, Virtualization, VPC Tags: , , ,

Decommissioned or Unreachable Domains: How the App-V 4.5 Management Server handles them differently from Softgrid 4.1 Virtual Application Servers

November 29, 2011 Leave a comment

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

October 29, 2011 Leave a comment

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.

Categories: Uncategorized Tags: , , , ,

App-V: Arithmetic Overflow Error (0000B065) when Running System Utilization Report

October 20, 2011 Leave a comment

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.

Categories: Uncategorized Tags: , , , , , ,

Error when you Attempt to Delete a Package using the XenApp Connector for Configuration Manager 2007 R2

September 7, 2011 Leave a comment

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.

Categories: Uncategorized Tags: , , , , ,

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