Running a MED-V application that depends on presence may not properly show presence when hovering over it in the System Tray
Let’s review some basic information about how MED-V: The way MED-V V2 works is the Windows 7 host machine connects to the Guest Virtual PC through an RDP-style connection. This basically turns the Windows XP Virtual PC into a mini-RDP server. This must always be in the back of your mind while you test your applications under a MED-V solution. Leveraging RDP removes the need for a hooking DLL to be injected into the guest OS and cuts down on the overhead of the MED-V Guest Agent.
Since applications that run under MED-V are basically the same to the Windows 7 host as applications running remotely on an RDS or Terminal server, you will encounter specific limitations in cosmetic desktop features. For example, the AeroPeek style thumbnail preview of the remote application will not be visible. Window titles will show an appended (Remote) to differentiate it from the local applications.
In addition to what comes through the remote connections, MED-V will republish (pass along) critical messages that appear in the Windows XP system tray. For example, password expiry notices and update notices from WSUS (or Configuration Manager) will also appear on the local desktop. Applications that publish to the Windows XP System tray in the guest will also appear in the host (with an appended “Remote.”)
One item that is not simply a cosmetic issue that you will need to be aware of when considering MED-V for application remediation are applications that have presence indicators in the system tray. Changes in presence often cause a change in icon or icon color as well as their pop-out status message. While these status icons will appear in the Host system tray, there will be potential issues with changes in user presence updating icons properly. Applications such as Communicator, Windows Messenger, and Lotus SameTime may not always update/change presence notifications properly when running in a MED-V workspace.
Let’s use the example of a user being signed in initially as “available.” When the use steps away and becomes idle, the system tray icon may not initially reset the icon appearing in the host to “Away” even though the user is away from their desk.
In Version 1, the MED-V Management Console, will use the IE proxy settings of the current user to connect via HTTP to the MED-V Policy Server. If the proxy server is not configured correctly, it will trigger an Event ID 75 error:
“The MED-V Server is unreachable at <URL> “
Please check your connectivity and try again.
In fact, any operation in the MED-V Management Console (v1) will use the user’s proxy settings including the uploading of images to an image distribution server. For the MED-V Client service and application, it is different in that it uses the system’s proxy configuration for all operations including authentication, policy, and image download.
MED-V Version 2
For MED-V Version 2, there are no images or policies to download. So the likelihood of proxy issues with MED-V agents specifically will likely not be an issue although it is important to point out that Host and guest proxy configurations are not automatically kept in sync by MED-V.
Setting Proxies at the System Level
For Windows XP, you use the proxycfg command to set system account proxies.
For Windows Vista and Windows 7, you would use the netsh command:
netsh winhttp set proxy – http://technet.microsoft.com/en-us/library/cc731131(WS.10).aspx
App-V 4.5: Difference between what happens when you change the LogLevel on the Streaming Server vs. the Management Server
Here’s an interesting item I stumbled upon recently. While I was editing this document (http://social.technet.microsoft.com/wiki/contents/articles/5889.aspx) to include the very import *location* of these values, I was reminded of an interesting item that you will probably only notice if you are troubleshooting the App-V Streaming Server.
The level of log verbosity is set using the LogLevel registry key. For the App-V Management Server, this value is located in HKEY_LOCAL_MACHINE\Software\Microsoft\Softgrid\4.5\Server while for the Streaming Server, it is located in HKEY_LOCAL_MACHINE\Software\Microsoft\Softgrid\4.5\DistributionServer.
The LogLevel value is a DWORD and it can go from 0 to 5. 3 is the default, but in some cases, you may want to reduce the verbosity to cut down on growth of the SFT-Server.LOG file or increase the verbosity for troubleshooting (NOTE: Please use debug logging sparingly as it will affect performance of the server.)
With the Management Server, if you change this LogLevel value the changes will immediately take effect – but – with the Streaming Server, it will require a restart of the App-V Streaming Server service.
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:
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
Just about a year ago, I moved all new posts over to Technet.com. In spite of that, this blog still continues to get much attention due to a lot of the existing content proving to be very useful for users. For that I am extremely happy to help and it recently gave me an idea. I have been mulling over how I should focus my current blog over at Technet with regards to information, guidance, and support tips. While I have a lot of great information coming (a lot of new products/product versions in the pipeline) I also have a wealth of information I’ve been needing to post tat was related to existing products and legacy products (Softgrid/App-V 4.x/MED-V V1, etc.) I also realize there is a strong user community and install base still present who may not be moving off until the products get closer to end of life.
- Steve Thomas
With this said, I decided that I would use this blog on WordPress in the future for legacy product information (App-V 4.x/Softgrid/MED-V V1/VMM 2008/VPC) while keeping my blog over at Technet more related to current and forward technologies (App-V 5.0/UE-V/Hyper-V 2012/Win8/Win2012.)
Effective this week, I will be transitioning this blog over to technet. There will be no more direct posts here. there will be only links referencing new posts on Technet. This site will remain up along with all of the existing posts.
Transitional Post Below:
App-V: Recommended Upgrade Preparations and Rollback procedures when upgrading from App-V Management Server 4.5 RTM or SP1 to SP2.
Before Upgrading to App-V 4.5 SP2 on the management server, it is recommended to first review the release notes for added features such as SQL mirroring support.
App-V 4.5 SP2 Release Notes
Also, you can download the installation for SP2 here:
The following are recommendations for preserving information and critical data to ensure a proper rollback is available in the event of an upgrade failure or a desired rollback to a previous version of the App-V server.
1.) Backup a copy of the App-V management SQL datastore. In SQL this is the APPVIRT database by default.
2.) If .NET 4.0 is installed and you are using Windows Server 2003, The current work around is to:
a. Remove the .NET 4.0 (temporarily as it will be re-added later.)
b. Restart the server.
c. Perform the Upgrade. Restart the server.
d. Reinstall the .NET 4.0 Framework.
Potential Upgrade Failures
The following are recommended options for rollback should an error occur during upgrade.
In the event of a 25109 error, please use Rollback Option #1 for rolling back the server to its previous state.
In the event of a 25119 error (or any error not otherwise mentioned), please use Rollback Option #2 for rolling back the server and data store to its previous state.
In the event of a 2512* error, please use rollback option #3 for rolling back the AppVirt management Service (ASP.NET Web Management Service) to its previous state.
In the event that the installation completes successfully and you decide for reasons otherwise not mentioned here to roll back the server to its previous state, please refer to Rollback Option #2 for rolling back the server to its previous state.
Rollback Option #1
A 25109 error indicates failure to connect to the database. In the event of this error, all that needs to be rolled back are the binaries on the App-V Management Server.
1.) After the installation rolls back, very connectivity to the App-V Management server.
2.) If the binaries list version numbers at SP2 (4.5.3.XXX) uninstall the App-V Management server and reinstall your previous version.
Rollback Option #2
A 25119 error or a successful completion of the upgrade means that both the App-V Management server binaries and the SQL data store have been upgraded. The rollback procedure requires both the server binaries and the data store to be reverted back to its previous version.
1.) Restore the previously backed up version of the App-V data store on the SQL server back to its previous version.
2.) The App-V Management Server will likely be rolled back to its previous version during the installation. If this as a rollback following a successful installation then the existing version will need to be uninstalled and the previous version will need to be reinstalled.
Rollback Option #3
1. Manually uninstall ONLY the AppVirt Management Service (Service – not server.)
2. Restart the server.
3. Reinstall AppVirt Management Service component from SP2 media.
- Steve Thomas