Archive

Posts Tagged ‘app-v’

On Debugging Virtual Applications Part 4: The Case of the Missing Dump

September 27, 2016 Leave a comment

I’ve been blogging lately (well . . . not exactly lately) about debugging virtual applications that misbehave – whether by hanging, crashing, or spewing some strange error message. In discussing the use of tools, one question I often get is the relationship of attaching the debuggers to the virtual application inside or outside the virtual environment. With App-V 5, it only matters in certain circumstances at the user mode level as virtualized applications work from a state-separated registry and file system that leverage the native file system and registry.

When a developer is troubleshooting a virtual application that they have developed, or an IT Pro Debugger is attempting to reverse engineer an application issue, I usually recommend they attach to the virtual process as they would any other application at first. You may decide due to necessity or preference to attach a debugger or a tool to the virtual application process within the context of the virtual environment by launching it in the application’s “bubble.” You may want to be advised that once you do this, the debugging tool will also be running virtually and will behave accordingly.

I bring this up due to an interesting issue that was encountered by one of our partners a while back: There was an issue with a plug-in to Internet Explorer causing it to hang shortly after the BHO had been triggered while running in standard isolation (i.e. no Dynamic Virtualization involved.) Given that the individual had developed the code for the plug-in, they wanted to capture a full user mode memory dump of the instance of Internet Explorer that was running virtually. The issue could not be reproduced in the developer’s environment so there was the usual suspicion of something environmental being a factor. Since standard WER (Windows Error Reporting) is somewhat limited by default, the customer was leveraging ProcDump -h to capture a user mode memory dump of the IEXPLORE.EXE process.

Here’s the thing: while Procdump appeared to attach to and generate a dump successfully, there were no dumps to be found per the developer. Upon further inquiry, I found that the developer was doing the following:

  1. Using C: as a target. This is not good on many levels.
  2. Running ProcDump from a command prompt in the application’s (IEXPLORE.EXE) virtual environment.

