Do you work in multi-server MED-V environments? Do you currently have a MED-V development environment as well as a production environment? Will you be preparing images in a lab and then pre-staging images in production? If so then chances are you probably ran into the following error:
Failed to download Workspace image. Reported error: The image file index key is missing or wrong.
This is an issue that results from the key pair used to encrypt the VHD during the image packing process (creating the .CKM file) being different than the one being used by the client policy to decrypt the image.
How can this happen? One file is at the center of this issue: the KeyPair.XML file. This file is stored in the main installation directory. This file holds the encryption keys. This file is generated by each MED-V server installation. This file will need to be manually synchronized between MED-V servers if they are configured in an active/passive failover cluster. The only exception to this would be if the servers are using shared storage.
This file will also need to be manually synced between test and production servers that share packed images (CKM files.)
That means when moving management consoles back and forth between servers and importing policies back and forth between test and production servers may also create problems launching images - especially when image have been packed and associated with one policy server, then used with a completely separate one. Lack of synchronicity between this as well as the workspacekeys.xml file can cause workspace startup failures, most common being:
Understanding the XML files and their relationship to the way the MED-V client and server communicate will help you avoid running into issues such as having the wrong index keys or problems with clients and servers not starting at all because the wrong XML files were modified (digitally signed ones) thus creating tampering prevention mechanisms that have been built into the MED-V v1 product.
Overview of the MED-V Server Configuration Files
The majority of MED-V Configuration is stored inside of specific XML files. As mentioned in passing earlier, these files are additionally protected via digital signatures to protect from tampering. The server configuration files are located in the MED-V default installation directory.
This is where the base server configuration is stored. This file is protected by a digital signature and direct modification will trigger a tampering alert and will require the server component to have to be reinstalled.
This is where the global settings for clients are stored. These will be passed down to the client upon authentication. This particular file should also never be modified.
This is the file located in the main directory that is modified by the Server Configuration Utility. THIS FILE CAN BE EDITED. Please refer to the previous blog posting on specific configuration options when modifying this file: http://blogs.technet.com/medv/archive/2009/10/14/configuring-the-med-v-server-by-manually-editing-the-serversettings-xml-file.aspx
This is the location of additional minor configuration details. This file is stored in the main directory. There is one important entry <StorePath> which houses the location of the non-protected XML files. These particular files are unsigned, unencrypted, and unprotected. The default location is <InstallationDirectory>\ConfigurationServer.
The Non-protected Configuration Server Files
The ConfigurationServer directory is the location directory of the MED-V Environment’s configuration repository for managed environments. This is where the server keeps the files which will be sent to the client computers. This is also the location where the management console reads and writes the MED-V policies. The policy files are divided up into two files:
· OrganizationalPolicy.XML: This is the file that is used and modified by the management console.
· Client Policy.XML: This is the file which is passed down to the client upon policy update.
In addition, there are additional files which also govern managed clients:
· PublicKey.XML: Each file that is sent to the client is protected with a digital signature. This file holds the public key used to verify the data integrity.
· Workspace Keys.XML: This holds the workspace encryption keys. When creating a new version for an existing image, the server will use the existing key. When creating a new image the server will generate a new encryption key.
· ClientSettings.XML: A modifiable copy of the ClientSettings.XML found in the base installation directory.
Client XML Files
During authentication, specific copies of key XML files are copied down to the client (and refreshed during subsequent authentications. When these files are passed down to the client, they are stored in the %PROGRAMDATA%\MED-V\Local \Config directory.
The clientpolicy.xml file is also encrypted on the client and are not viewable through an XML editor. This is to prevent viewing potentially compromising information related to policy restrictions. These files will remain mandatory on the client, and tampering with or removing the file will cause the MED-V Client service to fail. When a file is removed it will cause the MED-V client to malfunction and fail to restart.
Log Name: Application Source: MEDVService Date: <date/time> Event ID: 0 Task Category: None Level: Error Keywords: Classic User: N/A Computer: steveth1 Description: Service cannot be started. System.TypeInitializationException: The type initializer for 'Kidaro.Foundation.Config.Configuration' threw an exception. ---> System.IO.FileNotFoundException: Could not find file 'C:\ProgramData\MED-V\Local\Config\Configuration.xml'. File name: 'C:\ProgramData\MED-V\Local\Config\Configuration.xml' at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share) at Kidaro.Foundation.IO.BackupGuardedFile.CreateReadStream(String path) at Kidaro.Foundation.IO.BackupGuardedFile.ReadFile() at Kidaro.Foundation.Config.SynchronizedFilesAccess.ReadFilesContent(List`1 paths, Boolean getFullPath) at Kidaro.Foundation.Config.SynchronizedFilesAccess.ReadFiles(Boole...
If the file has been tampered with or overwritten with an invalid file, it will generate tampering errors as well as signature verification errors when trying to launch the MED-V client. Tampering in between policy refreshes can trigger authentication errors.
Restarting the MED-V Client will also fail with the same signature verification error.
Log Name: Application Source: MEDVService Date: <date/time> Event ID: 0 Task Category: None Level: Error Keywords: Classic User: N/A Computer: steveth1 Description: Service cannot be started. System.TypeInitializationException: The type initializer for 'Kidaro.Foundation.Config.Configuration' threw an exception. ---> Kidaro.Foundation.Config.FileSecurityException: Failed verifying signature of file 'C:\ProgramData\MED-V\Local\Config\Configuration.xml'. ---> Kidaro.Foundation.Cryptography.XmlIntegrityException: Verification failed: Signature does not match file content. The file may have been tampered with. at Kidaro.Foundation.Cryptography.XmlIntegrityLogic.VerifyXml(XmlDocument doc, AsymmetricAlgorithm keysForVerifying) at Kidaro.Foundation.Config.SignedConfigurationFilesAccess.GetVerifiedConfiguration(String path, Byte content, XmlDocument verifyingKey) The Zone of the assembly that failed was: MyComputer --- End of inner exception stack trace --- at Kidaro.Foundation.Config.SignedConfigurationFilesAccess.GetVerifiedConfiguration(String path, Byte content, XmlDocument verifyingKey) at Kidaro.Foundation.Config.SignedConfigurationFilesAccess.ReadConfigurationFiles() ...
OR this error which usually happens when trying to parse a corrupted encrypted client-side clientpolicy.xml file.
Log Name: Application Source: MEDVService Date: <date/time Event ID: 0 Task Category: None Level: Error Keywords: Classic User: N/A Computer: steveth1 Description: Service cannot be started. System.Xml.XmlException: Data at the root level is invalid. Line 1, position 1. at System.Xml.XmlTextReaderImpl.Throw(Exception e) at System.Xml.XmlTextReaderImpl.Throw(String res, String arg) at System.Xml.XmlTextReaderImpl.ParseRootLevelWhitespace() at System.Xml.XmlTextReaderImpl.ParseDocumentContent() at System.Xml.XmlTextReaderImpl.Read() at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace) at System.Xml.XmlDocument.Load(XmlReader reader) at System.Xml.XmlDocument.Load(Stream inStream) at Kidaro.Foundation.Config.XmlConfiguration.LoadXml(Byte xml) at Kidaro.Foundation.Config.XmlConfiguration..ctor(Byte content) at Kidaro.Foundation.Config.SignedConfigurationFilesAccess.GetVerifiedConfiguration(String path, Byte content, XmlDocument verifyingKey) at Kidaro.Foundation.Config.SignedConfigurationFilesAccess.ReadConfigurationFiles() at Kidaro.Foundation.Config.SimpleFileConfigurationProvider.PrepareConfiguratio...
Steve Thomas | Senior Support Escalation Engineer