Virtualization by Davis: “Sustainable Energy Leader Uses XenClient to Migrate to Windows 7 and Accelerate ROI” plus 3 more

Sustainable Energy Leader Uses XenClient to Migrate to Windows 7 and Accelerate ROI
Microsoft Application Virtualization 5.0 Integration
Can a wildcard be used to insert specific FQDN for a web pool to throw an alert?
2013 Predictions: Proper Application Management Will Save Time, Money and Frustration (Part 2 of 2)

Sustainable Energy Leader Uses XenClient to Migrate to Windows 7 and Accelerate ROI

Posted: 03 Jan 2013 02:15 PM PST

Afval Energie Bedrijf (AEB) of Amsterdam, Holland is a world leader in the sustainable conversion of waste into energy and reusable raw materials. But when they wanted to convert native PCs into virtual desktops to solve their very costly Windows 7 migration challenge, they turned to Citrix and deployed XenClient. Using local virtual desktops and laptops powered by XenClient made it possible for AEB to comply with…

Microsoft Application Virtualization 5.0 Integration

Posted: 03 Jan 2013 06:24 AM PST

written by – Ozge Yavuz, SDE

Introduction

App-V 5.0 "isolates" virtual applications from the operating system and other processes. This is done by hiding the application resources from everything else. One can imagine this as running the virtual application in a bubble that isolates the application from the outside world. Integration, on the other hand, can be thought of as tunnels punching through this bubble, exposing the virtual application capabilities to the native operating system and to the user in a controlled manner. This enables virtual applications to behave as native applications. Think about a shortcut of a virtual application residing on the user's desktop. This shortcut is outside the virtual bubble and is not isolated since it is on user's desktop. But this shortcut enables the user to launch the virtual application seamlessly as if it was a native application. This shortcut feature and some others make up the Integration component of App-V. Integration is a collection of subsystems that individually handle one specific integration area. The following is the list of integration subsystems currently available in App-V product:

· Shortcut Subsystem

· FTA Subsystem

· COM Subsystem

· Software Clients Subsystem

· Application Capabilities Subsystem

· URL Protocol Handler Subsystem

· App Path Subsystem

· Virtual Applications Subsystem

Extension Points

An extension point is a single integration unit such as a shortcut of a virtual application. Each integration subsystem can have one or more extension points (EPs). An example would be a virtual package having multiple shortcuts.

Integration Workflows

Integration has two separate work flows:

1. Sequencing: Capturing integration data from the application being sequenced

2. Publishing: Integrating the application to the native operating system during publishing of the package by using the data captured during sequencing

Sequencing

During sequencing of a package, integration subsystems are started after the target application is installed. These subsystems consume the application installation data that the installer lays down (e.g. shortcuts, FTAs, etc.) and then produce extension points (EPs) that end up in the package manifest.

Sample Package Manifest

Publishing

During publishing of an App-V package, Integration reads extension points from the package manifest, dynamic deployment configuration and dynamic user configuration files (if these configuration files are provided). Integration then merges EPs from all these sources and finally integrates these EPs to the native operating system.

Important:

Please note that throughout this blog entry, I will refer to publishing of a package as "integrating the package to the computer". The reasoning behind that is integration of a package can be initiated externally by a publishing operation or internally when the package is already published to the user but not yet integrated. Further details are outside the scope of this article and will be discussed in a future blog entry.

Global vs. User Publishing

During publishing of an EP, App-V will automatically select where in the operating system the EP should be integrated based on how the package is published.

Global publishing

If the package is published globally (sometimes referred as machine publishing), the shortcuts will be created in public locations on the computer and other integration will happen in HKLM locations in the registry.

Examples:

o If a shortcut is to be created on the desktop, the location would be FOLDERID_PublicDesktop (%PUBLIC%\Desktop),

o If an FTA registration is to happen, it would be created under HKLM\Software\Classes

User publishing

This will place shortcuts in user locations and other integration to HKCU registry locations.

Examples:

o If a shortcut is to be created on the desktop, the location would be FOLDERID_Desktop (%USERPROFILE%\Desktop)

o If an FTA registration is to happen, it would be created under HKCU\Software\Classes

Backup, Restore and It's Ownership

During integration, integration subsystems backup existing data of native applications that would be otherwise overwritten.

For example, if a native application is installed and has the .docx file type association, and a virtual application package with the .docx EP is being integrated, the file type association belonging to the native application is backed up first and then the EP is integrated. Also, when the package gets unpublished, the EP will be de-integrated first and the backed up .docx file type association will be restored.

App-V also tracks which package owns the backed up data and only restores it if the owner package gets de-integrated. This is to allow for two or more virtual application packages publishing the same EP (e.g. the same .docx file type association), the last published package should be the owner and if the first package gets unpublished first, we shouldn't restore the backed up data so that we don't overwrite the last package's extension points.

· If two packages are competing for the same EP, the last package that is integrated takes ownership.

· If the first package gets unpublished, backed up data will NOT be restored since the package is no longer the owner of the backed up data.

· If the second package gets unpublished, backed up data will be restored.

This backup and restore process happens for each extension point, including shortcuts and registry-based subsystems.

Notifying Windows Shell of User Account

App-V client uses a separate process called AppVShNotify.exe during integration of a package to send notifications to the Windows Shell. For example, the Windows Shell requires applications (here, App-V Integration) to notify the Shell when a new shortcut on user's desktop is created. When the Shell receives this notification, it refreshes the user's desktop display. The AppVShNotify.exe process runs under the user account. It will be started when the first package for the user is published and will keep running until user logs out.

Dynamic Configuration Files

App-V uses dynamic configuration files to provide customizations to the virtual package since the package itself is not editable. These configuration files can be used to alter behavior of integration subsystems such as adding or editing a new shortcut.

These configuration files can be used to:

· Enable or disable integration subsystems. When a subsystem gets disabled, its EPs will not be integrated

· Provide extra configuration for integration subsystems (see COM subsystem below for an example)

· Replace EPs of subsystems

Important:

When a configuration file includes EPs of a subsystem, these extensions will replace all EPs defined in the package manifest. To edit or remove a single EP (e.g. a shortcut), all the EPs belonging to that subsystem should be copied first from the manifest and the EP in question edited or removed.

There are two types of configuration files:

· Dynamic User Configuration (DUC)

Configure the package for an individual user
- E.g. add a new shortcut specific to the user to whom the package is being published
If a Dynamic Deployment Configuration (DDC) exist for the package, DUC replaces "User Configuration" section during integration

· Dynamic Deployment Configuration (DDC)

Configure the package for global publishing or user publishingon that machine
- E.g. add a new shortcut for all users that get the package

o Can have a "User Configuration" section which can be overridden by DUC

The App-V Sequencer generates sample DUC and DDC files for each package to ease creation or modification of these documents. It uses EPs from the package manifest to prepopulate them.

Example Integration Scenarios

Let's examine the example scenarios below using sample files to understand what happens during publishing. First, let's introduce sample files:

When package is published to a user

· If no DDC or DUC provided during publishing, Shortcut 1 and Shortcut 2 are integrated

· If DDC is provided, only Shortcut 3 is integrated

· If DUC is provided, only Shortcut 4 is integrated

· If both DDC and DUC are provided, only Shortcut 4 is integrated

When package is published globally

In global publishing a DUC cannot be provided. So the scenarios become simpler

· If no DDC provided during publishing, Shortcut 1 and Shortcut 2 are integrated

· If DDC is provided, only Shortcut 3 is integrated

App-V client PowerShell Cmdlets and Integration

Below are the PowerShell cmdlets that are relevant to integration. See App-V 5.0 Client PowerShell Deep Dive for further details.

Add-AppVClientPackage <path to package> [- DynamicDeploymentConfiguration <path to file>]

o No integration of the extension points from the package is done

