App-V or FSLogix?

2015

THE GOOD, THE BAD & “THE BETTER TOGETHER” DUNCAN MURDOCH

Contents 1 Introduction ...................................................................................................................... 3

2 App-V 5.X Key Infrastructure Components .................................................................. 4

2.1 Desktop Client: .......................................................................................................... 4

2.2 Load Balancing Mechanism: ................................................................................... 4

2.3 APP-V Web Services: ................................................................................................. 5

2.3.1 Management Console: ..................................................................................... 5

2.3.2 Publishing Service: .............................................................................................. 5

2.3.3 Reporting Service (Optional): ............................................................................ 6

2.4 SQL Database(s): ...................................................................................................... 6

2.5 App-V Sequence Content Store: ............................................................................ 6

2.5.1 Standard Mode: ................................................................................................. 6

2.5.2 Shared Content Store Mode: ............................................................................ 6

2.6 DR Requirements: ...................................................................................................... 7

2.7 SCCM Integration: .................................................................................................... 7

2.8 Manual or 3rd Party Management: ......................................................................... 7

3 Adding FSLogix ................................................................................................................ 8

3.1 Working Together: ..................................................................................................... 8

3.2 Replace App-V Infrastructure: ................................................................................. 9

3.3 Working Alone: ........................................................................................................ 10

3.4 Summary: ................................................................................................................. 11

4 App-V Capabilities ........................................................................................................ 12

4.1 Technical: ................................................................................................................. 12

4.1.1 Application Compatibility / Isolation: ............................................................. 12

4.1.2 Deployment/User configuration: .................................................................... 13

4.2 Operational: ............................................................................................................ 13

4.2.1 User Configuration: ........................................................................................... 13

4.2.2 Binaries, Configuration and COW: ................................................................. 14

4.2.3 Apps that change frequently: ........................................................................ 16

4.2.4 Remove the Fear of the Uninstall: ................................................................... 17

4.2.5 Rapid Deploy and Roll Back: ........................................................................... 19

4.2.6 Manageable Upgrade of Dependencies: .................................................... 20

4.2.7 No Push Deployments: ..................................................................................... 24

4.2.8 Cross Platform Capabilities: ............................................................................. 24

5 App-V Limitations .......................................................................................................... 27

5.1 Technical: ................................................................................................................. 27

5.1.1 COM+/DCOM/ COM DLL Surrogate: ............................................................. 27

5.1.2 Device Drivers: .................................................................................................. 27

5.1.3 Services: ............................................................................................................. 27

5.1.4 Printers: ............................................................................................................... 27

5.2 Operational: ............................................................................................................ 28

5.2.1 Office and Plugins: ........................................................................................... 28

5.2.2 IE and Plugins / Add-ons? ................................................................................ 30

5.2.3 Changes to User Behaviour may be Necessary: .......................................... 30

5.2.4 Splitting Application components between Virtual and Installed? ........... 31

6 Other Topics ................................................................................................................... 32

6.1 Number of Applications in the Base Build: ........................................................... 32

6.2 Licensing Considerations when all Apps are in Image: ...................................... 33

7 Time and Effort Analysis ................................................................................................ 34

7.1 Approach: ............................................................................................................... 34

7.1.1 Sequencing Approach: ................................................................................... 34

7.1.2 Creating FSLogix Rules: .................................................................................... 34

7.1.3 Application Selected: ...................................................................................... 35

7.2 Results: ...................................................................................................................... 35

8 SUMMARIES ..................................................................................................................... 36

8.1 Deployments of 50 Apps or Less: ........................................................................... 36

8.2 Deployments of 50-100 Apps: ................................................................................ 36

8.3 Deployments of Greater than100 Apps: .............................................................. 36

8.4 Key Considerations: ................................................................................................ 37

1 Introduction The purpose of this document is to discuss the strengths and weakness of App-V and FSLogix Apps, and how the two can be used together to form a complete application provisioning and management strategy.

The document uses scenario-based considerations to demonstrate the pros and cons of using each solution independently, or when combined.

2 App-V 5.X Key Infrastructure Components This section aims to give an overview of the App-V full infrastructure and to describe the purpose of each component. The diagram below represents where each component sits within the infrastructure and demonstrates the components that are required in a DR scenario.

2.1 Desktop Client: App-V has a client component that is installed and configured on the client device and it is this client that adds the intelligence to the App-V infrastructure. The App-V client controls the registration/delivery and launching of virtual applications. The client configuration can be managed by Group Policy or manually using PowerShell. It is in the client that the administrator will configure the locations of Publishing servers and Reporting servers. When using the SCCM integration the client is “controlled by” the SCCM agent and at the time of writing it is not possible to have both SCCM and Full App-V infrastructure co-exist. The SCCM agent will remove publishing servers as part of its management of the App-V client.

2.2 Load Balancing Mechanism: For a highly available App-V infrastructure an organisation will need to implement load balancing to ensure that the application delivery mechanisms are available when there are failures in the systems. Common options will include:

a) Load balancing infrastructure such as Netscaler / F5 / Kemp etc. b) Microsoft Network Load Balancing (NLB) - smaller environments c) Round Robin DNS

High availability is most relevant in an environment where the customer is using Non-persistence. In Persistent 1-to-1 environments where the application is streamed and cached to the client device, the high availability of the App-V infrastructure is less relevant. If the infrastructure is not available it will have minimal effect on the user base. Applications that have been delivered to the users will continue to function.

In Non-Persistent or Pooled environments it is necessary to make the App-V infrastructure Highly Available. To deliver the applications to the user base on-

demand, and/or for the users to have access to all of their Virtual Applications, the delivery capabilities of the infrastructure need to be made HA.

Load Balancing Mechanisms allow multiple instances of the App-V Infrastructure components to be used and the user load spread across these.

2.3 APP-V Web Services: While there are 3 distinctly separate Services that are installed for the App-V infrastructure they are commonly all installed onto the same servers and the load balancing mechanisms put in place to manage the access and consumption of these services. This simplifies the deployment and design.

2.3.1 Management Console: The Management Console is the interface for adding packages for Distribution. When an application is imported into the Management console it will be given various properties the main ones being:

a) The Active Directory Group that is associated with the package. This might be a group that contains users or it might be a group that contains computer accounts. The difference being that on the client device if the application is published to a user it will be “User Published” if the group contains “Computers” it will be published globally to all users of the machine.

b) Connection Groups: the console will enable the creation of connection groups and associated Active Directory groups. Connection groups allow multiple individual sequences to be grouped into a logical one. This allows separation of applications in the Sequencing process (i.e. Java 1.4.1 and application that needs Java) so that updates might be performed individually, and then the combining of these separate sequences at delivery time.

c) User and Deployment Configurations: This capability allows manipulation of the sequenced application at delivery time, and the ability to run scripts etc. that help enable the application to function in a virtualised environment. The manipulation of the application may be for configurations (different Database connections based on user groups, where the application binaries are the same), Remediation (A script to copy certain files onto that local device to ensure the application works for that platform), Visibility of shortcuts (Some users may require extra icons to be made available for the application. e.g. a Supervisor may have access to an extra exe in the application suite).

All of these stated capabilities could also be managed without the Management Console by creating and manipulating XML files at the client using the Client PowerShell Interfaces.

2.3.2 Publishing Service: The publishing service is a Web Service that builds a view of the available applications and is consumed by the App-V client. The Client will query the Web service on its configured polling intervals (by default at login, but possibly every day/ hour). The publishing service delivers to the client the application data relevant to the requesting user as an XML file. The Client will then use this XML file to connect to

