App-V 5 – How App-V 5 Handles Software Clients, Application Capabilities, and URL Protocol Handlers

App-V 5 brought a lot more options for integrating virtual applications with the local operating system. This is a big win for those organizations wanting to move as many of their applications as possible over to the APPV package format. These Extension Points can be defined within the App-V package manifest (if detected during sequencing) or applied through dynamic configuration. Extension points such as Shortcuts and FTAs (file type associations) as well as advanced ones such as COM and Environment Variables are well known and are not exactly new to App-V. What I wanted to do was dive into some of the lesser known extension points. Particularly some of those that are new to App-V 5.

Software Clients

Software Clients, often referred to as SPAD clients (for “Set Program Access and Defaults) are documented well in the following MSDN article:

“How to Register an Internet Browser or Email Client with the Windows Start Menu”

http://msdn.microsoft.com/library/windows/desktop/dd203067

The way they work is to basically register as a software client within the registry under HKEY_LOCAL_MACHINESoftwareClients

 

Then the application can show up as an option under the Set Program Access and Computer Defaults in the Control Panel:

Default web browsers, media players, email clients, instant messaging, and other applications can have defaults configured here. This will subsequently help to control other defaults for shell actions such the Right-Click —à Send To à Mail Recipient action.

App-V virtual applications can be used through the Software Client Extension Point to have the following applications configured through the SPAD option in the Windows Control Panel:

• Email

• IM (Instant Messaging)

• Media Players

• Java VM

To clarify – only the above clients are currently supported.

A Software Client registration is defined within the manifest and can be adjusted via dynamic configuration as well. An example below shows the MAPI client extension being registered for Outlook 2013 as a Software Client:

 <SoftwareClients Enabled="true">

        <ClientConfiguration EmailEnabled="true" />

        <Extensions>

          <Extension Category="AppV.SoftwareClient">

            <SoftwareClients>

              <Email MakeDefault=”true”>

                <Name>Microsoft Outlook</Name>

                <Description>Microsoft Outlook</Description>

                <InstallationInformation>

                  <RegistrationCommands>

                    <Reinstall>[{AppVPackageRoot}]Office15OUTLOOK.EXE /spadreinstall</Reinstall>

                    <HideIcons>[{AppVPackageRoot}]Office15OUTLOOK.EXE /spadhideicons</HideIcons>

                    <ShowIcons>[{AppVPackageRoot}]Office15OUTLOOK.EXE /spadshowicons</ShowIcons>

                  </RegistrationCommands>

                  <IconsVisible>1</IconsVisible>

                  <OEMSettings />

                </InstallationInformation>

                <ShellCommands>

                  <ApplicationId>[{AppVPackageRoot}]office15OUTLOOK.EXE</ApplicationId>

                  <Open>"[{AppVPackageRoot}]Office15OUTLOOK.EXE" /recycle</Open>

                </ShellCommands>

                <MAPILibrary>mapi32.dll</MAPILibrary>

                <ExtendedMAPILibrary>[{AppVPackageRoot}]Office15OLMAPI32.DLL</ExtendedMAPILibrary>

                <MailToProtocol>

                  <Description>URL:MailTo Protocol</Description>

                  <EditFlags>2</EditFlags>

                  <DefaultIcon>[{AppVPackageRoot}]Office15OUTLOOK.EXE,-9403</DefaultIcon>

                  <ShellCommands>

                    <ApplicationId>[{AppVPackageRoot}]office15OUTLOOK.EXE</ApplicationId>

                    <Open>"[{AppVPackageRoot}]Office15OUTLOOK.EXE" -c IPM.Note /mailto "%1"</Open>

                  </ShellCommands>

                </MailToProtocol>

              </EMail>

            </SoftwareClients>

          </Extension>

        </Extensions>

      </SoftwareClients>

 

In the example XML above for Outlook, we have four elements that are essential to understanding how this fits into integration as a software client:

<SoftwareClients Enabled="true">

This element turns on the extension subsystem.

 <ClientConfiguration EmailEnabled="true" />

This element turns on integration of the Email clients.

 <EMail MakeDefault="true">

This element does two things – tells the application it is an email software client and makes it the default selected Software Client. Yes, both the E and the M are capitalized. That is not a typo.

<MAPILibrary>mapi32.dll</MAPILibrary>

This element shows the DLL that will be registered.

 

In the example in the picture below, Trillian is registered through dynamic configuration as an Instant Messaging Software Client. Notice it is not enabled as default.

 

