Archive

Archive for November, 2013

MED-V: More Detail on Full-Screen vs. Seamless Mode

November 26, 2013 Leave a comment

I recently had a customer inquire further as to how the mechanics differ between all of the application modes in MED-V. I would have thought this far into the life cycle of MED-V that I had gone into enough detail on the subject. Turns out, while the article I wrote on TechNet a couple of years back (http://blogs.technet.com/b/medv/archive/2011/06/02/med-v-v2-why-would-an-application-fail-in-seamless-mode-when-it-succeeded-in-full-desktop-mode.aspx)  gave a good high-level explanation, more clarification is needed.

So in addition to the information I laid out back in 2011, I’ve done some more diving into RAIL (Remote Applications Installed Locally) the inline VPC implementation of TSRemoteApp (now called RemoteApp) where the RemoteApp Server component was ported to Windows XP for the guest integration.

First of there are actually two “full-screen” modes in MED-V 2. One involves starting full screen mode from either the MED-V toolkit or using the command MEDVHOST /fullscreen to launch the workspace in full screen mode with the MEDV Guest services and agents still engaged. If you were to access the Virtual PC out of band using the VPC Window or by double-clicking on the .VMCX file, you would get the warning message about another user being logged on (see http://blogs.technet.com/b/medv/archive/2011/08/24/med-v-v2-strange-message-lt-virtual-pc-name-gt-was-closed-with-a-user-logged-on.aspx)

I outlined the basics of the differences in this high-level chart:

medv-seamless-vs-fullscreen-vs-vpc

RDPINIT/RDPShell and Active Setup

In addition to items that depend on Explorer.exe such as Login Scripts, Active Setup also does not run. You may can get around this by leveraging group policies and the RUNONCE.EXE command. You can specify the startup applications as a part of a user’s logon settings in Group Policy. Because Group Policy controls these settings, any startup application that you specify runs as expected when the user logs on. To specify the startup applications as a part of a user’s logon settings, follow these steps:

1. In the server Group Policy Management Console (GPMC), select the GPO (that applies to the GUEST OS [XP]) and edit.

2.  Click Computer Configuration, and then click Administrative Templates.

3. Click System, double-click Logon and then double-click Run these programs at user logon.

4. In the Run these programs at user logon Properties dialog box, click Enable.

5.Click Show, and then click Add.

6.Type the name of the startup application – runonce.exe /AlternateShellStartup (must include the argument)

7.Click OK two times.

One Final Note on Termination

When a Remote Application is terminated, the process on the XP Guest that is associated with the application is terminated. However, the RDP session remains in a disconnected state until is reset by an administrator. This behavior can be modified by using the group policy “Set time limit for logoff of remote app sessions.”

Any other processes that should be terminated when the Remote Application is terminated can be specified in the following Registry key.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Sysprocs

This is a registry key that the RDP RAIL Shell uses to filter out “system” processes (in addition to rdpshell.exe and rdpinit.exe).  Processes configured via this key are ignored by the RAIL Shell. In addition, they will be terminated upon exiting of the RDP session.

A process can be added by adding a REG_DWORD value with a name of the process and a value of 0x0. The following is a list of processes that are terminated by default when a Remote Application ends.

Clipsrv.exe          Conime.exe        Ctfmon.xe           Dwm.exe             Imepadsv.exe

Lmsvcs.exe         Msgsvc.exe         Nddeagnt.exe    Netdde.exe         Netstrs.exe

Os2srv.exe          Proquota.xe        Rdpclip.exe         Screg.exe            Taskeng.exe

Wfshell.exe         Win.com

 

 

Categories: MED-V, RDS, VPC Tags: , , , , ,

App-V 5: Further Dissection of the App-V Error Code Format

November 26, 2013 2 comments

I recently just returned from the Microsoft Global MVP Summit where I got to spend some time with the App-V MVPs. We received a lot of good feedback and I got to see some great presentations (as well as do a little bloviating of my own.) I received specific feedback encouraging me to write more App-V troubleshooting blog posts. I also got thrown for a temporary curve where I was asked what was the “20” component field of an App-V error message and why did I not include it when i was discussing this in my blog on dissection of App-V error codes. For example, what is the difference between hypothetical error code 0x3E500D04-80070005 and error code 0x3E500D20-80070005?

So in my recent said blog in question on App-V operational troubleshooting (http://blogs.technet.com/b/gladiatormsft/archive/2013/11/13/app-v-on-operational-troubleshooting-of-the-v5-client.aspx) I discussed the component mappings. What I did not point out was the fact that the upper three bits in that field also bear some significance.

So, the App-V 5 error return code format is similar to the Softgrid and App-V 4 error code format in that it has build-specific sections. For App-V 5, once a return code is in hex format, you can ignore the first six hex digits as it relates specifically to the source file and build number. The most important digits to look at are the last ten digits. What I neglected to point out in that blog post was the upper three bit values of the component field in the error code.

If the module field is greater than the numbers mentioned in the previous blog, you will need to further dissect the bits in that field.

  • 1st bit – This bit determines whether or not the return code is a success code or an error code. This is important because if you ever notice an error with the format xxxxxx8x-xxxxxxxx then you know it is actually a success code.
  • 2nd bit – This bit determines whether or not an event has been logged or not. If the bit is 1, an error has been logged.
  • 3rd bit – If this bit is flipped, it is a Windows code and not and App-V specific code.

Ultimately, these are revealed in hex as:

  • 8x-xxxxxxxx – You can ignore this message as this is a success code.
  • 4x-xxxxxxxx – The return code that has been logged as an event.
  • 2x-xxxxxxxx – This is actually a Windows error code and not an App-V specific event.

So, with this knowledge, let’s look at the following error:

0x00001525-00000057

So we know the first six digits is build-specific so we only need to look at the last 10 digits. When we convert the “25” field from hex to binary we get:

00100101

This tell us that the 3rd field is flipped to 1 so the error is a Windows error and not an App-V specific error. The remainder in the last five bit field is 05 in hex which means it was logged by the Shared Components module. Using the ERR utility or even “NET HELPMSG” you can resolve the 57.

So, to reinforce, let’s look at another error:

0x45500D27-80072EE7

Again, if we focus on the 27 hex field, converting it to binary yields:

00100111

So again, we see this is a windows error. The last three bits convert to 07 hex which denotes the publishing agent. The last 8 digits translates to the HRESULT: ERROR_INTERNET_NAME_NOT_RESOLVED

Categories: Uncategorized Tags: , , , ,

App-V 5: Useful Stuff for the App-V Professional (I hope!)

November 15, 2013 2 comments

So I’ve been receiving a lot of feedback on ways to enhance  App-V toolkits for customers and their in-house troubleshooting. I’ve received usually two kinds of feedback on previous articles such as http://blogs.technet.com/b/gladiatormsft/archive/2013/11/13/app-v-on-operational-troubleshooting-of-the-v5-client.aspx
and http://blogs.technet.com/b/gladiatormsft/archive/2013/04/24/app-v-5-0-launching-native-local-processes-within-the-virtual-environment.aspx – 1) This is great! Can I have more?” and 2) “It’s about @*#&% time!Can I have more?

Do we have a “Cached OSD” equivalent in App-V 5.0?

Remember when you were troubleshooting configuration for a virtual application in App-V 4.x? Instead of going through the trouble of modifying the OSD file at the content root, removing and republishing as well as re-streaming the application – instead you locate the application’s cached OSD file and make modifications there while you do your temporary testing of adjustments to the XML configuration. The cached OSD files were located in a subdirectory of where you set the GlobalDataDirectory value in V4. Identifying which of the OSD files applied to your application could easily be achieved by viewing the properties of the application using the App-V 4 Client Admin UI.

In v5, this information will likely be stored in either the deployment configuration or the user configuration file (what we refer to as the dynamic configuration files.) To determine the source of the Deployment Configuration for a particular application, you can take advantage of PowerShell and the App-V Client API’s to find the location of this information without having to know the actual GUID of the package.

$AppVPackage = Get-AppvClientPackage –name <PACKAGE>

$AppVPackage.GetDynamicDeploymentConfigurationPath()  

   

You can then proceed to test out these changes.

How can I tell which Virtual Environment (packageconnection group) an Application is Running in?

Often on systems that are running a bunch of different virtual applications that may or may not be grouped together via connection groups (RDSCitrix Servers) you might want to verify a running process is running in the correct virtual environment. You can use the following PowerShell commands to determine the current package version and also possible connection groups (virtual environments.)

$AppVPackage = Get-AppvClientPackage –name <PACKAGE>

Start-AppVVirtualProcess cmd –AppvClientObject $AppVPackage

Get-AppvVirtualProcess | select -ExpandProperty AppvPackageData

In the example below, we use the CMD prompt to verify the version and package ID running.

 

How Can I tell if an Application was Running Virtualized simply by looking at a Process Monitor Log?

Any executable that is running within an App-V virtual environment will have the module “AppVEntSubsystems64.dll” injected into the process. So all you have to do when viewing a process monitor trace is double-click on any event containing the process you need to check. When the “Event Properties” dialog box appears, Click on “Module” tab and look for AppVEntSubsystems64.dll.

Here’s a Short Blog with a very Important Message (T-MINUS LESS THAN 6 MONTHS)

November 14, 2013 Leave a comment

Early last year I wrote a blog specifying how MED-V does NOT affect the Windows XP EOL Support issue: http://blogs.technet.com/b/gladiatormsft/archive/2012/07/30/how-med-v-affects-windows-xp-end-of-life-support-policy-it-doesn-t.aspx 

Little did I know how widely pulicized this would be (re: quoted in The Register and others – http://www.theregister.co.uk/2012/08/01/windows_xp_medv_no_go/)

Today’s a good reminder for all that we are now within six months. If you are looking to start a Windows XP migration please be advised that if the purpose of migration is to avoid unsupported or expensive custom extended support agreements, then MED-V will not resolve these concerns. Everything in that article is still valid. If you are still on XP, please feel free to comment on what your migration blockers are below. Are you being held back by a legacy LOB app or is it an Internet Explorer 6 issue?

Categories: Uncategorized Tags: , , , ,

App-V: On Operational Troubleshooting of the V5 Client

November 13, 2013 10 comments

 Update 12/6/2014: The App-V 5 logs have been consolidated and are organized differently as of App-V 5 SP3 – but the event and event formats are still the same. Please read more about it here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_event_logs_moved

Whenever I am doing customer engagements, I find it always valuable to ensure that the customer has a plan in place for ongoing support. Having my origins in support myself, I can relate to the customers concerns with impact to their helpdesk. Especially when a new product has been introduced in their ecosystem.

In the world of App-V, we divide up troubleshooting problems in two ways: 1) troubleshooting the operational client engine and 2) troubleshooting the application itself. IT departments relegate level 1 operational troubleshooting to their helpdesk team. This requires training your helpdesk with FAQs, CubeNotes, flowcharts, etc. to resolve basic issues and to at the very least, gather the necessary data to help higher level escalation teams isolate the problem.

Training or Retraining your HelpDesk on App-V 5

The App-V Client will be a very different experience for your help desk in terms of toolkit. Conceptually, they will be doing a lot of the same thing but the way they do it will be different.

Package Repair

Repairing a package will still be needed, but instead of using the client UI (which is deprecated in App-V 5.0 SP2) or SFTMIME, you can use the Repair-AppVClientPackage to reset user and or package state. You get can get specifics on this by reading Ryan Cobb’s blog post on the subject here:

http://blogs.technet.com/b/appv/archive/2013/10/28/how-to-quickly-repair-published-app-v-packages.aspx
 

Also NOTE: I have seen information out there stating that you can also simply delete files directly in the native locations. That is true but this command is much cleaner and useful for the help desk professional. You should also never, ever, ever, ever, ever, ever, ever delete the VFS directories manually as this will also create problems by potentially breaking the user mode VFS and copy-on-write mappings for the application. If you suspect issues with those VFS directories, use the Repair-AppVClientPackage command instead.

Connection Group Cleanup

The same options available for an individual package are also available for a connection group using the Repair-AppVClientConnectionGroup command. In fact, you should be advised that if you repair the connection group instead of the individual packages when you are experiencing issues where you would normally repair the application, this will purge out all of the settings for all applications within the connection group. If there are applications currently in use and it is preventing you from running these repair operations you will need stop all of the package processes. Stop-AppVClientPackage will stop all virtual processes in a package and Stop-AppVClientConnectionGroup will stop all virtual processes in a group.

App-V Client Logs

The SFTLOG.TXT is gone. So are all of the other text-based logs. Knowing how to collect good log data is essential to every help desk professional especially if escalations will be involved. The good news is everything is now logged to event logs. You can view these by opening up the event viewer and navigating to Applications and Services Logs – Microsoft – AppV – Client. The default view will show the three basic event logs: Admin, Operational, and Virtual Applications.
  
 

If you would like to view the additional logs that can enabled, navigate to the view menu and select “Show Analytic and Debug Logs.” In many cases, you may need to take advantage of these.

 

As you will see, there are a tremendous amount of additional logs. Most of these are not enabled by default. You will have to expand the folder, right-click the log and select “Enable Log” to enable it. Be careful turning on a lot of these as it can potentially affect performance.

Which Log do I Use?

Well now that will depend on the type of issue that is occurring be it an error upon publishing, streaming, launching, client service start-up, etc. often, the basic logs will give you what you need to know to fix the issue, but when it doesn’t, it is time to investigate further and these additional logs can come in very handy. The question is, which log or logs should I enable? The actual error message or error code may quickly provide some insight.

The App-V 5 Error Code

Like I did in V4, I am not necessarily concerned with the entire error code. I usually only have to pay attention to the last 10 digits when looking at V5 errors ONCE I have the error in the correct Hex format. Often time, in the event logs, the error code is actually in decimal format. One of the first things you will want to do is get the error in its correct format. For example, if you see the following error in the event log:

64 notification failed with error 5746720685053444123, Package <GUID>, version <GUID>, pid
<PID>, ve id 0

The first thing I do is convert the decimal error over to hex.

 

5746720685053444123  translated to hex is 0x4FC074040000001B.

If you break it down first separating the last ten digits (04-000000001B) you diagnose this further by resolving the first two digits to the component using the table below:

 

Hex
  Code

Category

Where you might further Info

01

Integration

Client-Integration Log

02

Orchestration

Client-Orchestration Log

03

Client Service

Client-Service Log

04

Virtualization Manager

Client-VirtualizationManager Log or Client-Vemgr Log

05

Shared Components

Admin and Operational Logs

06

Catalog

Client-Catalog

07

Publishing

Client-Publishing Log, Client-PackageConfig Log, or
  FileSystemmetadataLibrary Log

08

Client Common

Admin and Operational Logs

09

Policy

PolicyLibrary Log

0A

Virtualization Subsystem

May need to diagnose using the individual virtual subsystem debug logs.

0B

Subsystem Controller

Client SubsystemController Log

0C

Streaming Manager

Any of the five streaming debug logs

0E

Client Host

 

0F

Client Configuration

Registry/PowerShell

10

Scripting

Client Scripting Log

11

Client User Interface

Client-StreamingUX Log

12

Sequencer

Only on Sequencer

13

Reporting

Client Reporting Log

14

Manifest

ManifestLibrary Log

 

 

 

 

Then the last 8 digits will usually just be a standard Windows HRESULT code. In the example above, I know the issue is somewhere in the virtualization manager and the last eight digits are 0x0000001B. The HRESULT alone does not really lead me anywhere so I would likely need to dive further into the Client-VirtualizationManager debug log.

Sometimes, you will get really lucky. For example, if the error is 0xFC03E0480070003. Well, again we know it is an issue with the virtualization manager but the HRESULT 0x80070003 is well-known – ERROR_PATH_NOT_FOUND. You know where I would then go next – Process Monitor of course!

         
 Update 12/6/2014: The App-V 5 logs have been consolidated and are organized differently as of App-V 5 SP3 – but the event and event formats are still the same. Please read more about it here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_event_logs_moved

         
 

 

 

App-V: On Virtual Services in App-V 5.0

November 12, 2013 4 comments

On the subject of services, it is probably worth mentioning some of the changes with how App-V handles virtual services in V5. First and foremost, you may have noticed there is no separate virtual service agent service running for the V5 client. You have probably also noticed that virtual services are not managed or modified through the sequencer interface. So how do you configure a service during sequencing? Well, the same as a regular service, through the services control panel or the command line (or PowerShell) during the monitoring phase. Also, only the use of the LocalSystem account is supported. Other well-known SIDs such as Network Service are not supported. Services that are virtualized will also have read-only configuration during run-time when virtualized. You will not be able to change the state of the service when it is running in the virtual environment using traditional APIs.

Since App-V requires execution of an application in the context of a user account, it limits what kinds of services can be virtualized. Services that require execution at boot time or any time prior to a user logging on will not likely be a good candidate for virtualization. There are, however, many user-mode services that can be virtualized with App-V and actually work quite well with App-V.

. . .  and then there are those services we do not want in our virtualized application package due to functional or practical reasons. I use Google Chrome’s auto-update service feature as an example. Virtual applications work best when sequenced to a steady state and updated through the App-V update process. Services that automatically update base software binaries can cause applications not to function as expected.

The App-V sequencer will capture services during the sequencing process. In previous releases of the sequencer, there was a way to review the services detected in the Services tab. At that point, you could delete the services should you not want to keep them in the package. This has changed in the V5 version of the sequencer. If you notice, when you go to the services tab, you will notice that at this stage, you are unable to remove the virtual services from this screen.


  
 Removing Services during Sequencing

If you want to remove services that are captured in the monitoring process with the V5 version of the sequencer, you will have to use a different method now. During sequencing, you need to delete the services registrations in the registry prior to closing monitoring. This will require you to know where the service registrations are stored in advance or before you close out the monitoring process. For example, if I wanted to remove the service registrations for the Google Update Service, I would open up the Services management console and the Registry Editor after installation has completed and prior to stopping monitoring. When you view the properties of the service, the Service name field will give you the short name of the service. This will reflect the name of the subkey of the service located in HKLMSystemCurrentControlSetServices


 

You can then delete this subkey to remove the service registration. In most cases, the sequencer will capture that removal and thus remove the service entry.

Removing Services from an Existing Package

If the package has already been saved, then you can modify this by opening up the package using the workflow “Update Application in Existing Package.”

 

Then during monitoring, you can open up a command prompt and run the registry editor to remove those service registrations.

Once you delete the keys under HKLMSystemCurrentControlSetServices<SERVICENAME> you will find the services are gone when you look at the Virtual Services tab.

 

In addition to the above, you can also use other registry editing utilities (such as REG.EXE) or even use the SC command if you are looking for a safer alternative for removing service registrations.

Disabling Virtual Services using Dynamic Configuration

If you do not want to open up the package to remove a service, you can simply disable the virtual services subsystem using dynamic configuration. Just set the subsystem value to “false” such as follows:

<Subsystems><Services Enabled=“false“/></Subsystems>

App-V: On COM+

November 7, 2013 4 comments

Throughout the history of App-V and Softgrid, you have likely read from many sources that COM+ cannot be virtualized. Many tools, including the App-V sequencer, contain detection logic that will also notify you of the presence of COM+ components when you are attempting to sequence an application.

COM+ evolved from DCOM (Distributed Component Object Model) and has historically been used to develop components that leverage transactional technologies including SOAP, JIT (Just-in-time) activation, queued components, and more. If you want to dive into this further, you can find some good developer references are here:

http://msdn.microsoft.com/en-us/library/ms685978(VS.85).aspx

http://msdn.microsoft.com/en-us/library/ms973847.aspx

Be careful not to confuse COM+ with an out-of-process COM server, which can be communicated with by enabled local interaction in the virtual application in 4.x or configuring out-of-process integrated COM in the deployment configuration of an App-V 5.x application.

For an application to be able to use COM+ Services, they will need to be configured within the COM+ Catalog. One easy way to do this is using the COM+ Component Services Snap-in that comes with Windows where you can configure most of the settings for COM+. Since Com+ actually generates dynamically at run time not during the actual installation, the sequencer is not able to process it, therefore is cannot be captured into a static state like other installation assets. When COM+ came on the scene in Windows 2000 with distributed transaction servers, application virtualization was not taken in to consideration.

When Microsoft developed Server App-V, the Server App-V sequencer was designed to capture COM+ components created by the application installer along with other elements such as local groups and WMI. Since there is state separation and not isolation, COM+ is not sandboxed, but laid down during deployment through its normal registrations so it can function normally at run time.

Remediating COM+ Limitations with App-V

If your sequencer happens to detect and notify you of a COM + component, it is telling you that this application may not function correctly as expected with the package as-is. Does this mean that the application cannot be virtualized with App-V and delivered via an App-V delivery system? Not necessarily. Like other components that cannot be virtualized (such as drivers,) it does not necessarily mean that you are completely out of luck. In fact, there are possible remediation options. And with App-V, we have more options to implement these remediation fixes. In a sense, you can package the component to be laid down during deployment in a similar manner (but not identical) as it is with Server App-V.

Once you are made aware of a COM+ component within an application, you will need to install the application natively on a test machine. Then you will need to launch the Component Services management console (HINT: I am always confused as to which operating system launches this so I just launch DCOMCNFG and it always launches it.) You should likely find the component or components within the COM+ Applications folder under “My Computer.”  

 

Once you locate it you can then right-click the component and select “Export.”

 

This will launch the COM+ Application Export Wizard.

 

You will then give the path and name to the destination MSI file you want to export this application to. 

 

Accept defaults and select ‘Next’ then ‘Finish’.

Now you will need to either re-sequence the application or update the existing package and during sequencing or updating, add the MSI file to the package. In the case of a V 5 package, I would usually add it into the scripts folder.

If you are using App-V 4.x, you will want to edit the OSD file and add in a script that will install the Copy out the MSI file and run the installer. You do this by adding the following beneath the <DEPENDENCY> tag.

 

        echo off n

       if exist C: goto end n

        mkdir n

        copy /y “q:mymsi.msi ” “C: ” n

 

 

        echo off n

        if not exist C: goto end n

       C:mymsi.msi /quiet n

        del /f /q C:mymsi.msi n

        :end n

 

Now, let’s be realistic. For the above to work, you must accept two siginifcant caveats. 1) The user executing the application will need to be a local administrator. This is often a deal-breaker. 2) The user will have to encounter a delay upon launch due to the installation.