the Package source (either over SMB or HTTP) to register the application package and add the icons and integration points (FTA’s, Shell integration, etc). Depending on client side configurations these packages may then be fully loaded into the App-V cache or they will be Pulled on launch to the client.

2.3.3 Reporting Service (Optional): The Reporting Service is an optional component and is designed for the App-V client to Push information to a database. This database will collect information regarding application usage so a customer can report on the actual time and frequency an application is used by the users.

2.4 SQL Database(s): For the full App-V infrastructure to work there is a need for at least one SQL database (The Management Database). The Reporting Service also requires a SQL Database. The Management Database is necessary for the infrastructure to hold the data regarding who has access to what applications. The requirement for SQL introduces a need for Backup and DR capabilities into the system. This Database will need to be available in the DR location. It also holds the reference location for the App-V packages, which means that the App-V content Store will need to be held within a “DFS Namespace” to mask its physical location. Otherwise, there will be an inconsistency during DR between where the client is told the package is located and where the package actually is. This is also relevant for delivery in a highly available configuration where multiple servers are delivering the package info.

There is a client side configuration that can be set which will override the default Content path delivered from the Publishing Service and stored in the DB. This override offers greater flexibility in the location of the App-V Content Store and can reduce the complexity of the infrastructure design if used.

2.5 App-V Sequence Content Store: An SMB File share (or an HTTP site) that contains all of the App-V sequences

2.5.1 Standard Mode: The Packages are stored in the Content Store and the client will either fully cache the application or pull files into the local cache as required. This is the mechanism for delivery to persistent desktops (Physical Desktops/Laptops or persistent VDI).

This mechanism allows for on-demand/pull capabilities for users that roam and a deliver once use many model.

2.5.2 Shared Content Store Mode: Used for Non-persistent environments: (VDI / RDS). The client is configured to not cache the applications into the Disk Cache, instead the files are loaded directly into Memory. This requires that the client has continual access to the Network location storing the sequenced “.appv” files so that application requests can be pulled on demand. The benefit is that there is reduced file storage at the client end. However there is now a much higher reliance on the Fileshare being both available and performant along with a higher reliance on network connectivity.

2.6 DR Requirements: Once the App-V infrastructure has been adopted then the infrastructure needs to be part of the DR strategy for the organisation. With Virtual Machines and storage replication this may not be a large operational overhead, but it does however need to be designed and tested.

Many organisations will build their VDI environments Active/Active between the Datacentres, which will mean that the App-V infrastructure will need to be delivered in a similar fashion, with particular attention to the SQL server component and the replication of the App-V Content Store.

DR or even the Active/Active setup using FSLogix and App-V client PowerShell components makes the design, and therefore management of the environment simpler. There is only the replication of the App-V content store and the FSLogix rules that need to be considered. This also offers simple capabilities for distributed offices where applications may need to be deployed to physical machines. Reducing individuality in disparate locations can reduce the support efforts.

2.7 SCCM Integration: SCCM has not traditionally been considered a good delivery mechanism for “Non-persistent” environments. The SCCM agent has not been designed like the App-V client with full App-V infrastructure where the client will poll on each login to dynamically present the current “Assigned” application capabilities for that user and populate their start menu. The SCCM client has been design for a large, distributed delivery system and will generally poll the SCCM infrastructure in a much more “leisurely” fashion to collect its instruction set. In non-persistent environments this results in the applications being populated long after the user has logged in. The most recent release announced at Ignite 2015 promises better virtual application delivery times but this has not been proven and rumour is that it is still not an acceptable speed increase.

SCCM has also traditionally been a per device service rather than a per user service.

SCCM and App-V integration is often seen where an organisation is using SCCM to deliver applications to the end device as MSI packages and only using App-V as a “Remediation” tool to deliver applications that may conflict with installed applications. (e.g. Project 2007 when Office 2010 is installed).

2.8 Manual or 3rd Party Management: As mentioned above, the App-V client can be managed by PowerShell and this enables the creation of more flexible and business aligned capabilities. It does require that the Deployment/User configuration files and Connection Group XML files be created outside of the App-V management infrastructure.

When using a 3rd party application management solution (either RES/AppSense/Immodio/etc) the organisation can use the rules engines baked into these solutions to run PowerShell scripts to publish applications based on the users Active Directory group associations.

3 Adding FSLogix FSLogix provides many of the capabilities for managing an application on a per user basis as the full App-V Infrastructure. FSLogix can also replace the need for some use cases of application virtualization, such as the need to support multiple Java versions. What FSLogix does not offer that the App-V full infrastructure offers is the actual distribution of the applications, nor does it enable the capability to create and distribute application connection groups on a per user basis.

Since FSLogix allows all applications to reside in a single base image (or greatly reduced number of base images), it can replace the need for most push/pull infrastructure, and eliminate the overuse of application virtualization as a provisioning system for apps that do not require true isolation.

3.1 Working Together: Where a client has the App-V infrastructure already in place, FSLogix works well in parallel to manage the applications that cannot be, or do not need to be virtualised, adding the same “per user” capabilities. These applications can be installed into a base image and made available to the users based on the same principles as the App-V infrastructure provides.

The non-virtualised applications can also be distributed to Persistent environments (Desktop, Laptop, Full-Image VDI/RDS) along with FSLogix rules that will mask the availability of the Applications should the device be accessed by a user that is not authorised to use the application. This can offer similar device flexibility to the persistent environment as can be made available in the non-persistent environment. Being able to achieve this opens a number of usage options to the organisation that are currently not available when using only a traditional device focused delivery mechanism, such as SCCM, Altiris, etc.

The view above shows where FSLogix and App-V working together reside in the deployment process. The reason for not adding the FSLogix rules into the image is flexibility. Adding these files to the image after the deployment phase allows the rules to be edited and the group assignments altered without the need to open the image. The FSLogix rules should be distributed to the clients as part of a Start-up

script process rather than a part of the Login process. This way they are pre-staged and will not add an overhead to the Login time. The App-V client, in such a scenario, is likely to be configured to register the virtual applications at Login so that only the apps for that user are presented. While the two technologies are working together in the above illustration, there is no real functional cross over between what they are doing or delivering.

3.2 Replace App-V Infrastructure: Alternatively the two solutions can work together with FSLogix taking over the responsibility of managing the availability of the App-V packages from the App-V infrastructure. This is done by creating a Rule that masks the Registered App-V package from the App-V Cache locations meaning the user account is unable to see the App-V package nor run the application even if they Officially have rights to do so. [Note: This technique also prevents a “smart user” from being able to publish an application to themselves even if it is registered on the client, reducing the requirement for “-RequirePublishAsAdmin” settings on the App-V Client].

This requires that an alternative App-V registration and delivery mechanism is in place, however this is easily achieved using the App-V clients PowerShell interfaces or an alternative such as “AmberReef’s App-V 5 PowerShell Agent” or “App-V Scheduler”. In this scenario all App-V packages would be registered to the device (irrespective of what a user may be entitled to) and published globally on the desktop. This would happen at the Start-up of the desktop. In a VDI environment this would preferably be a Pre-booted image. When the desktop is booted a Scheduled Task, defined for “at start-up” would be configured to Pre-Cache all App-V packages, followed by copying all FSLogix rules (for installed and virtual applications). The result of this process is the delivery of a Single Image capability, a reduction in the Infrastructure requirements (only a replicated fileshare) and simplified Disaster Recovery capability. What is required however is investment in understanding the App-V capabilities at a more detailed level than might be required when using the Management Console. The Admins will need to understand how to create and edit Connection Group and Configuration/Deployment XML files. There are community tools available to make these tasks easier (TMurgent,

AmberReef, VirtualEngine, App-VCommander etc.). These are key skills that the administrator should be obtaining to enable them to properly support the user base.