Application Capabilities

Do not confuse Software Clients (which are set under SPAD) with Application Capabilities which are set under Default Programs in the Control Panel. With this extension point, applications provide their capabilities to the operating system. The capabilities and mappings are aggregated in the HKLMRegisteredApplications key.

 

 Users can then use these capabilities to set the default programs through the Default Programs interface:

For more information on how this is handled internally, check out the background on MSDN:

http://msdn.microsoft.com/en-us/library/windows/desktop/cc144162(v=vs.85).aspx

One final note on Application Capabilities: Even though these settings are per user as of the release of Windows 8, App-V 5 only supports this extension point for globally published virtual applications.

 

URL Protocol Handlers

The URL Protocol Handler associates a virtual application with a URI protocol. This has always been possible with App-V but the extension point integrations ensures that it gets configured at deployment through the extension point. Rather than associating an application with a specific document type like an FTA, the application is associated with the protocol itself.

The URL Protocol subsystem is based off standards defined for URI registration which is documented here:

http://msdn.microsoft.com/en-us/library/ie/aa767914(v=vs.85).aspx

If the package is user targeted, the URL protocol handler registration will occur under HKCUSoftwareClasses. If the package is machine targeted or globally published, URL protocol handlers will be registered under HKLMSoftwareClasses.

An example of URL Protocol extension point registration is below:

  <URLProtocols Enabled="true">

      <Extensions>

        <Extension Category="AppV.URLProtocol">

          <URLProtocol>

            <Name>FirefoxURL</Name>

            <ApplicationURLProtocol>

              <Description>Firefox URL</Description>

              <DefaultIcon>[{ProgramFilesX86}]Mozilla Firefoxfirefox.exe,1</DefaultIcon>

              <FriendlyTypeName>Firefox URL</FriendlyTypeName>

              <EditFlags>2</EditFlags>

              <ShellCommands>

                <DefaultCommand>open</DefaultCommand>

                <ShellCommand>

                  <ApplicationId>[{ProgramFilesX86}]Mozilla Firefoxfirefox.exe</ApplicationId>

                  <Name>open</Name>

                  <CommandLine>"[{ProgramFilesX86}]Mozilla Firefoxfirefox.exe" -requestPending -osint -url "%1"</CommandLine>

                  <DdeExec>

                    <NoActivateHandler>true</NoActivateHandler>

                    <Application>Firefox</Application>

                    <Topic>WWW_OpenURL</Topic>

                    <DdeCommand>"%1",,0,0,,,,</DdeCommand>

                  </DdeExec>

                </ShellCommand>

              </ShellCommands>

            </ApplicationURLProtocol>

          </URLProtocol>

        </Extension>

      </Extensions>

    </URLProtocols>

 

MED-V: The Case of the Unresponsive Word Window

I recently resolved a long standing issue that affected legacy web applications running inside a MED-V 2.0 workspace. Often web applications will trigger documents and other objects that will launch within their respective host application either through an instance of that application via COM or through a special control via ActiveX (like PDF documents.)

On more than one occasion involving one or more application the parent windowed application (usually a legacy version of Internet Explorer) will trigger an application to launch containing critical data sent to that application by way of the web application. Usually this followed a Java process that would crunch some data and then generate a document object, populate the data and then launch the form from within Microsoft Word. What was happening in every case of this issue was – the Word Window never displayed when running inside a MED-V workspace.

Make sure the problem is not resolved with the super-secret hotfix.

First of all, if you are experiencing the occasional disappearing window, there was an out of band hotfix for the Windows XP RDPShell that addressed disappearing windows. You can call up Microsoft support and request this hotfix by its name (KB2446473.) However, this only addresses a flaw in the RDPShell and did not likely apply in the cases I mentioned above because these problems were not intermittent. They were very consistent and could be reproduced consistently.

Tracking it down . . . 