o Dynamic Deployment Configuration is optional

Publish-AppVClientPackage [- DynamicUserConfigurationPath <path to file>] [-Global]

o Package gets integrated

o Dynamic User Configuration is optional

o If Dynamic Deployment Configuration was provided to Add-AppvClientPackage, and/or Dynamic User Configuration is provided to Publish-AppvClientPackage, they will be used during integration

Unpublish-AppVClientPackage [-Global]

o Package gets de-integrated

o If Dynamic Deployment Configuration and/or Dynamic User Configuration was provided, they will be used during de-integration

Remove-AppVClientPackage

o If package is published globally: The package gets de-integrated immediately if not de-integrated before (by an Unpublish-App-VClientPackage)

o If package is published for user: The package gets de-integrated immediately if the user is logged on or next time the user logs on

Repair-AppVClientPackage [- Extensions] [-Global]

o If "Extensions" flag is provided, or if "-UserState" not provided, the package gets re-integrated, effectively repairing all extension points

Integration Subsystems

Following are the integration subsystems currently supported by App-V as of 5.0.

Shortcut Subsystem

Shortcuts are one of the main mechanisms by which a user can launch an application. The Shortcuts subsystem captures shortcuts that were created during installation. During publishing of a package, these shortcuts are recreated.

Note: For information about shortcuts, Shell Links on MSDN.

This is the only file-based integration subsystem that exists in App-V 5.0.

Manifest Example:

<File>[{Desktop}]\Shortcut.lnk</File>

<Target>[{App-VPackageRoot}]\Folder\application.exe</Target>

<ApplicationId>[{App-VPackageRoot}]\Folder\application.exe</ApplicationId>

</Shortcut>

</Extension>

FTA Subsystem

This subsystem allows file extensions to be associated with applications.

· FTAs usually associates a file extension to a ProgID

o Ex: .docx => Word.Document.12

· The ProgID for an FTA will usually have a shell command to execute

o Word.Document.12 \ shell \ Open \ command \ <Path to Winword.exe>

Notes:

1. As of App-V 5.0, the only supported shell extensions are:

a. Preview Handler

b. Icon Handler (partially)

2. For more information about FTAs, see File Types and File Associations on MSDN.

This is a registry-based integration subsystem.

Manifest Example

<ProgId>AbcFile</ProgId>

</FileExtension>

<Name> AbcFile</Name>

<Description>Description of the ProgID</Description>

<ApplicationId>[{App-VPackageRoot}]\Folder\application.exe</ApplicationId>

<CommandLine>"[{App-VPackageRoot}]\Folder\application.exe" "%1"</CommandLine>

</ShellCommand>

<ApplicationId>[{App-VPackageRoot}]\Folder\application.exe</ApplicationId>

<Name>Print</Name>

<CommandLine>"[{App-VPackageRoot}]\Folder\application.exe" /p "%1"</CommandLine>

</ShellCommand>

</ShellCommands>

</ProgId>

</FileTypeAssociation>

</Extension>

COM Subsystem

App-V has two subsystems to provide support for COM objects in a virtual application package.

· COM integration: Responsible for integration of COM objects, TypeLibs, etc. from the virtual application package to the native operating system. This is an integration subsystem and is covered in this document.

· COM virtualization: Isolation of COM objects when the virtual application is launched. This is a virtualization subsystem and is not covered in this document.

COM Integration

Com integration subsystem is responsible for integrating registration of COM objects from the App-V package. These registrations are captured during sequencing and are integrated during publishing.

Note: For more information about COM, see Component Object Model (COM) and COM Registry Keyson MSDN

This subsystem supports two types of registration:

· Out-of-process COM registration

· In-process COM registration

Note: Virtualization of In-process COM objects are not supported by the App-V 5.0 client and thus it is not guaranteed that such objects will function properly.

COM Modes

COM support in App-V can be configured using dynamic configuration files. These files provide a "COM Mode" setting that alters the behavior of the two COM subsystems (integration and virtualization)