FSLogix offers the application administrator some of the capabilities that application virtualisation offers, but with installed applications. Understanding the application and usage of redirection, isolation etc. is a skill that can then be transferred between the 2 technologies. The shift from Application Installation focused skills towards an Application Runtime set of skills will enable the application administrators to build much more flexible capabilities into an organisation’s environment and align more closely the requirements of the business and the users within. Once these skills are understood there are likely to be many more opportunities to utilise FSLogix to address “application features” or anomalies alongside application virtualisation capabilities. (e.g. the “Specify Value Rule” allowing a per user FTA association)

With App-V 5.x now being more integrated with the Operating Systems it enables the likes of FSLogix to also manage and control virtual application capabilities (e.g the ability to mask a virtual application). The investment in the skills required for virtualising the applications can be cross pollinated to maximise the capabilities with FSLogix for managing the installed applications.

3.3 Working Alone: The ability to manage applications without having to virtualise them may offer a quicker route to value, and therefore enable a customer to deliver their environment without needing to re-package the applications in App-V format.

The Key to achieving this will be based on:

a) The Number of applications b) The User to Application Matrix (Who requires which applications) c) The operating model used to manage the desktop/application allocation

To deliver a single base image within the Non-Persistent VDI / RDS environments will potentially require a change to the operational processes used to deploy the VDI/RDS base image. This operating model will require a process that Assembles the end image, removing any application “uninstall” requirements. Business applications are separated from the OS. The OS upgrade process can happen weekly based on

the patching cycle defined by the business. The application patching/upgrade/introduction lifecycle processes are managed separately creating a “Current State” application run-book, which will be deployed onto the OS prior to deployment. This process will remove the need to uninstall applications when updates etc. are required and allows the application administrators to manage the versions of applications available within each image release independent of the OS management team’s requirements. FSLogix rules should then be deployed as a post image process (placed on each running desktop at start-up) so that the management of the Applications Availability does not require image management. Any changes to rules and associations can be managed as necessary and offer a more responsive access model for the business.

3.4 Summary: FSLogix adds flexibility to any application deployment that is not present with Application virtualisation alone. It can allow decisions to be made about the appropriate delivery/installation method without having to consider one or the other as being a compromise in the overall scheme of business application utilisation. Both application virtualisation and FSLogix Apps can change the focus of the business engineers to being Runtime focused rather than Deployment focused and therefore more aligned to the business requirements of applications, rather than the IT departments’ requirements for deploying applications.

4 App-V Capabilities 4.1 Technical: 4.1.1 Application Compatibility / Isolation: Compatibility is fften the primary reason for utilising application virtualisation, which is also a long running misrepresentation of its actual value. The true value in a virtual application should be seen as the equivalent to a Virtual Server. The ability to create a snapshot, make a change and revert back if the change was unsuccessful is also applicable to a virtual application. You can turn off the current version, turn on the new version and if there are problems, reverse the process, all without the fear of affecting anything else on the Client Device.

The ability to rapidly deploy services: Installing applications comes with a perceived risk of breaking something else in the environment. Virtualisation has enabled the “Fear of Breaking” and the “Fear of the Uninstall” to be largely mitigated as the application is unable to affect the underlying system. This can enable the IT function to be more responsive to the users request for an application by enabling or disabling it.

It is also a “User Centric” capability allowing a user to roam devices and have the application follow them (an enabler to actual hot-desking capabilities). Unfortunately – it is the complexity in the application estate, and more importantly the lack of knowledge regarding the applications, that may make the promise of application virtualisation appear less. This is generally an issue with how the promise was sold and the perception therefor being poor.

Impact of Isolation:

1. The isolation capabilities in App-V allow for multiple versions of an application to co-exist on the same operating system without them being aware of each other.

2. Isolation also allows applications that traditionally don’t live next to each other (e.g. Marketing applications and Finance applications), and may have conflicts, to be made available within a centralised shared infrastructure (e.g. Pooled VDI / RDS)

Isolation – Negatives:

3. Ridged isolation prevents some application capabilities. See Section 7: 4. There is a need to understand the applications and how they:

a. Interact with each other b. How they are used by the users

These final 2 items are often key to the issues that people have around application virtualisation. They tend to concentrate on the End Device or Platform and consider applications at the end of the process &/OR outsource the creation / management of the applications, ensuring that the knowledge required to deliver their application does not remain inside the organisation. Staff are rarely trained in the Operational and Technical requirements of virtual applications so the benefits/efficiencies that can be made in the support processes are seldom realised.

4.1.2 Deployment/User configuration: Applications may require different configurations on a per user/per device basis. The ability to create a generic sequence and then alter the feel of the application / user views at delivery/runtime are powerful capabilities. These offer flexibility at a level that traditional installation mechanisms don’t allow. Also it ensures that the requirements of the application and the settings are all in one place. Otherwise the Binaries are deployed by one tool, the configurations etc. are delivered by another (AD / GPO / Login Scripts etc.) and this decoupling of the application into not only 2 / 3 tools but also into 2 / 3 separate teams makes management / upgrade / lifecycle / etc. a much harder process than it needs to be.

4.2 Operational: 4.2.1 User Configuration: 4.2.1.1 Overview: Applications are generally more complicated than just the Binaries. There are various layers of configuration that make the deployment of applications to users in a corporate environment more challenging:

Applications can create and store their configurations in many places and formats (registry, XML files, INI files, config files, Javascript files, JSON files etc). When the configuration settings are added in Global locations (Local Machine registry keys, %ProgramData%) then this can make managing the application easier, as these setting can then be applied to all users. When these settings are applied in the “User Context” then the configurations are more difficult to apply across all users. A good example of a setting that many applications add in the User context is the Auto Update feature, which most organisations want disabled so that they have a managed application estate or are deploying to a “non-persistent” environment.

4.2.1.2 Scenario: When applications contain key configuration options (e.g. application ODBC settings / Autoupdate features) that cannot be managed by GPO etc. and are

stored within the User Context (e.g. HKCU or the Users AppData location), then these can be configured and contained within the applications virtual environment. This allows the organisation to deliver the application and its appropriate configuration settings to the user ready to use. It also sets a good working-state roll-back position when a user has issues with the applications. The virtual environment can be reset back to the corporate Factory Reset position and the user can continue to work. This can reduce support time and effort troubleshooting issues.

4.2.1.3 Problem Consideration: When an application cannot be virtualised and requires these configurations to be created then the options available include:

1. Create login scripts that copy files or add registry keys 2. Inject these by some means into the “Default User” 3. Create Application GPO’s that add login overheads and are managed

separate to the applications. These may still be applied even when the application is retired or the user no longer uses that application

4. Do not configure the application and leave it to the user to configure Post Installation.

Alternatively these are these are the sweet spot for the traditional “Environment Management” suites (AppSense/RES/Immodio/Norskale etc).

4.2.1.4 Where can FSLogix Help in this Scenario? FSLogix Profile Containers add value to the post configuration of the application settings and can work in conjunction with something like UE-V from Microsoft to bring user personality mobility to a solution, without having to incur the overhead of traditional Folder Redirection.

Utilising the “Redirection” and “Specify Value” capabilities of FSLogix, it is likely the administrators will be able to build application specific configuration rules that mimic the application virtualisation capabilities.

