App-V: On App-V Applications Hosted in Azure RemoteApp

With the release of Azure RemoteApp, Enterprise customers can now move their non-persistent RDS session-hosted applications from the on-premises data centers into a hosted cloud – with the Azure platform providing all of the necessary image provisioning and updating services. With Azure RemoteApp, you can use gallery templates or your own custom image. In addition to your own custom image, you can leverage virtual applications using App-V. With App-V, you can reduce the size of your custom image uploads by streaming the content on-demand.

Right now, App-V support in Azure RemoteApp is limited and licensed to only hybrid collection deployments. This is due to the current licensing requirement of App-V needing to be on domain-joined computers. While you could use a cloud collection to test a virtual application, in order to take advantage of the image reduction features of App-V with Azure RemoteApp – and to have full supportability and license compliance, the implementation within Azure RemoteApp would need to be joined to a domain within a hybrid collection deployment using a Site-to-Site VPN.

Setting Up Azure RemoteApp Images

Before you set up your image for Azure RemoteApp, you will need to first set up your Azure RemoteApp Subscription at https://www.remoteapp.windowsazure.com/. In addition, you will need to set up Azure PowerShell on the machine where you will be uploading the image. You can download Azure PowerShell here at the following link:

http://azure.microsoft.com/en-us/documentation/articles/powershell-install-configure/#Install

There is also existing guidance for configuring a custom RemoteApp image for uploading:

http://azure.microsoft.com/en-us/documentation/articles/remoteapp-create-custom-image/

Make sure you follow everything specified in the documentation and no steps are missing when configuring the VHD including disabling encryption and ensuring the partitions are MBR-based. For App-V considerations there are some additional steps that you will need to ensure are included with regards to configuring and preparing the image.

Configuring App-V Client and Pre-requisites

• In Server Manager, make sure .NET 3.5 and 4.5 Services are configured as features for Windows Server 2012 R2.
• Install the most recent App-V 5 Client.
• Install the App-V Client pre-requisites here: https://technet.microsoft.com/en-us/library/jj713458.aspx
• Configure the App-V Client as required (script enablement, etc.)

Publishing Applications

After the App-V Client has been configured, you will need to add and globally publish your virtual applications using PowerShell. You can do this using the built-in App-V PowerShell Cmdlets referenced here: http://technet.microsoft.com/en-us/library/dn508409.aspx. Whether you are using hybrid or cloud deployments, only globally published applications will fully survive the generalization (as well as picked up by the RemoteApp provisioning) so it is currently a hard requirement.

Testing and Final Preparation

You should test and verify your applications within the image prior to uploading your image. Finally, before generalizing your image with the SysPrep tool, you will need to perform a current workaround that involves an issue with App-V and SysPrep. You will need to stop the AppV Client Service and delete the local VFS Folder under Local AppData (%LOCALAPPDATA%MicrosoftAppVClientVFS.)

Also remember, if the image you are uploading is drastically behind in operating system updates, it will further delay provisioning after uploading.

The last thing you will need to do is generalize the image using the command line:

C:WindowsSystem32SysprepSysprep.exe /generalize /oobe /shutdown

Creating the Collection

You will need to create an Azure RemoteApp collection to house the image and published applications from that image. You can use this quick reference for the details: http://azure.microsoft.com/en-us/documentation/articles/remoteapp-create-cloud-deployment/

In order to upload your custom image containing your virtual applications, in the collection dialog, you will need to click “Template Images.” You will then specify to upload a RemoteApp template image:

After you have given the name and location, it will take you to the next screen where you will download a PowerShell script that you will use to upload your VHD to the correct Blob.

Once you download and run the command from an elevated Azure PowerShell session, it will mount, validate, and fixup the image and then proceed to thoroughly check the integrity and then finally uploading to Azure.

While the image is uploading, the status will remain “Upload pending.”

Once the upload is complete, you can then apply the template image to a collection.

Once the image is associated with a collection, the provisioning will begin. This may take a while. It will show a status of “Provisioning” until it is finished fully prepping the image and parsing for applications.

