Archive for June, 2011

MED-V 1.0: Errors that can occur when you allocate too little Memory to the Virtual PC

If you fail to allocate enough memory to the MED-V Guest Workspace operating system, you will find yourself having a tremendous amount of performance problems and possibly including the following errors:

“Your computer is running low on free memory. This may cause the Workspace to run slowly. Please close applications you are not using and try again.”


“Workspace ‘<NAME>’ failed to start. Please try starting the Workspace again.”

“Encountered an unexpected error. Internal error: Timed out waiting for VM to load: <IMAGENAME>”

The workspace policy option in MED-V v1 bases allocation of memory based upon a matrix constructed of specific memory allocations based on physical memory ranges on the host. Too often the memory is configured with the ratio allocatting an insufficient amount of memory to the workspace (i.e. where only 256MB memory is allocated to the workspace when the physical memory is 1GB or above; 128MB of memory if lower then 1GB of physical memory.)

The settings for these can be adjusted in the MED-V Management Console and confirmed in the ClientPolicy.XML file within the following section:



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

App-V: Important App-V/Softgrid KB’s and Documentation Links

Office 2010 Sequencing

Office 2007 Sequencing

Problems Sequencing Office 2007

Information about how to use Office 2010 suites and programs on a computer that is running another version of Office

Issues Sequencing Office 2010

Server Command Line Installers Options

Troubleshooting w/ Process Monitor

Introduction To Softgrid Networking

App-V White Paper Portal

App-V Technet Documentation

App-V Blog

Top 5 App-V SQL KBs:

25119 Upgrade Issue

Moving 4.1 Databases

App-V Server fails to start when SQL is on the same machine

Concurrent Licenses

MWS Administrative Issue

MED-V 1.0: Error: “Failed to fetch policy from the server”

After upgrading the MED-V 1.0 Server to either SP1 or SP2, the MED-V clients may get the following error:

“Failed to fetch policy from the server.”

You may also get this same error when trying to open up the MED-V Management console.

This can happen if the server version is newer than the client. For example, the server may be version 1.0.200 yet the clients may be 1.0.105.

Upgrading the clients to the same version (or later) than the server is the only solution to this problem.

Categories: MED-V Tags: , , ,

App-V 4.6: App-V 4.6 Reporting does not work when using 4.1 Server

When Softgrid evolved into App-V for version 4.5, the reporting model was changed to where reporting is cached by the client and uploaded to the server during DC Refresh rather than with each application launch.

While 4.5 and 4.6 clients can connect to and use a 4.1 Softgrid Virtual Application Server, reporting will be disabled due to the difference in models. The 4.5/4.6 clients will cache this information in an XML file labled by a <GUID.>

The location of this <GUID>.XML file is registered using the LastCacheFile registry value in the following registry path:


This LastCacheFile contains both the path and GUID file name.

Here is an example of the reporting cache file:

<REPORT_DATA_CACHE><APP_RECORDS><APP_RECORD Name=”Adobe Reader 9.0″ Ver=”1.0″ Server=”app-v-ms.steveth.local” User=”STEVETH\Gladiator” “Launched=”8/19/2010 8:55:52 PM” Shutdown=”8/19/2010 8:56:00 PM”/><APP_RECORD name=”Adobe Reader 9.0″ Ver=”1.0″  Server=”app-v-ms.STEVETH.local” User=”STEVETH\Gladiator” Launched=”8/19/2010 8:58:58 PM” Shutdown=”8/19/2010 9:00:19 PM”/></APP_RECORDS></REPORT_DATA_CACHE>

The server reporting tag is located in the following registry path:

HKEY_LOCAL_MACHINE\Software\Microsoft\Softgrid\4.5\Client\DC Server\<SERVER>

The DWORD value is 1 by default when using a 4.5 or later server. it can be set to 0 to disable reporting. However, if the server is 4.1 and the client is 4.5 or later, then this value will always be reset to 0.

This process happens upon detection of the App-V 4.5 or later server. An event in the client log is also logged when this happens.

