Independent App-V Blog

Just Zarb wrote a nice approach when an organization is starting on virtualizing their application portfolio.

The first step in such a project is to identify which applications are installed and used in your environment. If your application delivery method currently consists of automating applications you probably have a good insight in this information. Software distribution mechanisms (like Microsoft System Center Configuration Manager) usually provide great reports for this particular scenario.

If you don’t have an ESD in your environment you might want to look at the freely available Microsoft Application Compatibility Toolkit, which has some basic inventory functionality as well.

Now having software installed on your enterprise workstations doesn’t mean that the application is mandatory for the end-user or the organization. More than once when I support customers in this particular process, application reduction is one of the most time consuming activities. Mostly due to political discussions.

Once you know which applications need to be deployed throughout your organization you should find out if there are good virtualization candidates.

Microsoft evaluates the potential candidate and places the application into one of three categories:

Ideal Candidate. Applications meet all of the possible candidate criteria and have no identifiable roadblocks to success.

Possible Candidate. Applications do not meet disqualifying criteria but may require additional research or validation.

Not a Candidate. Applications are more expensive to virtualize than the benefits achieved from virtualization. This category also includes applications that technically cannot be virtualized because of current limitations.

Remember that virtualization candidates are not only based on technical limitations of the application virtualization product you are using. Sometimes functional restrictions can weigh just as much.

Original article here.
Microsoft case study here.

It is a fact that many applications require other applications to run properly. In App-V these dependencies can be sequenced along with the main application in the same virtual environment or they can be sequenced separately and joined together through Dynamic Suiting Composition.

In the old days we could use the “Run another program first” on the Advanced tab of the Program properties option to chain two applications together. But since App-V applications don’t have Programs we can’t use this anymore.

Luckily this issue can be solved by using Configuration Manager 2007 Task Sequences.(continue at source)

So Windows 7 reached Release Candidate status last week and even earlier Microsoft released Cumulative Update 1 for App-V and now supports Windows 7 as a platform.

So you got out and downloaded the RC as well as CU1 for App-V through either the MSDN or licensing websites. You deploy your virtual applications just like you did on your mainstream platform but it doesn’t work. The applications don’t seem to get added to the client cache. "This App-V technology should ease my future OS deployments, right?" So why isn’t this working?

During the sequencing process you have selected Operating Systems that the application was supposed to work on. You have probably selected some or maybe all the available Operating Systems in the list, but definitely not Windows 7 as it was not available in earlier version than CU1.

The behavior on the App-V client is that prior to adding the application it will check if the Operating System it is currently running on is supported by the application. It does this by checking the OS VALUE tag in the OSD.

To be clear: this is done on application level, not on package level. It’s not likely but if the package has multiple applications associated with it (like Microsoft Office suite has) it might be that one application will be added while others might not depending on this tag and the way you have implemented it in your organization.

Anyway, if the Operating System is not listed the application simply won’t be added.

If you check the log you would see two messages related to this error:

The Application Virtualization Client could not parse the OSD file ‘C:\PATH\xxx.osd’. Reason: No valid implementation for this machine (rc 07708804-00000007)

The app manager could not create an application from ‘C:\PATH\xxx.osd’ (rc 07708844-00000007)

The solution to this is fairly simple, just add the tags to the OSD. This can be done in different ways:

Using the sequencer

The sequencer that you created the applications with, doesn’t hold the Windows 7 key. The version that came with CU1 does, version 4.5.1.15580.

Simply open the package and go to the deployment tab. You’ll see the Windows 7 option available here. It’s actually called Windows 7 32-bit already, probably preparing on future 64-bit versions of App-V.

Edit the OSD directly

By using a text editor or a script you could edit the OS VALUE tag in the OSD. The tag you want to add is Win7. So the result should look something like this:

Note: Be aware that if you are using the MSI option to deploy your virtual applications the OSD’s used by the installer are inside the MSI. So after you edit the OSD you need to recreate the MSI. This has to be done through the sequencer either manually (Tools-Create MSI) or automatically (SFTSequencer.exe /MSI)

Future Ready?

So all applications are updated to Windows 7 and you can enjoy (hopefully )testing them on the new platform.