While running it in the bubble was not necessarily a bad thing, I had the developer simply redirect the output to %TEMP% instead of C:. The dumps showed up as normal. When asked why C: mattered, I told him that due to coupling factors (specifying an unexcluded folder, VFS Write mode, running as an administrator, and launching in the bubble, the dump file was treated as application state data and was redirected to the VFS CoW location. Upon a quick demonstration, it was discovered buried beneath the user’s VFS folder.

 

164

 

 

I should note that there shouldn’t be any concern with regards to the usability of these redirected dumps. I will also note that upon repairing the App-V package in questions, the user freed up around 12GB of disk space. I guess they had been trying the ProcDump command quite a bit. J

 

Advertisements

On Debugging Virtual Applications: Part 3 – Situations where a Debugger is most needed for Virtual Applications

February 23, 2016 1 comment

In parts 1 and 2 of this series, I’ve covered some of the basic fundamentals of the concept of debugging compiled software code which, for the most part, has been a black box for many working with virtual applications. In part 3, I would like to now move the discussion towards those situations that warrant further debugging analysis. Note that for this topic, I will be limiting the scope to specifically user mode applications as application virtualization products like App-V are pretty much limited to these.

Native Code vs. Managed Code

Managed Code refers to computer source code that will only executive under the management of a special runtime module. Technically managed code refers to any code that requires a specific run-time but even native code may be dependent on underlying libraries contained within middleware (i.e. VC runtimes, java.) Microsoft coined the term “Managed Code” to describe code that requires the .NET Common Language Runtime (CLR.) It is written in .NET languages such as C# or Visual Basic .NET. Managed code’s memory, reference counting, and garbage collection is done by the underlying run-time – hence the term managed.

Native code refers to the classic Windows code that has been written in C, C++, Visual basic, and others in rare cases. While native code can easily be debugged through classic debuggers, managed code requires additional extensions. Native code is compiled to work directly with the underlying operating system while managed code is precompiled and then processed by the JIT (Just-in-time) .NET compiler and converted to native code at run-time allowing for greater portability. Native code was actually compiled for the operating system and hardware architecture. Porting this code to other architectures requires re-compiling.

Situation 1: Application Crashes

When an application crashes, it stops – immediately. Data is lost. It’s dead. It usually happens because the application has an encountered an unexpected exception and the potential for the exception has not been anticipated therefore the exception is not able to be properly handled within the application. Because of this, a special program within the operating system must deal with the aftermath. How the crash is intercepted and handled will depend on specific configurations within the operating system. How much data (active memory snapshots) that are actually saved for diagnostics also varies on how things are configured. Whether the module is native code or managed code will also potentially affect how it is handled.

Native Code Unexpected ErrorsExceptions

Depending on the operating system, when a normal application crashes, you will be interrupted with a dialog telling you that the application has stopped working and will be closed. Older users of windows may recognize the older 16-bit Windows blue screen that stated this. In recent versions of Windows (Windows Vista) and later WER (Windows Error Reporting) kicks in and cleans up the virtual address space and makes a record of the information even collecting a basic mini-dump. You will see a message like the one below.


WER is the modern version of an older program which would collect basic diagnostic data and a mini-dump. This program was called Dr. Watson and has been around since the dawn of Windows. WER takes this a step further and can report the crash to Microsoft. This is especially helpful if the program crashing is a Microsoft application. Other ISV’s often incorporate JIT’s (just-in-Time) debuggers to collect information for their diagnostic purposes as well.

Developers, Support Technicians, and Diagnostic Engineers will often register an alternative JIT debugger to intercept an application crash. Often times this is so they can do live debugging, or substitute their preferred collection tool for collecting user mode dump files for further debugging. For example, if you have either Windows Debugger (WINDBG) installed or Visual Studio, you will see this instead:

 

Note that in the above example, the debugger is able to intercept at the exception point (just in time) so there could even be further live/step-through debugging done.

The Windows Error Reporting model (https://msdn.microsoft.com/en-us/library/windows/desktop/bb513641(v=vs.85).aspx) is really a newer generation of what was formerly Dr. Waston in that it integrates with Microsoft for diagnostic and troubleshooting telemetry data called Software Quality Management (or SQM) data. WER defaults to collect SQM data and minidumps, but can easily be managed centrally, especially through GPOs. By default, minimal data is collected in the realm of user mode dumps and the dump files go into a special queue for upload to microsoft or potential another central repository.

 

You can configure WER to generate bigger dumps that can be more useful when debugging application crashes. You must provide some additional configuration to WER. Since I usually use this as a temporary measure (where I cannot install additional tools) I usually remove these once I have the data that I need.

First, create a folder where the dumps will be stored out of band from the WER queue (i.e. C:dumps.) Then import the below text as a .reg file:

Windows Registry Editor Version 5.00

 [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumps]

"DumpFolder"=hex(2):63,00,3a,00,5c,00,64,00,75,00,6d,00,70,00,73,00,00,00

"DumpCount"=dword:0000000a

"DumpType"=dword:00000002

Alternatively, you could also batch this out as well:

mkdir C:Dumps

reg add "HKLMSOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumps" /f

reg add "HKLMSOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumps" /v DumpType /t REG_DWORD /d 2 /f

reg add "HKLMSOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumps" /v DumpCount /t REG_DWORD /d 100 /f

reg add "HKLMSOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumps" /v DumpFolder /t REG_EXPAND_SZ /d C:Dumps /f


Double-click the .reg file to import it into the registry. If you wish to change the path where dumps are stored, you can edit the following key to reflect the preferred location:   

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumpsDumpFolder

Even when I use the above, I still have trouble collecting good dumps when dealing with virtual application crashes. Not to mention, in my case I often have Visual Studio and the Windows Debugger installed together. I prefer (and strongly) recommend that you use the Sysinternals tool PROCUMP (https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx) to intercept application crashes to collect dumps for post-mortem debugging.

One great feature of ProcDump is that you can also configure it to override WER (and other debuggers) as the default debugger by registering it with the JIT Application Exception Debugger key (AEDebug) and also control where the user mode dumps are stored. Once that happens, you will then see ProcDump intercept and collect dumps by default when application crashes occur.

 

Managed Code Unhandled Exceptions

For .NET applications that encounter unhandled exceptions within managed code, you get a different experience. The runtime incorporates elements for this very type of thing giving the user a different option than what they would normally get with WER or the alternative registered with AEDebug.

 

Exception Handling

Since we have discussed the fact that many application crashes come from unhandled exceptions – often access violations or what it used to referred to – GP faults – let’s discuss actual exception handling and why it is important. Exception handling is literally what it means, a method through code of anticipating and controlling how these exceptions will be handled through special processes or something relatively easy to track (often through interface messages and/or logging.) One of the many reasons we have WER (and historically Dr. Watson) in Windows was to ensure that the operating system would have a last resort method of handling these issues. Every exception cannot be caught with programming and often, the usefulness of how it is handled will vary from developer to developer. 🙂

In early Windows, primarily the early days of Win32, one of the touted features was the capability of being able to leverage SHE (Structured Exception handling) in the Win32 API. I first read and learned about SEH again, from master Matt Pietrick back in the NT 4 days reading MSJ (the earlier version of MSDN magazine. To my excitement and amazement, the article is STLL available online and worth a read to this day (https://www.microsoft.com/msj/0197/Exception/Exception.aspx.) Exception handling leverages trap and try/catch statements in most programming languages. Here is an implementation in its simplest form using native code (C++)

 

               __try

               {

                              *lpstr = '';         

               }

               __except (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ?

                                                            EXCEPTION_EXECUTE_HANDLER :

                                                            EXCEPTION_CONTINUE_SEARCH)

               {

               MessageBox(NULL,"EXCEPTION_ACCESS_VIOLATION","CRAPPYAPP.EXE",MB_OK);

               g.fHandledViolation = FALSE;                     

               }

 

This exception would yield the following message but still allow the program to continue.

 

 

How exception levels differ

Whether the exception comes in the form of a popup window or is just simply logged into a file or to ETW, it is up to the programmer to ensure this. It is also up to the developer as to the level of information that will be collected. To use a managed code example, the following exception handler will sufficiently catch the exception:

 

            try

            {

                 .

                 .

                  .

            }

            catch (Exception e)

            {

                Console.WriteLine("ERROR: Unexpected error.");

                Console.WriteLine("DETAILS: {0}", e.Message);

                return 3;

            }

 

But the example below would serve even better as it would give more diagnostic information for troubleshooting:

 

       try

            {

                .

                .

                .

            }

            catch (Exception e)

            {

                Console.WriteLine("ERROR: Unexpected error.");

                Console.WriteLine("EXECPTION TYPE: {0}", e.GetType().Name);

                Console.WriteLine("DETAILS: {0}", e.Message);

                Console.WriteLine("STACKTRACE: {0}", e.StackTrace);

                return 3;

            }

 

This will log more detailed information including a trace of the current thread stack. Not sure what “Stack Trace” means? Do not worry, that will be covered in a later post.

 

Situation 2: Hangs

When an application hangs, you can break into the process using a debugger or you can use a debugging utility to save the existing data in memory into a dump file for post-mortem analysis. Windows has a similar mechanism for user mode hangs as it does for application crashes using WER. With WER, you are often given options to either wait, close the program and destroy the hung memory space, or capture a small dump and upload it to Microsoft to see if it is possibly a known issue with even perhaps a known solution.

 

In the case of virtual application, the data collected can often be unreliable so in place of using WER, I will use WinDBG or ProcDump to collect a hang dump for further analysis.

 

Situation 3: Heap Corruption

Another type of issue that can happen often with virtual applications is Heap Corruption. The Process heap is a special section of usable memory that is initially created when a process is created. The size is determined the linking portion of the compiler. Subsequent heaps may be created allocated, deallocated, and destroyed throughout the life of a process. With managed code, the heap is managed by the runtime (.NET CLR) to allocate objects and to provide its memory services like for example the Garbage Collector.

 

Heap corruption usually occurs when a process allocates a block of heap memory of a given size and then a thread writes to and/or frees memory addresses beyond the requested size of the heap block. Heap corruption can also occur when a process writes to block of memory that has already been freed.  Sometimes it is pretty obvious and the debugger is able to quickly assess it

0xc0000374 – A heap has been corrupted.

Usually during a heap API operation on the thread stack:

 

77b888c8 77b15c49 ntdll!RtlpFreeHeap+0x59c49

77b888cc 77abb4c8 ntdll!RtlFreeHeap+0x268

77b888d0 76eecb60 kernelbase!GlobalFree+0xc0

77b888d4 7796cd18 kernel32!GlobalFreeStub+0x28

77b888d8 000a1871 shttyapp!CorruptDatHeap+0xd1

77b888dc 000a2525 shttyapp!WndProc+0x345

77b888e0 777d84f3 user32!_InternalCallWinProc+0x2b

77b888e4 777b6c40 user32!UserCallWinProcCheckWow+0x1f0

77b888e8 777b6541 user32!DispatchMessageWorker+0x231

77b888ec 777d6f30 user32!DispatchMessageA+0x10

77b888f0 000a1242 shttyapp!WinMain+0x152

77b888f4 000a2c19 shttyapp!__tmainCRTStartup+0x11a

77b888f8 779638f4 kernel32!BaseThreadInitThunk+0x24

77b888fc 77ae5e13 ntdll!__RtlUserThreadStart+0x2f

77b88900 77ae5dde ntdll!_RtlUserThreadStart+0x1b

 

Most of the time, you have to incorporate more specific tools to track it down. Speaking of that:

 

Next up: more on the tools!

App-V: On Current Recommended Practices and how they Evolve . . . (a.k.a. – about that PVAD)

February 16, 2016 2 comments

This morning, I was on a joint webinar with Flexera (http://learn.flexerasoftware.com/AR-WBNR-Microsoft-AppV-Best-Practices) on App-V best practices and I reminded many on the call why I always prefer to use the term "current recommended practices" as opposed to "best practices." Today I explained that I know longer insist on avoiding the use of the PVAD (Primary Virtual Application Directory) and sticking to strictly VFS sequences. True, I did make this recommendation nearly a year and a half ago (http://blogs.technet.com/b/gladiatormsft/archive/2014/08/25/app-v-5-installing-to-the-pvad-don-t-do-it-yes-i-said-it.aspx ) however, at the time, App-V 5.0 Service Pack 2 required VFS sequencing to ensure connection group convergence as well as a few others mentioned in the blog post. With the addition of the merged roots feature as well as the correction of issues with the convergence of environment variables, there is no longer any major reason to force packages to VFS sequences for the purposes of making connection groups work.

Some Applications Need the PVAD for Proper Functionality

As App-V 5.0 SP3 was released over a year ago and App-V 5.1 was released a few months back, it has become known that due to issues with pathing limits and other issues related to the App-V VFS subsystem and its native NTFS integration, there are some applications which still require the use of the PVAD. By this, I mean to actually expose the Primary Virtual Application Directory (PVAD) within the App-V sequencer and selecting that same directory during the installation of the application during the monitoring phase of the sequencer. You will find many examples of applications within the App-V community. While the number of applications requiring the use of the PVAD is a relatively small percentage, the applications that are affected represent a significant footprint that involve nearly every major enterprise organization's application library. For example, Office 2010 is one of those applications. In fact, if you were to look at the virtual file system structure of the App-V package generated by the ODT (Office Deployment Tool) you would also find that the flattened Office 2013 and Office 2016 packages are actually PVAD sequences.

Categories: Uncategorized Tags: , , , , ,

App-V: Current Recommended Practices for using App-V with Azure RemoteApp

February 12, 2016 Leave a comment

In recent blogs posts, I’ve been discussing the topics of how to leverage App-V for software delivery and management to custom Azure RemoteApp images joined to a hybrid collection. I’ve discussed what is supported and demonstrated a few walk-throughs regarding image setup and targeting. While there are many particular variances for each facet of configuration, I would like to shed some light on some recommended practices that we have found in the early stages of testing and implementing these scenarios.

Isolate ARA App-V Publishing Servers to ARA OU

Azure RemoteApp is a PaaS (Platform as a Solution) in the Azure cloud for non-persistent session-based applications. Like any other implementation of non-persistent session and VDI solutions, there will be provisioning and de-provisioning of Azure VMs depending on the amount of connected users combined with the particular subscription plan. Since the collection number will vary in size (as well as potential App-V client configuration changes) it is recommended that you create a specific OU (organizational unit) for the ARA images as it will allow you to control targeting and configuration more easily through GPO (Group Policy Objects) and GPP (Group Policy Preferences.)

When Possible, Leverage GPO’s for App-V Client Configuration

The App-V 5.1 client can have the vast majority of the client configuration controlled and modified through group policy. Controlling images via GPO allows for the extra insurance that newly provisioned ARA images will inherit the same client configuration the existing images also have. Group policy also ensures that changes in Publishing servers or Reporting servers will also properly propagate to the images.

Path Publishing Gives More Flexibility – Path Publishing Requires Integration Path

If the applications are not pre-published within the image, then advanced knowledge of the App-V integrated path to the application executable must be known in advance. This also means package information (Package GUID) must be known prior to targeting.

  • User Paths (%LOCALAPPDATA%MicrosoftAppVClientIntegration<GUID>Root<EXE>)

  • Machine Paths (%SYSTEMDRIVE%ProgramDataMicrosoftAppVClientIntegration<GUID>Root<EXE>)

As with other VDI scenarios, you could consider devising a custom launcher and pre-install that within the image.

Preserve Package Lineage (Sequencing) to Prevent OS Image Updates

One of the primary use cases for App-V streaming with ARA (be it pre-publishing or management server targeting) is the capabilities of streaming package updates for applications. This prevents the need to re-upload custom OS images when the application is updated. In order to take advantage of this feature, it is necessary to preserve the package lineage where the base package GUID always remains constant as packages are updated. In order to do this, you must always open the package for editing or upgrade in the App-V Sequencer as oppose to just simply re-sequencing a new version or “saving as new package.”

Use an App-V Reporting Server with Frequent Agent Upload Intervals

One of the most convenient features of the App-V infrastructure is the capability of configuring the client’s reporting agent to upload application usage data per user to a reporting service. This has been especially helpful for tracking package and application usage history in on-premises non-persistent environments and is just as valuable with Azure RemoteApp. It is recommended to customize reporting configuration on the images via GPO.

Have an RSDH Host in Azure IaaS for Testing Publishing and Targeting prior to ARA deployment

Prior to joining your ARA images to the existing VNET and domain, it is a great idea to have an RSH VM within Azure on the same VNET in order to test publishing and targeting in advance. That way you can confirm things are working right with regard to the entitlement and publishing of applications – especially if the App-V infrastructure is based in Azure IaaS.

 

As mentioned, these are CURRENT recommended practices. As App-V and ARA evolve (and they have,) so may these.

 

App-V: On Targeting Azure RemoteApp Images with the App-V Management & Publishing Server

February 10, 2016 1 comment

There are two types of Collections with Azure RemoteApp: A Cloud Collection and a Hybrid Collection. App-V requires that the client must exist on domain-joined machines in order to be supported. Azure RemoteApp Custom Images can be part of a Hybrid RemoteApp collection where the images are joined to the local domain. This now entails App-V and Azure RemoteApp the possibility of integration with the App-V Management & Publishing Server using a cloud-based or on-premises App-V Infrastructure scenario:

Cloud-based App-V Infrastructure: This is where the App-V Management, Publishing, and Content Sources are based in Azure IaaS (with the content being also available with extended Azure PaaS services as well.) In this scenario the Hybrid Collection must be associated with an existing VNET that also contains the App-V back-end resources. This scenario also requires that the Azure RemoteApp clients and the App-V infrastructure are joined to the same local domain either hosted in Azure IaaS or via the forthcoming Azure AD Domain Services (In preview – https://azure.microsoft.com/en-us/services/active-directory-ds/) The Azure RemoteApp images are pre-configured for the Publishing Server or controlled via GPO (group policy.)

The Cloud-based App-V Infrastructure can easily service both cloud-based resources (RDSH in Azure IaaS, Azure RemoteApp) as well as traditional on-premises clients (via the web, through Site-to-Site VPN’s, or ExpressRoute.)

On-Premises App-V Infrastructure: This is where the App-V Management and Publishing Servers are based in an on-premises network servicing primarily on-premises clients. In this scenario the Hybrid Collection must be associated with a VNET attached and routed to the on-premises App-V infrastructure through a site-to-site VPN or ExpressRoute. The Azure RemoteApp images are joined to the local domain and pointed to the Publishing Servers via pre-configuration or GPO. In this scenario, it is recommended to still leverage Azure-based content sources for content even though streaming over the on-premises connection would be possible – but not recommended.

Walking Through the Process:

For the sake of this conversation, we will assume that an existing App-V 5.1 infrastructure has already been provisioned, be it cloud-based or on-premises. Obviously, before you would start the process of setting up a custom image, you will want to make sure you have this in place.

1.)    Create a custom operating system image that has the App-V RDS 5.1 Client installed –  then import image into Azure RemoteApp. This is an oversimplification of a process that is further outlined in a previous blog post on configuring and preparing an image for use with App-V and Azure RemoteApp: http://blogs.technet.com/b/gladiatormsft/archive/2015/04/29/app-v-on-app-v-applications-hosted-in-azure-remoteapp.aspx.) You can pre-configure the client and even pre-publish some applications prior to upload. I would advise skipping the client pre-configuration and instead, leverage AD GPO’s to configure the client.

2.)    Create an Azure RemoteApp domain-joined (hybrid) collection and leverage the OS image as the template image for the collection. When you go to join the domain, you will want to join the domain to a specific OU (organizational unit) within your local domain. It will be much easier to administer and control the configuration of your ARA images if they are contained within a specific OU. NOTE: This step is massively simplified here in the explanation. More specific ARA information on joining Hybrid Collections can also be found here (https://azure.microsoft.com/en-us/documentation/articles/remoteapp-create-hybrid-deployment/)
 

3.)    The image upload may take a while to provision. Once the image has been provisioned, the status will show as ready.

     

4.)    Once the images have been provisioned, you will start to see computer objects appearing in the OU you specified for the domain join.

      

5.)    At this point you can begin to configure a Group Policy Object and link it to the OU for the ARA images.

      

Within the GPO, you can leverage the ADMX templates for App-V via the MDOP ADMX template download package (available here: https://www.microsoft.com/en-us/download/details.aspx?id=41183) to control the App-V 5 client settings including App-V Publishing server targets, shared content store mode, scripting configuration, etc.

6.)    Now the interesting part begins: The App-V management console allows you to target packages to user AD (Active Directory) groups or machine AD groups.  When it comes to targeting groups, GPO’s only allow you to control local group membership. As a result, the targeting options available for machine groups that affect ARA machines is pretty much the Domain Computers Group. However, if you wanted to target the ARA images for machine groups (global publishing) you can effectively use the Domain Computers group coupled with the OU configuration for the specialized publishing server. User Targeting is a more flexible option as there are no restrictions with regards to the non-persistent provisioning of the ARA images.

   

In this example, I have targeted both the Domain Computers machine group as well as a custom user group within the App-V Management Console.

   

7.)    Publish App-V apps in ARA (using path option or pre-published discovery.) Within ARA, you can publish applications by querying the Start Menu of the image or by using Path Publishing. App-V applications will not show up via a Start Menu query unless they have been pre-published globally in the image. For this reason, it is better recommended to Path Publish the App-V applications. This requires juuuuuuust a bit of a workaround. If you plan on publishing an App-V application by path, you will need to be able to know the actual integration path to the executable in advance.

For machine-targeted (globally published) packages, they will begin with:

%SYSTEMDRIVE%ProgramDataMicrosoftApp-VClientIntegration<Package_GUID>Root

For user targeted (user published) packages, they will begin with:

%LOCALAPPDATA%MicrosoftApp-VClientIntegration<Package_GUID>Root

If you do not know the package GUID from sequencing, you can easily retrieve it from the package details within the App-V management console.

Any additional path information beyond the root folder must also be obtained in order to complete the path. Since the APPV format is a ZIP format, you can easily view this information within the APPV package file itself.


8.)    Once you have this information, you can proceed to publish the App-V applications n the Azure RemoteApp publishing console.

  