[08/19/2010 14:55:18:179 MIME VRB] {tid=BA4:usr=steveth}
DC server does not want to receive v4.5+ reporting

Categories: App-V Tags: , , , , ,

MED-V 1.0 SP1: CD/DVD/Optical Drive Access Appears Problematic

MED-V V1 SP1 running on either Vista or Windows 7:

If a workspace configured by policy to use the host machine’s optical drive starts without Optical Media injected (in either full desktop mode or seamless mode) the following may happen:

When you insert an optical disk post workspace start, the drive in Explorer will show the proper-media injected however when you try to open the workspace while the workspace is running you will get the error:

“Please Insert a disk into <TYPE> Drive (n:).”

Likewise – the same also happens inside the guest operating system as well.

After restarting the workspace, it is, however available to the host and guest.

This is caused by a combination of the process for VirtualPC not being elevated and the drive is captured only at startup for a standard user process.

There are four ways to work around this:

1.) Simply restart the workspace with the disk in the drive.

2.) Start the MED-V Client elevated (run as admin.)

3.) Disable UAC.

4.) Disable the feature in the workspace policy.

If required for guest OS’es use a drive mapping to the shared optical drive.

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

MED-V v1.0 SP1: Getting Message “Error Upgrading Workspace” post upgrade

You may encounter the following scenario where the MED-V client gets the following error when trying to start workspace after upgrading to version 1.0 SP1 from version 1.0 RTM.
MED-V Client is running Windows XP or Windows Vista and originally had MED-V v1.0 (Build 1.0.72)
Error: Failed Upgrading Workspace

NOTE: Even after successfully deploying an image with the upgraded workspace binaries (version 1.0.105) or pushing the binaries into the workspace succeeds. This error may still occur.

The cause is likely because you are not always following the procedures that are recommended:
For example, instead of running the MED-V.1.0.105.msp upgrade file, the either remove the older client and reinstall the newer client or push out the SP1 MSI client by itself.

When you do this you can find that you may have the VPC Version still at version 6.0.213 (QFE for MED-V V 1.0 RTM.)

You will need to apply QFE 979714 and/or 974918 manually to get the VPC to at least 6.0.214. Also in the original MED-V Image, VPC additions may still be at 13.822 rather than 13.823.
Categories: MED-V, VPC Tags: , ,

App-V: The app manager could not create an application from . . . Error 44-00001004

June 3, 2011 2 comments

What essentially has happened is that an application was launched associated with one package then another new application with a different GUID was attempted on the same machine. It can happen after an OSD file has been cached but the original package (often an Office package) was switched to a different package hence the GUID Attribute for the CODEBASE element changes.

For example, a launch of an OSD (either by direct SFTRAY launch, IFS, or publish via Citrix or TSREMOTEAPPS points to an identically named OSD file as to one that has been cached but from a different package (hence the different package GUID.)

Then you get the following error when trying to launch:

The Application Virtualization Client could not launch the application you requested.

The Application Virtualization Client could not use the specified OSD file because the application package identifier has changed. Report the following error code to your System Administrator.

Error code: xxxxxxx-xxxxxx44-00001004

And the following shows up in the SFTLOG.TXT

The app manager could not create an application from ‘<PATH>\<APPNAME.OSD>’ (rc 0C403644-00001004).

If you recently re-sequenced a package with the same names and applications and tried to load it with a client that had the previous package still cached, this can happen.

  1. Compare the GUID in the CODEBASE element in the PSD file you are trying to launch with what is currently cached.
  2.  Then on the App-V Client’s administrative console, locate the application.
  3. Right-click the application and select “properties.”
  4. Copy the local OSD File.

 Open that file in Notepad and check to see if the GUID is different 

If the Locally cached OSD file is different, verify that GUID is registered as a package in the App-V Client’s registry.

Once that has been verified, unregister that package by running the following from an Administrative command prompt


Then refresh against the server and reload the application.

Categories: App-V Tags: , , , , , ,