MED-V v1: Error: “System.NullReferenceException: Object reference not set to an instance of an object” when trying to browse for users using the “Find” option using the MED-V v1 Server Configuration utility.

When using the MED-V Server Configuration utility (serversettings.exe)) you will get an exception when you attempt to use the search capability to find users in Active Directory.

If you select the permissions tab, then select add, then select find, then select advanced, and then select find now. Finally, select one or two user groups. Click OK twice and you will get the following exception:

 

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
   at Kidaro.Management.Forms.UserSelectionUtils.FindUsers(IWin32Window parent, Boolean localUsers)
   at Kidaro.Management.Forms.UserSelectionUtils.EntitiesFindHandler.Handler(Object sender, FindUsersEventArgs e)
   at Kidaro.Management.Forms.UserSelectionForm.FireFindRequested()
   at Kidaro.Management.Forms.UserSelectionForm.FindClickHandler(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 a known issue in MED-V v1.0 SP1.

The current workaround is to avoid using the Find feature to select multiple users and/or groups. This issue still appears in SP2 for MED-V v1.

MED-V V2, V1, or XP Mode?

It looks like both MED-V v1 and v2 will be around for the remainder of the Windows XP support lifecycle. Because of this, I often I get asked the question, “Which version of MED-V should I be using?” as well as “Why should I be using MED-V instead of Windows XP mode?” The following table lists the differences in the basic feature set between versions 1 and 2 of MED-V. This decision making relies on comparing several factors. You also have to take into consideration that MED-V v2 was a complete re-engineering of the product. There is no direct upgrade path between MED-V v1 and v2.

 General Feature Differences between MED V1 and V2

This table focuses on the Primary feature changes and enhancements that drove development of the MED-V/Windows 7/Optimized Desktop Strategy. These include features added into the product as a result of customer feedback for version 1.

Feature	MED-V V1	MED-V v2
Policy Source	XML-based from Server	Local Registry (can be deployed by policy)
Authentications Source	AD	AD
SSO Support Host-Client?	No	Yes
SSO Client-Workspace	Yes	Yes
Workspace Support	Persistent and Revertible	Only Persistent

General Component Differences between V1 and V2

If you are an experienced MED-V v1 users, you will need to be aware of  some functional component differences. The following table lists the differences between the installable components available between versions 1 and 2 of MED-V.

Component	MED-V V1	MED-V v2
MED-V Policy Server	Yes	No
Image Distribution Server	Yes	No
MED-V Client	MED-V Client	MED-V Host Agent
MED-V Workspace	MED-V Workspace (Manually Installed)	MED-V Guest Agent (Auto-installed)
VM Preparation	VM Preparation Tool	MED-V Workspace Packager
MED-V Management Console	MED-V Management Console	MED-V Workspace Packager
Diagnostics	Kidaroreport.exe	MED-V Toolkit

Differences that Affect Enterprise Decisions

There will be many customers who have been surveying MED-V for enterprise deployments. Many may have looking at MED-V version 1 and are trying to determine whether MED-V v1 or MED-V v2 is suitable. The following chart outlines many factors that determine adoption in the enterprise. Use this to help you make that decision.

Feature	MED-V V1	MED-V V2
Client Host OS Support	XP, Vista, and Windows 7	Windows 7
VPC Engine	VPC 2007 (VPC 6)	VPC7  (Non VT requires Patch)
URL Redirection	Basic (Bidirectional)	Host-to-Guest only
Full Desktop Mode	Yes	Only through VPC
Reporting (SQL)	Yes	No
Policy Source	Server (XML)	Registry/GPO
Seamless Integration	Yes – Manual	Yes – Automatic
Application Publishing Foundation	Kidaro	RDP/RemoteApp
Console	Yes	Yes (Workspace Packer)
Integrated Image Distribution	TrimTransfer/BITS/Pre-Staging	Pre-staging Only (ConfigManager Integration with DCM)
WMI Support	No	Yes

 The Feature Comparisons between XP Mode, MED-V V1, and MED-V v2

Finally, how both MED-V v2 and v1 stack up in comparison with XP Mode is outlined in the table below. XP Mode is designed to be a consumer solution while MED-V is for the enterprise.

Feature	XP Mode	MED-V v1	MED-V v2
Seamless Application Compatibility Environment	X	X	X
Host/Guest Folder Integration	X		X
USB/Smart Card Redirection	X		X
Dynamic Application Publishing	X	Manual	X
Custom XP Image		X	X
Domain Joined		X	X
SCCM Integration		(Bridged)	(Bridged and NAT)
IE6 Web Redirection		Bi-Directional	Host to Guest only
Shared VHD Support		X	X
Guest Wake-to-Patch			X
Automated First-Time-Setup		X	X
Packaging/Configuration Wizard		X	X
WMI Monitoring Interface			X
Network Printer Syncing		Steve Thomas	X

MED-V v1: How to Configure MED-V Client-Side SSL

For MED-V v1, Client-side TLS/SSL security is an optional configuration which can be set to ensure only legitimate clients connect to the server. This will take security one-step further than the traditional server-based TLS/SSL.
To configure client-side SSL on the server:

1.) Verify SSL is enabled on the server (refer to Configuring Server Settings (on page 15)).

