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.

SCVMM: Creating a New Template from a Virtual Machine with a Differencing Disk will copy only the differencing disk without the Parent Disk

If you use a Virtual Machine as the basis for a template in System Center Virtual machine Manager 2008 or 2008 R2, do not use one that uses
a differencing disk. If this happens, it will break the disk chain for the destination virtual machine and will remove the parent disk.

The end result will be orphaned differencing disks and the virtual machine will be put in an incomplete VM Confguration state. It will
also, subsequently fail to start. This happens whether you use the SCVMM console or through the PowerShell cmdlets.

Bottom Line: DON’T DO THIS!

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.

A Visual Studio 2008 Package Sequenced with Microsoft Application Virtualization may not Function Properly after Upgrading to Visual Studio Service Pack 1

Symptoms:

If you open a Visual Studio 2008 package for upgrade (or simply upgrade in the 4.6 SP1 sequencer) and upgrade the package to Visual Studio Service pack 1, it may fail to function properly on the App-V Client.

Cause:

This is caused by the Visual Studio SP1 installer setting a reparse point for key SxS (side-by-side) assemblies. The Visual Studio  2008 Service Pack 1 installer sets a reparse point from

<%SFT_MNT%><root>VFSCSIDL_WINDOWSassemblyGAC_MSILWcfSvcHost.0.0.0__31bf3856ad364e35

to

<%SFT_MNT%><root>VFSCSIDL_WINDOWSWinSxSMSIL_WcfSvcHost_31bf3856ad364e35_9.0.0.0_x-ww_e0abf5ea

This means that if the application on the client looks for the files in the first location, they won’t be found because they are actually only located in the latter.  When running virtualized on the client, the VFS does not reflect to the application the fact this is a reparse point. The application thinks the files will be located here but they are not actually found here.

Resolution

During the monitor phase, when the upgrade application has completed, you will need to open a  command prompt and copy the files from:

Q:<root>VFSCSIDL_WINDOWSWinSxSMSIL_WcfSvcHost_31bf3856ad364e35_9.0.0.0_x-ww_e0abf5ea

to

Q:<root>VFSCSIDL_WINDOWSassemblyGAC_MSILWcfSvcHost.0.0.0__31bf3856ad364e35

so they are located in both locations.

For example, If the drive used for the SFT_MNT volume is Q:, then the syntax for copying via XCOPY would be:

XCOPY /S /E Q:<root>VFSCSIDL_WINDOWSWinSxSMSIL_WcfSvcHost_31bf3856ad364e35_9.0.0.0_x-ww_e0abf5ea Q:<root>VFSCSIDL_WINDOWSassemblyGAC_MSILWcfSvcHost.0.0.0__31bf3856ad364e35

Use the MOFCOMP Utility to fix MED-V Error 7006

A WMI feature of MED-V v2 lets you configure your environment to detect certain network changes that might occur after MED-V workspaces are deployed and that can affect MED-V. The feature includes a component running in the guest operating system that is notified of network configuration changes on the host computer. It allows a non-Microsoft ESD or other application that is running in the guest to resolve to the same network endpoints that the host ESD or application resolves to.

This feature is only available if the virtual machine is configured for network address translation (NAT) mode. If the virtual machine is configured for BRIDGED mode, no change indications are generated.

If you are finding this feature is not functioning properly, please look for the following in the MED-V Guest event log:

Event Type:         Information

Event Source:     MEDV

Event Category:                Network Settings

Event ID:              7006

Detail: The rootccmNetworkConfig WMI namespace does not exist. Network configuration change events will not be processed.

You will get this error without the SCCM NAT patch for MED-V installed. More information can be found here: http://support.microsoft.com/kb/2278056

If you are not using SCCM or if you are using SCCM, have installed the SCCM NAT patch and are still getting this error, you will need to open up the workspace to a command prompt or Notepad or a Text Editor using administrative rights. Using Notepad or another text editor, create a Managed Object Format (MOF) file that will look for the network configuration changes that you want to monitor. Use the following code snippet:

 

#pragma namespace (“\\.\root\ccm\NetworkConfig”)

 class CCM_IPConfig

{

    [NotNull: ToInstance ToSubClass] uint32 AddressFamily; // AF_INET, AF_INET6

    [Key, NotNull: ToInstance ToSubClass] string IPAddress; // IPv4 or IPv6 address

    [NotNull: ToInstance ToSubClass] string SubnetMask; // IPv4 subnet mask

};

 

class CCM_NetworkAdapter

{

    [Key, NotNull: ToInstance ToSubClass] string Name;

    [NotNull: ToInstance ToSubClass] uint32 DHCPEnabled = 0;

    [NotNull: ToInstance ToSubClass] uint32 Quarantined = 0; // To check if it is quarantined.

    CCM_IPConfig IPConfigInfo[];

};

 class CCM_NetworkAdapters

{

    [NotNull: ToInstance ToSubClass] String ProviderName; // MED-V or other provider

    CCM_NetworkAdapter AdaptersInfo[];

};

 

Save the file in the %SYSTEMROOT%System32wbemmof directory of the guest OS as medvnet.mof.

Compile the MOF file using MOFCOMP.EXE in the guest.

Restart the Guest OS.

You can then use the WMIC command to verify the namespace: