Fellow MVP Tim Mangan and myself decided to finally release a book about App-V. We decided to release a 233 page book that focuses on an often overlooked core piece of the technology which is the App-V client. The content should help you better understand the operation of the App-V client so you can properly configure and maintain it in your environment. We took only a chapter from our 500+ pages of App-V 4.6 Masters Class manuals and expanded upon it to create this book. I truly hope this is the most complete piece of documentation you find on the subject and maybe some of the topics will spark some of those “ah-ha!” moments.
You can order the book directly from here http://stores.lulu.com/tmurgent.
Recently I was deploying a Application Compatibility Toolkit’s Data Collection Package to some key workstations to look for application behaviour that may experience issues on their new Windows 7 platform. Our testing went great and we thought everything was good to go for production so the change request was put in and we released the DCP to our target group.
The next day some tickets rolled into the the helpdesk describing issues with McAfee host intrusion protection detecting changes with Office and my gut reaction was “oh sure, blame the change”. But I did know that this could be a possible issue because ACT may appear as malware as it monitors the endpoint environment.
I quickly did some searching on the net and found reference to McAfee’s KB article 59837. Essentially signature 432 needs to be disabled in order to work around the issue and should be re-enabled once DCP data collection is finished. Because the status of this issue may change over time I recommend checking into McAfee’s knowledge base for the latest information but hopefully this blog entry prevents some of you getting a little egg on your face when trying to deploy ACT.
Normally I want to keep the content on this blog more on the technical side but before my days as an App-V MVP and even further back to when I first put myself on SoftGrid training out of my own pocket in 2003 I saw the potential ROI story with application virtualization. As I started to consult in this area and perform some large scale deployments of App-V both the client and myself could see the ROI story play out rather quickly with the technology. As you can probably guess I see application virtualization becoming a fairly standard application deployment mechanism for environments in the 1000+ seat size.
So rather than try to have you buy into my vision Microsoft is having a ROI Microsoft has a presentation around Forrester’s Total Economic Impact model and how it applies to App-V. This session will help you identify potential savings your environment could realize through App-V including the business needs it can satisfy. If you feel that this may be a session for you or the ammunition you might need to sway management use the link below to view the event page.
https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032453953&EventCategory=4&culture=en-US&CountryCode=US
In an effort to aid the App-V community with sequencing guidance Microsoft launched the App-V sequencing forum yesterday. The goal of this area is to collect more App-V specific application sequencing guidance so that other users can reference and learn from other people’s experiences.
For example I put up recipe for Adobe Reader and for the most part Adobe Reader is a very easy application to sequence. But what I’ve seen most people do to turn off the auto updates they end up hacking the MSI to bits so that the feature never gets installed. In my recipe I utilize a more supported method by downloading a setup customization tool that easily configures the Adobe Reader installer to install with many options configured the way a systems administrator would prefer it to be.
I also tackled the Oracle 11G client even though most of you will probably not sequence just the client. The idea here was to give some idea as to best practice if you are using a TNSNames.ora file for service name resolution since that is a very common configuration of the client in sites I have been to. You’ll likely apply another application that uses Oracle to the same sequence or join the sequence with an application using DSC but at least you have a building block that will get you one step closer to your solution.
Take a look around and see the content currently available. If you think that you have found a sequencing solution that may benefit others open up the following post that you can use as a template for your recipe submission.
http://social.technet.microsoft.com/Forums/en-US/prescriptiveguidance/thread/ce5e2617-637a-4ab6-a6fe-f1ebe965709d
If you are only interested in browsing the current content use the following link to access the forum.
http://social.technet.microsoft.com/Forums/en-US/prescriptiveguidance/
Today fellow App-V MVP Ruben Spruijt has posted online the Microsoft App-V volume format specification over on his site for download by the public. Thanks to Microsoft and reviewer (another App-V MVP) Tim Mangan the details around the black box known as the App-V volume can be properly understood.
For those of you who really want to know what all these strange file types such as the .fsd .fsg .pkg and .tmp files are used for you can probably find more than you wanted to know. The real purpose here is to help the App-V ecosystem by enabling 3rd party developers to design new tools for use with App-V. MVPs Tim Mangan and Kalle Saunamäki have already released tools to read the package volumes. Both tools below allow you to view the changes made to the virtual application environment and in the case of Kalle’s Application Virtualization Explorer you can modify the user’s virtual environment. In case you weren’t aware of these tools here are some links to get you started.
Overview of Application Virtualization Explorer (Commercial)
http://www.gridmetric.com/products/ave.html
Overview of PkgView (Free)
http://www.tmurgent.com/TmBlog/?p=166
You might be wondering what other tools we may expect on the horizon. Gene Ferioli over at Microsoft suggested that Antivirus vendors can finally develop the capability to scan and repair infections inside the virtual environment without the virtual application running. Other vendors may decide to develop troubleshooting tools that go beyond what is currently available today. Maybe some vendors will develop tools to inventory the contents of a virtual environment and provide better software inventory capabilities to your systems management solution.
Microsoft will have the documentation up on their site soon but if you are curious here’s your chance for a sneak peek. Just download, execute the EXE in the folder you wish to unpack it in and agree to the EULA.
http://virtuall.eu/download-document/microsoft-application-virtualization-volume-format-specification
The reason I picked this error message as something to blog about is because I ran into a situation where this error code was a little bit misleading at face value. As a result more time was spent on this issue as we tried to isolate the root cause and resolve it. The funny thing about this error is that it can lead you on a bit of a goose chase as you try to fix your OSD task sequence if you don’t properly read your log.
At face value this error is nothing more than a simple problem with a package missing from a distribution point. The problem for me was that I was dealing with a bunch of issues straightening out the OS deployment piece where I was at so I wasn’t exactly trusting the infrastructure health. No matter what I did with the problem package the error would persist but if I recreated the problem package from scratch the error went away. Unfortunately once I fixed one package a new package became a problem. I then went about replacing all my packages until the task sequence started complaining about my installation source for the second time. At this point I knew I was in some sort of loop and recreating all my packages again wasn’t going to fix anything.
To make the situation even more confusing my 64-bit task sequence was using the problem packages without issue but my 32-bit task sequence was generating errors saying the content wasn’t available. At this point I was pulling out my hair trying to find out what the root cause of this mess was. Well it turned out the problem wasn’t SCCM but VMware Workstation. And to be fair it wasn’t VMware’s fault it was my mistake as to how I configured the virtual machines for imaging. So how could the VM configuration make such a big difference?
When I was reading my SMSTS.log it was very clear that package INI00027 wasn’t being found by the SCCM client environment.
But it wasn’t available for the usual reason which is usually missing files on the distribution point. When I looked at my only distribution point the files were happily waiting to be used. After another dive into the logs I realized that I wasn’t properly reading the SMSTS.log! If I look up a few lines I found the critical message.
My operating system deployment client thinks that the distribution point is not local and determines the package is not available which is a good behaviour. Most people wouldn’t want SCCM to deploy operating systems over a WAN link so this is why this is a default behaviour inside SCCM. So why it this virtual machine not appearing to be local to the distribution point? Easy, after looking at my virtual machine configurations in VMware Workstation I realized the mistake I had made configuring the virtual machines. The working 64-bit VM had its network interface set to bridged so it was getting an IP address off of the corporate network.
However the broken VM I had left the default of having the VM on a NATed network making the SCCM task sequence think the PC is not on a local network to the distribution point.
You might not see the specific situation I’ve encountered but hopefully this sheds more light on the logging and another possible cause for this error code. Also look at this blog post for the more common situations which this error can occur.
http://brothertu.blogspot.com/2008/09/failed-to-resolve-selected-task.html
Unfortunately that will not happen any time soon but I though I would make readers aware that some of my content has been translated by fellow App-V MVP Junxian (Tommy) Huang. Tommy was kind enough to select some of my content for translation so that it could reach a wider audience. For those of you that don’t know where Tommy blogs here is a list of links for you.
http://blogs.itecn.net/blogs/virtualtom
http://virtualtom.blog.51cto.com
http://bbs.winos.cn/thread-90753-1-1.html
Enjoy!
I a few weeks ago I was putting in a new SCCM environment and we decided to try out the App-V 4.6 client since it was released that week. What we didn't expect was an issue deploying our first virtual application to our test PC. It just wouldn't deliver the virtual application so we had to look into the first logical spot for this configuration, the SCCM client logs. What we were trying to see is if SCCM was passing the virtual application over to the App-V client so that the App-V client can import it into the client cache, configure shortcuts, etc... My first stop was the SCCM client log usually associated with application delivery known as the execmgr.log. We opened the log and we thought we might have found the issue but the log suggested something we didn't expect.
Requesting content from CAS for package INI00003 version 1 execmgr 14/03/2010 8:07:33 PM 3988 (0x0F94)
Policy arrived for parent package INI00003 program [Virtual application] execmgr 14/03/2010 8:07:33 PM 4088 (0x0FF8)
Raising event:
[SMS_CodePage(437), SMS_LocaleID(1033)]
instance of SoftDistProgramOfferReceivedEvent
{
AdvertisementId = "INI20000";
ClientID = "GUID:7A4870CF-6F16-4E5C-9762-803620B7B3E8";
DateTime = "20100315020733.678000+000";
MachineName = "WIN7X32ENT-SEQ";
ProcessID = 280;
SiteCode = "INI";
ThreadID = 4088;
};
execmgr 14/03/2010 8:07:33 PM 4088 (0x0FF8)
Successfully created a content request handle {8FEDE91E-A80B-4506-BD8A-9A48E53C48F4} for the package INI00003 version 1 execmgr 14/03/2010 8:07:35 PM 3988 (0x0F94)
Program [Virtual application] change to state STATE_ADVANCED_DOWNLOAD content in progress execmgr 14/03/2010 8:07:35 PM 3988 (0x0F94)
Execution Request for package INI00003 program [Virtual application] state change from NotExist to AdvancedDownload execmgr 14/03/2010 8:07:35 PM 3988 (0x0F94)
Mandatory execution requested for program [Virtual application] and advertisement INI20000 execmgr 14/03/2010 8:07:35 PM 236 (0x00EC)
Creating mandatory request for advert INI20000, program [Virtual application], package INI00003 execmgr 14/03/2010 8:07:35 PM 236 (0x00EC)
Raising event:
[SMS_CodePage(437), SMS_LocaleID(1033)]
instance of SoftDistWaitingContentEvent
{
AdvertisementId = "INI20000";
ClientID = "GUID:7A4870CF-6F16-4E5C-9762-803620B7B3E8";
DateTime = "20100315020735.381000+000";
MachineName = "WIN7X32ENT-SEQ";
PackageName = "INI00003";
PackageVersion = "1";
ProcessID = 280;
ProgramName = "[Virtual application]";
SiteCode = "INI";
ThreadID = 236;
};
execmgr 14/03/2010 8:07:35 PM 236 (0x00EC)
Successfully raised SoftDistWaitingContentEvent event for program [Virtual application] execmgr 14/03/2010 8:07:35 PM 236 (0x00EC)
Execution Request for package INI00003 program [Virtual application] state change from WaitingDependency to WaitingContent execmgr 14/03/2010 8:07:35 PM 236 (0x00EC)
Content is available for program [Virtual application]. execmgr 14/03/2010 8:07:37 PM 2772 (0x0AD4)
CExecutionRequest::Service Windows Manager has allowed us to run. execmgr 14/03/2010 8:07:37 PM 2772 (0x0AD4)
Executing program {4E6A9B91-8BCA-4B06-A720-7485CE71BB9D} in Admin context execmgr 14/03/2010 8:07:37 PM 2772 (0x0AD4)
Execution Request for package INI00003 program [Virtual application] state change from WaitingContent to NotifyExecution execmgr 14/03/2010 8:07:37 PM 2772 (0x0AD4)
Execution Manager timer has been fired. execmgr 14/03/2010 8:07:37 PM 236 (0x00EC)
Checking content location C:\Windows\system32\CCM\Cache\INI00003.1.System for use execmgr 14/03/2010 8:07:37 PM 2772 (0x0AD4)
Successfully selected content location C:\Windows\system32\CCM\Cache\INI00003.1.System execmgr 14/03/2010 8:07:37 PM 2772 (0x0AD4)
Executing program as a virtual application registration. execmgr 14/03/2010 8:07:37 PM 2772 (0x0AD4)
SCCM package version number : 1. execmgr 14/03/2010 8:07:37 PM 2772 (0x0AD4)
CVirtualAppExecution::ExecuteProgram - The virtual application package was not registered because the SoftGrid client is not installed. execmgr 14/03/2010 8:07:37 PM 2772 (0x0AD4)
EnterRsRuningState failed to run script {4E6A9B91-8BCA-4B06-A720-7485CE71BB9D} 0x80008281 execmgr 14/03/2010 8:07:37 PM 2772 (0x0AD4)
Fatal error 0x80008281 enountered for program [Virtual application]. This program will not retry. execmgr 14/03/2010 8:07:37 PM 2772 (0x0AD4)
We didn't expect to see the message "The virtual application package was not registered because the SoftGrid client is not installed." in the execmgr.log because we knew the App-V 4.6 client was installed. Just for fun we opened another SCCM client log file that involves the installation of virtual applications the VirtualApp.log.
Could not open the registry key SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration. (0x80070002) VAppRegistration 14/03/2010 7:44:01 PM 3476 (0x0D94)
The VirtAppMgmt client was not found on this system or is an unsupported version. VAppRegistration 14/03/2010 7:44:01 PM 3476 (0x0D94)
CVAppRegistration::ConfigureVappClient() failed. (0x80008281) VAppRegistration 14/03/2010 7:44:01 PM 3476 (0x0D94)
Registering the virtual application package [INI00003] with the AppVirtMgmt client. VAppRegistration 14/03/2010 8:07:37 PM 2772 (0x0AD4)
Loading package properties from the manifest file: C:\Windows\system32\CCM\Cache\INI00003.1.System\WinRAR-V3.91-WinRAR.001_manifest.xml. VAppRegistration 14/03/2010 8:07:37 PM 2772 (0x0AD4)
The installed AppVirtMgmt version [4.6] cannot be used with this version of SCCM. VAppRegistration 14/03/2010 8:07:37 PM 2772 (0x0AD4)
The VirtAppMgmt client was not found on this system or is an unsupported version. VAppRegistration 14/03/2010 8:07:37 PM 2772 (0x0AD4)
The package cannot be registered. The Application Virtualization Management client is not ready. VAppRegistration 14/03/2010 8:07:37 PM 2772 (0x0AD4)
Raising event:
[SMS_CodePage(437), SMS_LocaleID(1033)]
instance of CLIMSG_VIRTUALAPP_ERROR_PACKAGEADD_FAILURE
{
AdvertisementId = "INI20000";
ClientID = "GUID:7A4870CF-6F16-4E5C-9762-803620B7B3E8";
DateTime = "20100315020737.850000+000";
ErrorCode = "";
ErrorMessage = "The Application Virtualization Management client is not installed or is an unsupported version.";
MachineName = "WIN7X32ENT-SEQ";
PackageID = "INI00003";
ProcessID = 280;
SiteCode = "INI";
ThreadID = 2772;
VirtualAppPackageGUID = "{4E6A9B91-8BCA-4B06-A720-7485CE71BB9D}";
VirtualAppPackageName = "WinRAR-V3.91-WinRAR.001";
};
VAppRegistration 14/03/2010 8:07:37 PM 2772 (0x0AD4)
Raised ADD PACKAGE Registration Failure event for Ad: INI20000, PackageID: INI00003, Name: WinRAR-V3.91-WinRAR.001, PackageGUID: {4E6A9B91-8BCA-4B06-A720-7485CE71BB9D} VAppRegistration 14/03/2010 8:07:37 PM 2772 (0x0AD4)
The key message from the VirtualApp.log was the "The installed AppVirtMgmt version [4.6] cannot be used with this version of SCCM.", obviously we needed to upgrade our SCCM infrastructure from version 2007 R2 to 2007 R2 SP2! Aside from not doing our homework when installing App-V 4.6 this was a good exercise to understand the SCCM client logs involved with delivering an App-V application. This however is not the complete picture when looking at all the logs involved with App-V application delivery when it is integrated with SCCM. The client application event log and another log file called sftlog.txt can be used to specifically look at App-V client events. I hope that this at least gives you a basic picture when trying to troubleshoot your App-V application delivery in a SCCM integrated configuration.
Introduction
With the availability of 64-bit operating systems from Microsoft many terminal server administrators and desktop super users have been trying to justify these platforms in their enterprise so that scalability enhancements found in these operating systems could be exploited. The problem with 64-bit platforms has been the adoption if the architecture by the industry resulting in a situation where many solutions taken for granted when using a 32-bit platform were not available for the 64-bit platform. A much sought after App-V feature for the terminal server administrator community has been a 64-bit App-V client because 32-bit terminal servers have user constraints around 40-60 users due to memory limitations. Some terminal server environments with 64-bit operating systems are boasting over 120 or more users per physical host but could not leverage App-V as part of their terminal server solution stack. Desktop administrators face a somewhat different scenario where some of their more resource intensive applications such as engineering applications are now being released as 64-bit releases and in one known case the only upgrade path for thre application is to upgrade to a 64-bit release.
It was a matter of time until App-V would need to support 64-bit operating systems and applications. Now that 4.6 is available you can plan to migrate that App-V environment over to 64-bit hosts to overcome memory constraints and see better scalability for both applications and terminal server environments. For those of you looking at a migration path from a 32-bit to 64-bit terminal server environment see the following white paper from Microsoft.
Terminal Services Scaling and Performance on x64-Based Versions of Windows Server 2003
http://www.microsoft.com/downloads/details.aspx?familyid=9B1A8518-D693-4BBB-9AF8-B91BBC0D2D55&displaylang=en
Making App-V 64-bit Capable
If it was an easy job to make App-V x64 capable it would have likely been introduced earlier but there are many technical requirements to make this a reality. The largest issue was going to be converting the kernel level components of the App-V client to 64-bit so that they could run on a 64-bit platform. Even though a 64-bit operating system can run a 32-bit application this is not true for applications that need to run in the kernel memory space. All code at the kernel level must be 64-bit, no exceptions. Much of the App-V client’s core functionality occurs down at the kernel level so this wasn’t going to be a quick walk in the park for the App-V development team.
Some of you who have some spare time may have noticed that not all off the App-V client is 64-bit. Some of these 32-bit components were necessary to properly handle 32-bit applications but in other instances 32-bit code was left in place such as the management interface. You might wonder why something like the management interface wouldn’t be converted to 64-bit like the rest of the client but unless there is a good architectural reason to do so it is perfectly ok to leave code compiled as 32-bit. This is not unique to App-V and probably will remain to be a practice with application development until 64-bit computing becomes even more dominant.
Sequencing with 4.6
Not only is App-V the only product that can package 64-bit virtual applications but App-V 4.6 has the ability to sequence both 32 and 64 bit application using the same sequencer tool. On top of that the sequencer tool has been streamlined so that the process is easier than before with earlier versions of the sequencer. In order to have a look at some of these new features let’s sequence a 64-bit edition of WinRAR on Windows Vista Enterprise Service Pack 2 x64 and deploy it on a Windows 7 Enterprise x64 machine using App-V 4.6. Do note that we are not implying some sort of application compatibility here but the econcomics of sequencing once and deploying to many using the least common denominator method. See the following support statement for more guidance. http://blogs.technet.com/appv/archive/2009/12/14/do-i-need-to-re-sequence-my-applications-when-i-move-to-a-new-os.aspx
1) Launch the application virtualization sequencer application.
2) As you can see creating a new sequence can be invoked from the main page. Select “Create Package” to start the sequencing wizard.
3) Type in a name for the package and click “Next” to continue.
4) Select “Begin Monitoring” to start the monitoring process.
5) A dialogue will appear prompting you to create the asset folder on the Q:\ drive that should be in an 8.3 format. Unlike older versions of the sequencer you are forced to define this configuration item for the sequence ahead of time. You can select the Q:\ drive and then click “Make New Folder”.
6) Remember the best practice is not to exceed a folder name that goes beyond the 8.3 naming specification. In this example I named the folder "WinRAR.001".
- Select the WinRAR.001 folder.
- Click OK.
7) The sequencer should take a moment before it is ready to monitor the installation, once it is ready you can then launch the application installer.
8) To follow best practices change the Destination Folder for the install to “Q:\WinRAR.001”.
9) Select “OK”.
10) Select “Done”.
11) As a matter of best practice you should launch the application at least twice to make sure the initial state of the application is the way you want your users to see it. Launch WinRAR.
12) Close WinRAR but open and close WinRAR a second time.
13) After WinRAR shuts down select “Stop Monitoring”.
14) Select “Next”.
15) This page will still let you define what shortcuts are available as well as modify file associations and shortcuts before you save your sequence. Since we won’t be making any changes, click “Next” to continue.
16) Since we did not configure feature block one on the previous screen we are presented with a warning. Click “Next” to continue.
17) Select “Yes” to complete the sequencing wizard.
18) Select “Finish” to close the sequencing wizard.
19) In the sequencer application perform the following.
1) Go to the “Deployment” tab. In order to publish my application.
2) Change the Protocol field to RTSP.
3) Edit the Hostname field will have the server name 46labms1.
4) Edit the path field to be WinRAR-V3.92B1-WinRAR.001.
5) And before I am finished with the tab I will add Windows 7 64-bit and Windows 2008 R2 Terminal Server 64-bit to the list of operating systems able to run the sequence. Remember this doesn’t necessarily mean the sequence with run on the additional operating system but we will attempt to test it on Windows 7 x64 but before we do we need to make it available for that operating system using the dialogue below.
Also note the “Generate Microsoft Windows Installer (MSI) Package checkbox below. If you need to generate a MSI for application deployment it is as simple as checking off the checkbox. With the checkbox in the on position a MSI file will be generated along with the rest of the sequence files when you save the sequence.
20) Go to the “Package” menu and select “Save”.
21) What I like to do is save the sequence locally.
- Click the new folder icon.
- Rename the folder to WinRAR-V3-92B1-WinRAR.001.
22) Open the folder you created and name the file name WinRAR-V3-92B-WinRAR.001.
I’ll save you the step by step of publishing the application but as you can see I’ve launched the application sucessfully on Windows Vista Enterprise SP2 x64.
Now let's see if the same sequence works on on Windows 7 Enterprise x64.
And to take things a step further, let’s see WinRAR running on W2K8R2 in Terminal Server mode.
App-V Sequence Portability
The great thing with App-V 4.6 is the amount of sequence portability you can gain, many of your sequences that have been sequenced on 32-bit platforms should see portability much like what I have achieved with my 64-bit application. Specific to 64-bit environments items such as registry and file redirection that changed in Win7 and Server 2008 R2 can be successfully navigated using App-V. The key for maximum value with App-V is to sequence once and deploy to many. The following chart should help you understand the sequence compatibility matrix so you can get the most bang for your buck when moving to 4.6. (Yes, this means you don’t have to necessarily re-sequence everything)
In order to achieve the best economics you have to make a strategic call on what platforms to use for sequencing. The strategy that is commonly employed is called the lowest common denominator method where the oldest operating system in production is used as the primary platform for sequencing. I’m not going to go into too much detail because there is more at play with the design than just the least common denominator but it is the foundation of a sequencing environment. How does 64-bit play into this? I would say the textbook answer would be to use the 32-bit operating system as the least common denominator operating system but in the real world you may be able to use the 64-bit equivalent instead and get very high success rates with regard to sequence portability. But in the real world you will likely need a sequencing equivalent for each operating system that has been deployed because in some cases a matching sequencing platform is needed to resolve an issue you may be having where you cannot port a sequence from an older operating system to a newer one.
Conclusion
App-V 4.6 offers many new possibilities when it comes to application deployment on the desktop and terminal server environments. Because App-V can service both x86 and x64 environments effectively while the complexity and effort involved with deploying applications across different platforms is reduced resulting in savings for the organization. Being the only product that supports virtualization of 64-bit applications this opens the door on what used to be a major pain point for systems administrators. Now the management benefits of virtual applications can be extended to your 64-bit application portfolio and 64-bit hosts.
Introduction
Since the release of Windows Vista application compatibility shims have been getting plenty of attention as organizations try to find solutions for applications that have migration issues when a new operating system is introduced into their organizations infrastructure. Interest from organizations looking to deploy Windows 7 has brought even more attention to the technology and in a way spurred further development of the Application Compatibility Toolkit; a free toolset provided by Microsoft to identify and manage application compatibility issues. This toolkit provides the ability to create what are called shims to that allow older applications to work with newer operating systems. Most of the confusion I see out in the App-V community is when to use App-V to solve a compatibility issue and when to use the Application Compatibility Toolkit so let’s explain what App-V can do then take it from there.
App-V and Application Compatibility
App-V is sometimes referred to as an application compatibility technology but it really isn’t a good technology in that context. App-V can do many wonderful things but the architecture doesn’t really address the majority of programming level incompatibilities with a new operating system. App-V has a virtual registry and virtual file system which is part of the SystemGuard™ technology that isolates the application from the operating system and other applications. The SystemGuard™ allows applications that are not well written for users who do not have local administrator rights to run the application in a sandbox where they are effectively a local administrator when it comes to the virtual file system and virtual registry.
High Level View of an App-V Application
On more rare occasions App-V may be used to overcome issues with software installers on newer operating systems by sequencing (packaging) the application on an older operating system then running that sequence on a newer operating system. Also in even more rare occasions this process allows the application to be packaged with older shared DLLs that the application may be compatible with but this sometimes does not work out because newer operating systems may not be compatible with these old DLLs that exist inside the sequence. In short we have learned the following about App-V and application compatibility.
· Can be used to mitigate issues where applications need admin access to registry and file system.
· Using an older operating system application installer compatibility issues can be overcome.
· On a rare occasion older DLLs can be captured inside the sequence to provide compatibility.
Application Shimming
Application shimming however is a completely different technology and approach to application compatibility. In a way this is the way application compatibility should be done because the application compatibility shims behave much like downgrading DLLs to older versions on a system but the way this effect is achieved isn’t quite so simple but the end result is more complete.
Some of the best hacks I’ve seen on the Windows platform involve what is called API hooking where the API call from an application is intercepted and redirected using linking. How this works in a nutshell is that the Windows Portable Executable (PE) using the Common Object File Format (COFF) specification contains headers (for things such as shared libraries) that provide a layer that can be used for indirection between the application and the linked file. At the core of this is the Import Address Table (IAT) that facilitates this indirection functionality. Essentially the table is built when the application is loaded but the shim engine can change some of the data being populated into this table to redirect API calls that normally go to the operating system.
Application Calling Windows Function Using the Import Address Table
In this example a Windows API call is put through the Import Address Table which then ensures that the correct shared library is called to fulfill the request.
Using the Import Address Table to Access a Shim
This example is much like the last except the Import Address Table redirects the call to a specific shim that imitates the API but has a different behaviour.
With the call being redirected to alternate code we can provide functionality to the application that didn’t previously exist in the operating system but what actually supplies this functionality? Most shims use helper DLLs that aren’t technically part of the operating system but are loaded by the shim engine when the application executable loads. Many off these DLLs are prefixed with AC* and exist in the C:\Windows\AppPatch folder of the system where they affect the behaviour of many system APIs. For example these are the DLLs on my Win7 x64 test machine.
These shims are applied based on properties of the executable so that the correct shim(s) are loaded for the application. Typically acgeneral.dll or aclayers.dll is used at this step to provide very generic compatibility fixes between the application and operating system such as operating system specific behaviours in older operating systems. The next type of shim is acspecific.dll where specific behaviours are applied such as a fix to an API to make it work correctly may break an application therefore a shim is needed to provide a behaviour the application required to operate properly even though the application is relying on a bug to function correctly. The third type provides flags to least privileged user account (LUA) or the application installer. The final type involves in memory patching of the executable rather than a traditional API hook.
Now you might be wondering with all this hacking going on is my system going to be safe and secure? All the code that runs within the shims must adhere to Windows programming standards and that includes the Windows security model. You may be able to lie to an application that it is an administrator but unless the user is actually elevated or the registry / file ACLs are loosened the application will still fail due to lack of privileges.
App-V and the Shim Engine
Now that we have an idea as to how both technologies address application compatibility how do we get these two technologies to work together so that we can have the best of both worlds? Well the answer is somewhat complicated so we will address how the shim engine and App-V can interact. The shim engine is loaded by kernel32.dll which is in user mode but it is essentially a part of the operating system. If we look at how App-V isolates applications we know that applications are isolated from each other to a great deal leaving only copy / paste, DDE and File Type Associations as methods of communication between virtual applications. Virtual applications can use COM objects, OLE interfaces, printers etc… from the operating system but the operating system is limited to copy / paste, DDE and File Association as methods of communication with the other virtual application(s).
App-V Communication Overview
What this all means is that the shim engine cannot see shims inside sequences because of the isolation that makes the product such a useful tool. When you apply a shim using the sdbinst.exe utility the shim settings are applied inside the sequence so that when the application is run the shim engine cannot go inside the sequence and read the required configuration information to modify the import address table. For example you can find your application compatibility flags in the local registry under the following locations.
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags
Conclusion
So how do we take advantage of shims with App-V? Well the first and most important lesson is that the shim must be installed to the operating system in order for it to function correctly with the shim engine. The virtual application can take advantage of the shim because its import address table can be built properly by the operating system and will redirect / modify API calls handled by the shim engine to effectively fix the application. Now that I’ve explained the architecture you can look forward to my follow up post that will focus on how to apply a shim that can be used with a virtual application and more importantly how to manage shims for virtual applications.