2.) Verify that the CA that issued the client certificate is in the Trusted Root Certificate Authorities of the Local Computer certificate store of the server.

3.) In the ServerSettings.xml file (located in the server installation\Servers directory), configure the following:

Set <RequireClientCertificate> to true.

4.) If you would like to verify the certificate thumbprint on the client:

In the <ClientCertificateThumbprint> tag, add the thumbprint so that the server will only accept client certificates with the specified thumbprint and a valid certificate chain. If the line is missing or blank, the server will accept all client certificates whose chain is valid.

Note: Verifying the certificate thumbprint on the client is only relevant if the administrator distributes one certificate to all clients.

5.) Restart the MED-V Servers service.

To configure client-side SSL on the client:

1.) Create a client certificate from the trusted CA and install it in the client’s Local Computer certificate store (refer to Configuring a Certificate for details).

2.) Verify that the CA that issued the client certificate is in the Trusted Root Certificate Authorities of the Local Computer certificate store of the client.

3.) In the ProfileInfo.xml file (located in the MED-V Client Installation\Management\Profile directory), copy and paste the thumbprint into the <ClientCertificateThumbprint> tag.

Note: Once the server side XML has been configured with the certificate attribute, this attribute is automatically added to the client side XML when creating a MED-V package.

Note: It is recommended to provide access permissions to the client certificate for Everyone.

On XP – use the WinHttpCertCfg.exe tool which can be downloaded from the Microsoft http://msdn2.microsoft.com/en-us/library/aa384088.aspx website.

On Vista or Windows 7 – use the MMC utility.

MED-V: Published Batch Files/Command Scripts Should use Internal Start Command to Call

Whether you are using MED-V versions 1.0 or 2.0, batch files or published batch files (or command scripts) with MED-V should be approached in the same manner. Essentially, when you are publishing any script using *.BAT or *.CMD extensions, you may find the parent command window never closes when spawning the external command.

For example,

If you were to run the following batch file:

call \\NETWORK\FOLDER\FOLDER\FOLDER\master.bat
%SystemRoot%\explorer.exe “\\NETWORK\FOLDER”
exit

The end result would be an open explorer window with a parent command prompt window remaining open until explorer is closed.

This is a design issue with command processing and batch files when using default syntax.

To resolve this, replace the last command by pre-pending a start command to it to make the window disappear.

Use the following syntax:

call \\NETWORK\FOLDER\FOLDER\FOLDER\master.bat
start %SystemRoot%\explorer.exe “\\NETWORK\FOLDER”
exit

MED-V v1 and Image Version Lineage

We speak of version lineage in MED-V, we are speaking of the model for version change control. Some application environments, such as Microsoft’s App-V (formerly called Softgrid) will use GUID identifiers to represent a version and separate it from the GUID identifier for the package itself. It allows App-V servers to manage versioning through its data store.

While there is a methodology for lineage in MED-V v1, it is very simple. It simply bases its version from the filename ending. Original image version will end in “_1” and will carry the underscore format. When you pack locally, or upload a new image to a MED-V server, it will always append

1.) Don’t use image names ending in “_1” when using the console. This will simply wind up having the image file names with confusing suffixes. For example, if you pack an image in the console and call it “XPImage_1,” it will pack it as “XPIMAGE_1_1.CKM” instead. Let the console do it for you.

2.) When you select an image to upload to a server, and you have multiple versions, it will upload only the latest one based solely on filename.

3.) Don’t modify version stamps outside of the console.. While you can do it, users often forget to modify the .INDEX file that corresponds and if there is any mismatch in expected file name between the .CKM file and its corresponding index file, the MED-V console will just ignore the image altogether.

4.) Deleting an image version from the console WILL delete the CKM file and INDEX file for the image. Be very careful when deleting images.

It is also important to understand that MED-V will always download the latest version whether it is from a MED-V image distribution server or even in the event of pre-staged folders. Even though TrimTransfer does not work with pre-staged images, version lineage does.

MED-V: Support for Multiple Drives within MED-V

Support for multiple drives and volumes within a virtual PC (workspace) used by MED-V will depend on the version of MED-V being used. MED-V v2 only supports the use of one fixed disk volume within a single virtual hard disk (VHD.)

It is technically possible to use more than one partition/volume within a single virtual hard disk but it is not recommended if it can be avoided.

MED-V v1 supported the use of multiple virtual hard disks (VHDs.) In addition, MED-V also supported multiple volumes (drives) as well as the use of the SUBST command to mount drive letters to local directories.

MED-V: Performance Issues when using Internet Explorer 8 and later in a v1 workspace

Due to performance limitations of Virtual PC 2007 and the additional resources required for Internet Explorer version 8 and later to function properly, it is not recommended to use any version greater than Internet Explorer 7 in the MED-V 1.0 Workspace.

Only Windows Internet Explorer 6 SP2 and Windows Internet Explorer 7 are officially supported for the MED-V 1.0 SP1 workspace installation. This is referenced on the following link:

http://technet.microsoft.com/en-us/library/ff603753.aspx

For Version 2 of MED-V, Windows Internet Explorer 6, Windows Internet Explorer 7, Windows Internet Explorer 8, and Windows Internet Explorer 9 are supported for the MED-V 2.0 workspace installation.

MED-V 1.0: Error: “MED-V Workspace cannot start because the version of Virtual PC on your computer is not supported by MED-V”

When you attempt to start a MED-V v1 workspace, if you get the following error, you may not have properly deployed all of the appropriate pre-requisites:

MED-V Workspace cannot start because the version of Virtual PC on your computer is not supported by MED-V.

This can happen if you upgraded MED-V v 1.0 to either v1.0 SP1 or SP2 and the updated Virtual PC 2007 QFE patch was never applied to the client (KB974918.MSP.)

You will need to verify that the version of Virtual PC on the computer is at least at version 6.0.213 to ensure the KB974918 patch has been deployed. This patch must be deployed in order to meet the supported requirements for operation.

This installation requires Windows 2000?!?!?!? Do What? Error when deploying MED-V Deployment Package . . . aka – did I just Travel back in Time?

Note. We are speaking of MED-V V1 here. 😉

 

So, here is the scenario: You are creating a deployment package using the MED-V Deployment Packing Wizard. This is available in the MED-V v1 console. More information about this is found here:

 

http://blogs.technet.com/b/medv/archive/2009/07/27/creating-a-med-v-deployment-package.aspx

 

The MED-V Deployment Package Wizard allows you to bind all of the binaries required for deploying a MED-V client along with a prestaged image into a single package. During the wizard, you have the option to specify the installers to include in the package. The trouble is, it does not verify that the installer you are choosing is the right one. For example, when you are specifying the MED-V installation file under “MED-V installation settings” it does not verify that that is, in fact, the client installer.

 

I recently encountered an issue where a customer was attempting to deploy the MED-V client to a Windows 7 host using the MED-V 1.0 SP1 Deployment Package methodology. It failed with the following error:

 

This installation requires Windows 2000 SP4 or Windows XP SP2/SP3

Needless to say, getting this error on a Windows 7 computer was confusing. Luckily, the customer did not attmept to cretae a Versionlie AppCompat shim as this could have yielded even more trouble.

This was simply caused by the wrong MSI being selected during the packaging wizard. When you select the option to run the MED-V packaging wizard (From the Management Console – select Tools – Packaging Wizard.”In the MED-V Installation Settings, dialog box, the installation binary selected should be MED-V_1.0.105.MSI.

In this particular scenario where the above error occurred, the MED-V_Workspace_1.0.105.MSI was selected and used instead of the client installer (MED-V_1.0.105.MSI.) The MED-V_Workspace_1.0.105.MSI is only one used to install the workspace guest binaries inside the virtual machine.

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