App-V 5.x

Enter App-V 5 and its enhanced scripting model. On either a global publish or add package event, you can add deploy the component in a secure manner as those events will execute under the context of the SYSTEM account. You can place the MSI and the scripts installinguninstalling it into the embedded scripts folder inside the package. HINT: Since the script event only allows for one command element, my advice is to but all of the installation commands into a batch file or PowerShell script and call that script for the event. Since the scripts and package root directory in the package are automatically searched, you do not have to worry about specific paths.

     
<AddPackage>

        <Path>Powershell.exe</Path>

        <Arguments>-F deployComPlus.ps1</Arguments>

        <Wait RollbackOnError=”true” Timeout=”30″/>
     
</AddPackage>

<RemovePackage>

        <Path>Powershell.exe</Path>
       
<Arguments>-F removeComPlus.ps1</Arguments>

        <Wait RollbackOnError=”false” Timeout=”60″/>

</RemovePackage>

In the interest of full disclosure – with regards to this working seamlessly, I am 3 for 4 as I write this. In my opinion, .750 is a good batting average! Understand that this is meant to be an option for remediation as COM+ still technically cannot be virtualized.

App-V: On Named Kernel Object Virtualization (a.k.a. the VObjects Subsystem)

November 5, 2013 Leave a comment

Virtual Objects: You have also possibly heard this referred to as virtual eventing. You have seen references to this in the context of troubleshooting. You may have possibly used this as a workaround when troubleshooting in 4.x:

Add an asterisk wildcard in the following registry path: HKEY_LOCAL_MACHINESOFTWAREMicrosoftSoftGrid4.5SystemGuardObjExclusions

Before you ever do the above again, please read this article.

The question is: what exactly are you doing when you do this and what are the ramifications? Well, first of all, this should NEVER be disabled ad-hominem unless you have a specific reason for doing so. This is especially important in versions prior to V5 where disabling this subsystem actually disabled it for the entire client. Second, if possible, only disable using specific markers for objects pertaining to the application in question. It is understandable to avoid this method as it can be a daunting and tedious task to track these down in the case of some applications. The concept of “disabling virtual objects” in App-V really refers to disabling eventing and essentially everything else under the App-V virtual object isolation subsystem by name or wildcard mask. To understand the function of the virtual object subsystem (or VOBJECT) it will help to have a good understanding of kernel objects in general.

When we speak of kernel objects we are talking about all of the object types that fall into this category, i.e. mutexes, semaphores, base named objects, events, file-mappings, etc. Applications work with objects through the use of handles. This is accomplished by calling a Win32 API that is specific to the kernel object being instantiated. If you want to know more about these individual object types and how they work within the operating system, I would suggest picking up the latest copy of Windows Internals.

When an object is instantiated it is often identified using a string. Because the object is managed by the kernel, this means this object can be leveraged by multiple applications. In the case of App-V, like COM, there is name obfuscation that serves as the isolating factor so it allows for the kernel to still manage these objects and the virtual object subsystem within App-V can allow multiple processes within the same virtual environment to share access to the object.