4.2.2 Binaries, Configuration and COW: 4.2.2.1 Overview: Applications that put things in the Wrong place or do things that only the developer can explain. There are generally a set of guidelines Windows developers should follow when it comes to where they place programs files (exe, dll etc.) and there are also places that they should put global configuration information. These guidelines are not always followed, and can lead to difficulties with permissions on the OS. This is becoming less an issue, but there are still examples of peculiar practices even in newer applications. AutoCad is an example; when you first run the application it will place two .dlls in the user’s %AppData% location. Why? Probably a workaround for some functionality. Google for a long time installed all of Chrome into the users’ %AppData% path, again as a workaround to permission lockdowns.

[UPDATE: As of App-V 5.1 the COW list has been greatly reduced removing a number of these considerations]

4.2.2.2 Scenario: The application, when installed, has placed files in locations that are not sensible and their configuration settings are also in the wrong place. This would mean that in a modern OS (Windows 7) the default security permissions will prevent the users from altering settings that they should be able to configure. It will also require the installation engineers to build workaround scripts that change permissions on folder structures like the “Program Files\AppName” path to allow the application to write to a configuration .ini file for example.

Application virtualisation has the ability to emulate elevating the user as an “Administrator” within the virtual bubble allowing the application to believe it is writing to its standard locations, but will have the virtualisation engine redirect the file to an appropriate location that the user does have permission to write to (i.e. their %appdata% location).

4.2.2.3 Problem Consideration: Depending on the file type needing to be redirected, App-V has a set of Excluded file types in the COW (Copy on Write) mechanism. This means that even when an application has been configured so that the user has administrator privileges inside the bubble, it will still not allow a user to change settings or for the application to redirect these files out to the relevant location. Examples of applications where this is found are Mozilla Firefox and Thundirbird. These applications store settings in Java Script files (.js). The COW exclusions are generally file types associated with executable code.

[UPDATE: As of App-V 5.1 the COW list has been greatly reduced removing a number of these considerations]

[ref: http://virtualvibes.co.uk/cow-and-its-exclusions-in-app-v-5-0/]

[ref: http://blogs.msdn.com/b/gladiator/archive/2014/08/29/app-v-5-on-the-now-sometimes-immutable-package-cache-location.aspx]

[ref: http://blogs.technet.com/b/gladiatormsft/archive/2013/10/24/app-v-5-on-that-issue-with-firefox-where-you-cannot-save-preferences.aspx ]

The effect is that the application when packaged will not retain the user’s settings. When setting up Thunderbird as a mail client for example, the functionality works but the next time the user starts the application the settings have not been retained and the user will need to input their details again. This can be remediated by excluding the %AppData% files for users settings and have Thunderbird recreate the profile settings the first time it starts.

Many of these issues can be addressed within the creation of the Sequencing process or by using some of the other application virtualisation capabilities like pre-launch scripts once the reason for the issues has been discovered. The ability to determine in the first case that the application is having issues due to COW exclusions can take either an insightful / experienced application virtualisation person, and/or can take a good amount of time analysing the application to get to the answer.

4.2.2.4 Where can FSLogix Help in this Scenario? If the application cannot be virtualised then FSLogix is able to offer the same redirection capabilities as the application virtualisation technologies by using File or Registry redirection rules.

Also where an application that is taking a long time to investigate and convert over to an App-V Sequence, but is shown to work on the OS natively then a decision can be made based on effort and time to install the application and utilise FSLogix to manage visibility. This may mean that the investigation of the application as a virtual application can continue but the deployment of the application is not necessarily impeded by the packaging/delivery technology.

4.2.3 Apps that change frequently: When an application changes frequently then the benefits of delivering a runtime version of it and not having to update the Base Image is much more operationally effective. It also means that applications can be delivered just-in-time (JIT) to the users without re-boots etc.

4.2.3.1 Overview: When there are frequent changes to an application, then the overhead of managing these as installed applications can become an operational headache. These may be internally developed applications that are having features added / regulatory updates made on a monthly basis (or even weekly). When considering these types of application in a Non-persistent environment then the application updates are going to have an impact on the release cycles of the base image.

4.2.3.2 Scenario: The organisation has an application that every 2 weeks requires a new set of dlls to be deployed to the end clients. These dlls hold various rules and logic to keep up with regulatory changes and or competitive advantage capabilities.

The developer may deliver the updates in a number of ways. He might just deliver the dlls to the deployment team or he may wrap them up in an msi or msp to patch the application. In any of these scenarios the deployment team would traditionally add the packages/create a script or package, and deploy the updated dlls to the end clients.

When the end devices are non-persistent these files will need to be added into the base image to update the application, which means every 2 weeks there is going to be a need to update the base image(s) that contain this application. With one base image this may fit fine into a standard operating refresh process. However if this application is utilised across a number of organisational units/departments and due too other considerations the image count has grown to 10 then the management overhead of updating and redeploying all 10 images on a 2 weekly cycle will become excessive.

App-V can help eliminate this by allowing a 2 weekly update to the package and this gets deployed / refreshed across the estate without the need to alter the image. It can also help by allowing the same App-V package to be deployed to the non-virtual estate. It is also possible to use some more advanced skills to create a pre-launch script in App-V that would create a self-updating package. As the core of

the package is not changing it would be possible to have a script that would copy the updated files from a central location into the virtual environment, removing the need to have the deployment engineers involved in the 2 weekly update process.

4.2.3.3 Where can FSLogix Help in this Scenario? FSLogix can help the above scenario for applications with this update profile by ensuring that there is only the 1 image to manage, or a substantially reduced set of base images. If the application is not virtualised then the operational overhead for deploying the updates into one image is massively reduced.

Utilising FSLogix Application Containers (VHD mounted files) would also offer a dynamic update capability for the application. While the Core Binaries are installed into the OS and change infrequently, the changing dll set can potentially be added to a VHD file and mounted at login, or a set of redirection rules utilised to point to the updated files, for the users. This would also ensure that if there was a need to roll back the dll changes there is not a need to amend the image, outside of the normal schedule, to replace the new dlls with the last know good versions. The VHD file could be replaced with a previous version and the roll back can be non-intrusive.

4.2.4 Remove the Fear of the Uninstall: 4.2.4.1 Overview: Even in environments with a well-managed application estate, that have been through the pain of having all of their applications created as MSi for deployment, there is still a Fear of Uninstalling. There is often a requirement to remove an application from a device either because:

• It is no longer used by the user and therefore needs to be uninstalled for compliance

• The application is no longer used by the organisation and should be removed • The application needs to be uninstalled to be replaced by a new version

This situation can create operational stalling because of fears that the removal may break something.

Often Deployment and Application teams are not the same. Application packaging may well be one function, and is generally focused on the forward path, creating and testing the Package to deploy the application. This team may not be part of the organisation. The Deployment function might well be a single team or part of the larger Desktop Management team and their role may include managing SCCM and other desktop management tooling. The fear of removing will often be a result of historical issues (which may well have been addressed after) that resulted in the removal of an application breaking a subset of other applications. The remediation of issues introduced into the live estate would be seen as disruptive and require a re-deployment of the uninstalled package in the hope that this would actually return the desktop estate too the original configuration. This problem would then be followed up by investigating the issue before tentatively trying again, or the problem may have to remain broken while remediation steps are investigated and deployed.

To manage this process, the deployment team will generally take a soft deploy/install approach, starting with a few users and gradually ramping up the

numbers. This approach is effective in catching large disruptive issues but in doing so it also makes the deployment of the new version slower. And this approach may not be relevant because the client application needs to be updated across the organisation at the same time due to backend application infrastructure upgrades (see Rapid Deploy and Roll Back.)

4.2.4.2 Problem Consideration: There is still a need to manage the removal of applications that cannot be virtualised. Where 60% of the applications have been virtualised and therefore the matrix of complexity has been reduced, it is likely to reduce the fear of uninstalling because there can be a clearer understanding of what might break in the uninstall process.

4.2.4.3 Where can FSLogix Help in this Scenario? FSLogix may not directly affect the “Fear of the Uninstall” because the applications do need to be installed. Other Layering Technologies can be considered as deployment engines that will allow customers to remove the Fear of the Uninstall but won’t necessarily solve the other limitations that can come with these approaches. The Appstack or the Departmental Layer that is being muted as a good thing, will operationally need to be updated and will need to have applications installed and uninstalled into the stack. Some issues with a Departmental Stack are:

a) It will need to be updated as a stack and then applications will need to be uninstalled and installed into the stack. Therefore the removal of the uninstall issue has not actually been addressed. It has just been moved. (Granted it has been moved to somewhere that you can test out of path and that roll back position is to attach the old stack.

b) Departmental stacks of applications are not flexible. It is an IT idea that allows IT to command and control the end user by saying this is what you can have. Modern IT should be looking for solutions that allow the users to describe what they need. Even within departments there are sub department and individual’s requirements. Finance will have Accounts Payable and Credit Control functions (money in and money out) and they will have different needs on top of the departmental standards. There will also be the 1 or 2 people that produce the end of year payroll documentation etc. As an example: a recent engagement on a 100 -120 user migration of a business unit. When you dig into the application requirements and what people did in their roles and what functions they had adopted but might be outside of their traditional role, there were 100 applications (After rationalising them). There was not a simple departmental model.

c) Applications will still live across application stacks – departmental apps “creep” and become Business Unit apps or multi departmental apps. Attempting to bundle apps into a fixed buckets for IT benefits is not a modern approach.

d) If the organisational aspirations are to build a modern IT service focused offering, then the natural end goal will be for applications to be delivered and available to users by an App-Store model. These types of solutions require separation of applications, not grouping.