The possible values for the "COM Mode" are:

· Off

· Isolated (default)

· Integrated

o Out-of-process registration (OOP)

o In-process registration (IP)

COM Mode	COM Integration	COM Virtualization
Off	No integration with OS	Off
Isolated	No integration with OS	On – renaming on
Integrated (OOP: N, IP: N)	No integration with OS	On – renaming off
Integrated (OOP: Y, IP: N)	Integrate only OOP	On – renaming off
Integrated (OOP: N, IP: Y)	Integrate only IP	On – renaming off
Integrated (OOP: Y, IP: Y)	Integrate both OOP and IP	On – renaming off

Renaming: Mechanism used by virtualization subsystems to "hide" named objects of the package (such as COM) from native applications by modifying the name of these objects

Sample Dynamic User Configuration

<COM Mode="Integrated">

<IntegratedCOMAttributes OutOfProcessEnabled="true" InProcessEnabled="false" />

</COM>

</UserConfiguration>

Software Clients Subsystem

Allows virtual applications register to the software client list of the native operating system. This in turn allows actual users of the virtual applications to set default programs for certain tasks.

To set the default programs, a user can follow these steps: Control Panel > Default Programs > Set program access and computer defaults

Used for the following types:

· Email (MAPI)

· Instant messenger

· Media player

· Virtual machine for Java

Note: For more information, see How to Register an Internet Browser or Email Client with the Windows Start Menu on MSDN

Manifest Example

<Name>Contoso Email</Name>

<Description>An Email Client</Description>

<DefaultIcon>[{ProgramFilesX86}]\Folder\application.exe,0</DefaultIcon>

<Reinstall>"[{ProgramFilesX86}]\Folder\reghelper.exe" /SetAsDefaultAppGlobal</Reinstall>

<HideIcons>"[{ProgramFilesX86}]\Folder\reghelper.exe" /HideShortcuts</HideIcons>

<ShowIcons>"[{ProgramFilesX86}]\Folder\reghelper.exe" /ShowShortcuts</ShowIcons>

</RegistrationCommands>

</InstallationInformation>

<ApplicationId>[{ProgramFilesX86}]\Folder\application.exe</ApplicationId>

<Open>"[{ProgramFilesX86}]\Folder\application.exe" -mail</Open>

</ShellCommands>

<MAPILibrary>[{ProgramFilesX86}]\Folder\application.exe\mapi.dll</MAPILibrary>

<Description>Email URL</Description>

<DefaultIcon>[{ProgramFilesX86}]\Folder\application.exe,0</DefaultIcon>

<ApplicationId>[{ProgramFilesX86}]\Folder\application.exe</ApplicationId>

<Open>"[{ProgramFilesX86}]\Folder\application.exe" /email "%1"</Open>

</ShellCommands>

</MailToProtocol>

</EMail>

</SoftwareClients>

</Extension>

</Extensions>

</SoftwareClients>

Application Capabilities Subsystem

This subsystem exposes the capabilities of virtual applications to the native operating system. Users can use these capabilities to set default programs by: Control Panel > Set Default Programs.

Notes:

1. As of App-V client 5.0 this subsystem is integrated only when package is published globally

2. For more information, see Set Program Access and Computer Defaults (SPAD) on MSDN

URL Protocol Handler Subsystem

This subsystem exposes the URL protocol handing capability (such as "mailto:") of an application to native operating system

Note: For more information about URL protocol handlers, see Registering an Application to a URI Scheme on MSDN

Manifest Example

<Name>Contoso Email</Name>

<Description>An Email Client</Description>

<DefaultIcon>[{ProgramFilesX86}]\Folder\application.exe,0</DefaultIcon>

<Reinstall>"[{ProgramFilesX86}]\Folder\reghelper.exe" /SetAsDefaultAppGlobal</Reinstall>

<HideIcons>"[{ProgramFilesX86}]\Folder\reghelper.exe" /HideShortcuts</HideIcons>

