Troubleshooting IIS/BITS Issues with MED-V

Tools Here are some common errors related to IIS and BITS that you may encounter when uploading and downloading images from an image distribution server.

 

1. When you attempt to upload a packed image to an image distribution server within the MED-V management console, you may get the following error:

Failed Uploading image to the server. Please verify that the server is configured correctly.

Error details: The image file <HREF path to file> already exists on the server. Remove the file from the server and try uploading the image again.

clip_image002

You get this error in spite of an existing file not on the image distribution server. In addition, you will notice 0 byte file markers (labeled bitssrv_{GUID}) in the MED-V Server images directory.

clip_image004

This is caused by the directory not having CREATOR OWNER listed in the NTFS permissions list for the directory with its appropriate permissions. To resolve this issue, add in the CREATOR OWNER account in the permissions list for the local directory being used by the IIS virtual directory for the MED-V server-based images.

  • NAME: CREATOR OWNER
  • Apply to: Subfolders and files only
  • Permissions: Allow Traverse Folder/Execute File, List Folder/Read Data, Read attributes, read extended attributes, Read permissions

clip_image006

We normally do not get this error when permissions are off, we will instead get the following error:

clip_image008

2. Unexpected Condition Errors During Uploading

You will see the following issue if using non-standard ports (i.e. 81, 8080) on image distribution servers.

Failed uploading image to the server. Please verify that the server is configured correctly

Error details: BITS error code: 801901F4 ('An unexpected condition prevented the server from fulfilling the request.')

image

A mistake users will make is changing the port for image distribution (using a custom web site or changing the port for the default web site) and not updating the firewall configuration, whether it is a 3rd-party firewall or the Windows Server firewall.

For example, I recently worked a case where instead of using the default web site, the customer was using a second web site on port 81. A rule was not created in the firewall for port 81. Correcting this with an inbound rule for port 81 for BITS and HTTP allowed this to work.

 

3. Unexpected Condition Errors During Image Download

When launching a MED-V workspace, you may get the following error after selecting the workspace image to download:

"Failed to download Workspace image. Reported error: An error occured while downloading 'https://server/directory/file.ckm.index': An unexpected condition prevented the server from fulfilling the request."

(2149122548).

image

This is another internal error which could denote errors in IIS configuration. Most often, it relates to errors in the web.config file. Fortunately, any mistake barring corruption can be adjusted in the IIS interface on Windows 2008 or Windows 2008 R2. In most cases, it relates to MIME types not being properly configured. Often the *.CKM and *.INDEX MIME entries have not been added or have been added at the parent level, but overridden by a local MIME setting, or not properly propagating.

 

4. Errors when Using HTTPS

The following error is received when either trying to upload a packed image to the distribution server from the MED-V management console or download an image from the distribution server when launching a workspace from the distribution server:

"Error details: BITS error code: 80072F06 ('The host name in the certificate is invalid or does not match ')

image

This error occurs due to a name inconsistency when accessing the IIS server URL used by MED-V for image distribution. Verify the hostname used on the certificate and then make sure the name is reference properly in the following locations:

MED-V Client settings: Right-click the MED-V system tray icon and select "Settings." Verify the name under "Server Properties."

image

MED-V Server Configuration Manager: In the "Images" tab, verify the VMs URL is set to the correct name.

Often, the certificate is either self-signed to the regular short hostname and the FQDN is used or vice-versa (from a CA) where the certificate is using an FQDN and the short name is used instead.

Hope this helps,

Steve Thomas | Senior Support Escalation Engineer