Archive

Posts Tagged ‘softgrid’

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.

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

App-V 5: On Explaining this New VFS to Softgrid Users

November 4, 2013 5 comments

There is an expression that is based upon a well-known book – “Who moved my cheese?” Ah, change – it can be hard. I will confess, there was a lot of “cheese moving” in the redevelopment of App-V 5 from my perception. I’ve
spoken about some areas where changes have been significant. I find myself doing a lot of explanation to Softgrid users. When I speak of Softgrid users, I speak of those who were brought up in what I now call the “legacy SFT world.” This was the world of the SFT file; the world of the SFTMIME and SFTTRAY commands; the troubleshooting of the SFT listener service and the SFTLOG file. This went all the way to App-V 4.6. It is still in use, still supported, and it will be here for a while. But as of App-V 5.0, that era is now starting down its road into the sunset. If you are looking to survey App-V for the first time, you should be looking into a modern solution: App-V 5 and beyond.

To continue on a point I alluded to earlier regarding change, I wrote an article on scripting several months back. Scripting was indeed an area where there was tremendous change. I felt it was needed as I was hearing numerous stories about “how scripting just doesn’t work in App-V 5.” What bothered me the most was that I was hearing this from experienced users of App-V 4. I laid down as best I could a guide for transitioning scripts from 4.x to 5.x. Not only were the mechanics different, but a lot of concepts had changed, because we now had more options. It was change. Change for the better.

With a new VFS, there are also changes, but the concepts are very similar. It is the implementation that is drastically different. I’ve noticed something interesting. With this new VFS, there is a huge desire to understand what has changed and what has not changed. There is also the assumption that since the way App-V handles file assets has been completely re-written, then all of the fundamental basics should be thrown out the window. Sometimes, one can get lost when there as an attempt to over complicate something. And believe me, I’ve read some over-complicated interpretations out there in the blogosphere. Fundamentally, at a high level there are no major differences. AppV uses a VFS to separate assets from their traditional locations as to not conflict with each other. The concept is not different from 4.x.

Isolation vs. Immutability and State Separation

Isolation implemented differently is still isolation and protection. Moving from a proprietary file system to one that uses native NTFS means that the way AppV “isolates” has to be implemented differently. If you ever look at the Server App-V product, you can actually see a mid-point in this evolutionary process where there was indeed, still a “Q drive” – yet the Q: drive yielded a human-readable file system. With App-V 5, there is a moving of these “Q:
drive assets” or %SFT_MNT% assets into an overlay of file assets that are state separated where the base package remains immutable or read-only – just as the assets within %SFT_MNT% which were cached into an actual file called SFTFS.FSD in 4.x.

Advice for the Softgrid Users:  Learn by aligning the concepts

Transitioning is easier when you can map where the concepts carry over. Then all that is needed is to focus on the details of transitioning how you would virtualize your applications in v5, especially those that required customization and advanced sequencing techniques.

SFT_MNTPackageRoot vs. AppVPackageDriveAppVPackageRoot

The package root in v4 (which we referred to as SFT_MNT due to the variable %SFT_MNT% reflecting the package root of an application) was laid down in the virtual environment as Q:RootDir. Applications outside the virtual environment could not see this without special configuration. All cached assets went here in their own separate folders which would all actually be stored inside a read-only file system file called sftfs.fsd (by read-only, I mean immutable – the changes and modified files go somewhere else.) In V5, it is essentially the same. They are just laid down in human-readable file system assets. It is just not isolated. However, it is still read-only. It is still
immutable. This is why you cannot change anything – by anything we also mean permissions. When you add a package through PowerShell, or a package comes down on the ConfigurePackage function (using the publishing server) regardless of the target publishing, a “Package Root” is laid down with a series of shadow files and directories.

This will be in the PackageInstallationRoot configuration item which defaults to %PROGRAMDATA%AppV but it can be redirected if needed by changing PackageInstallationRoot in HKLMSoftwareMicrosoftAppVClientStreaming in the registry. Directories and markers will be laid down as well. These markers are actually shadow files. Do not confuse these with sparse files. Sparse files will be used if you are implementing the Shared Content Store. When you stream the package, the shadow files will become the streamed-to-disk assets. They will be immutable, or read-only. The integration components, including links and shortcuts, will not be laid down until the publish event has occurred. The integration link placement will depend on how the actual package has been targeted for publishing.