Running the workspace in full screen mode never exhibited the issue. This issue only occurred when running in the seamless mode of MED-V. Launching a parallel command prompt in the workspace and running tlist.exe revealed that the WINWORD.EXE process was running so the application was not crashing. Killing the MEDVGUEST.EXE process from a command prompt prior to attempting to reproduce the problem caused the issue to go away as well. This led to me down the path of investigating what was really going on. The active Word window was being sent behind the browser window and was not being brought to the foreground for the RAIL mechanism used by MED-V to display the active window. Further debugging revealed LockSetForegroundWindow as a common denominator. Some research into the SetForegroundWindow function (http://msdn.microsoft.com/en-us/library/ms633539(VS.85).aspx)  and/or LockSetForegroundWindow function (http://msdn.microsoft.com/en-us/library/ms633532(VS.85).aspx)  yielded a way to control this.

• HKEY_CURRENT_USER\Control Panel\Desktop
• Value: ForegroundLockTimeout
• Data Type: DWORD

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

If the time required to launch the Word application window is less than the value specified in the ForegroundLockTimeout, the application will be launched behind the Internet Explorer window.

If the time taken to load the Word window is greater than the time set in ForegroundLockTimeout registry key, the window will be launched on top of Internet Explorer. Setting this value inside the workspace to 0 resolved the issue.

While this may likely resolve all instances of this type of problem bear in mind that I also learned that if the base priority of Internet Explorer is higher than the Microsoft Word window, it will still be launched behind the Internet Explorer window to avoid active window focus change.

Free App-V Training from Microsoft Virtual Academy!

There is a wealth of on-demand and live training available at the MVA web site: (www.MicrosoftVirtualAcademy.com)

Now there is free on-demand App-V 5 Training featuring Ron Dockery and yours truly!

http://www.microsoftvirtualacademy.com/training-courses/mdop-application-virtualization-deep-dive

For the IT Pro that is either new to App-V or specifically new to App-V 5, this training should be a good introduction and deep dive into the App-V 5 management and publishing system. I hope you enjoy it and would love to hear suggestions for additional courses (Yes, one with Config Manager integration is likely in the works! 🙂 )

Update: Now available on Channel 9 as well!:

https://channel9.msdn.com/Series/MDOP-App-V-Infrastructure/01&nbsp;
https://channel9.msdn.com/Series/MDOP-App-V-Infrastructure/02
https://channel9.msdn.com/Series/MDOP-App-V-Infrastructure/03
https://channel9.msdn.com/Series/MDOP-App-V-Infrastructure/04

The Role of Server Groups in App-V 4

The Role of Server Groups in App-V 4

Server groups are for configuring a server or server farm to have alternate provider policies, server-centric application management, and/or alternate logging pipelines to databases.

Provider Policies

Provider policies are bound to users and servers by way of server groups. Provider Policies can control client configuration for:

• Publishing/Refresh Intervals
• In prior versions of Softgrid, this also controlled Authentication methods. This has been deprecated in 4.5. Only Windows Authentication is supported
• Type of License enforcement

Some Administrators would rather manage their provider policies by server as opposed to simply user groups, therefore they use this method. After creation of the server group object, an administrator can then associate an alternate provider policy with the server group:

Provider Policies can also toggle application usage on and off. Alternate Pipelines for logs can control excessive database traffic going out on the WAN

 

Application Association and Management

You can also associate applications with a specific server group:

Assigning applications to a specific server group involves configuring the application itself for server group membership. You will then see the application show up under the “Applications” tab in the properties of the server group.

The applications tab is for informational purposes only to determine a quick view of which applications associated with each server group are currently enabled.

Logging

Once you create a server group, you can also use this to control the pipeline for logging. This will require at least one server object to reside in the group. This has to originate as a pre-created server object. You can pre-create a server object by right-clicking the server group and selecting “New Application Virtualization Management Server.”

Once your servers have been configured/installed inside the server group, you can control the log pipeline methodology (although the options are more limited starting with version 4.5 and later. While the “File” option is available in the interface, it no longer works on versions 4.5 and later. The only log type supported is SQL Database.

By default, the destination is the AppVirt Database using the same SQL server that was specified when the database was first created during the installation of the first App-V server. The default event type is “Warnings/Errors.”

Given the potential growth of the MESSAGE_LOG table inside the SQL data store and the additional web traffic it can create, some App-V server administrators will leverage local datastores for logging while using a central App-V datastore for application and overall management control. Each server can then send these messages to that server’s MESSAGE_LOG table.

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

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.

App-V 5: On App-V 4.x to 5.x Token Transitions

Tokenization is essential to application virtualization. This is where traditional directory paths are replaced with tokenized paths to ensure portability and flexibility. While hard-coded paths have not left the world of software development (although it should have more than two decades ago) most modern software is able to install to known paths and shell locations allowing App-V to easily capture and tokenize the paths during sequencing.

Application State and User State are kept portable through the use of App-V Tokens. This allows for the portability of applications across machines where the folders may be relocated to a different folder and/or drive. For example, %APPDATA% may be redirected to another drive or a network path. Another example would be having %ProgramFiles% being redirected to D:Program Files instead of the default on Drive C.

 

App-V 4.x Legacy Tokens

In versions of Softgrid and App-V prior to V5, the token paths were built upon objects leveraged by many API’s that are now deprecated – especially with the end of Windows XP’s life. These CSIDL folders, which are actually referred to as “special folders,” are folder which is presented to the application through an API interface abstracted instead of using the absolute folder path. You may hear these referred to erroneously as shell folders. I try not to use that term because while many of these folders relate to the “shell” not all of them do – as many are tied to the operating system in general regardless of “shell” being used. With that being said, the SHGetFolderPath function was the most common use of these in previous version of Windows:
(http://msdn.microsoft.com/en-us/library/windows/desktop/bb762181(v=vs.85).aspx)  

The CSIDL reference on MSDN is here as well:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494(v=vs.85).aspx

Softgrid and App-V 4.x had to also leverage custom tokens or CSIDL’s not previously defined in Windows for the purpose of abstraction. These were actually prefaced with SFT_ instead of CSIDL.

App-V 5 Tokens

App-V 5 uses two types of tokens as well: Known Folder tokens and Custom Tokens. Known Folder Tokens are tokens that resolve to KnownFolderIDs (instead of the legacy CSDIL) that are defined within the Windows shell:
(http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457(v=vs.85).aspx.) Custom Tokens are ones that have to be specifically defined by App-V 5 and apply only to those applications virtualized within App-V 5.

Known Folder Tokens

App-V 5 uses non-localized names to denote Known Folder tokens. These tokens and the paths they represent are built dynamically when a virtual application runs on a machine for a particular user. Some of these tokens represents system specific paths (i.e., C:Program Files) and others represent user state paths (i.e., C:Users<UserName>AppData). The folders are initially laid down in the immutable package cache using there token names. The actual translation to specific virtual path comes within the virtual environment. In some cases, the tokens have to be defined by bitness so the tokens remain consistent across bitness of platforms. This allows a sequencer running on a 32-bit sequencer to capture tokens that will be compliant – should this package also be ran under a 64-bit client. 64-bitspecific paths/tokens will not be available when the list is built on a 32-bit machine.

A list of Known Folder Tokens are found in the App-V 5 Sequencing guide found here:

http://www.microsoft.com/en-us/download/details.aspx?id=27760 in section 16.2

Each of these tokens are parenthesized with a [{ and }]. For example, [{Local AppData}] reflects the token for the known folder variable %LOCALAPPDATA% which defaults to Known Folder path C:Users<UserName>AppDataLocal

 Custom Tokens

On top of the Known Folder tokens, App-V 5.0 uses custom tokens just as it did with earlier versions of App-V and Softgrid. Older custom tokens, however, have been renamed following the new naming convention. For example, SFT_SYSTEM32_SPOOL is now called AppVSystem32Spool.

Some of the older custom tokens are discontinued as their paths are now covered by Known Folder tokens. For example, the path represented by old custom token SFT_PROFILES_DIR did not have a CSIDL representation so a custom token was created. The path is now represented by the Known Folder token “UserProfiles.” Section 16.2 of the Sequencing document also lists the common custom tokens used by App-V 5.

Package Drive

We have no Q: drive in App-V 5. Previous versions of App-V used the custom token “SFT_MNT” to represent the virtual drive, or rather, default “Q drive”, where during sequencing the user would install the app on Q drive. This allowed having a different drive letter for virtual drive on the client machines from the one on the sequencer machine. Where in older App-V versions it explicitly represented virtual drive, in App-V 5.0, where there is not a virtual drive, it now represents the drive on which the user installed the application.

In App-V 5, we have the PVAD (Primary Virtual Application Directory.) The PVAD (which is laid down in the immutable package cache as Root and abstracted as [{AppVPackageRoot}]. If drive letters or multiple drives are specified and tokenized, the install drive name will be abstracted as “AppVPackageDrive.” For example: the path C:AppNameInstall would be translated to [{AppVPackageDrive}]AppNameInstall

If the application installer lays down files on the installation drive which do not fall under any other Known Folder or custom tokens, these paths are translated from the specific drive on Sequencer machine using “AppVPackageDrive” token.

Keeping Consistent with WoW64 Bitness Virtualization

Certain subdirectories under %windir%/system32 are exempt from Wow64 redirection (see http://msdn.microsoft.com/en-us/library/aa384187(VS.85).aspx.) Access to these subdirectories is not redirected to %windir%SysWOW64. The following custom tokens are used to represent these subdirectories so that they are not tokenized using “System” known folder. This is because 32-bit apps sequenced on 32-bit OS are when deployed on 64-bit OS, “System” known folder token is expanded to %windir%SysWOW64, which will not work for these subdirectories which are exempt from Wow64 redirection.

Custom Token	Custom Token Expansion
AppVSystem32Catroot	C:windowssystem32catroot
AppVSystem32Catroot2	C:windowssystem32catroot2
AppVSystem32DriversEtc	C:windowssystem32driversetc
AppVSystem32Driverstore	C:windowssystem32driverstore
AppVSystem32Logfiles	C:windowssystem32logfiles
AppVSystem32Spool	C:windowssystem32spool

 

 

App-V 5: On Asset Intelligence

Asset Intelligence has been used for years to enhance the inventory capabilities of Microsoft System Center Configuration Manager (SCCM) by extending hardware inventory and adding license management functionality. The Asset Intelligence features of SCCM (2012, 2012 SP1, and 2012 R2) can report application data such as digital PID, MSI product codes, and publisher names for each virtual application registered on a client computer. With App-V 4.6 virtual applications, this was hindered by some limitations including lack of full integration into the SFT package as well as FB1 definitions to be defined for every applications.

App-V 5 improves upon the limitations of SCCM collecting Asset Intelligence data by incorporating Asset Intelligence information into the package.

Captured During Sequencing

Using a special process, the Sequencer will capture Asset Intelligence metadata during the monitor phase. The data is then placed inside the AppXManifest file embedded into the APPV package. This is the only supported time the information can be placed inside the package. In most cases, App-V 5 packages will have asset intelligence unless the application itself specifically does not install that metadata or is an older legacy application without an installer.

 

Manifest Values

The package manifest stores this information under the <AssetIntelligence> element. Additional properties are then specified under the sub-element <AssetIntelligenceProperties>:

<AssetIntelligenceProperties>

     <SoftwareCode/>

     <ProductName/>

     <ProductVersion/>

     <Publisher/>

     <ProductID/>

     <Language/>

     <ChannelCode/>

     <InstallDate/>

     <RegisteredUser/>

     <InstalledLocation/>

     <CM_DSLID/>

     <VersionMajor/>

     <VersionMinor/>

     <ServicePack/>

     <UpgradeCode/>

     <OsComponent/>

     </AssetIntelligenceProperties>

</AssetIntelligence>

Please note that Asset Intelligence data is optional and not required for valid AppV operation for an application. This information is provided for the purposes of inventory with SCCM.

Appearance on Client

The Asset Intelligence marker is attached to the package record in the registry and WMI to inform the AppVHandler in SCCM 2012 SP1 and R2 whether or not the package has asset intelligence.

You can see this when you type Get-AppvClientPackage in PowerShell under the HasAssetIntelligence value.

Why would a package not have Asset Intelligence?

There are a few reasons why an App-V 5 virtual application would not have this information in the manifest:

• Timed out during sequencing: If the AI sequencing collector fails to collect the information within a specific period, it will time out. You can disable this value by adding a DWORD value called DisableTimeout to HKLMSoftwareMicrosoftAppVSequencerAssetIntelligence (Will need to create key by default.) Set this value to 1.

• No attempt to collect: If the element is missing from the manifest, it means that no Asset Intelligence was gathered during sequencing. You will always see this if the package was converted but it also could be tied to an error collecting it on the sequencing workstation.  This means that SCCM will have to manual scan this package as if it were a legacy package by injecting itself into the virtual environment. 

• Attempt was made but failed: If the element exists but is empty, it means that collection was attempted and nothing was gathered. 

 

Chatting All Things Dash V with Richard C on RunAs Radio!

Last week, Chris Jackson appeared on RunAs Radio talking about about the benefits of Windows XP Migration (Yes, we still have customers who have not made the jump to a modern OS.) You can view the recording here: (http://www.runasradio.com/default.aspx?showNum=374)

It is an honor to be following my mentor and idol in this week's show where I talk with Richard  Campbell on a variety of topics. Originally we were to discuss App-V, but as we dove into the VDI use cases, the conversation turned over to UE-V which is starting to take off!

Listen Here: http://www.runasradio.com/default.aspx?showNum=375