To answer the Fear of the Uninstall. FSLogix should be used in conjunction with a change in the operating model for assembling the desktop. (see below “Apps in Base Build” for full description) where applications are always INSTALLED and NEVER UNINSTALLED (uninstalled only during occasionally scheduled service windows) onto a VDI/XenApp environment.

4.2.5 Rapid Deploy and Roll Back: 4.2.5.1 Overview:

1. Allows a lower risk / more aggressive deployment mechanism. Knowing that a new application cannot break what is the current state (however likely / unlikely that is these days) is a mental hurdle that can be removed.

2. The knowledge that the old application can be Turned off/and Turned on again with the simple reallocation of an Active Directory Group opens up confidence in the change process allowing more agility.

4.2.5.2 Scenario: A Client server application needs an update: The Server infrastructure will be upgraded over a weekend and a database upgraded. There is also a need for the client application to be deployed to 1,000 desktops at the same time (even laptops that may or may not be on the network during the upgrade). If the application is virtualised the old version is turned off – the new version is enabled and if the Server upgrade was successful, on Monday morning the users that login to any of the platforms (VDI / Desktop / Laptop) will all have access the new version. No chance of the OLD client version being run against the New Infrastructure. If a user comes in on Wednesday they will not have been missed, as the same process will happen for them. This approach can reduce the planning and deployment requirements for this type of project because there is no longer the need to find out who has the application in the 1st instance, nor do you need to monitor the deployment successes and ensure that all offline users have been upgraded.

Additional benefits are that should there need to be a roll back after the new client has been deployed (due to some technical issue with the infrastructure upgrade or with the functionality of the software), then the client can be disabled, removing it from the users’ environments. The new client version can be re-enabled if the issue is resolved or the old version can be re-enabled once the infrastructure has also been rolled back.

4.2.5.3 Problem Consideration: Applications not virtualised would need to be delivered / managed and rolled back as described in the above scenario.

4.2.5.4 Where can FSLogix Help in this Scenario? When planning for this type of deployment, FSLogix could be used to deliver a similar affect. When an application is not virtualised but can be installed alongside the original version (installed into a different installation path etc.) then the new client can be distributed / Installed and the FSLogix rules applied to mask the application until it is time to enable it - at which time a new rule can be deployed to mask the old version. If there is any issue with the deployment then FSLogix can easily be used to revert to the old version. Once the system is settled then the organisation can do a controlled removal of the original application.

Within a non-persistent VDI environment the single image capability offered by FSLogix can mean that the upgrade/roll back requirement is only applicable to the one image rather than across multiple images that the application resides.

4.2.6 Manageable Upgrade of Dependencies: 4.2.6.1 Overview: Applications are often not islands; they require 3rd party components to enable them to fully function. Examples of these might be Java, Oracle Client, C++ libraries, even Office. When applications also require middleware elements the decision tree needs to consider that multiple applications may require the same middleware component. With App-V the Connection Group functionality allows the integration of multiple applications that require each other to function. However, if one of the applications does not virtualise then the middleware component will need to be delivered non-virtualised for that application. The benefits of achieving middleware virtualisation can be seen in the scenario below.

4.2.6.2 Scenario: Post a successful Transformation, the application estate has been tested and rationalised to a position where the relationships between application and middleware is in a Tidy and Measured position.

Effort has been made to ensure all applications have been rationalised to use a single middleware component (say Oracle 11 Client). This may have involved extensive application testing and even application platform upgrades. Alternatively there may have been a good number of Tactical Solutions (workarounds) implemented that will raise their heads at some point in the future. In this scenario the former happened. However, one of the givens in IT is that “Things will Age / There will be New things / Things Change”.

So our example scenario goes like this. 6 months after a major transformation, a business unit requires a major upgrade to their application. This is to bring new capabilities and also to keep their solution in support. This upgrade will include updates to all the infrastructure components that host the application and also the client. Part of the client requirements for the new version is also an update to the

client middleware (Java / Oracle / etc.). Currently there are 4 applications that use the same middleware.

4.2.6.3 If the Middleware Component and Application are Virtual:

When the application and its middleware components are virtualised then the process for upgrading can be managed outside of any other interdependencies. As the above image shows the NEW middleware version can be created alongside the new version of the application. The steps to deploy are:

1. Create and test new applications against new middleware and backend infrastructure

2. User Acceptance Test (UAT) the application 3. Deploy the application and middleware (new Connection Group created) at

the same time as Disabling the old application. This ensures that the ability to roll back quickly is available to the deployment function.

4. After appropriate time running live and business signs off as a successful deployment, remove vApplication D.v1 and the Connection Group to vMiddleware.V1.

5. For the purposes of the application upgrade this has been non-disruptive to the user base.

Operationally and for the benefits of the business (continual improvements initiatives) it would then be wise to also begin testing the other applications that currently use middleware.v1 against middleware.v2. This would enable an ever-greening process and add operational knowledge so that a single application does not get left aging and cause undue disruptions to the organisation’s future plans.

Testing the current A.v1, B.v1 and C.v1 applications against the new middleware in the above scenario results in NO changes being made to application sequences. The only change will be in the Connection Group that associates the applications with the middleware.v2 rather than middleware.v1. In the above scenario B.v1 and C.v1 are proven to function correctly with middleware.v2 and so operationally these can then be re-configured to use middleware.v2. A.v1 is not able to work with the new version of the middleware and is therefore left operationally to use the mw.v1. This should not be the end of the story however. Knowing that A.v1 does not work with the supported middleware should trigger beginning the remediation process to have the A.v1 application upgraded to work with the new version. This way the application estate is being continually improved.