Targeted Publishing – A Difference

It is with publishing that things get different. The integration components (what serves as the target for linking the OS environment and ultimately the user) for this package will be placed in IntegrationRootUser if it is published to the user and IntegrationRootGlobal if it is published to the machine (globally.) These locations can also be controlled by setting those values in HKLMSoftwareMicrosoftAppVClientIntegration.

For those packages that are targeted to the user you will see the symbolic links to the package GUIDs under IntegrationRootUser which will reflect the beginnings of the user state data, the user mode VFS, and the elements that are allowed through the COW (copy-on-write-filter.) In essence, the data that would have normally be encapsulated inside of the PKG files in Softgrid. With user publishing, you will see here exclusively the publishing
integration elements which would normally be under %PROGRAMDATA%MicrosoftAppV when they are published globally. Even with global publishing, the users will maintain settings for their user state within %LOCALAPPDATA%MicrosoftAppV or IntegrationRootUser.

 

How AppV 5 Manages File-based user data vs. PKG’s

We used to call these PKG files. We use to have both user state data and global package data inside these PKG files. This data is managed differently in that they are no longer isolated into PKG files. AppV lays down these assets into human-readable files but everything is still state separated. But for the application, the virtual view is no different conceptually. The virtual view is the combination of namespaces in V5 just as it was in V4 (where the
virtual view was a combination of read-only immutable assets (within the FSD) and read-write global and user assets (within the PKG.)

Caching is now mounting

Which means, to pre-stream, or pre-mount, you simply run a “Mount-AppVClientpackage” cmdlet. Otherwise, the operation is similar in the mounting occurs on demand when you stream the application on first launch. Slowly, as the files are fully downloaded, the shadow files become fully cached files. The icons switch back to a normal icon in the PackageInstallationRoot. THAT IS – if you are using the traditional “stream-to-disk” process. If you are
implementing the Shared Content Store or “stream-to-memory” you will not be caching 85-90% of the file system assets. Those sparse files remain as such in the PackageInstallationRoot. NOTE: If you run the Mount-AppVClientPackage even in shared content store mode, it will fully cache those files to disk.

Now Why Can’t I set ACL’s on the Package Files beneath PackageInstallationRoot?

Applying permissions to the files and directories beneath PackageInstallationRoot is not possible because, as I mentioned, earlier, these files are read-only and that also includes the extended attributes. You can however set permissions on folders and files located in the user mode VFS located beneath IntegrationRootUser (which itself is beneath %LOCALAPPDATA%.) Pre-staging these permissions does require some work. Some in the community
have come up with great ideas. I like the script by Dan Gough in particular (located here: http://packageology.com/2013/06/file-permissions-app-v-5/) The reason why it has to be done this way is due to the new way in which file
assets are implemented using native NTFS instead of the previous methods.

Conclusion

Change can be hard. But not so much if all you are having to do is learn new technique. Conceptually, not a lot has changed but because Windows as a whole is evolving, applications and application formats are modernizing,
it is important that App-V evolves as well as a key tool for that modernization. This means that certain things may change when it comes to minor elements such as permissions. In a later post, I will dive further into the intricacies of how files are handled and how this understanding can help us troubleshoot when needed.

I sense the comments will come in 3 . . . 2 . . . 1 . . .

Categories: Uncategorized Tags: , , , , , ,

Important Information for those still using Softgrid 4.1 and 4.2

September 25, 2012 Leave a comment

If you are currently using Softgrid 4.1 or4.2 clients and/or servers, you need to be aware of the following support milestones:

Product

Availability

Mainstream Supports Ends

SoftGrid Application Virtualization 4.1 for Desktops

5/25/2007

7/10/2012

SoftGrid Application Virtualization 4.2 for Desktops

5/25/2007

7/10/2012

SoftGrid Application Virtualization for Terminal Services 4.1

5/25/2007

7/10/2012

 

As of last July 11th, these products are now in extended support which means

  • No more requests to change product design and
    features
  • No more hotfixes unless using an extended hotfix
    support contract.

Once a product moves out of mainstream support, I immediately start advising my customers to move forward. In the case of application virtualization, the reasons for moving to a more modern virtualization engine primarily revolve around more virtualization features and support for more modern operating systems (Windows 7 and Windows 8.) At this point it is a matter of determining what course of action to take – either moving to 4.6 or moving to 5.0. Most of the time, this decision depends on parallel factors (OS migration, ESD implementation, Application Compatibility remediating efforts, etc.) Use the following table to determine your general options for
moving forward:

Product

Transitional OS Support

Modern OS Support

Configuration Manager Integration Support

Upgrade from 4.1/4.2?

Engine Co-existence Support

App-V 4.6 Desktop Client

Windows XP & Windows Vista

Windows 7 & Windows 8**

2007, 2012

Yes

App-V 5.0**

App-V 4.6 RDS Client

Windows Server 2003 & Windows Server 2008

Windows 2008 R2 & Windows 2012**

2007, 2012

Yes

App-V 5.0**

App-V 5.0 Desktop Client

None 

Windows 7* & Windows 8

2012 ***

No

4.6**

App-V 5.0 RDS Client

None 

Windows Server 2008 R2* & Windows Server 2012

2012 ***

No

4.6**

 *- requires PowerShell 3.0
**- Requires App-V 4.6 SP2
***- Requires CM 2012 SP1 or later

Getting Your Virtual Applications to 4.6

Should you decide to move to 4.6, besides the obvious infrastructure upgrades, you will need to plan on moving your virtual applications to this newer platform. If you are currently on Windows XP, 4.6 is still the only option. For moving to is 4.6, I generally recommend following the general process below for assessing and remediating virtual application package migration.

  • Test existing package. While the injection/virtualization model did change between 4.2 and 4.5, a lot of regressions were identified and fixed – however – in my opinion, this may only be a guarantee in 80-90% of applications.
  • Update SFT file using App-V 4.6 SP1 sequencer or later. You can simply open a package and save it under the 4.6 SP1 sequencer and this will often serve the purpose of getting the applications functioning properly on the 4.6 client. You can also automate this by using the App-V sequencer command-line. Refer to this Technet Article – http://technet.microsoft.com/en-us/magazine/gg236638.aspx
  • Re-sequence using 4.6 SP1. If all else fails, re-sequence using the 4.6 SP1 sequencer (or later.)

Getting your Applications to 5.0

Should you decide to move to 4.6, your 4.1/4.2 packages will need to follow a different process for migration as there is a drastic change in the sequencer file format (SFT to APPV) as well as the XML governing these packages. Sequencer generates new package format based on the Windows 8 installer (APPX).

There is no direct step for moving these packages to the new formats. For moving to 5.0, I am currently recommending following the general process below for assessing and remediating virtual application package migration.

1.)   Update the 4.1/4.2 package using the App-V 4.6 SP1 sequencer or later. You can simply open a package and save it under the 4.6 SP1 sequencer and this will often serve the purpose of getting the applications to the minimum level needed for migration to 5.0 as mentioned above, you can also automate this by using the App-V sequencer command-line.

2.)   Test the package functionality using a test client running App-V 4.6 SP1 or later. This step is often left out – but is necessary.