9.)    Upon logon using the ARA RDP client, you should then see your App-V applications appearing just like any other normal application.

      

App-V: More on App-V with Azure RemoteApp

February 9, 2016 Leave a comment

Last April, we gave a little bit of information on the limited use of App-V applications with Azure RemoteApp (http://blogs.technet.com/b/gladiatormsft/archive/2015/04/29/app-v-on-app-v-applications-hosted-in-azure-remoteapp.aspx.) This piqued the curiosity of many and over the past several months, we have been validating several scenarios involving the integration of App-V with Azure RemoteApp images within hybrid collections. 

As you might have heard, Eric Orman – the Program Manager for Azure RemoteApp, announced at Ignite Australia that App-V *IS* supported with Azure RemoteApp within specific scopes. (https://channel9.msdn.com/Events/Ignite/Australia-2015/WIN336.)   This is a significant development for companies that want more options for bringing their desktop applications to Azure as well as the birth of another chapter in the story of App-V in Azure. In the three months since that announcement, one of the most common question I have been getting is “Why? How is this significant?”

Why App-V for Azure RemoteApp?

I would say the three most important aspects about being able to use App-V with Azure RemoteApp are the following:

Keeps Custom Images Thin: Custom Images with Azure Remote App have to remain beneath the 127GB maximum for VHDs. In addition, the more applications pre-installed to ARA images translates to a longer upload time. Customers embracing App-V will have the ability to quickly bake an image for upload with minimal pre-publishing (or NO pre-publishing if leveraging path publishing the with the App-V Publishing Server or Configuration Manager.) In addition, App-V clients baked into Azure RemoteApp images can have those applications stream to memory using the App-V Shared Content Store rather than to disk also preserving permanent storage consumption on the ARA images. It is important to note that Premium Plus subscriptions coupled with a high-end storage back end (Azure Files) would be recommended for Shared Content Store use in ARA.

Allows for Streamed Application Updates: When a company decides they would like to move a LOB application to the Azure cloud using ARA, it involves an image upload. Periodically, the application may require maintenance and patching. Without a demand technology such as App-V, this would require re-uploading and re-provisioning of ARA images. With App-V, applications that have been sequenced for streaming can be dynamically updated to the ARA images without the need to re-upload any new custom images.

On-Premises, Azure IaaS, and Azure RemoteApp resources can share application Content Sources: If your organization is currently leveraging App-V and streaming content from content stores – be it on-premises or in Azure IaaS, these same resources can also be leveraged by your ARA-provisioned images as well.

Scenarios for App-V with Azure Remote App

When designing a strategy for delivering App-V applications with Azure RemoteApp, you will pretty much follow along the same lines as you would when you are designing App-V for any other target. The exceptions in the world of App-V involve the current existing gaps between the App-V IaaS (Infrastructure as a Service) and the Azure RemoteApp PaaS (Platform as a Service.)

The following table outlines the pros and cons of the different options for App-V delivery, application storage, and publishing and targeting with Azure Remote App:

 

Configuration options

Pros

Cons

Delivery method

Streaming (on demand from content server)

Application is always the latest and fresh

Possible first time latency upon initial application launch

Mounted (Pre-cached into the ARA image.)

Fastest 1st launch – all of the application assets are already present on the ARA virtual machine.

Potential Image Bloat – applications take up additional image space (remember the 127gb limit)

Primary Application location storage

Shared Content (Stream-to-memory)

App runs in memory of Azure RemoteApp instance

Eats memory and requires good connection to streaming (file) server where the app resides. Affects baseline.

Disk (Cached)

  • Fast execution
  • App not dependent on availability of Content Source

Bloat – takes up image space (127gb limit)

Targeting

User*

*Requires full standalone App-V infrastructure or Configuration Manager 2012 R2 or later

Global (machine)

Pre-publish or target using Publishing server

  • Need to update your Azure image if you want to update the app.  (huge)
  • Takes up some space on image

* In addition, User targeting also requires that the App-V application be pre-published via a path Publishing rule for the Azure RemoteApp collection.

 

More to come . . . 🙂

Anatomy of an Outlier Bug: The Issue of the Failed App-V Report Upload

January 24, 2016 2 comments

When software malfunctions, product support teams attempt to narrow the issue down to user error, configuration, or code. If the software attempts to perform a function where a specific result is expected and the actual results are different, we classify that as a bug. Of course, there is great debate on what is perceived as a bug, or is simply “by design” meaning the software was doing exactly what it was programmed to do – it just may be completely different from what the end user expected.

Let’s assume we are not having the “by design” vs. “bug” debate. When a bug confirmed, the next common item that is measured is the impact of that bug – impact within the specific customer’s environment, the frequency and likelihood of the bug occurrence. Bugs that have only occurred one or two times where the impact is minimal is usually referred to as an “outlier bug.”

Outlier bugs can be tricky – especially if there is not a known workaround. Software vendors have to weigh the risk and cost of implementing bug fixes via current version patches (as opposed to correcting the code for the next release.)

A while back I encountered one of those outlier bugs in which this bug only affected one customer (at the time) and it only revolved around one specific App-V package. It involved the App-V Client Reporting Agent failing to upload reporting XML data. The following issue was occurring.

Client machines were failing to upload reporting data. Upon a manual test using the Send-AppVClientReport cmdlet, it would yield the following error:

 

PS C:Windowssystem32> Send-AppvClientReport

Send-AppvClientReport : No reporting data has been sent to the specified URL. Verify the URL and try again.

Operation attempted: Send reporting data to reporting server.

AppV Error Code: 1300000013.

Please consult AppV Client Event Log for more details.

At line:1 char:1

+ Send-AppvClientReport

+ ~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidResult: (:) [Send-AppvClientReport], ClientException

    + FullyQualifiedErrorId : SendReportError,Microsoft.AppV.AppvClientPowerShell.SendAppvClientReport

==============

This issue was NOT occurring on all of the clients, so the first major step was to find the common denominator. Eventually we found the common denominator was a specific package. In addition, we actually got quite lucky. In many cases, the machines getting this issue only had one specific package deployed to them.

So we grabbed the XML file (C:ProgramDataMicrosoftAppVClientReportingdd6c24e-be93-48f7-b531-4eaa007128ec.xml) to view the Reporting cache and eventually narrowed it down to only occurring when the specific application was published.

What makes this issue an outlier is that the element that was causing the issue involved a package where the primary application had a version field that was greater than 16 characters. On a lark, we started modifying the XML data manually and found that if the reporting XML file was manually edited, and enough digits were removed from the version field, the upload worked. For some reason, only 16 characters were allowed in the version field. All of the fields were supposed to allow for 32.

Once root cause was narrowed down, the time came to assess the impact of the bug. It was definitely viewed as an outlier bug due to the fact there was only one known occurrence (again – at the time.) The assessment of how likely this would reoccur soon became a moot point as the good news here as the issue was within the database itself. The App-V 5 reporting service is stateless and writes directly to the temporary tables in the AppVReporting database. So we were able to fix the issue for the customer without cracking open binaries for patching.

If you are interested in the database script, it was published out on the TechNet Gallery here:

https://gallery.technet.microsoft.com/App-V-5-Fix-for-App-V-f8c1ac29

This fix was included in the App-V 5.1 release.