Once the applications become available in the “Publish RemoteApp Programs” screen, you will see that the AppV programs will show alongside the native applications. These application were queried upon the provisioning that occurred after the collection was created. The AppV applications will be the ones originating from the AppV Client’s PackageInstallationRoot (which by default is C:ProgramDataAppV.) Once the applications have been published and user access has been configured, you can then download the Azure RemoteApp RDP client from:

https://www.remoteapp.windowsazure.com/

Once you download the ClickOnce application, you will be prompted with a wizard upon first launch:

The first item you will need to do is supply the appropriate credentials. You will need to supply a corporate account or an MSA.

After you have been authenticated, you will see your published applications (both native and virtual applications) assigned and published to the user. You can then begin to test virtual application behavior in Azure RemoteApp.

App-V 5: On Java Virtualization Strategies

Throughout the past 15 years, from its origins in Softricity, one of App-V’s primary use cases has been addressing complex version-dependent Java run-time ecosystems. The “Application-to-Application Isolation model” of App-V – particularly using JRE runtimes as a test case – proved much success for those applications and enterprise websites that were married to a specific runtime – and needed to be used by the same user and/or multiple users on the same machine. As Softgrid became App-V, the client engine developed more and more methods of further, optional integration into the operating system via advanced extension points as well as dynamic virtualization (or just-in-time virtualization.)

Fast-forward to today: While the many of the old traditional issues that came with DLL Hell (such as DLL stomping) were rectified via registry-free assemblies and WinSxS, managing multiple JRE runtimes still requires intervention – especially when deployed to pooled session and virtual desktop environments (i.e. Citrix XenApp, MS RDSH/RDVH, etc.) As “JAR hell” as it is often called – appears to be here to stay for a while, JRE isolation is still one of the top use cases for App-V as a result.

Historical Strategies

In the world of Softgrid up until Softgrid 4.1, the strategy choices were simple:

• Single JRE (Virtualize None): The most desired scenario. This simplified deployments and allowed for JRE to be included in base operating system deployment images.
• Virtualize All JRE’s: No native JRE images in the base image. All versions are isolated using App-V.
• Virtualize all but One JRE: In this scenario

In addition, the versions of Java had to be sequenced within the same virtual environment as the parent application. This would eventually start to change with App-V 4.5. In that particular release, DSC (Dynamic Suite Composition) was introduced allowing applications dependent upon Java to be sequenced separately from Java and linked together.

Methods

With the release of App-V 5 and its subsequent iterations, the options for Java have become more flexible.  However, since the primary reason for virtualizing Java is to be able to deploy multiple versions of the run-time module to same virtual or physical machine, all options for virtualizing Java are not necessarily on the table. Each option must be assessed on its own merit. The potential strategies for Java are as follows:

Packaged with Application or Browser

This is where the specific JRE middleware is installed alongside an application within the same App-V package. Not a very common solution as it requires the master application to be updated as the runtime needs to be updated. Because of the many issues that come with this, Dynamic Suite Composition was introduced in version 4.5. This was later improved with Connection Groups in V5.

Connection Groups and Challenges

Connection Groups are where two or more applications are sequenced separately and brought into the same virtual environment (essentially a meta-bubble.) This was introduced first in App-V 5 and then drastically improved for 5.0 SP3. This allows for the capability of updating applications and pre-requisite JRE packages independently. Connection Groups for Java run-times can be challenging – especially on RDS systems where many different users are running multiple applications dependent upon the same version of Java. Once a Java Package was initialized, it can only run within one Connection Group at a time. This requires proper planning and potential silo-ing for RDS scenarios.

RunVirtual

This is where a designated native application is linked to a virtual environment. RunVirtual (in its many forms) tells a native application to run within the virtual environment of the assigned application (as well as its connection group if the application belongs to one.) RunVirtual is a great solution for those natively installed applications to take advantage of interoperability with a virtual application. The ways you can configure a native application to “Run Virtually” are as follows:

• The RunVirtual Registry Key: This works great as it is tied to the processes’ executable name. Can be configured per-machine or per-user starting with App-V 5.0 SP3.
• Configured Package Shortcut: This is a good solution as it travels with the package.
• Out-of-Band RunVirtual: Where a Shortcut or Command Line contains the /AppVVE or /AppVPID switch or uses PowerShell to run a native process within the virtual environment of specific package.