You should ask yourself however if you want to go through this situation again when the next Microsoft Operating System comes along. Because a new Operating System will probably bring a new tag along with it which then has to be updated throughout the OSD’s again.

One way to avoid this situation is to have no limitation on the application whether it will deploy on a certain platform in the first place. Of course there is no guarantee it will work properly, but why restrict it from technical perspective? Another approach is to allow it to run on every platform except when you determined it isn’t suppose to.

This can be achieved in App-V by not mentioning any OS VALUE tag at all, either by removing all of them from the OSD or not selecting any OS in the deployment tab of the sequencer.

Now the client won’t decline any OSD on any platform, so you are ready for every operating system to come.

Maybe something to consider if you go through updating all your OSD’s?

Using Security Descriptors
When using the new App-V 4.5 sequencer, Security Descriptors are switched on by default.

But what is this security Descriptors function in the first place? How does it work? And is it of any use at all? In this article I will answer those questions.

What are Security Descriptors?
One of the big Advantages of SoftGrid always was that users could work with their applications like if they had Full Control rights. This was a huge advantage especially in Terminal Server environments where administrators usually put a lot of effort in getting applications to work on one hand and securing the Terminal Server environment on the other hand.

By enabling Security Descriptors during sequencing an application (switched on by default), permissions on the windows file system are “pulled into the bubble” (not the registry, thanks for the heads-up by Brian Kelly).  The sequencer always captures security descriptors during sequencing, but only with the Enforce Security Descriptors setting checked, the client enforces them on the file system drive at runtime.

So if a users group on the Sequencer had read rights on the D:\APP-X folder, these rights are stored in the Virtual Environment. Once streamed and run on the client, the user cannot edit in this particularly folder. In this manner you can set permissions on parts of the Virtual Environment and secure parts of being modified by a user.

How does it Work?
Like I mentioned before the enforcement of Security Descriptors is switched on by default. You can find the check box on the new Deployment tab of the Sequencer’s SFT-editor:

So if the check box is switched on the permissions are stored inside the virtual environment.

What’s the use?
Good question! Like I mentioned above, one of the biggest advantages of SoftGrid always was that users had sort of Full Control rights within their virtual environment. The advantage especially for Terminal server environments was huge.

I don’t see the advantage of switching the “Enforce Security Descriptors” setting on by default. I can imagine this option can be useful with some applications which need to have certain restricted permissions on parts of the virtual file system. For instance, some (badly written) applications need to have restrictions on parts of the virtual file system to ensure that settings don’t get corrupted or that .PKG files don’t grow excessively.

Because this situation only applies to some applications it is my opinion that the Security Descriptors should not be switched on for every application but just for the applications where you’re facing a problem that can be solved by using Security Descriptor Enforcement.

How to switch the enforcement off by default?
This is not too difficult. The first step is to create a default.sprj (if you do not already have one):  Launch the Sequencer, go to the tools menu and select options. On the options screen go to exclusion items and click on “Save As Default”.

I know this is a weird place for saving default settings. Don’t bother and just browse to the program directory of the Sequencer (by default  C:\Program Files\Microsoft Application Virtualization Sequencer) and open the default.sprj file. This is an XML file. Besides a lot of other settings, you can also set the Security Descriptors option in this file. Just set the value of the “UseSecurityDescriptors” option to “No” and you’re done.  

January 26th 2009 Posted to Sequencing, App-V Q&A by Jan

An article has come to my attention recently (whilst being available for some time) which addresses some issues in how to make the .NET framework available in conjunction with virtual applications.

Microsoft has made several architectural changes in the implementation of Microsoft Application Virtualization (App-V) 4.5 to ensure that the product is aligned with our roadmap for future innovation. One such change entailed moving the API intercepts from kernel mode into user mode. This change had a side-effect of changing the App-V compatibility with the .NET Framework from previous versions of App-V.

App-V 4.5 continues to be fully compatible with .NET applications. The change in compatibility only manifests itself with the .NET Framework.

This table summarizes the requirements for .NET support in APP-V 4.5.

Read more at source.

