App-V 5: On App-V Package Modernization with the OPC (Open Package Container) or: One Package Container to rule them all!
Much of the changes in App-V 5 revolved around moving to more integrated components (NTFS, a “real” registry, native API’s on the client, representational state transfer on the server side, etc.) – but one of the most major key developments was the modernization of the AppV Package format. The reason behind this was simple. Using this new standard based upon an open standard allows for the modernization of your legacy applications with regards to package format. This provides synergy going forward by synchronizing the packaging of legacy application with the native packaging format of your modern applications existing (or to come.)
This drastic change makes a huge difference. The package is open and human readable. No more closed, custom package format full of mystery. Pre-requisites, installation process, experience opt-in settings, configurations, and site-specific deployments can be simplified into a single-command deployment. In addition, the package format exists in an installed state that follows the principles of the open package specification outlined in the ISO standards for the Open Package Specification (OPC) – http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=51459
This is also clarified in the following magazine article from MSDN: http://msdn.microsoft.com/en-us/magazine/cc163372.aspx
The OPC Standard
The Open Package Conventions, or as it also referred to as Open Packaging Container, are a set of standards spearheaded by Microsoft to store binary data and XML metadata in a single entity leveraging Open XML and ZIP formats. OPC-based file formats combine the advantages of leaving the independent file entities embedded in the document intact and resulting in much smaller files compared to normal use of XML. With OPC, you have a package in ZIP format that can contain mandated descriptor files, content definitions by MIME type, followed by application-specific metadata and resources files. With the embedded MIME definitions it also removes many issues associated with simple document file type extensions.
The container could be treated as a package or a document – as in the case with Office documents. Regardless, each is technically a ZIP archive containing resources identified as parts and each part has a unique path identifier by URI and by a specified content type expressed as a MIME type to describe the actual data stored in that part. You can see this when you browse an APPV, APPX, or even a .DOCX file using a ZIP utility.
In addition to a hierarchy of directories and parts, OPC packages representing document types commonly use relationships to access content through associations. These Relationships are composed of four elements:
- The identifier (ID)
- The optional source (the package or a part within the package)
- The relationship type (a URI-style expression that defines the type of the relationship)
- A target (a URI to another part within the package or to an external resource)
The extension ".rels" is reserved for storing relationships metadata within "/_rels" subfolders. The subfolder name "_rels", the file extension ".rels" within such directory, and the filename "[Content_Types].xml" in any folder are the only three reserved names for files stored in an OPC package. Otherwise, it is extensible to associate additional resource type with their specific package and application standards (for example – those resources tied to App-V i.e. StreamMap.xml, PackageHistory.xml, etc.)
Notice in an APPV package while the [Content_Types].xml is present, the .rels components are not. AppX and AppV handles these relationships differently using its own AppXBlockMap.xml and AppXManifest.XML files. More information can be found in that excellent MSDN article I referenced earlier: http://msdn.microsoft.com/en-us/magazine/cc163372.aspx
AppX (Modern Applications)
AppX is the OPC-compliant package format for both Modern applications and Windows RT packages (what we commonly refer to as store applications) as referenced in: http://msdn.microsoft.com/en-us/library/windows/apps/hh464929(v=VS.85).aspx
The AppX package can be viewed with a ZIP extraction utility just like the AppV package. Like the APPV file format, the APPX package uses declarative XML to define requirements, dependencies, and relationships defined in “AppxManifest.xml” instead of a relationship resource folder.
AppV (Legacy Applications)
While the AppX package format can be generated during modern application development (http://blogs.msdn.com/b/windowsappdev/archive/2012/12/04/designing-a-simple-and-secure-app-package-appx.aspx) your existing applications can be sequenced with the App-V sequencer and deployed, managed, and serviced as App-V packages that have the binary equivalency of the Windows Store APPX format. Even better, these can be deployed to Windows 7 computers running the App-V 5 Client (where store-based modern applications cannot.) Be advised however, that while App-V 5 uses the same file format as modern applications, it does not mean you can deploy or publish an App-V package as a Windows Store application. They only share the same modern package format.
UPDATE 4/29/2015 – The AppV package format will be leveraged for Store deployments of Win32 applications going forward in Windows 10.
That’s not all . . .
Document Formats have gone that way as well. Ever opened a DOCX or XLSX file in 7-ZIP? You can see the OPC-based layout this way! This is by no means new. This began with Office 2007. In fact, other vendors besides Microsoft have started to adapt this standard including Autodesk, Siemans, and Mathworks. There is an excellent historical reference on MSDN that introduced the OPC document format and relationships back in 2009 that is very helpful in understanding the Open Packaging standards as they apply to Office document formats here: http://msdn.microsoft.com/en-us/library/ee361919(v=office.11).aspx
App-V 5: The Case of the Failed Connection Group Descriptor (or . . . Another Reason not to Use Notepad for XML File Creation)
Have you ever noticed that when you go to save a newly created file in Notepad, the default encoding is ANSI? And this matters to App-V how you ask?
Normally this may not matter to you but I should inform you that this actually is important – especially if you are a purist and insist on using Notepad to create XML files. In the case of App-V, you may be using it to create dynamic configuration files or Connection Group Descriptors to test Connection Groups in stand-alone mode.
Take the following Connection Group XML descriptor document:
<?xml version="1.0" encoding="Unicode" ?>
<appv:Package DisplayName="JRE6U32" PackageId="58bade90-3338-4ef5-bdf7-c7bc87c3b177" VersionId="0ec92974-d30a-4dd9-b52c-77b0ea7e59ef"/>
<appv:Package DisplayName="FREECOL_VFS" PackageId="1f635638-3e0b-44da-98f4-48f12e823c65" VersionId="6fcb3000-d4b5-45e6-991f-f88c6668b9aa"/>
Do you notice anything wrong with the above document? Me neither. However, if you were save the file in Notepad using the default ANSI encoding, you may run into problems when you try to add the Connection Group.
The error you will get is:
“Data at the root level is invalid. Line 1, position 42.”
You’ll notice that in the event of this error, you will likely not see much of anything else in terms of logging. The root cause is exactly what the error states. It is invalid data – due to encoding.
You can also confirm this by attempting to view the XML document in Internet Explorer. If there is an encoding mismatch where the encoding is ANSI instead of unicode, IE will just simply show a blank page. Proper XML encoding will show up correctly formatted as shown below:
Applications such as XML Notepad and Notepad++ match up with the schema specification automatically – especially Notepad++ (which I actually use) when you specify the output as XML specifically.
Now some savvy users may want to know what would happen if they simply just changed the element of ENCODING to ANSI in the XML document. It will error out as well because ANSI encoding is not supported.
When you attempt to launch a MED-V workspace you may get the following error:
Error: Initial Handshake with Workspace failed.
This is caused by the the handshake timeout failure. The default value may be set too low for the MED-V RTM release (build 220.127.116.11).
For MED-V SP1 (Build 18.104.22.168) the default value has been doubled. As a workaround for v1, check the timeout setting in the clientsettings.XML. The InitialHandshakeMaxTimeout value in the ClientSett The RTM build will have this value empty meaning it is using the default (30.) You can modify this setting by placing this entry below the <Client> node.
Here is the settings placement inside the XML file:
For information on how to safely modify the clientsettings.xml file, please refer to the following link:
You will also need to set the appropriate COM port settings in the base .VMC file. You can do this through the user interface by editing the settings of the virtual machine.
You can also modify the VMC directly. The XML for the .VMC pertaining to the serial port is below. The below XML represents COM1 enabled for serial port usage:
<serial_port id="0"> <connect_immediately type="boolean">true</connect_immediately> <port_name type="string">COM1</port_name> <port_type type="integer">1</port_type> </serial_port>
You may also need to ensure the settings are verified on the guest OS as well (inside Device Manager within the guest operating system.)
Registry values include:
- DesktopShortcut: A REG_SZ value that determines if the client will auto place a desktop shortcut.
- PrestagedImagesPath: A REG_SZ value that determines the path to CKM images that have been predeployed.
- StartAutomatically: A REG_SZ value that determines if the client starts at logon.
Most of the other information is stored here:
This is the MED-V Client Profile. The client profile is where the information set during the installation is stored. This serves as a template for the actual Windows user running the client. The user working copy is always stored in the %LOCALAPPDATA%\MED-V\Profile directory.
If you were to manually modify the MED-V server, you will want to modify <ServerAddress>
<Kidaro> <ServerAddress type="System.String">http://localhost:80</ServerAddress> <ImageDistributionEnabled type="System.Boolean">True</ImageDistributionEnabled> <ConfigurationFolder type="System.String">C:\ProgramData\MED-V\Local\Config</ConfigurationFolder> <VmsFolder type="System.String">C:\MED-V Images\</VmsFolder> <ClientCertificateThumbprint type="System.String"> </ClientCertificateThumbprint> <ClientId type="System.String"> </ClientId> <KidaroDomain type="System.String"> </KidaroDomain> <DataFolder type="System.String">C:\ProgramData\MED-V</DataFolder> </Kidaro>
This (Profileinfo.xml) and the other files explained in my blog post on the MED-V Team Blog:
If you want to modify the password save policy for all of your clients, you will need to modify the global clientsettings.xml file in the C:\Program Files\Microsoft Enterprise Desktop Virtualization\Servers\ConfigurationServer directory.
Please refer to this blog on modifying this file – particularly the version modification.
1.) To change the Password save policy
2.) Back up ClientSettings.xml file.
3.) Edit clientsettings.xml file