App-V Internet Explorer Add-on Conflict: Watch those Registry Keys

Students run into this problem in our App-V training classes every time.

The Problem

In one of the labs we deal with creating and deploying a handful of browser plugins in a connection group.  And everyone runs into an issue of some of them seemingly not working.  The lab specifies a set of plug-ins to use, but I usually encourage students to work off-script and sequence from a bigger set I have available or download something they use at work.  Typically, they sequence a bunch of add-ons, running a smoke test on each to verify operation.  Then, when they place them in a connection group, some don’t appear in the browser.

The Cause

The problem happens due to created registry keys.  Add-ons to the Internet Explorer are registered via one of several registry keys, by adding in a subkey with the appropriate information.  But out of the box, the naked OS does not have the base keys that you register under.  Thus, when you install the plug-in it creates the base key along with its subkey, both of which are then marked as “Override Local” keys.

In particular, I have noticed the following keys (under HKLM or HKCU):

  • Software\Microsof\Internet Explorer\Extensions
  • Software\Microsoft\Internet Explorer\MenuExt
  • Software\Microsoft\Internet Explorer\Explorer Bars
  • Software\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects

but there may be more not on my list yet.

Left as Override Local, these keys cause the add-on to work just great when tested alone, but placed in a connection group this package will cause other addons to not be seen.  The technical details and scenarios I described in the research paper Pellucidity and Deletion Objects: Connection Groups and Layering in App-V 5 a couple of years back.

The Solutions

The solution is to locate those keys and make sure they are marked “Merge with Local” in the sequencer.  There are three ways to handle this:

  1. View the virtual registry in the sequencer editor and manually locate and change the setting on those keys.
  2. Using AppV_Manage 3.11 or above, run the analyzer.  I have added warnings in the analyzer for the three specific keys above, as well as a bunch of other things that you should be aware of in your package.  Basically, if you see yellow in the analyzer, you had better check it out.
  3. Pre-create those keys in your sequencer image.  These are just like the ODBC key and dummy printer key that became best practices for sequencing over the years.  Those two keys you no longer have to worry about because the installer for the Sequencer creates them for you.

While the last solution is probably the one you should use, be aware that this is probably not a complete list.  A better practice is the first in the list; to always review the virtual registry keys for potential keys marked as override that should be marked as merge (to allow for integration) or those marked merge that should be marked as override (to prevent visibility of locally installed junk).  The same goes for file folders.

Other good advice…

Double-checking your package with an up-to-date AppV_Manage analyzer is also a really good idea (it is free). Now between updates to support new App-V features (4 releases adding features to App-V in the last 13 months), plus the additions I am constantly adding to the quality of the analyzer to help you understand more about what is in your package, your current version is probably out of date. So every time you think about  it, check the TMurgent home page to see if there is an update.  The sequencer editor hides an awful lot of detail that we can expose, and I am constantly looking for examples of problem packages that I can add detection of.  When the next version is posted (probably 3.11?) is released soon this will include::

  • Detection of bad ProgIDs.
  • Detection of shortcuts with spaces at the end.
  • Display of longest file path (could cause file-not-found issues).
  • Detection of Services ignored by the sequencer due to incorrect logon accounts.
  • These keys mentioned above, if marked Override Local.
  • Publishing issues with non-com based Browser Extensions.
  • Publishing issues with Com-based Browser Extensions.
  • Publishing issues with Browser Helper Objects.
  • Detection of internal scripts (Office 2013).
  • Overhauled Analysis of COM, including linking COM entries to usage.
  • Detection of whether the DCOM warning is real or not.
  • Counts of Registry Keys and Values, including those hidden deletion markers not shown by the sequencer.

 

 

 

 

JreBlock: Script for hiding native Java

Photo: Patrick Mangan

By Patrick Mangan

JreBlock: is a simple PowerShell script to help when you need to sequence a Java JRE inside of an App-V virtual environment and want to block visibility to other Java versions that might be natively installed at the client.