App1.exe —–> Handle —-> Named Object (ObjEvt1)

App2.exe —–> Handle —-> Named Object (ObjEvt1) (previously created)

Many kernel objects can be named using a string. Because the kernel manages the objects, the name can be used by multiple processes. In the case of the above, Both App1.exe and App2.exe have handles to the named object ObjEvt1. App1.exe can now wait for eventing from App2.exe.

Isolation

Named Kernel objects are isolated by App-V intercepting calls made to create the kernel object and modifying the name in a manner that only the current virtual environment understands. So if you have multiple applications that need to communicate to each other this way, you will need to ensure they belong to the same virtual environment. If you have a virtual application and a local application that will need to communicate with each other in this way, then you will need to disable naming of these objects.

In the case of application conflict resolution, this isolation process allows the virtual applications running in different virtual environments to create the same kernel object, yet have these objects handled differently by the kernel because the names will be different as far as the kernel is concerned. To put it crudely, if two versions of an application called GROUCHOv1.EXE and GROUCHOv2.EXE respectively need to create and “use” the same object (we’ll call it “cigar”) – then virtualizing them separately under App-V will make this possible as one object will actually be called sg<16-hex digit random ID>_cigar and the other will be sg<16-hex digit different random ID>_cigar.

Now, a pre-populated list of exclusions will show up in the registry under both 4.x and 5.x in order for App-V to be happy in the world of Windows. Adding further exclusions and disabling objects as a whole can be done, however, do NOT remove any existing exclusions that are already populated in the client registry. There is absolutely no reason for you to REMOVE any existing exclusions that you did not put in to begin with. When you are troubleshooting the virtual object subsystem, you may want to add in a single “*” to disable eventing for all objects or add in a specific kernel object name or names (preferred.)