4.2.6.4 Problem Considerations: Where the difficulties lie:

When one of a collection of applications that utilise the same middleware does not virtualise this can often be where complexities occur. If the application cannot be virtualised then the middleware component will also need to be delivered as a physical installation.

This can mean that all applications already tested with the virtualised version of the middleware need to be retested against the same middleware component but installed. The middleware component is likely to be passed back through a packaging factory process to re-engineer it as an MSI. If the testing is successful great – If the applications that are virtual then don’t work with the physically installed version of the middleware, then all applications are likely to be passed back through the process to convert them to locally installed applications, doubling the effort per app, and removing any of the operational benefits of virtualising them in the first place. Decisions like this are often made as part of the transformation process as the decision to move back to physical appears easier for the delivery of the transformation project and does not consider the overheads in operations.

Often because of the unknown nature of the applications during a transformation program, arbitrary decisions are made, and one of these might be that all middleware components are installed to prevent the doubling up of packaging

efforts should an application be found that will not virtualise and needs the middleware.

For the scenario above where the applications and middleware are installed locally the following is likely to happen:

Within a testing environment the Middleware V1 will be uninstalled and Middleware V2 installed alongside all of the applications that utilise the middleware. Application Dv1 will be “uninstalled” from the image and Dv2 installed. This will be tested and proven to work. Av1, Bv1 and Cv1 will all then be tested against the new middleware version where Bv1 and Cv1 will prove to function as expected however Av1 will not work.

Traditionally this would leave the organisation with 4 options.

1. Do not perform the upgrade of application D and leave the application estate as is. This option does not consider the reason for upgrading D (business benefits, support levels, security issues etc.). It also leaves the organisation in a stale state that will ultimately lead to future issues.

2. Split the platform(s) and deliver application Av1 via a tactical deployment mechanism (e.g. move to RDS/XenApp offering) and move all of the other applications over to the new Middleware V2. This would incur an infrastructure cost to re-platform Av1and an implementation of a tactical solution.

3. As above but moving Dv2 to the new platform. Splitting the application set across multiple platforms will often introduce a number of problems in itself that are rarely considered at the time of moving and will result in a poor users experience.

4. Plan for the upgrade of Dv2 and Middleware v2 to accommodate Bv1 and Cv1. The ability to move the Application and middleware into production will not be possible until the remediation (or possibly even the upgrade) of application A to V2 has been tested and proved to work with Middleware v2.

4.2.6.5 Where can FSLogix Help in this Scenario? When the middleware can be virtualised but the application cannot:

A version of the middleware can be installed in the OS and also virtualised as part of the transformation program. The applications that are virtualised can consume the virtual middleware. The installed applications can consume the version installed. There can be issues where an application is both virtualised and installed. FSLogix can be used to mask the installed middleware version from all apps other then the installed application (using a process rule)

When multiple versions of a middleware component can be installed on the same OS without conflicting, then FSLogix can then be used to configure the application rules to utilise the appropriate middleware using a combination of masking and redirection. FSLogix provides several methodologies to assist with conflict resolution to enable this approach.

4.2.7 No Push Deployments: 4.2.7.1 Overview: While most traditional deployment technologies are designed to Push an application out to a device, App-V infrastructure is designed to Pull the application to the appropriate device a user is using at that point in time. If 100% of applications could be virtualised then the ability to pull the application to where you required it to be run would make the process of managing users and applications much simpler, however this is still not the case, even though Pull technologies have been widely available for over 10 years.

4.2.7.2 Scenario: VDI, particularly non-persistent or Pooled, does not fit the traditional push deployment model. Simply put, the VDI operating system is actually working as the deployment mechanism. The application does not need to be delivered to the users’ device as the application is contained within the VDI image. The benefits of Pulling applications into the image as required by the user is an appealing scenario as it adds greater flexibility to the users types that can consume the environment at any one time.

4.2.7.3 Problem Consideration: Not all applications can be virtualised so the benefits can never be fully realised at this time. Infrastructure to support Pulling applications introduces additional overhead and can introduce HA requirements.

4.2.7.4 Where can FSLogix Help in this Scenario? By masking the applications that cannot be virtualised, the IT department can master a single image solution, blending capabilities of masking and virtualising to produce an environment that could be consumed by any user in the organisation. This allows for a greatly simplified approach, which allows for a large degree of operational flexibility.

4.2.8 Cross Platform Capabilities: 4.2.8.1 Overview: It’s a simple fact that marketing people will try to hide, but there are very few organisations that can service every user with a single desktop platform. The complexity for a system administrator is when the view of VDI and Laptops/Desktops become separated from an application perspective. All of a sudden the application may need to the “packaged” in multiple formats depending on the platform. This only complicates things when a user’s device type is not fixed.

If an application is required to be delivered across multiple platform types, then the overhead of creating it in two separate delivery formats results in excess effort. This is generally an issue with organisational structure where the departments responsible for various platforms operate separately and don’t look at the value of technologies across the enterprise.

4.2.8.2 Scenario: A user might have a desktop for when they are in the office but be given access to a RDS session for when they need to work from home or a remote location. Their applications are then needed in both traditional physical installation formats for the desktop, and in App-V for the RDS session. This will add an extra layer of overhead when the applications need to be updated, as they will need to be updated in both formats

App-V can be used across all platforms but with different client configurations depending on the platform. For a VDI/RDS session the client should consume the applications using SCS (Shared Content Store) where as for the laptop the application should be streamed and cached to the endpoint.

4.2.8.3 Problem Consideration: However, in many cases App-V has been introduced as an architectural item to enable VDI and had not been considered for the desktop/laptop estate.

The multiple format issue is only exacerbated when you consider the introduction of Layering Technologies as the next generation of application delivery capabilities. Currently in their 1st generation they are largely VDI focused and hypervisor tied. This is changing as they evolve, however they also come with a need to be on the network. So an organisation might have a single application virtualised with App-V to the XenApp Servers, and delivered in an AppStack where they have VMware View and MSI for distributing the applications to the desktops/laptops. Upgrade nightmare…

4.2.8.4 Where can FSLogix Help in this Scenario? Being able to manage both App-V and installed applications as well as being only reliant on the OS as the Platform component allows FSLogix to add value across all of the Platforms. If an organisation can rationalise their application delivery technologies to be more aligned across the organisation then they can be in a better position to maximise the values of these technologies.

If the application works as a virtual application, distribute it across all platforms as a virtual application. If the application does not work virtual, distribute it across the organisation as an installed application. FSLogix can then be utilised to mask the applications where it is necessary to do so (VDI/RDS/SHARED Office Desktops/Hot-desking spaces/Shared or Pooled Laptops/etc.)

5 App-V Limitations 5.1 Technical: 5.1.1 COM+/DCOM/ COM DLL Surrogate: Applications that utilise these technologies are unlikely to work. These are often discovered during the creation and testing of the packages. Once it is found that the applications do not work then these will need to be engineered by another process.

5.1.2 Device Drivers: Device Drivers need to be installed outside of the virtual environment. Once they are available in the OS build then the virtualised application is more than likely to be able to consume it. However a view of roaming the application and the driver together will need to be taken, if the application is run on a device where the driver is not installed then the application will not work.

Also if the application is associated with a particular piece of hardware that itself does not roam then the value in virtualising the application to deploy to a static desktops is probably over engineering. However it might be that the organisation would like to limit the users that can use the device and this is where FSLogix would enable the masking of the application to the appropriate operator groups on these desktops (e.g. all users in an organisation could login to the 3D printer PC, but only the 3D printing operators group would be able to run the software installed on the device.)