The typical technique to sequencing Java JREs is to actively attempt to hide all other versions of Java from the virtual environment other than the one you want. Arron Parker provided a cmd script back in the App-V 4.5 days, but it needs to be updated to the latest versions of Java to use it.

This is a PowerShell script that anticipates the likely versions of Java over the next few years, and allows you to optionally specify a maximum version if that isn’t enough.

To use the script using the default settings, which handle up to version 1.9.2.99, you would run the following commands:

  • Before sequencing, PowerShell.exe -ExecutionPolicy Bypass ” jreBlock.ps1 $true”
  • While Monitoring, PowerShell.exe -ExecutionPolicy Bypass “jreBlock.ps1 $false”
  • and then install the JRE that you need.

It will create a few more blocker keys than you need, but better safe then sorry.

The tool is free for personal or commercial use.

Here is the ZIP package with the PS1: jreBlock V 1.0.0.0


Patrick Mangan is a consultant at TMurgent Technologies where he specializes in sequencing difficult packages.

Why our App-V Training Classes are Finally Upgraded to “Masters” Level

When App-V 5 was released two years ago, I blogged about how we were renaming our training classes as “Experts” level, rather than the Masters Level designation that we used for the App-V 4.6 classes.

The idea was that while I had been working with pre-releases for almost a year, I knew that we didn’t know enough about the completely rewritten product.  At the time, I was guessing it would take about a year of digging through the mud to uncover enough about how the product really worked under the hood to be comfortable enough to consider the product mastered.  Little did I know that it would take two years!

We are finally there.  While I think that we did a pretty darned good job with our training classes over the last two years (ask anyone that attended) we are now convinced that we can teach you more about mastering the product in one week than you can learn on your own working with the product full time for years and years.  Our classes, both those run by TMurgent and those run by Kevin Kaminski over at The Big Hat Group, will be designated  as “Masters Level” in 2015.

App-V 5.0 Sp3 Upgrade: Clear Browser Cache to clear issue on Server MC upgrade

Just in case this bites someone else…

An upgrade of App-V Server to 5.0 SP3 includes a replacement Management Console.  As this is Silverlight based, this means that the website delivers a Silverlight XAP file to your browser.  Where it remains in your browser cache.

Upgrade of the server does not always mean that the browser cache gets flushed.  So you might find that while your console is “working”, you are not getting the new UI features (in this case for connection groups). To verify, open the console and click on the “About” link (upper right) to check the version, which should now be 5.0.10107.  If not, clear your browser cache.  And don’t forget about any shortcut links that you made to the console.  In my case, typing the URL in a browser got me the new console, but clicking the link each time got me the old one.

 

Tim on App-V 5.0 SP3

image attribution Stuart MilesThis week Microsoft released the anticipated App-V 5.0 SP3, along with an updated UE-V 2.1, as part of the MDOP fall release.  We normally expect the MDOP release around November 1st, so this drop is a little later than usual for some reason.  But it is well worth the wait.

While Microsoft App-V is generally regarded as the best application virtualization solution out there, the product did take a step back in the 5.0 re-write that was released two years ago.  Oh, it was still better than the alternatives, but not necessarily better than App-V 4.6.  At that time, I cautioned companies to work with 5.0 in their labs, as eventually they will want to move to the new platform, but if they were on 4.6 currently they shouldn’t be in a hurry to upgrade in production. 

With the release of 5.0 SP2 last fall, I felt that it was mostly ready.  On one hand, 5.0 SP2 allowed you to do many things that you just couldn’t do otherwise, while on the other hand there were some annoyances that kept it from being declared the best.

During 2014, we saw a couple of “hotfix” releases, especially HotFix 4 and HotFix 5, which were really feature releases and major performance improvements.  5.0 was looking really good.