<ShowIcons>"[{ProgramFilesX86}]\Folder\reghelper.exe" /ShowShortcuts</ShowIcons>

</RegistrationCommands>

</InstallationInformation>

<ApplicationId>[{ProgramFilesX86}]\Folder\application.exe</ApplicationId>

<Open>"[{ProgramFilesX86}]\Folder\application.exe" -mail</Open>

</ShellCommands>

<MAPILibrary>[{ProgramFilesX86}]\Folder\application.exe\mapi.dll</MAPILibrary>

<Description>Email URL</Description>

<DefaultIcon>[{ProgramFilesX86}]\Folder\application.exe,0</DefaultIcon>

<ApplicationId>[{ProgramFilesX86}]\Folder\application.exe</ApplicationId>

<Open>"[{ProgramFilesX86}]\Folder\application.exe" /email "%1"</Open>

</ShellCommands>

</MailToProtocol>

</EMail>

</SoftwareClients>

</Extension>

</Extensions>

</SoftwareClients>

App Path Subsystem

This subsystem exposes the App Path registration of a virtual application to the native operating system. Using this registration, the operating system can find the application's executable. This feature is usually used by an application to avoid modifying the system PATH environment variable.

For example: When this registration is done, the user can start an application by providing the application name. To launch Microsoft Office Word one can:

· Start "Run" dialog

· Type Winword

Note: For more information, see Application Registrationon MSDN

Manifest Example

<Name>application.exe</Name>

<ApplicationPath>[{AppVPackageRoot}]\path\application.exe</ApplicationPath>

<PATHEnvironmentVariablePrefix>[{AppVPackageRoot}]\path\</PATHEnvironmentVariablePrefix>

<ApplicationId>[{AppVPackageRoot}]\path\application.exe</ApplicationId>

</AppPath>

</Extension>

Virtual Applications Subsystem

This subsystem provides a list of applications captured during sequencing. This list is usually consumed by other App-V components. Also, using dynamic configuration files, integration of EPs belonging to a particular application can be disabled. For example, if a package contains two applications, it is possible to disable all EPs belonging to one application, to only allow integration of EPs of the other application.

Manifest Example

<Target>[{AppVPackageRoot}]\Path\Application1.exe</Target>

<Name>Contoso E-mail Client</Name>

</VisualElements>

</Application>

<Target>[{AppVPackageRoot}]\Path\Application2.exe</Target>

<Name>Contoso News Reader</Name>

</VisualElements>

</Application>

</Applications>

Can a wildcard be used to insert specific FQDN for a web pool to throw an alert?

Posted: 03 Jan 2013 10:52 AM PST

I am not certain this is the correct forum, if not please advise. Thank you

I want to be able to create a custom Distributed Transaction. This DT has multiple facets (IIS, Db and Application to name a few).

Specifically, I want to be able to create a single Web Transaction Monitor that checks for a specific return on both the web pool level as well as the individual IIS server level.

In this – I would have an alert if the URL was not available from the pool level as well if a single server in the IIS pool was unable to deliver a specific return. As far as I know, this is accomplished by creating a custom Web Transaction Monitor for the pool URL as well as individual monitors for the individual servers.

I DO NOT want to create individual rules for individual servers if at all possible.

My question then, is there a way to use a wildcard to insert the specific FQDN of the individual servers in the web pool to throw an alert if the desired return is not reached?

Richard Tamboli

This posting includes an audio/video/photo media file: Download Now

2013 Predictions: Proper Application Management Will Save Time, Money and Frustration (Part 2 of 2)

Posted: 03 Jan 2013 05:12 AM PST

Yesterday I started sharing my 2013 predictions for application management. This year will be one of change due to Windows XP migration, virtualization taking center stage and cloud discussions moving more on the corporate agenda. Delivering applications to end users is the goal in each of those scenarios. Doing it well will mean great rewards for you in 2013- especially in terms of saving time,…

Virtualization by Davis

viernes, 4 de enero de 2013