5.1.3 Services: Services that start at boot time will not work and also there are limitations to the “user context” that the service can run under. Services can be used but it is generally accepted that the service would need to be a service solely consumed by the application (often for licensing purposes).

There are other considerations when running applications with services. Flexnet licensing service is an example. When there are two applications running on a client that use the service for licensing, then each instance will run the service. However when communicating with the service it might be that the application request is answered by the “wrong” instance of the service. This version will not be able to service the application request and the inconsistent issues will occur which can be hard to investigate and troubleshoot.

In cases like this it is generally accepted that the FlexNet licensing service be installed into the OS and managed as a physical application. All virtual applications can then consume it. When to extract the license service and when to leave it in the package will often be a decision made once an the application estate is understood and mapped to the users to see if there is likely to be a conflict. This can lead to reworking once the decision has been made.

5.1.4 Printers: Applications that utilise print drivers may not be good candidates for virtualisation. The Print Driver will not work as part of a virtual application, however in some cases this does not prevent the application form being used. PDF readers often now come

bundled with printer drivers for creating PDF and it is this capability that will not be available. This can either be mitigated by deploying an alternative PDF creation solution, or spending potentially a large amount of engineering time extracting the printer driver installation from the package to deploy as a separate application. Extracting the driver is seldom an operationally effective approach, as this would need to be performed for each version of the application.

5.2 Operational: 5.2.1 Office and Plugins: 5.2.1.1 Overview: To Virtualise office (or not) has always been a discussion point. In the majority of cases Office will be delivered and managed as an installed application. This decision is often due to the number of applications that also treat Office as Middleware and how the users then consume the application plugins. In many cases the Office Plugin is not a standalone capability, but also relies on other binaries and configurations of the UI application. Separating then is therefore not a clear option, the plugin needs to be run in the same Physical or Virtual Context as the other application components.

When an application has both a full windows UI and also a plugin there is a need to consider how to present these to the users.

Does IT deliver the application icons to the user and also add a relevant Office icon that the user will launch to gain access to the plugin, or will they use connection groups with the configuration to always run Excel in the virtual context?

5.2.1.2 Scenario: The requirement to map Office plugins to users is not normally something that is required because applications are delivered to a device dedicated to a user. This masks the complexity that Office plugins introduce in a multi-user environment.

When building the complexity into virtual applications or non-persistent/pooled desktops a number of options might be available to the IT department.

Option for delivering applications that have Plugins:

1. Application level Office icons; Adding an Office icon (Excel) to the applications Start Menu and training the users. If they need the plugin for that application then they must close the Office application and use the specific icon.

2. Departmental Connection Groups; Build the appropriate matrix and allocate a connection group that combines all of the departmental plugin applications. The Office apps will then always be launched in the context of this Connection Group. Replace the Office icons with ones that launch virtualised.

3. One Large Connection Group with permissions at a package level; A Global Connection Group that connects all applications with Office plugin and uses permissions within the connection group settings to enable plugins for each user type. Replace the Office icons with ones that launch virtualised.

4. Use the RunVirtual capabilities of the client to always launch Office applications in the context of a Connection Group

Office plugins bring a complexity that people perceive as a difficulty of virtualisation, but is actually a complexity within non-persistent environments in general.

5.2.1.3 Where can FSLogix Help in this Scenario? There is a trade-off to be made in these scenarios. The applications that have plugins will also likely benefit from some of the other App-V benefits described,

however they do then come with the complexity overhead of managing the Office integrations.

If we follow the models described for assembling the VDI image, and the applications that we choose not to virtualise are laid down into the image as a deployment RunBook, then the effort of managing these applications with plugins can be reduced (we are not looking at the application lifecycle requiring uninstallation from the OS). We can then decide that applications with plugins can be installed and managed by FSLogix, removing one of the more complex requirements from the App-v delivery requirements.

5.2.2 IE and Plugins / Add-ons? 5.2.2.1 Overview: IE has much the same considerations as Office. Is there one large Connection Group to manage all middleware requirements (Flash/Adobe Reader/ActiveX/etc.)

5.2.2.2 Scenario: The requirements for IE integrations may be reducing, and recent Flash security issues have brought to the front the overall issues with such technologies - the ongoing potential for use will likely reduce and therefor the complexity will reduce.

5.2.2.3 Where can FSLogix Help in this Scenario? For all standard plugins these should be installed natively and managed with FSLogix. Then the complexity of the matrix is much simpler.

Other IE plugins that are more complicated can then be considered for delivery with App-V and the operating overheads determined at the appropriate time.

The ability for FSLogix to mask these plugin technologies also offers the business a security layer by masking the vulnerable version immediately after it is identified and until the organisation is in a position to upgrade to a new secure version.

5.2.3 Changes to User Behaviour may be Necessary: 5.2.3.1 Overview: When dealing with the more complicated scenarios where Office or IE plugins have been virtualised there may be a need to change some of the users’ interactions with their applications. They may need to be presented with a particular Excel icon that is specific to the application to be able to run an Excel plugin.

5.2.3.2 Scenario: A user runs an applications which creates a .docx file and opens this in Word. Depending on the mechanism used to launch Word there is a pretty good chance that this version of Word is now running in the virtual environment. If the user makes changes in this version of Word these will not necessarily be saved to the physical Word locations. If the user then closes this version of Word and launches the native Word installation there is a possibility that the change will not be available to the user, as these changes were persisted in the virtual environment of the previous package. To alleviate this kind of issue, organisations will tend to introduce a User Virtualisation technology (AppSense / RES / UEV etc.) to allow the users settings to be roamed between different Office versions and deployment technologies.

5.2.3.3 Problem Consideration: Educating users about a need to change the way they work to accommodate an IT issue is often difficult. It needs to be presented with a business level benefit that justifies the overhead added to the users, or is a compromise to enable something that they are asking for. This is seldom very well executed. The introduction of another technology can often mask the issue from the users perspective however it adds an overhead to the IT function.

Understanding the application and making the correct configurations during the Sequencing process would also enhance the users’ experience.

5.2.3.4 Where can FSLogix Help in this Scenario? Understanding which virtualisation decisions to make and which to leave as an IT overhead (to ensure the user experience is maximised) is essential when delivering an end-user workspace. Having FSLogix in the IT tool belt allows the administrators to have more options in determining the correct solution.

5.2.4 Splitting Application components between Virtual and Installed? 5.2.4.1 Overview: If an application has a component that does not work within a virtual container (e.g. a print driver) then this component might be extracted from the installation / sequencing process. If this component is installed onto the OS then the likelihood is that it will work natively, and the remainder of the application can then run as a virtual application, and it will be able to consume the now “installed” component.

5.2.4.2 Scenario: A PDF reader also delivers a printer driver that users can use to create PDFs by printing a document from their application to the PDF Printer. The printer driver can be extracted from the virtual package and using either the “App-V Deployment Configuration” (or another deployment mechanism like SCCM) the printer driver can be added to the OS and then the users can continue to use the functionality.

5.2.4.3 Problem Consideration: While this is a viable technical option it does split the application into two separate items that need to be managed. It will often require both time and advanced application skills to achieve.

5.2.4.4 Where can FSLogix Help in this Scenario? Rather than split the applications that require non-virtualised components, FSLogix can be used to manage these applications within the base build.