3.)   Once the package is a confirmed working 4.6 SP1 package or later, you can proceed with migrating the package using the package conversion module that is included with the App-V 5.0 sequencer. The “AppVPkgConverter” PowerShell module installs with the App-V 5.0 Sequencer.

Please note: It is early in the process for me to give exact specifics as to expected successes – however, I can point out that there are elements that will not convert and will need to be tweaked/adjusted as of the App-V 5.0 Beta 2 release. These will help you determine if you would be better of re-sequencing the application:

  • OSD Scripts These will need to be added using the Dynamic Configuration feature of 5.0
  • OSD Registry Settings: These will also need to be added using the Dynamic Configuration feature of 5.0
  • Dynamic Suite Composition Settings: You will need to use the Virtual Application Connection feature instead.

You will also need to re-sequence in order to take advantage of Virtual Application Extensions Points.

Bringing Legacy Blog Back to Cover Legacy Products


Just about a year ago, I moved all new posts over to Technet.com. In spite of that, this blog still continues to get much attention due to a lot of the existing content proving to be very useful for users. For that I am extremely happy to help and it recently gave me an idea. I have been mulling over how I should focus my current blog over at Technet with regards to information, guidance, and support tips. While I have a lot of great information coming (a lot of new products/product versions in the pipeline) I also have a wealth of information I’ve been needing to post tat was related to existing products and legacy products (Softgrid/App-V 4.x/MED-V V1, etc.) I also realize there is a strong user community and install base still present who may not be moving off until the products get closer to end of life.