With the release of SP3 this week, I think that 5.0 is now the best release, clearly surpassing even App-V 4.6.  Which is important since the end of support for App-V 4.6 SP3 as I read it as Dec 2 2014,  or this guy thinks  might be next June.   In any case, time to get moving. 

So what do we get in SP3?

To start with, everything here is based upon a combination of access to pre-release software, plus a review of the release notes.  The msdn download center has been all bonkers so I haven’t gotten the actual bits yet. 

In the release, all components of App-V are upgraded.  Server, Sequencer, and Client.  There are MDOP downloads, RDS downloads, and Hosting Provider downloads showing on the site (even if the download button isn’t working.

See the release note here, but read my summary as well…

  • Single Install. First, we get a roll-up of those important “hotfixes”.  A single install for new clients is a beautiful thing.
  • Connection Group Flexibility. This consists of four things:
    1. You can now include apps published to the user and those published globally in the same group (as long as you enable the connection group to the user).  Previously all packages in the group had to be published the same way as the group.
    2. You can mark packages as optional in the group.  This means you can define a master group for anyone getting the primary package that includes all possible add-ons, but publish the add-ons independently without having to manage a group for each permutation.  It is kind of like the And/Or used in the Configuration Manager, except that the group GUID is consistent at the client.
    3. You can mark a package version with a wildcard of “*”.  So if you upgrade the package you don’t have to think about updating the connection group.
    4. You can now unpublish and/or remove a package from the client without disabling the connection group (as long as the package is optional in the group).
    5. Connection groups can get upgraded even if in use.  This is similar to the package pending scenarios (where a package add/publish/unpublish/remove is queued up for execution at a later time when the package is not in use), except that in this case pending means that the client needs to make additional changes to state but you immediately get the effect for newly launched packages/groups.

Keep in mind that this new flexibility is not available to Config Manager deployments at this time.  That would require a rev of Config Manager.  So those that deliver using the App-V Server, Stand-alone deployments, or with third-party tools, get a leg up.

  • Publishing for other users. You may now publish/unpublish a package, or enable/disable a connection group to a user other than yourself via powershell.  The limitation is that the user must be currently logged in, or at least profile still available on this machine, and that you must be an administrator.  The powershell now accepts the user SID as an optional parameter.
  • Local Publishing Authorization.  The Group Policy (as well as regular registry based configuration) for App-V is expanded to allow you to control if package and connection group publishing is limited to only Administrators.  Previously, it was possible for users with standard rights to self-publish by googling the PoweShell commands.
  • Merged Roots. This is huge! When packages are placed in connection groups, an improved merging of identical paths between the packages occurs.  There were improvements in HotFix 5, but is even better now.
  • Goodbye PVAD (almost). Thanks to merged roots, it is no longer necessary to declare a PVAD folder in the sequencer and install the software to be virtualized into that folder.  In fact, I found out that if you are going to use a Connection Group, you are probably better off using a VFS style install! With SP3, there still is a PVAD, it is just hidden.  For most all applications, this turns out to be just fine, but we know of a few applications that require PVAD installation, so how to we handle that?  You have a couple of ways to do this:
    1. There is a new command line switch, -EnablePVADControl when you launch the Sequencer GUI to show the PAD prompt like before.
    2. You can set a new registry DWORD HKLM\Software\Microsoft\AppV|Sequencer\Compatibility\EnablePVADControl to 1.
    3. Or, when you enter monitoring mode, just browse to the C:\ folder.  The Sequencer created a random PVAD folder name (looks like a GUID) for you.  Just install the app there.

So how do you know when to sequence to the PVAD?  .  Each app will act differently, but often the when at the client and you launch the virtual app, it will in some way complain that it isn’t installed or configured correctly and refuse to run. When the app doesn’t work at the client, give PVADing a try.  It might just work. 

The MVPs have a short list of apps that we have found that need PVADing, including:

WinZip
ArcGIS Desktop tool
Avaya CMS Supervisor R17
Wonderware InTouch 10.x

I also think that we will find apps that have long path length issues with VFS style installs, and a PVAD install, especially one carefully crafted with a long PVAD, might be needed.

  • PowerShell Changes. Some small changes were made to the PowerShell interface to support the new features.
  • Client Publishing from Publishing Server. Some behind-the scenes changes were made to support the new connection group features.  This mostly affects manual diagnostic debugging from the client of the publishing information as the new client will automatically use the new syntax.  If previously you used http://servername:port to test the publishing server, you now use http://servername:port&clientversion=5.0.xxxxx.x&clientos-WindowsClient_6.2_x64 (replacing the x’s with the actual client version and the OS as well).
  • RunVirtual. RunVirtual is now supported for per-user published packages. WooHoo.
  • Some App-V Client Debug logs have been consolidated, and some moved to a ServiceLog subfolder.  See the release notes if you care.
  • Virtual Services with DACLS Fix. For some time, certain windows services that use “unusual” Service DACL settings to protect themselves would not work when installed using the sequencer.  This included the FlexNet licensing service and those of Google Chrome Enterprise.  While the prior work-around to manually modify these permission settings in the Sequencer will still work, you no longer need to do so.

NOTE: Microsoft doesn’t list this as a feature or fix with the release.  It seems that this was simply a side effect of a different fix to virtualized services.  They only became aware of this fix when I discovered it and asked about it.  No word on what they were trying to fix, but presumably it was to fix a different virtual service issue reported by a customer.

Please pay attention to the details in the readme about the order of upgrade installation, as this is different from prior releases due to the changes to support the new connection groups.  You should upgrade the servers before upgrading ANY clients.

This information is based on working with some pre-release builds, and re-checking the release notes to make sure that there are no unexpected surprises. We will switch out and use the new version in our training class this week (if I can get it downloaded!).  Perhaps we will learn a little more. 

Also check out Thamim’s blog on the subject here: http://virtualvibes.co.uk/connection-groups-2-0-in-app-v-5-0-sp3-more-manageable-more-flexible/

PS: I have a new version of AppV_Manage ready to release that works with the new features, and works with the Windows 10 Preview, where there are some PowerShell differences that needed addressing.  I will get that released soon.

App-V and .Net Performance

This post is about the performance impacts of combining Microsoft App-V 5 sequenced virtual applications with applications that use Microsoft .Net.  I wish this story ended with good news, or at least reasonable actions that you could take to improve performance, but it isn’t so.  Instead it is mostly informational, however, in the end there is a technique mentioned that might be useful for a really poorly performing app. In the most typical cases the trick is probably too much work for the performance gains that you might receive, but maybe it can help you if you are stuck with user’s complaining about the runtime performance.  So here is the story (so far).

Background on .Net

Like Java, Microsoft .Net programs are constructed with the concept of “write once, run anywhere”.  Except anywhere means places where you have the supporting runtime.  For Java, this means the appropriate Java Runtime (which can be placed about everywhere), and with .Net it means the appropriate .Net Framework (more limited currently, but now it might be coming to other OSs).  But while Java may run on more CPU architectures and OS platforms, .Net tends to have much fewer version incompatibilities. Both programing languages achieve processor independence by compiling into a processor independent language.   This is called MSIL (Microsoft Independent Language) in “.Net-speak”.

The processor independent language is compiled into binary form by a “just-in-time” compiler, known as JITing. Both Java and .Net use JIT compilation to improve speed over interpreted languages like the older Visual Basic (the non-managed variety) or Perl languages. While binary code will always be faster than interpretation, the overhead of JIT compiling every time the program is run is a drag on performance. Microsoft supports three forms of performance improvements for .Net programs that the developer of the app can take advantage of.

  1. Strong Named Assemblies. When a .Net dll is added to a system, if it was built with a StrongName it can load faster.  A StrongName is basically a weak public digital signature that doesn’t verify authenticity but verifies that the file hasn’t been messed with.  When dlls built with StrongNames are stored in the Global Assembly Cache, signature verification occurs only once (when placed into the cache).  When the dll is loaded by a program into memory, the OS can perform a quick hash check that the file hasn’t been modified since installation into the cache.  For large dlls where you might not need all of the functionality this will improve performance by a small amount.  To gain this performance, the StrongNamed dll must be added to the .Net Global Assembly Cache (one of the following folders under C:\Windows\assembly: GAC, CAG_32, GAC_64, GAC_MSIL).  The dll placed in the Global Assembly Cache is not compiled, so gains are limited. Some .Net dlls are built without a StrongName, and these will never be added to the Global Assembly Cache.  Adding this into the cache is typically a post-installation step (sometimes performed by the installer).
  2. Native Compilation (post-install). When a .Net dll or exe is installed on a system, NGEN can be used to create a “Native Image” copy via compilation.  This compiled copy is specific to a CPU architecture.  Back when I attended the “Hailstorm” event in Redmond (when .Net was originally announced more than a dozen years ago), compilation to a CPU was very processor specific.  But these days, my sources inside Microsoft inform me that we don’t need to worry about AMD versus Intel, or Xeon versus Core I*.  Compilation is really to the bit-ness of the CPU architecture (32 versus 64 bit) and major design.  Usually, these native compilations occur as part of the application installer as a post-installation event.  Often, the installer designer forgets about this, and the program is just JITed all of the time.  Post-install compilation is performed using the ngen.exe program that is part of the framework.  The compilation may be performed synchronously, or placed into a queue for asynchronous compilation by the NGEN service whenever the system is idle for a period of time.  When compiled, an executable named foo.exe or bar.dll will have a compiled copy placed in the windows\assembly subfolder for the major .Net version (2 or 4, currently).  These files are distinguished by being called foo.ni.exe or bar.ni.dll.  These files will almost always be larger than the original file, but usually perform much faster as JIT compilation is no longer needed at runtime.  The system loader automatically detects if there is a Native Image available whenever the original component is loaded into memory.
  3. Native Image Compilation (by the developer).  This is a new option available to developers in Visual Studio 2014 preview for applications being developed for the Windows Store.  Because the compilation is being performed at build time, the optimizations available are far greater.  Among other things, this compilation pulls in the portions of framework dlls directly into the native image (sort of like embedding mfc dlls into a Win32 executable), making these Native Images independent of the .Net Framework itself.  Of course on the flip side, these Native Images are processor specific. The result is a real exe, so special handling by the loader is not required.

.Net compilation can improve performance significantly.  There are no hard numbers on this, as it really depends on the program.  Some simple tests I have run using post-installation compilation into Native Image on small programs saw a 15 to 20% improvement in launch time.  So the potential performance gains of .Net Native Image compilations are significant enough to be interested in.

Which brings us to the .Net and App-V discussion.

When we install and capture programs in the sequencer, post-installation activity of type 1 and 2 are a possibility and may get captured.  If captured, we are essentially redistributing these components to the clients.  I used to think that this would break things, but never saw that happen.  And now with the latest information from Microsoft, it seems not to be the case and redistribution in an App-V sense should be OK.

To confirm when a native image is in use, I use ProcessExplorer to examine what is actually loaded into the process memory. Using the lower pane display to show loaded modules, you can see that both AppV_Manage.exe  and Appv_Manage.ni.exe are loaded in the process shown in the image below:

Process Explorer showing a process using a Native Image

Note: The above capture is with AppV_Manage version 3.8 where I realized that my installer wasn’t creating the native image either.  You will now also see the compression library has a native image also.

In tests not using App-V, I have proven the ability to redistribute an “AnyCPU” executable that was natively compiled on an x86 system.  Outside of App-V, I redistributed the native image to both an x86 system and an x64 system.  The x86 target system used the Native Image (as seen in ProcessExplorer) and saw the expected performance gains.  The x64 system did not use the Native Image compiled for 32-bit as the “AnyCPU” executable ran as 64-bit on that system, thus the performance was the same as if not compiled.  But it wasn’t any for the worse!  So the bottom line is that capturing the native image and redistributing might make things better and don’t seem to make things worse.

But it turns out that we don’t often capture native images in our App-V packages.  I recently added support to the AppV_Manage Analyzer (version 3.8) to detect the number of modules in the Global Assembly Caches and the Native Image caches.  An example display is shown below:

AppV_Manage Analyzer showing a package containing a Native Image

Why don’t typically we capture Native Images in our App-V packages?

There at least a couple of reasons:

  1. The installer didn’t request the compilation. Depending on the installer, this may require the addition of a custom action.
  2. The installer requested asynchronous compilation.  This makes the installer seem faster, but unless you let the sequencer sit around a while after the installation is complete it won’t happen in time.  Pretty much, unless you are interrupted or go get some coffee or a smoke, the compilation won’t happen in time before you end monitoring.

So I was thinking that I’d like to force the compilation.  Either case can be handled by using ngen.exe which comes with the framework.  You might have two copies, one for v2 and one for v4.  When in doubt, use the v4 copy (it handles .Net 2 apps also).  To solve the second issue, you only need to run the command:

C:\Windows\Microsoft.Net\Framework\v4.0.30319\ngen.exe ExecuteQueuedItems

On a 64-bit system, you should also run the command in the Framework64 folder.

To solve the first issue, you identify the major exe programs and run:

C:\Windows\Microsoft.Net\Framework\v4.0.30319\ngen.exe Install "C:\...pathto...exe"

If you compile the exe, it automatically compiles the dependent dlls, so typically you do not need to compile the dll files directly.  Do these things while in monitoring mode, and the global and native image caches are automatically captured.

But does it do any good to do this in your packages?

Unfortunately, NO.

Currently (as of App-V 5.0 SP2 with Hotfix 5 on a Windows 7/8.1 system with .Net 4 through 4.5.2), the loader cannot detect the native images that are inside the App-V package. Nothing is broken, it is just that the VFS caches for .Net are not used.  Some simple testing indicates that it is not a timing issue.  There is an undocumented index file which might play a role in this, but I think it is a deeper issue.

Potential Workaround?

In theory, if you had a really badly performing virtual application, you could use a Publish-Package script to force an ngen compilation against the major exe(s).  You would have to create the package using the forced load for the streaming configuration, and then run this script outside of the virtual environment using the ProgramData reference to the exe.  If you had a really horrible app, it might be worth a try.  Keep in mind that you might not be able to have multiple versions of the same app with improved performance with different Native Images if done this way – it depends on the app.

I am reporting this into Microsoft for consideration.  So the story could have a happy ending one day after all.  Maybe.

Addendum

I should mention that while I only tested Microsoft App-V 5.0 SP2 (with Hotfix 5) in preparation of this article, it probably applies to any technology used to virtualize or layer applications.  Ultimately, I believe any filter driver, or user-mode dll injection, that adds application components to the OS will fail to deliver the native components in a way that the OS will use as intended.  This includes other application virtualization tools (like Symantec or VMWare ThinApp), and application layering solutions (like UniDesk, and VMWare AppVolumes, but maybe not FsLogix which should work as is).  At least with App-V I know that we can work around it, but I’m guessing that due to their architectures, some of the others cannot.

 

Don’t let your App-V 5 Reporting Database grow out of control!

Image from Sql Management StudioThe App-V Reporting database for App-V 5 and above is great for monitoring all usage of your virtual applications.  This is quite helpful when it comes to license compliance.  While it won’t prevent (accidental) usage of unlicensed apps, it is very useful for detecting usage as part of a program to “true up” your license allocations.

The Reporting Server is independent of how you deploy the virtual apps.  It doesn’t matter whether you use the App-V Server System Center Configuration Manager, or deploy using the stand-alone client.  You can still use the reporting server.

If you do, I highly recommend that you use the App-V Client GPO to configure the clients to use the reporting server.  Setting this as an enforceable policy makes sure that every client will report in usage data each night.  Only with non-persistent clients (like some VDI clients or PVS booted XenApp servers) is there a concern of not getting the data, but those can be solved by adding a report sync to the user logoff scripts using the App-V Client Powershell API.

There is always a but…

But this blog post is to warn you about a small flaw in the App-V Reporting Database setup.  By default, it will not clean out old data.  EVER!  I am not referring to the temporary table data (removed when records get consolidated each night), but the record data on each and every virtual application run by a user. The App-V 4.* server would automatically clean this out at some point.  But not version 5. While Microsoft added logic in the form of stored procedures to clean old data out, it isn’t used by default.

The stored procedure, spEnforceSizeLimit, is designed to check the size of the current database and compare it to a configurable maximum size. There are also two additional configured settings, a low water mark and high water mark.  These are stored as percentage factors and are interpreted as relative to the configurable max size. So the current value can be in one of thee states against these settings:

  1.  If the current size of the database is below the low water mark it decides that things are OK. If logs a WARNING message to the Sql database log (“WARNING The database size limit cannot be enforced“)  and exits. I guess it is a warning that maybe you aren’t collecting any data and maybe you should check on that.
  2. When above the low water mark and below the high mark , it will seek to purge the oldest application usage data.  The logic is simple (much simpler than the extensive logic used in the original App-V server) but sufficient.  It will take a ratio of the current size to that of the low water mark, look at the date of the record about that far into the usage table (when sorted by date) and remove anything older than that date.  It adds a message to the Sql database log (“WARNING: The database size limit has been enforced“).  This message is a good thing and indicates that the purging is working.
  3. When above the high water mark, it logs a different message to the Sql database log (“WARNING: The database is cleaning up a large percentage of data“), and then processes just as in the previous case.

So here are the two problems in the default install preventing this purging from working:

  1. It depends on the maximum size, and low and high water marks being present in the SystemOptions table of the database, and these are not set by default, as shown in the image below.Image from Sql Management StudioThis is treated by the stored procedure as an error, however no error message is logged and no purging occurs. This means that the stored procedure will do nothing when called of there isn’t a row in this table.
  2. There is nothing that triggers the stored procedure to run anyway.Image from Sql Management Studio
    The image above shows the default jobs in the database, one to handle the daily processing of received client reports, and the other a standard database job. No job to run the cleanup script though.

And I wouldn’t be writing this if there wasn’t a solution…

To solve these issues and ensure that your database doesn’t infinitely grow (well, or until your DBA notices), the DBA should do the following:

  1. Ensure that Sql Server Agent is running on the database server.  (If it isn’t, the stored procedure to process the client data from the temporary tables isn’t being triggered to run and you won’t get reporting data anyway).
  2. Add a row to the empty SystemOptions table.  Set the max_db_size column with a value for the maximum database size in Megabytes.  Each record in the Application Usage table takes around 200bytes of storage.  Multiply that by the number of users, then by the number of average app launches per day, then by the number of days of data you want to keep.  Then add some overhead for the temporary and other tables (maybe 50MB?) and spare capacity and you have your setting for the maximum size.  Set the low and high water percentage mark appropriately, but be aware that in spite of the name they are really factors, so 0.80 and 0.90 might be good numbers.  Make sure to monitor the logs after a while.  The warnings I mentioned provide details on the numbers calculated to help you adjust these settings.
  3. Add a SQL job to run that calls the spEnforceSizeLimit stored procedure.   There is already a job to call the spProcessClientReport stored procedure once a day, so mimic that job.
  4. Play the logic game on when things happen, and possibly adjust timers.
    • The App-V GPO schedules the reports to be uploaded, typically once a day at night.  The upload from a client is fairly quick, but there is a configured random delay when the scheduled time occurs.  If the random delay is 30 minutes, then an hour after the scheduled time is plenty of time for this to complete. This should  be allowed to complete before the spProcessClientReport is scheduled.
    • The job for spProcessClientReport should be scheduled next.  The amount of time for this job depends on the number of users*applaunches for the day.   But if you assumed that it can complete in an hour you would be safe.
    • Finally, the spEnforceSizeLimit should be scheduled last.  It won’t hurt anything if it runs while either of the other two activities are happening, but it makes sense to make this last.

Now I’m pretty certain that your DBA does not follow my blog, so if you are the App-V guy and are reading this, pass it on to him or her.

App-V 5 Management Server DB on Remote Machine Configuration

Well here was a wasted hour trying to figure this one out.  It should have been so easy!

Problem: Installed a lab App-V 5 Management/Publishing Server with default instance database on that server.  Works great.  Install second Management/Publishing server needing to use the remote database.  Fails.

What could have been the problem: (but wasn’t)

  • Windows Firewall on first server with the database.  You need port 1433 open.
  • Need to give machine account for new server permissions on the database.
  • Name resolution, need to use fully qualified names, etc.
  • User login account (used the same domain admin account on both servers).
  • Remembering to reset the Management Service (iisreset) after making any change to the configuration.

What could not have been the problem: (but needed to be done anyway):

  • Using the first Management Server, add the Second server into the list of authorized publishing servers. (This only affects the rights of the publishing server to talk to the management server).

Bold face verification of things that were not the problem:

  • Ping the database server by name.
  • Install Sql Management tools on new server and connect and successfully query the database.

Actual Problem: The settings in the Windows Registry HKLM\SOFTWARE\Microsoft\App-V\Server\ManagementService were incorrect.  Furthermore, http://social.technet.microsoft.com/wiki/contents/articles/18457.app-v-5-0-sp1-change-sql-server-name-sql-instance-name-database-name-or-services-port-number.aspx was misleading me for some reason.

That post suggests the following values (where {name} is something you substitute with the real values):

Registry Name Registry Value
MANAGEMENT_DB_NAME {NameOfDb}
MANAGEMENT_DB_SQL_INSTANCE {InstanceName}
MANAGEMENT_DB_SQL_SERVER {DbServer\InstanceName}
MANAGEMENT_DB_SQL_SERVER_NAME {DbServer}

In my case, using the default instance database server with the default database name on the remote server, this seemed to indicate I should use this:

Registry Name Registry Value
MANAGEMENT_DB_NAME AppVManagement
MANAGEMENT_DB_SQL_INSTANCE MSSQLSERVER
MANAGEMENT_DB_SQL_SERVER Av5Svr1\MSSQLSERVER
MANAGEMENT_DB_SQL_SERVER_NAME Av5Svr1

This did not work! Swapping in the fully qualified server names or even IP address was no help. Trying MSSQLSERVER$ did not help.

Viewing the working server, the values look like this:

Registry Name Registry Value
MANAGEMENT_DB_NAME AppVManagement
MANAGEMENT_DB_SQL_INSTANCE
MANAGEMENT_DB_SQL_SERVER .
MANAGEMENT_DB_SQL_SERVER_NAME

For these values to work, it seems that:

  • MANAGEMENT_DB_NAME must default to the default instance when not specified.
  • MANAGEMENT_DB_SQL_INSTANCE of “.” (a period character) specifies the local server (the period) and lacking a specified instance uses the default instance there.
  • MANAGEMENT_DB_SQL_INSTANCE must default to the local server when not specified.

So I tried the following:

Registry Name Registry Value
MANAGEMENT_DB_NAME AppVManagement
MANAGEMENT_DB_SQL_INSTANCE
MANAGEMENT_DB_SQL_SERVER Av5Svr1
MANAGEMENT_DB_SQL_SERVER_NAME Av5Svr1

This worked!

PS: Some good links: