Archive

Posts Tagged ‘Kidaro’

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.0 SP1: Error when trying to open the MED-V Management Console: “The MED-V Management application was unable to initialize.”

May 11, 2011 1 comment

When you attempt to open the MED-V Management console, you may get the following error:

“The MED-V Management application was unable to initialize.”
“The type initializer for ‘Kidaro.Foundation.Profile.UserProfile’ threw an exception.”

This is caused by either a blank or corrupt XML file containing the user settings:  (WIndowsUserSettings.xml)

To resolve this, delete the %LOCALAPPDATA%\MED-V\ directory and restart the application.

Categories: MED-V Tags: , ,

MED-V: How to Configure the MED-V v1 Client to Generate a User Dump on an Exception


When the Virtual PC Engine, Workspace, or MED-V v1 Client crashes or encounters an exception when deployed in a MED-V v1 environment, there is no user dump created or a minidump listed in Windows Error Reporting.

This default behavior is by design. The client is not configured by default to generate dump files on unhandled exceptions.

There is an option to turn UEF (Unhandled Exception Filtering) on but it requires a modification to the registry on the MED-V client.

To enable UEF User Dump generation, please do the following:

1.) Open Registry Editor.

2.) Navigate to the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Kidaro

3.) Create the following values (New – DWORD Value)

Name: DumpType
Data Type: dword
Value: 3ff

Name: GenerateDumpOnException
Data Type: dword
Value: 1

Name: WriteEventLogOnException
Data Type: dword
Value: 1

Name: DisplayMessageOnException
Data Type: dword
Value: 1

4.) Exit Registry Editor

5.) Restart the MED-V Client Service.

Categories: MED-V, VPC Tags: , , , , , , , ,

MED-V v1.0: Virtual PC Engine Crashes


When you attempt to start a MED-V 1.0 workspace using a test image or a deployed image, the Virtual PC engine may crash and generate a Fault Report using Windows Error Reporting. Subsequently, the MED-V Workspace will fail to start.

The Virtual PC engine crash will show the following fault:

{virtual pc.exe, 6.0.210.0, unknown, 0.0.0.0, ffff08ef}

You will also see the following event in the Application Event Log:

Log Name: Application
Source: MED-V Workspace
Date: 9/22/2009 12:24:30 PM
Event ID: 0
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: CSS-W013
Description:

The following information was included with the event:

Failed intializing the service log: System.TimeoutException: Timed out waiting for the shared memroy client to initialize
at Kidaro.Foundation.Log.PrettyLogProxy.InitializeSharedMemoryClient()
at Kidaro.Foundation.Log.PrettyLogProxy.Start()
at Kidaro.Workspaces.Service.WorkspaceService.ServiceStartThread()

Failed intializing the service log: System.TimeoutException: Timed out waiting for the shared memroy client to initialize
at Kidaro.Foundation.Log.PrettyLogProxy.InitializeSharedMemoryClient()
at Kidaro.Foundation.Log.PrettyLogProxy.Start()
at Kidaro.Workspaces.Service.WorkspaceService.ServiceStartThread()

Cause

This can happen if the MED-V Workspace (the workspace installation) binaries have been installed along with the client on the physical host machine. The MED-V workspace installer should only be run inside the virtual machine being used to create the workspace.

To resolve this issue, please do the following:

1.) Uninstall both the MED-V Workspace and the MED-V Client.

2.) Reinstall the MED-V Client.

Categories: MED-V, VPC Tags: , , , , , ,

MED-V 1.0: Error: Initial Handshake with Workspace failed.

January 13, 2011 Leave a comment

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 1.0.0.72).

For MED-V SP1 (Build 1.0.0.105) 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:

<TimeSpans>
  <InitialHandshakeMaxTimeout type=”System.Double”>60</InitialHandshakeMaxTimeout>
  <GinaStartupTimeLimit type=”System.Double”>1200</GinaStartupTimeLimit>
</TimeSpans>
For information on how to safely modify the clientsettings.xml file, please refer to the following link:

http://blogs.technet.com/medv/archive/2009/04/22/med-v-tips-on-modifying-the-clientsettings-xml-file.aspx

MED-V 1.0: MED-V service is fails to start with the following event in the System Log – Event ID 0


You may encounter problems with a Windows XP host when the MED-V service  is trying to start. It will fail to start if any of the critical .NET components are missing or corrupt with the following event in the System Log:

Source: MEDVService
EventID: 0
Description:
Cannot start service. System.IO.FileNotFoundException: Could not load file or assembly ‘System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ or one of its dependencies. The system cannot find the file specified.
 
File Name : ‘System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’
   at: Kidaro.Foundation.SafeXmlSerializer.Create(Type type)
   at: Kidaro.Foundation.Config.XmlConfiguration.get_Item(String path)
   at: Kidaro.Foundation.Config.CompositeConfiguration.get_Item(String path)
   at: Kidaro.Foundation.Config.Configuration.Get(String path)
   at: Kidaro.Policy.CurrentUserSecurityPolicy.get_ClientPolicy()
   at: Kidaro.Policy.Initializers.ServicePolicyInitializer.ReportPolicyChange()
   at: Kidaro.Policy.Initializers.ServicePolicyInitializer.InitializeComponents()
   at: Kidaro.Features.BaseFeature`1.Initialize()
   at: Kidaro.Features.FeatureManager.Initialize(IFeature feature)
   at: Kidaro.Service.KidaroService.OnStart(String[] args)
   at: System.ServiceProcess.ServiceBase.ServiceQueuedMainC…

Again, this problem is most likely happening because one of the following:

1. The file System.Data.dll has been moved or deleted (or one of its dependent assemblies)

2. The proper version of .NET was never installed (although the MED-V install should check for that)

3. The proper version of .NET was uninstalled after MED-V was installed

To resolve this issue, you should be able to run the .NET Framework 2.0 configuration utility to verify the existence of the System.Data.dll file. It is found in Control Panel under administrative tools.

After that is confirmed check the local directory:

C:\Windows\Microsoft.NET\Framework\v2.0.50727>dir System.Data.dll
 Volume in drive C has no label.
 Volume Serial Number is 36E4-4246

 Directory of C:\Windows\Microsoft.NET\Framework\v2.0.50727

06/10/2009  03:23 PM         2,933,248 System.Data.dll
               1 File(s)      2,933,248 bytes

– You can also use the .NET Verifier to confirm that the .NET 2.0 runtimes are correctly installed and registered.

More information about the .NET Verifier can be found here:

http://blogs.msdn.com/b/astebner/archive/2008/10/13/8999004.aspx

Categories: MED-V Tags: , , ,

How to Collect Full Diagnostic Information for MED-V v1.0


By default when you run the KidaroReport Diagnostic Utility (also known as the MED-V Diagnostic Utility) it will only collect a partial subset of events from the windows event logs and the MED-V software tracing log (devlog.log).  This is to keep the overall size of the compressed ZIP files reasonable enough to send via email. If you need to gather more than just the most recent events as well as both complete devlog.log files, please use the following command:

“%SystemDrive%\Programs Files\Microsoft Enterprise Desktop Virtualization\Manager\KidaroReport.exe” /full

Categories: MED-V Tags: , , , ,