6 Other Topics 6.1 Number of Applications in the Base Build: There have been at least two instances where I have noticed comments similar to the one from “Kris Smith” following Rory Monaghan’s blog (http://rorymon.com/blog/?p=3122) where Kris states the following:

“Ok so, you can create one unified base image. Just install all of your applications on your Gold image and then use FSLogix to manage what applications your users can see and use.

How far can you take this? I can see how it works fine with a few apps, and a couple of versions of java but does this start to break down at some point? The Idea of installing 50 to 60 apps in a base image starts to worry me but it could work, but when you 300+ applications. I can’t imagine that any base image is going to be happy having that lot installed.

And then what happens when you need to update the base Image?”

To rebuff these concerns the response that I believe best counters this is:

There are two key considerations:

1. The size of the resultant image (with 300+ applications installed)

If the image is to be non-persistent then the size of the master image is less of a concern.

2. The “management of change” for this number of applications

How many apps is a manageable number in a Base Image, and when does the rate of application change in the image become a management overhead? This is why I think that in the first instance, the combination of App-V/other virtualisation technology and FSLogix is excellent along with the ability to remove the need for App-V infrastructure etc. However when you are talking of hundreds of applications in the base image I think the there is a need for operational change in how you Compile the desktops. You keep your base image to a minimal number of applications (if any) and update that each week with the Windows patches. Once you have created this week’s OS image then you clone that and use a RunBook of the current applications in the estate, and install all of these before cutting the final image for releasing to the users.

This way you are not “managing the base image” as such, and when applications need changed you’re not “uninstalling and installing”, you are just installing the current release. It might be that you Patch on Wednesday, RunBook the applications on Thursday and release an image on Friday. This also separates the application upgrade and introduction processes from the OS updates process. A bit like bringing DevOps processes to the Desktop Assembly line.

6.2 Licensing Considerations when all Apps are in Image: Q: If I install all of my applications into the base image and then mask it am I not going to be accountable for paying for each license.

A: Along with the stance that is FSLogix have gained from the vendors it is also worth noting that it is no different than any of the other technologies that enable non-persistent desktops (other layering technologies / application virtualisation technologies). If the license is device based then the chances are that licenses would need to be purchased for all devices that the application can be run on whether it is installed and masked or added on the fly.

7 Time and Effort Analysis 7.1 Approach: To minimise any inconsistencies the same desktop was used for both Sequencing and creating the FSLogix rules:

Only the products native capabilities will be used for the comparison (no 3rd party tooling is being used to expedite the processes).

Only a Default Install of the application will be performed. The goal of this process is not to produce a properly configured and tested application. It is expected that in each case there would be “tweaks and configurations” required for the application to progress into a production environment. Testing of the application will be limited to an initial Launch. If there is an error this will be noted in the results.

Assumed “Best practices” will not be applied (e.g. disabling Auto Updates, creating App-V feature blocks etc.) as these are all subjective and dependent on end platform environment.

7.1.1 Sequencing Approach: 1. Copy Installation media to the Sequencing desktop 2. Start the Sequencer GUI and complete the initial information forms 3. Start the installation 4. Do a default installation (Next, Next, Next) 5. Don’t perform any customisations, application launches, or creating of

feature blocks 6. Finish Sequencing and save the package 7. Copy the .appv package to a network share 8. Revert the Sequencer to a clean state 9. Change to a client desktop 10. Use App-V PowerShell commandlets to add and publish the package 11. Launch the application and check that it functionally works 12. If there is an error – note as an application that requires further remediation

work 13. Close the application 14. Times will start when the Copy operation begins to the Time the App-V

package has been launched

7.1.2 Creating FSLogix Rules: 1. Copy all installation media to the desktop 2. Install the application 3. Launch and close the application 4. Open the FSLogix Rules creator 5. Create the Rule 6. Apply the Rule 7. QA that all application elements (COM integration etc., Uninstall info have

been masked) 8. Remediate Rule with necessary changes 9. Leave final Rule applied and install the next application 10. Rinse and repeat for all applications

11. Time for each application will be from the Time the install was started to the Time that the Rule was passed as complete. The initial copy time will be divided by the number of applications and added to each applications rule creation time

7.1.3 Application Selected: 1. 7-ZIP 2. Evernote 3. OpenOffice 4. Opera Browser 5. Sage Accounts 2014

7.2 Results: Application Name FSLogix Rule

Creation App-V Package Creation Difference

7-ZIP 3 Mins 40s 7 Mins 4s 3 Mins 24s Evernote 2 Mins 40s 6 Mins 40s 4 Mins 0s

Open Office 4 Mins 4s 7 Mins 32s 3 Mins 28s Opera Browser 3 Mins 3s 5 Mins 29s 1 Mins 30s Sage Accounts

2014 12 Mins 25s 19 Mins 8s ++ *1 6 Mins 43s

[ *1 : App-V package could be added to the App-V Client but the Publish-AppVClientPackage command failed with the following error:

Publish-AppvClientPackage : Application Virtualization Service failed to complete requested operation. Operation attempted: Publish AppV Package. Windows Error: 0x800736FF - The supplied assembly identity is missing one or more attributes which must be present in this context Error module: Virtualization Subsystem. Internal error detail: A460142A800736FF.

Further investigation needed to remediate the application.]

8 SUMMARIES 8.1 Deployments of 50 Apps or Less: Install all applications into the base image and deploy: manage the application updates as per a physical desktop environment by uninstalling and re-installing the application. Manage availability of the applications with FSLogix:

Adding Application virtualisation into the mix would offer benefits, however it would depend on the appetite of the organisation to learn the new technologies.

8.2 Deployments of 50-100 Apps: Separate the notion of applications into user applications, middleware components etc. Install all middleware components into the base build (C++ 2005-2013, .Net 2.0-4.5). Possibly include Office as a base build application.

Install the most recent version of any major middleware components (Oracle Client) into the image. Remediate as many applications as possible to work with this version. Trial installing multiple versions of the middleware components and masking older/less used versions with FSLogix. Consider masking by Process so the appropriate middleware version is consumed by the appropriate application. If the middleware is not able to be installed in multiple versions, then virtualise it.

Adopt a RunBook mechanism to allow installation of applications into the base build prior to deployments.

Separate applications that require Office / IE plugins and add these to the RunBook along with FSLogix RULEs for masking plugins / application where appropriate.

Attempt virtualisation of remaining applications but do not spend more than 4 Hrs attempting to virtualise the application. If it does not virtualise (due to technical complexities or deployment complexities) then add these to the RunBook.

Aspire to achieve 50%-60% virtualisation of applications which can be deployed per user, and outside of the image deployment process.

Consider options that remove the App-V infrastructure and simplify the deployment process.

Aspire to one non-persistent VDI image to manage across all applications and users.

8.3 Deployments of Greater than100 Apps: As above but consider adding more effort to the application virtualisation process (up to 24 Hrs effort).

Aspire for 60%-80% virtualisation of the applications.

Aspire to less than five non-persistent images.

Consider using FSLogix to manage the virtual application visibility and register all virtual applications on every desktop at startup, removing the need for a streaming infrastructure.

Look at the allocation of virtual desktop infrastructure into appropriate pools and possibly divide the allocation of these desktop pools based on application sets rather than users and departments in the first instance.

8.4 Key Considerations: Organisations should be looking at their application delivery strategy independent of the platform. This will lead to a better utilisation of these technologies and a greater uptake. As capabilities move forward, organisations will be in a better position to introduce and maximise the benefits made available to them.

It is key in any application delivery strategy to accept that no single solution will offer a 100% answer to the application dilemma. Once this has been accepted the goal is to ensure that the best delivery / availability option is selected for an individual application based on the platforms it needs to run on.