4.6 Object Exclusions

In version 4.6, the legacy list of excluded objects were listed here:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftSoftGrid4.5SystemGuardObjExclusions

A quick way of troubleshooting would be to create a new string value (I’d usually use 1001001) and enter an asterisk (*) as the value. When the application started to work, I could now use Process Explorer or WinObj to help determine what objects were being created. If I weren’t lazy, I would go back and only enter those object names for exclusion. If I were lazy, I’d leave in the asterisk. This can be dangerous – especially if I were on RDS or Citrix servers where you may have multiple versions of applications/middleware.

One thing I want to drive home is that changes here were MACHINE WIDE. If you wanted to apply these changes to one package only, you would leverage the LOCAL_INTERACTION_ALLOWED policy in the application’s OSD file – however this would also disable some COM virtualization features which you may not want. Bear in mind this policy element in the OSD file still looks up the objects in the virtual environment, but if not found, it will fall back to the native and check there as well. This is why it was and still is a great troubleshooting AND workaround for App-V 4.x.

To enable local interaction, your OSD VIRTUALENV tag should look like the following:

<VIRTUALENV TERMINATECHILDREN=”FALSE”>

<POLICIES><LOCAL_INTERACTION_ALLOWED>TRUE</LOCAL_INTERACTION_ALLOWED></POLICIES>