– Steve Thomas

With this said, I decided that I would use this blog on WordPress in the future for legacy product information (App-V 4.x/Softgrid/MED-V V1/VMM 2008/VPC) while keeping my blog over at Technet more related to current and forward technologies (App-V 5.0/UE-V/Hyper-V 2012/Win8/Win2012.)

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: Important App-V/Softgrid KB’s and Documentation Links


Office 2010 Sequencing

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

Office 2007 Sequencing

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

Problems Sequencing Office 2007

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

Information about how to use Office 2010 suites and programs on a computer that is running another version of Office

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

Issues Sequencing Office 2010

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

Server Command Line Installers Options

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

Troubleshooting w/ Process Monitor

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

Introduction To Softgrid Networking

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

App-V White Paper Portal

http://technet.microsoft.com/en-us/appvirtualization/cc843994.aspx

App-V Technet Documentation

http://technet.microsoft.com/en-us/library/cc843848.aspx

App-V Blog

http://blogs.technet.com/appv

Top 5 App-V SQL KBs:

25119 Upgrade Issue

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

Moving 4.1 Databases

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

App-V Server fails to start when SQL is on the same machine

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

Concurrent Licenses

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

MWS Administrative Issue

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

App-V 4.6: App-V 4.6 Reporting does not work when using 4.1 Server


When Softgrid evolved into App-V for version 4.5, the reporting model was changed to where reporting is cached by the client and uploaded to the server during DC Refresh rather than with each application launch.

While 4.5 and 4.6 clients can connect to and use a 4.1 Softgrid Virtual Application Server, reporting will be disabled due to the difference in models. The 4.5/4.6 clients will cache this information in an XML file labled by a <GUID.>

The location of this <GUID>.XML file is registered using the LastCacheFile registry value in the following registry path:

HKEY_LOCAL_MACHINE\Software\Microsoft\Softgrid\4.5\Client\Reporting

This LastCacheFile contains both the path and GUID file name.

Here is an example of the reporting cache file:

<REPORT_DATA_CACHE><APP_RECORDS><APP_RECORD Name=”Adobe Reader 9.0″ Ver=”1.0″ Server=”app-v-ms.steveth.local” User=”STEVETH\Gladiator” “Launched=”8/19/2010 8:55:52 PM” Shutdown=”8/19/2010 8:56:00 PM”/><APP_RECORD name=”Adobe Reader 9.0″ Ver=”1.0″  Server=”app-v-ms.STEVETH.local” User=”STEVETH\Gladiator” Launched=”8/19/2010 8:58:58 PM” Shutdown=”8/19/2010 9:00:19 PM”/></APP_RECORDS></REPORT_DATA_CACHE>

The server reporting tag is located in the following registry path:

HKEY_LOCAL_MACHINE\Software\Microsoft\Softgrid\4.5\Client\DC Server\<SERVER>

The DWORD value is 1 by default when using a 4.5 or later server. it can be set to 0 to disable reporting. However, if the server is 4.1 and the client is 4.5 or later, then this value will always be reset to 0.

This process happens upon detection of the App-V 4.5 or later server. An event in the client log is also logged when this happens.

[08/19/2010 14:55:18:179 MIME VRB] {tid=BA4:usr=steveth}
DC server does not want to receive v4.5+ reporting

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