In my previous post on the coexistence of the SCCM client and the App-V client on the same box I mentioned that the SCCM client will take control of the delivery and streaming of virtual App-V applications once it’s installed.

Aaron Parker posted a follow-up to this post in which he mentions that this behavior only occurs if you’ve allowed the virtual application package advertisement on the Advertised Programs Client Agent properties.

I did indeed forgot to mention that. Thanks Aaron!

Read more at source.

If you install the SCCM client on a machine on which the App-V client is installed, your current applications will no longer work and fail with the following error: Unable to initialize package information (0×00000000)

After the installation of the SCCM client the App-V client cache will be flushed and if you set up a publishing server you will recieve the published applications but they will fail to stream and start.

This is caused by a changed in registry during the installation of the SCCM Client:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\UserInterface

This means that when the SCCM client is installed on the system it is expected also to handle virtual application launch and stream.

I’ve seen that changing the registry back to the original value will make streaming available however if this is a supported scenario, I’m not sure. The SCCM client might change the value back in time.

When it comes to environment variables in Microsoft Application Virtualization it’s good to know how the sequencer handles them.

When an environment variable is changed during the monitoring phase of the sequencing process the sequencer picks it up. This works for both User environment variables as well as System environment variables.

After the sequencing process is done and the project is saved they end up in the OSD file under the <ENVLIST> section.

It’s good to know that the sequencer at this moment will detect if directories are referenced in the environment variable and automatically translates them to the appropriate %CSIDL_ or %SFT_MNT% variable.

Be careful however with referring to the hardcoded drives because this directory will not always be replaced with the %CSIDL_ variable. For example if you created a directory in the root of C:\. If your destination doesn’t have the specific drive and directory the application might fail.

During launch of the application all environment variables in the OSD will be treated as user variables during the use of the application. Also the ones that were captured as system variables. But be aware that the ENVIRONMENT tag in the OSD will override an existing system environment variable for that user’s session.

Usually applications don’t care if the environment variable is user or system based. However there are cases where badly written applications don’t check the variable but check the registry instead. Environment variables are (normally) saved in:

• HKEY_CURRENT_USER\Environment
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

If your application is not working with the environment variables in the OSD you can always try adding the variable to one or both of the registry keys above.

To do this you could use a prelaunch script to add the registry key:

<SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="FALSE" PROTECT="TRUE">
<SCRIPTBODY>cmd /c REG ADD HKCU\ENVIRONMENT /V _USERENV /T REG_EXPAND_SZ /D "USERVALUE" /F</SCRIPTBODY>
</SCRIPT>

This cannot be done for the HKEY_LOCAL_MACHINE key due to limited user rights. Instead just simply add it in the sequencer, either in the Virtual Registry tab or during monitoring phase.

Hope this saves some troubleshooting time!

Well if you have a minor change like a registry key or an .INI file, you don’t have to Sequence again. You can easily script changes into the virtual environment of an already deployed application. You don’t even have to use the Sequencer for this. Just edit the applications it’s .OSD file with the Login Consultants OSD Editor or something else that can edit XML files, like notepad.

Check the Microsoft KB939085 to learn how to run scripts in an .osd file in App-V.

Now that App-V 4.5 is RTM a lot of folks are thinking about or actually getting ready to deploy the App-V 4.5 client.

If you have System Center Configuration Manager 2007 as a distribution system you can find information about How to Install the Microsoft Application Virtualization Client here.

The article is mentioning the following prerequisites that must be installed on the Configuration Manager 2007 client computer:

• Microsoft Application Error Reporting – For more information about installing Microsoft Application Error Reporting, seehttp://go.microsoft.com/fwlink/?LinkId=116684
• Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) – For more information about installing Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) see http://go.microsoft.com/fwlink/?LinkId=116683

Is doesn’t mention Microsoft Core XML services (MSXML) 6.0 SP1 however, but if you are using the setup.exe this prerequisite will also get installed for you (if not already present)

If you are troubling the the command-line for client installation you might want to check out this article, which discusses How to Install the Client by Using the Command Line.

And if you are looking to customize your installation with setup parameters you can check out this article which discusses the Application Virtualization Client Installer Command-Line Parameters.