</VIRTUALENV>

 

App-V 5 and the VObjects Subsystem

There is not much new under the hood in V5 with regards to how isolation of kernel objects happens. There is more flexibility and granularity with configuration.

There is an element within the Deployment Configuration that you can use to turn on or off the VObjects subsystem for a package:

      <!–

      Objects

      –>

      <Objects Enabled=”true” />

What is great about this is that it will allow you to disable the VObjects subsystem for a package but still allow for COM to be virtualized. During the start of a virtual environment, the subsystem will read the manifest and Deployment Configuration file and combines them together. If there are multiple packages within a connection group, they will be combined as well.

You also still have the method of using the registry to exclude specific objects although I see no reason to use this as a means of disabling the entire object subsystem since you can do this through the XML on a per-package basis.

The exclusion locations in V5 are found in:

HKLMSOFTWAREMicrosoftAppVSubsystemObjExclusions

Tools to Isolate Objects

So, when you launch a virtual application, you can easily compare on a clean test machine whether this newly added virtual application package creates kernel objects. All you do is look for the objects that start with the name “sg” then remove that as well as the 16 character numeric identifier preceeding the underscore and everything else to the right of the underscore character is the actual name of the object which you can then use to create a mask for a custom object exclusion. There are two free tools that are great for this:

Process Explorer

When you run Process Explorer and turn on the bottom pane, there will be a view of objects. When you select the virtual processes, you can identify the objects that are virtualized. You will need to sort the object view by name in some cases to make this easier.

 

WinObj

Winobj is another tool from the Sysinternals Toolkit that is great to use however, you need to ensure that you run it as an administrator in order to get the right session context since this does not view from a process context. It will allow you to catch any objects you may have missed with the above.

 

 

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

November 4, 2013 5 comments

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

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

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

Isolation vs. Immutability and State Separation

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

Advice for the Softgrid Users:  Learn by aligning the concepts

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

SFT_MNTPackageRoot vs. AppVPackageDriveAppVPackageRoot

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

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

Targeted Publishing – A Difference

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

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

 

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

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

Caching is now mounting

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

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

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

Conclusion

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

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

Categories: Uncategorized Tags: , , , , , ,