Archive
MED-V V1: How to Update the Policy Update\Polling Interval
Within MED-V V1, you can modify the default policy interval by modifying one of the XML files on the client. While the official documentation alludes to this:
“A typical MED-V Management Server can support 5000 users based on the recommended hardware configuration. The client-server communication is lightweight: clients are normally configured to poll the server for policy every 15 minutes, and image updates every 4 hours (Can be changed using MED-V configuration)”
What is does not state is how exactly you change the policy update interval from the default interval of 15 minutes.
To modify the Policy Update Interval, this would have to be done on the client side. You can do this by editing the Configuration.XML located in %ALLUSERSPROFILE%\MED-V\Local\Config
The value is UpdaterTimeInterval and it is found under the element as displayed in the example below:
<Configuration>
<SpecialFileProcessor>
<WorkspaceKeys type="System.String">Kidaro.KeysStorage.KeysConfigurationFileProcessor</WorkspaceKeys>
<ClientPolicy type="System.String">Kidaro.Policy.Server.PolicyFileProcessor</ClientPolicy>
</SpecialFileProcessor>
<!-- Should the service update the configuration from the server. -->
<EnableServer type="System.Boolean">true</EnableServer>
<!-- Time interval in seconds between updates of configuration files. -->
<UpdaterTimeInterval type="System.Int32">900</UpdaterTimeInterval>
</Configuration>
Increase the default UpdaterTimeInterval value of 900 (15 minutes in seconds) to desired interval then save the file and restart the MED-V Client service.
MED-V V1 Disaster Recovery
Disaster recovery in MED-V v1 is a very straight-forward and seamless process. Offline access is available for those clients who have already cached their MED-V client authentications. One of the first steps in ensuring a good disaster recovery plan for this version of MED-V is to establish continuity through offline access. This will assume all images that the users need will have been downloaded. Information on MED-V v1 credentials and offline access can be found here:
For the MED-V server, since the configuration is all XML-based, the process for backing up crucial data is very easy and does not even require a system state backup. In my MED-V v1 environments, I simply backup the XML configuration, the reporting database, and the server-side images. This process is outlined in the following article:
http://technet.microsoft.com/en-us/library/ff433607.aspx
The article is pretty straightforward on the key locations for images and configuration:
\Med-V\Med-V Server Images
\Program Files\Microsoft Enterprise Desktop\Servers\ConfigurationServer
It also goes through the restoration process which is just as straight forward. The article does not mention the reporting database. While true, reporting is an option in MED-V V1 and is not required for the server to be operational, most organizations still using MED-V v1 are making use of the reporting database. If the database is locally available on the MED-V server (i.e. though SQL Server Express) please ensure that you are backing up the database (defaults to “medv”) manually using SQL Management Studio Express or through whatever means your database administrators backup databases.
– Steve Thomas
How MED-V Affects Windows XP End-of-Life Support Policy (It Doesn’t.)
Lately, I have many customers who are in the process or quickly planning their migration from Windows XP to Windows 7. Some of them are even looking to become early adopters of Windows 8. In the process of inventorying, rationalizing, and providing application compatibility remediation for their legacy applications, the need for leveraging MED-V for last-resort application compatibility remediation has created questions with regards to Windows XP supportability and how MED-V may or may not affect that. For application issues such as 16-bit remediation for x64, MED-V is the only option for enterprise customers.
Given that the supported MED-V solutions (v1 and v2) and its scaled-back VPC counterpart Windows XP Mode leverage the use of a Windows XP operating system instance, the question is always posed to me – Does the Windows XP EOL policy also apply to MED-V? The question may also be asked slightly differently but more pointedly: Does MED-V extend the Windows XP EOL policy?
The short answer is: No MDOP solution extends or affects the Windows XP Lifecycle end-of-life date for support. That date is firm and will not change. April 8, 2014 – as per the reference here: http://www.microsoft.com/en-us/windows/endofsupport.aspx
MED-V Version 1
MED-V Version 1 is technically still in support however, only MED-V V1 workspaces containing the Windows XP operating system are. Even though MED-V V1 did temporarily allow for the use of Windows 2000 workspaces on Windows 7 when released in 2009, it did not extend the support date for Windows 2000 instances beyond the end of 2010. Since mainstream support for MED-V v1 ends on August 10, 2013 (per http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=desktop+virtualization&Filter=FilterNO) there is no confusion as there is with MED-V V2 since MED-V V1 will already be out of support by the time 2014 arrives. If customers running MED-V V1 have not already started looking for alternative means of application remediation going forward for Windows 7 and/or Windows 8, the time to start thinking about that is now. Note: MED-V (any version) is not supported on Windows 8.
MED-V Version 2 and Virtual PC for Windows 7
MED-V version 2 will be supported until December 4, 2016 (per http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=desktop+virtualization&Filter=FilterNO.)
What this means is the actual MED-V and VPC7 code will be supported beyond the Windows XP EOL date – but the Windows XP code will not be. In essence, the host machine’s software will be fully supported until that date but no security or critical updates will be released for the guest operating system (other than potentially code fixes for elements pertaining to the MED-V guest agent.) Remember, MED-V is designed to only serve as a temporary solution for remediation. The end game should be the modernization or replacement of the application(s) in question. Also take heed the same applies for Windows XP Mode.
So the big question . . .
Finally, the last question I am always asked is: What do you recommend our end game date for leveraging MED-V should be?
My honest answer has never wavered: April 8, 2014 – if not sooner.
MED-V 1.0: Unhandled Exception when running the VM Prerequisite Wizard
If you are still using MED-V v1, you may run into this issue when you are running the VM pre-requisites utility on the Windows XP image:
“Unhandled exception has occured in your application. If you click Continue, the application will ignore this error and attempt to continue. if you click Quit, the application will close immediately.”
“Critical error.”
Details will show the following:
************** Exception Text **************
System.Management.ManagementException: Critical error
at System.Management.ThreadDispatch.Start()
at System.Management.ManagementScope.Initialize()
at System.Management.ManagementObject.Initialize(Boolean getObject)
at System.Management.ManagementClass.GetInstances(EnumerationOptions options)
at System.Management.ManagementClass.GetInstances()
at Kidaro.VMPreparation.PreparationUtils.IsMasterDriveSCSI()
at VMPreparationTool.VMPreparationToolActivator.Activate()
at VMPreparationTool.VMPreparationToolForm.OnApplyClicked(Object sender, EventArgs e)
at VMPreparationTool.VMPreparationToolControl.ApplyClickHandler(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at DevExpress.XtraEditors.BaseButton.OnClick(EventArgs e)
at DevExpress.XtraEditors.BaseButton.OnMouseUp(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at DevExpress.XtraEditors.BaseControl.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
This is caused by a corrupt WMI repository.
You will also see the following in the event logs:
“WMI ADAP was unable to process the performance libraries: 0x80041001” and/or “WMI ADAP failed to connect to namespace \.rootcimv2 with the following error: 0x8004100a”
if this has happened, you will need to run the WMI Diagnosis utility for Windows XP to find out what may be wrong with the repository. You can download it here:
If necessary, you may need to rebuild the WMI repository although this should only be done as a last resort.
Click Start, Run and type the following command:
rundll32 wbemupgd, UpgradeRepository
This command is used to detect and repair a corrupted WMI Repository. The results are stored in the setup.log (%windir%system32wbemlogssetup.log) file.
MED-V 1.0: Error in VM Prerequisite Wizard: “An unsupported version of Virtual Machine Additions is installed.”
When preparing a Virtual Machine for deployment for use with MED-V v 1.0 SP1, you will need to ensure that in addition to the MED-V workspace installation being installed inside the virtual machine, you will need to have the minimum level of Virtual PC additions for Virtual PC installed as well.
Upon completion of the workspace installation, it will prompt you to run the MED-V VM Pre-requisites Wizard. If the version of VPC additions is not at least at version 13.822.0, you will get prompted with the following message:
“The following errors were detected:
1) An unsupported version of Virtual Machine Additions is installed. Please make sure the latest KB of Microsoft Virtual PC 2007 SP1 is installed on the host machine, and reinstall Virtual Machine Additions through the Action menu of the virtual machine.” Even though the error refers to VM additions, technically these are called VPC additions.
This is caused by not having the minimum version of the VPC additions installed (Version 13.822)
The resolution is as follows:
On the host machine, running the virtual machine, ensure the following are installed:
1.) Virtual PC 2007 SP1
2.) The Bundled QFE with MED-V 1.0 for Virtual PC 2007 SP1 (KB958162.msp)
Then remove Virtual Machine Additions from the guest VM and reinstall VPC Additions through the Action menu of the virtual machine.”
madvirtualizer
The Mad Virtualizer at Microsoft 