All of the possible options for launching a native process into a virtual package’s environment (bubble) are found here: http://blogs.technet.com/b/gladiatormsft/archive/2013/04/24/app-v-5-0-launching-native-local-processes-within-the-virtual-environment.aspx

Internet Explorer – A Worthy Separate Discussion

Internet Explorer warrants its own discussion primarily for two reasons:

• Internet Explorer cannot be packaged and isolated from the native operating system.
• Internet Explorer, like Explorer, is eligible for supporting primary and secondary virtualization environments through dynamic virtualization.

For those reasons, I segment my Internet Explorer and Java discussions from all other applications when discussing application virtualization strategies with customers.

Internet Explorer, Java, and RunVirtual

Configuring RunVirtual to bring the local Internet Explorer into the Java packages’ virtual environment is a simple way to allow for interoperability – but it can lead to its own issues:

• RunVirtual via Registry Key: Whether it is per-user or per-machine – this methodology forces IE to only interact with one Java package (or else yield potential issues with RunVirtual collisions. Use this solution if only one Java package will be needed virtually with Internet Explorer for the user (or the machine if configured for the machine.)
• RunVirtual using command line switches (AppVVE, etc.): This requires a lot of out-of-band shortcut management – but it does give flexibility so long as all other instances of Internet Explorer are configured for RunVirtual in either this manner or though packaged shortcuts.
• Packaged Shortcuts: Using shortcuts to the local Internet Explorer – either captured via sequencing into the package manifest or configured via dynamic configuration. This method will create a special shortcut that essentially runs virtual for the native Internet Explorer. It also travels with the package and as long as the naming is unique, it will not create two much confusion although it does mean that Internet Explorer must be launched using this specific shortcut to ensure it runs within the specified virtual packages.

When you weigh out the “perceived” complicated options for bringing IE into an App-V Java package by Pros and Cons, you can simplify it using the table below:

IE Options	Pros	Cons
RunVirtual through Registry Key (Global)	Simple to Deploy.	Does not Travel with package. One Java per IE per Machine.
RunVirtual through Registry Key (User)	Simple to Deploy.	Does not Travel with package. One Java per IE per User
Packaged Shortcut	Travels with package. Allows for multiple Java packages.	Creates Multiple Internet Explorer Shortcuts.
Out-of-Band RunVirtual (/AppVVE, etc.)	Allows for Multiple Java Packages.	Does not Travel with package. Creates Multiple Internet Explorer Shortcuts.

 

Connection Group with EBIS (Empty Bubble w/ IE Shortcut)

This is where Internet Explorer is treated as a separate package though the creation of an “empty” virtual package containing only an Internet Explorer shortcut. That empty package is then linked to a virtual Java package using Connection Groups. If you want to use Connection Groups to link Internet Explorer with virtual Java packages instead of RunVirtual solutions, this may be the better solution – especially if you will be running both native and virtual Java on the same machine or device.

IE Native w/ JITV of Plug-In – Dynamic Virtualization Only

I have been starting to see this on App-V test matrices and I am a little bit concerned as it adds unnecessary testing variables that can further delay a package’s movement through common UAT (User Acceptance Testing) scenarios. That is not the case.

Dynamic Virtualization (also referred to as JITV – or Just-in-Time Virtualization) allows for virtualization of shell extensions, browser plug-ins, and ActiveX controls for a virtual package within the native processes that are hosting the COM objects. They key item being COM OBJECTS. They all need dynamic virtualization of COM in-process objects. There are some exceptions to some browser plugins that only use HTML scripts. They use an object model completely separate from COM. Not all browser plugins require COM in-proc virtualization. Do you get where I am going here?

Adding One Final (yet significant Variable) – the Legacy 4.6 Client

Running virtual packages containing Internet Explorer in 5.0 side-by-side with Legacy 4.6 packages running Internet Explorer running side-by-side with the App-V 5 client is supported. They did, however, had some initial issues when ran with Internet Explorer 10 and 11 due to issues with Enhanced Protection Mode and some double-hooking issues that were rectified by Hotfix Package 1 for 4.6 Service Pack 3 (https://support.microsoft.com/en-us/kb/2897394.)

 

On App-V with Azure: Streaming Applications from the Cloud

In App-V in general, the Content Store (also referred to as the package source or streaming source) is the most critical in both traditional streaming (stream-to-disk) scenarios and Shared Content Store mode clients (stream-to-memory.) Traditionally, Microsoft recommends placing Content Stores as close as possible to end user devices when possible leveraging on-premise technologies such as DFS-R to for replication and location. But what about those customers who are looking to leverage cloud services for App-V content for either:

• Disaster Recovery/Business Continuity solutions

• Internet-Facing Scenarios

• Part of an overall strategy to migrate from on-premises resources to hosted cloud services.

When looking to deploy Content Servers in Azure for application streaming, it is important to plan for regional proximity with a mechanism for replicating uniform copies of the App-V content just as you would have done in an on-premises environment.

Why Azure Web Roles can work for App-V Streaming

The App-V Content Server in the cloud is simply a hosted web server virtual machine with attached storage configuration and a corresponding set of cloud services configured to allow downloading of APPV package content via HTTP or HTTPs.  This package source requires no additional management (other than security and MIME configuration for .APPV files) of the static package content and is simple to deploy and scale out as needed.

Cloud Services and Endpoints

Assuming you have established an Azure subscription, setting up the necessary services is essential however, a lot of the minor configuration will vary depending on how these cloud resources are integrated within your existing App-V infrastructure. For the sake of example, I will use the scenario of deploying a Content Server to the cloud for the purposes of providing cloud-based content.

In most cases, the order will be to:

• Create the Cloud Service – to allow access to hosted Content VM's over the Internet

• Create the Storage Account to store the VHDs.

If you want to learn more about Storage Accounts, the reference “What is a Storage Account?” http://azure.microsoft.com/en-us/documentation/articles/storage-whatis-account/ is a good start especially when understanding storage redundancy options.

• Create the Virtual Networks

In addition, you will be leveraging external-facing Virtual IP’s (Public IP) an internal DIP, and an Azure Traffic Manager resource

Why do I need a Cloud Service, Virtual Network, VIP and DIP?

If you want to learn more about Cloud Service, Virtual Network, VIPs and DIPs, I highly recommend Young Chou’s (My buddy in DPE from Charlotte, NC) article on Windows Azure Infrastructure Services IP Address Management – at: http://blogs.technet.com/b/yungchou/archive/2014/03/17/windows_2d00_azure_2d00_infrastructure_2d00_services_2d00_ip_2d00_address_2d00_management_2d00_part_2d00_1_2d00_of_2d00_2.aspx

In addition, the following tutorials can walk you through the process:

• How to Deploy a Cloud Service: http://azure.microsoft.com/en-us/documentation/articles/cloud-services-how-to-create-deploy/

• Setting up Endpoints: http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-set-up-endpoints/

• Content Management and Upload: http://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/

VM Creation and Sizing

Content Servers in Azure can be any operating system supported for web services. In the case of Azure, it will be Windows Server 2008 R2, 2012, and 2012 R2 SKUs.

For Virtual Machine sizing purposes, it is recommended to align and plan capacity for Azure VM’s using the same guidelines for on-premises using the official App-V Sizing document: https://technet.microsoft.com/en-us/library/dn595131.aspx

I have found in my early testing with customers and myself, it is economical to scale out Standard Tiers using A1 or A2 series VM’s and load-balance as needed since we are only serving up web content essentially. I’ll also explain another reason when diving into the streaming protocol selection.

Internet Facing Scenarios

For App-V client retrieving content from cloud-based servers, there are three important factors to consider:

• Streaming/Performance

• Streaming/Bandwidth Costs

• Security

Streaming

For Azure Web Services, streaming APPV package content from the cloud is quicker using HTTP although the tradeoff of non-secure transmission may not meet all security requirements of some organizations. For those organizations, additional security of the cloud services for HTTPS communications will be required. Also you will need to flip the App-V clients to use single-range HTTP communication as opposed to multi-range.

BranchCache is Your Friend

To ensure fast, optimal delivery for on-premises App-V clients, and to provide the best experience possible for devices that may use the stream-to-disk scenario with clients – it is recommended to have the clients configured for BranchCache in either hosted mode or distributed mode. In addition, it is NOT recommend the use of Shared Content Store mode for on-premise clients due to limitations of offline access and heavy latency with the single-range HTTP protocol. Potential latency that may come with Single-range protocols would be offset and optimized by use of the BranchCache protocol. In addition, BrancheCache can reduce traffic overall to the cloud.

Security

In addition to security content transmission, you will want to secure access between your on-premises clients and the Azure-hosted cloud services. If the on-premises domain for which the App-V Client’s belong is federated with an Azure AD domain, you can secure access through individual users. Otherwise, you will need to leverage an alternative solution for restricting access.

Whitelisting IP Address Access

You can restrict access by IP address range in at least two ways. You can leverage the existing IP and Domain Restrictions feature in IIS. This will also work to secure Azure App-V Content servers to only allow access to IP addresses and domains that you have specified in a whitelist. https://technet.microsoft.com/en-us/library/cc731598%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396

You can also secure access to the cloud endpoints using ACLS.  http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-set-up-endpoints/

Regardless of how the web service is secured on the back end. For streaming seamlessly, it is also recommended to add the URLs of the resources to the App-V Client’s Intranet Zone policy.

App-V 5: On the App-V 5 Virtual Registry

I have been meaning to follow-up my previous discussions of the App-V registry staging subsystem with an article on the virtual registry in App-V 5. I will admit I am a little late to the follow up, however, as they say “better late than never.” In previous article I discussed registry staging and its effect on publishing and streaming. Now the discussion continues with how the virtual registry handles operations once the virtual registry has been staged.

The Virtual Registry in App-V was implemented in a much more streamlined way in version 5 than in previous versions. First of all, real hive files are packaged with the APPV package format. In addition, the real registry is used where the actual locations are state-separated while the Virtual Registry component provides the correct redirection and COW (copy-on-write) operations merging 3 elements into a single registry view:

• The native registry

• The immutable staged package registry (built from the registry.dat file within the package)

• The user and machine COW registry

Like with file assets, the view of each merged registry is done for each package and package group (virtual environment)

Functionality

At runtime, registry operations are hooked, and special sauce is made to ensure the redirection, registry merging, and copy-on-write operations of changes are done.

Registry reads are done in an ordered approach by layer and you can easily confirm this with Process Monitor. The order is:

• The COW registry is read first

• Followed by the Package Registry (constructed from REGISTRY.DAT)

• Finally the native registry for the requested location.

For registry writes, things are much simpler. Registry writes always go to the COW location corresponding to the original key that was opened. Registry data that is written to the user’s roaming registry is tokenized so that it is portable across machine boundaries.

Bear in mind, this is based upon the predication that the registry location is viewed as virtual (opaque) to begin with and was not excluded or configured to be translucent in the sequencer. There are special pointers contained in the registry that will govern opacity that I will mention later.

 

Registry COW Locations

The Virtual Registry will manage and track all COW locations for registry storage. The locations will vary depending on security context and type.

Roaming User Registry COW data will go here:

• HKCUSoftwareMicrosoftAppVClientPackages<GUID>REGISTRY

• HKCUSoftwareMicrosoftAppVClientPackageGroups<GUID>REGISTRY

Non Roaming User Registry and non-elevated Machine Registry COW data will go here:

• HKCUSoftwareClassesAppVClientPackages<GUID>REGISTRY

• HKCUSoftwareClassesAppVClientPackageGroups<GUID>REGISTRY

For Machine registry data coming from elevated processes, the Registry COW data will go here:

• HKLMSoftwareMicrosoftAppVClientPackages<GUID>

• HKLMSoftwareMicrosoftAppVClientPackageGroups<GUID>

 

Special Registry Key and Value Metadata

You may have noticed that for some keys, you will also see some additional data:

This data is not on all keys but when it is, it is reflective of the specific state of the key when responding to registry operations. Particularly, whether the key was previous deleted or if it was configured to be opaque and not merged with the other registry layers.

• 0x00010000: Key Deleted

• 0x00020000: Value Deleted

• 0x00040000: Key Opaque

If the value above also contains a 1 at the end of the type, this means there are sub keys present stored within the value data.

Purging the COW

The Registry COW data is purged along with the rest of the user state when the package has been deleted or when the package is repaired with the –userstate switch.

Recommendations for Ignite 2015

Better Dynamic Application Delivery through UE-V & App-V:

Aaron Ruckman and myself will be discussing recent and forthcoming innovations with App-V and UE-V as well as some general recommendations including some you may have never heard of before.

http://meme.ms/d5cdr3p

App-V 5.0 SP3: Advanced Connection Groups:

Briton Zircher and the Virtual Vibe Guy Thamim Karim will be discussing how to implement advanced Connection Groups and the recent development involving creating complex virtual environments.

http://meme.ms/d5ki5is

Fundamentals of Microsoft Azure RemoteApp Management and Administration:

You should turn out for this one as it is jammed pack full of information relating to Azure RemoteApp including some information on App-V possibilities.

http://meme.ms/d5jqcah

Microsoft Office 365 ProPlus: Have It Your Way!

Office365 offers many flexible options for deployment of the Office Client. This presentation will cover these options.

http://meme.ms/d5e74fu

Deploying Office 365 ProPlus Using System Center Configuration Manager:

This presentation outlines the pros/cons of the new Application-model versus Package-model deployment types and introduce a hybrid Application-model deployment using a Cloud DP.

http://ignite.microsoft.com/session/sessionmoreinfo/?topicid=1dd80124-2795-e411-b87f-00155d5066d7

On Office with App-V: Planning for a Virtual Office Deployment

Microsoft Office: A flagship product suite ubiquitous within the enterprise. The average enterprise IT environment runs multiple versions of Office not only as a suite of applications for the average information worker, but also as a platform for custom and mission critical LOB applications and workflows. As Office continues to grow or evolve, the question of whether or not to virtualize all or parts of one or more versions of Office are revisited on a regular basis.

Reasons to Use App-V with Office

There are many significant reasons why you would want to deploy office through App-V. Some of the more common are:

1. Legacy Add-in Version Isolation through Virtualization: Office is also constantly evolving. As a new version is released, applications that work with or interact with an Office application may not work on a new version of an Office application. For example, you may have a legacy Add-in that works on Excel 2007, but does not work on Excel 2013. For that reason you create an App-V package that contains Excel 2007 along with that legacy add-in (or linked through connection groups.) This allows the application add-in/plug-in to continue to be used alongside of the newer deployment.

2. Temporary Coexistence: Multiple versions of most Office applications can run side-by-side with a few caveats smoother with App-V than with native deployments. While App-V can be used with many applications to run multiple versions of the same applications, Office has some additional guidance [which will be discussed in a later blog in much greater depth.]

3. Package Modernization Strategy Alignment: App-V allows for Office to be delivered via streaming in a flexible, portable format and take advantage of features of App-V such as the Shared Content Store.

In many cases, the version of Office you choose to virtualize will align with the reasoning. For example, you may be involved with a deployment of Windows 8.1 with Office 2013, and to ease transition, deliver an App-V package of Office 2010 applications for temporary use. You could also deploy Office 2013 via App-V to an existing Windows 7 base running Office 2010 due to a change in packaging strategy.

A Little History

A common question asked revolves around which versions of Office can be virtualized and what specific limitations will be encountered. To answer this – even at a 50,000 foot level – involves a historical discussion to better understand how the process and guidelines evolved with customer desires. As a result, the history affects version capabilities when running under App-V.

Office 2003/2007

Back in the day, when App-V was called Softgrid, prescriptive guidance documents were published on how to sequence Office 2003 and Office 2007 with Softgrid. It was a complicated process, but the isolation allowed for the resolution of some compatibility issues. There were a few caveats:

• Applications could not self-heal.

• Integration was limited without disabling some virtual subsystems.

• Volume-licensed installation media was required.

There were other limitations involving client-server capabilities as well. When App-V 4.x and 5.x were released, no additional integration was developed due to the age of these products. Still generally, in most cases, these versions of Office are virtualized primarily for legacy add-in scenarios where only specific Office applications are packaged with App-V (Excel, Access, etc.) and they can still be done with success.

Office 2010

With Office 2010 came a few changes that would affect how Office would be deployed with App-V. First, Office moved over to the software protection platform that previously only used for operating system product activation. As with previous versions of Office, only volume-licensed media was supported for sequencing. In addition, a special component needed to be laid down natively in order to allow the activation of Office through either MAK (Multiple Activation Keys) keys or through a KMS (Key Management Server) Server. Hosts activated via a KMS have to report back to that key server once every 180 days. Like with the native Office format, you could also verify activation status with the OSPP.VBS script.

In addition to the software protection platform, the native component (which would become known as the ODK – Office Deployment Kit) included special virtualization handlers (or proxies) that would allow for better Office integration than we had before (MAPI, Search, SharePoint, OneNote) with previous versions of Office with App-V. This special integration allowed for the base applications to remain isolated but have better native integration with enterprise components. This would become a fine line to walk. Isolation is the opposite of integration. It is impossible to fully have both. The ODK would become the best solution.

2010 – App-V was not Click-2-Run

Beginning with Office 2010, a new format that was based on App-V technology was introduced for only Microsoft Office Home and Student 2010, Microsoft Office Home and Business 2010, and Microsoft Office Starter 2010. This was a portable streaming solution called Click-2-Run or Click-to-Run. Click-to-Run was not available in the Enterprise initially and was not to be confused with the enterprise deployment of Office using App-V. Click-to-Run behaved like a native Office installation to the introduction of dynamic virtualization technologies thus, in essence, it was simply an alternative installation format that allowed for speedy quick deployment and/or upgrades to Office 2010 for consumer users.

2013 – App-V IS Click-2-Run

Well, kind of. It comes from Click-2-Run. With the success of Office 2010 Click-to-Run, the birth of Office 365 and subscription-based deployments, and the desire for better virtual integration within the Windows shell on top of the existing integration components brought forth the solution for Office 2013 – flattened Click-to-Run.

The ODT

Instead of having to manually sequence the Office package, you will use the ODT (Office Deployment Toolkit) to download and create (flatten) the APPV package. The Click-to-Run download from Microsoft will serve as the APPV package once it has been flattened. The packaging process with flattening involves converted the STREAM.DAT file into the AppV package format alongside of generating the registries and manifests. Finally an INTEGRATOR.EXE component is embedded into the package and configure to deploy automatically via a package script when the APPV package is deployed. This integrator is the next generation of the virtualization handlers that were introduced with App-V 4 and Office 2010 integration.

The Office Deployment Toolkit is periodically updated and is also the primary tool for updating the App-V package. The flattener component puts in a permanent package GUID that simplifies updating and allows for updating with the Office 365 update cycle which is in line with patch Tuesday. The Office Deployment Toolkit is also the mechanism for determining which Office applications are part of your overall Office package.

While the Office 2013 AppV package originates with Click-to-Run from the Office365 CDN, starting with Service Pack 2 of App-V 5, the App-V package can also be activated via Volume Licensing as well as Office 365 subscription licensing. This means that the Office AppV package is now the most flexible option for licensing as it is the only package format that can be activated through either subscription or volume licensing. Bear in mind the activation method will be embedded into the package upon flattening.

Dynamic Virtualization

The Office 2013 APPV package was also the first introduction to JITV (Just-in-Time Virtualization) or what is known as “dynamic virtualization.” This allowed for better shell integration and enhanced the behavior of the virtualization handler components through tighter integrated extension points. This would be available for other AppV applications beginning with App-V 5 Service Pack 2.

In Essence, the newer the version of Office is, the tighter the integration options are. This allows for Office to be incorporated into your overall App-V application factory where the new Office can be leveraged for primary use under App-V while legacy versions can be leveraged (and) isolated for special circumstances.