Archive

Archive for November, 2013

MED-V: More Detail on Full-Screen vs. Seamless Mode

November 26, 2013 Leave a comment

I recently had a customer inquire further as to how the mechanics differ between all of the application modes in MED-V. I would have thought this far into the life cycle of MED-V that I had gone into enough detail on the subject. Turns out, while the article I wrote on TechNet a couple of years back (http://blogs.technet.com/b/medv/archive/2011/06/02/med-v-v2-why-would-an-application-fail-in-seamless-mode-when-it-succeeded-in-full-desktop-mode.aspx)  gave a good high-level explanation, more clarification is needed.

So in addition to the information I laid out back in 2011, I’ve done some more diving into RAIL (Remote Applications Installed Locally) the inline VPC implementation of TSRemoteApp (now called RemoteApp) where the RemoteApp Server component was ported to Windows XP for the guest integration.

First of there are actually two “full-screen” modes in MED-V 2. One involves starting full screen mode from either the MED-V toolkit or using the command MEDVHOST /fullscreen to launch the workspace in full screen mode with the MEDV Guest services and agents still engaged. If you were to access the Virtual PC out of band using the VPC Window or by double-clicking on the .VMCX file, you would get the warning message about another user being logged on (see http://blogs.technet.com/b/medv/archive/2011/08/24/med-v-v2-strange-message-lt-virtual-pc-name-gt-was-closed-with-a-user-logged-on.aspx)

I outlined the basics of the differences in this high-level chart:

medv-seamless-vs-fullscreen-vs-vpc

RDPINIT/RDPShell and Active Setup

In addition to items that depend on Explorer.exe such as Login Scripts, Active Setup also does not run. You may can get around this by leveraging group policies and the RUNONCE.EXE command. You can specify the startup applications as a part of a user’s logon settings in Group Policy. Because Group Policy controls these settings, any startup application that you specify runs as expected when the user logs on. To specify the startup applications as a part of a user’s logon settings, follow these steps:

1. In the server Group Policy Management Console (GPMC), select the GPO (that applies to the GUEST OS [XP]) and edit.

2.  Click Computer Configuration, and then click Administrative Templates.

3. Click System, double-click Logon and then double-click Run these programs at user logon.

4. In the Run these programs at user logon Properties dialog box, click Enable.

5.Click Show, and then click Add.

6.Type the name of the startup application – runonce.exe /AlternateShellStartup (must include the argument)

7.Click OK two times.

One Final Note on Termination

When a Remote Application is terminated, the process on the XP Guest that is associated with the application is terminated. However, the RDP session remains in a disconnected state until is reset by an administrator. This behavior can be modified by using the group policy “Set time limit for logoff of remote app sessions.”

Any other processes that should be terminated when the Remote Application is terminated can be specified in the following Registry key.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Sysprocs

This is a registry key that the RDP RAIL Shell uses to filter out “system” processes (in addition to rdpshell.exe and rdpinit.exe).  Processes configured via this key are ignored by the RAIL Shell. In addition, they will be terminated upon exiting of the RDP session.

A process can be added by adding a REG_DWORD value with a name of the process and a value of 0x0. The following is a list of processes that are terminated by default when a Remote Application ends.

Clipsrv.exe          Conime.exe        Ctfmon.xe           Dwm.exe             Imepadsv.exe

Lmsvcs.exe         Msgsvc.exe         Nddeagnt.exe    Netdde.exe         Netstrs.exe

Os2srv.exe          Proquota.xe        Rdpclip.exe         Screg.exe            Taskeng.exe

Wfshell.exe         Win.com

 

 

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

App-V 5: Further Dissection of the App-V Error Code Format

November 26, 2013 2 comments

I recently just returned from the Microsoft Global MVP Summit where I got to spend some time with the App-V MVPs. We received a lot of good feedback and I got to see some great presentations (as well as do a little bloviating of my own.) I received specific feedback encouraging me to write more App-V troubleshooting blog posts. I also got thrown for a temporary curve where I was asked what was the “20” component field of an App-V error message and why did I not include it when i was discussing this in my blog on dissection of App-V error codes. For example, what is the difference between hypothetical error code 0x3E500D04-80070005 and error code 0x3E500D20-80070005?

So in my recent said blog in question on App-V operational troubleshooting (http://blogs.technet.com/b/gladiatormsft/archive/2013/11/13/app-v-on-operational-troubleshooting-of-the-v5-client.aspx) I discussed the component mappings. What I did not point out was the fact that the upper three bits in that field also bear some significance.

So, the App-V 5 error return code format is similar to the Softgrid and App-V 4 error code format in that it has build-specific sections. For App-V 5, once a return code is in hex format, you can ignore the first six hex digits as it relates specifically to the source file and build number. The most important digits to look at are the last ten digits. What I neglected to point out in that blog post was the upper three bit values of the component field in the error code.

If the module field is greater than the numbers mentioned in the previous blog, you will need to further dissect the bits in that field.

  • 1st bit – This bit determines whether or not the return code is a success code or an error code. This is important because if you ever notice an error with the format xxxxxx8x-xxxxxxxx then you know it is actually a success code.
  • 2nd bit – This bit determines whether or not an event has been logged or not. If the bit is 1, an error has been logged.
  • 3rd bit – If this bit is flipped, it is a Windows code and not and App-V specific code.

Ultimately, these are revealed in hex as:

  • 8x-xxxxxxxx – You can ignore this message as this is a success code.
  • 4x-xxxxxxxx – The return code that has been logged as an event.
  • 2x-xxxxxxxx – This is actually a Windows error code and not an App-V specific event.

So, with this knowledge, let’s look at the following error:

0x00001525-00000057

So we know the first six digits is build-specific so we only need to look at the last 10 digits. When we convert the “25” field from hex to binary we get:

00100101

This tell us that the 3rd field is flipped to 1 so the error is a Windows error and not an App-V specific error. The remainder in the last five bit field is 05 in hex which means it was logged by the Shared Components module. Using the ERR utility or even “NET HELPMSG” you can resolve the 57.

So, to reinforce, let’s look at another error:

0x45500D27-80072EE7

Again, if we focus on the 27 hex field, converting it to binary yields:

00100111

So again, we see this is a windows error. The last three bits convert to 07 hex which denotes the publishing agent. The last 8 digits translates to the HRESULT: ERROR_INTERNET_NAME_NOT_RESOLVED

Categories: Uncategorized Tags: , , , ,

App-V 5: Useful Stuff for the App-V Professional (I hope!)

November 15, 2013 2 comments

So I’ve been receiving a lot of feedback on ways to enhance  App-V toolkits for customers and their in-house troubleshooting. I’ve received usually two kinds of feedback on previous articles such as http://blogs.technet.com/b/gladiatormsft/archive/2013/11/13/app-v-on-operational-troubleshooting-of-the-v5-client.aspx
and http://blogs.technet.com/b/gladiatormsft/archive/2013/04/24/app-v-5-0-launching-native-local-processes-within-the-virtual-environment.aspx – 1) This is great! Can I have more?” and 2) “It’s about @*#&% time!Can I have more?

Do we have a “Cached OSD” equivalent in App-V 5.0?

Remember when you were troubleshooting configuration for a virtual application in App-V 4.x? Instead of going through the trouble of modifying the OSD file at the content root, removing and republishing as well as re-streaming the application – instead you locate the application’s cached OSD file and make modifications there while you do your temporary testing of adjustments to the XML configuration. The cached OSD files were located in a subdirectory of where you set the GlobalDataDirectory value in V4. Identifying which of the OSD files applied to your application could easily be achieved by viewing the properties of the application using the App-V 4 Client Admin UI.

In v5, this information will likely be stored in either the deployment configuration or the user configuration file (what we refer to as the dynamic configuration files.) To determine the source of the Deployment Configuration for a particular application, you can take advantage of PowerShell and the App-V Client API’s to find the location of this information without having to know the actual GUID of the package.

$AppVPackage = Get-AppvClientPackage –name <PACKAGE>

$AppVPackage.GetDynamicDeploymentConfigurationPath()  

   

You can then proceed to test out these changes.

How can I tell which Virtual Environment (packageconnection group) an Application is Running in?

Often on systems that are running a bunch of different virtual applications that may or may not be grouped together via connection groups (RDSCitrix Servers) you might want to verify a running process is running in the correct virtual environment. You can use the following PowerShell commands to determine the current package version and also possible connection groups (virtual environments.)

$AppVPackage = Get-AppvClientPackage –name <PACKAGE>

Start-AppVVirtualProcess cmd –AppvClientObject $AppVPackage

Get-AppvVirtualProcess | select -ExpandProperty AppvPackageData

In the example below, we use the CMD prompt to verify the version and package ID running.

 

How Can I tell if an Application was Running Virtualized simply by looking at a Process Monitor Log?

Any executable that is running within an App-V virtual environment will have the module “AppVEntSubsystems64.dll” injected into the process. So all you have to do when viewing a process monitor trace is double-click on any event containing the process you need to check. When the “Event Properties” dialog box appears, Click on “Module” tab and look for AppVEntSubsystems64.dll.

Here’s a Short Blog with a very Important Message (T-MINUS LESS THAN 6 MONTHS)

November 14, 2013 Leave a comment

Early last year I wrote a blog specifying how MED-V does NOT affect the Windows XP EOL Support issue: http://blogs.technet.com/b/gladiatormsft/archive/2012/07/30/how-med-v-affects-windows-xp-end-of-life-support-policy-it-doesn-t.aspx 

Little did I know how widely pulicized this would be (re: quoted in The Register and others – http://www.theregister.co.uk/2012/08/01/windows_xp_medv_no_go/)

Today’s a good reminder for all that we are now within six months. If you are looking to start a Windows XP migration please be advised that if the purpose of migration is to avoid unsupported or expensive custom extended support agreements, then MED-V will not resolve these concerns. Everything in that article is still valid. If you are still on XP, please feel free to comment on what your migration blockers are below. Are you being held back by a legacy LOB app or is it an Internet Explorer 6 issue?

Categories: Uncategorized Tags: , , , ,

App-V: On Operational Troubleshooting of the V5 Client

November 13, 2013 10 comments

 Update 12/6/2014: The App-V 5 logs have been consolidated and are organized differently as of App-V 5 SP3 – but the event and event formats are still the same. Please read more about it here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_event_logs_moved

Whenever I am doing customer engagements, I find it always valuable to ensure that the customer has a plan in place for ongoing support. Having my origins in support myself, I can relate to the customers concerns with impact to their helpdesk. Especially when a new product has been introduced in their ecosystem.

In the world of App-V, we divide up troubleshooting problems in two ways: 1) troubleshooting the operational client engine and 2) troubleshooting the application itself. IT departments relegate level 1 operational troubleshooting to their helpdesk team. This requires training your helpdesk with FAQs, CubeNotes, flowcharts, etc. to resolve basic issues and to at the very least, gather the necessary data to help higher level escalation teams isolate the problem.

Training or Retraining your HelpDesk on App-V 5

The App-V Client will be a very different experience for your help desk in terms of toolkit. Conceptually, they will be doing a lot of the same thing but the way they do it will be different.

Package Repair

Repairing a package will still be needed, but instead of using the client UI (which is deprecated in App-V 5.0 SP2) or SFTMIME, you can use the Repair-AppVClientPackage to reset user and or package state. You get can get specifics on this by reading Ryan Cobb’s blog post on the subject here:

http://blogs.technet.com/b/appv/archive/2013/10/28/how-to-quickly-repair-published-app-v-packages.aspx
 

Also NOTE: I have seen information out there stating that you can also simply delete files directly in the native locations. That is true but this command is much cleaner and useful for the help desk professional. You should also never, ever, ever, ever, ever, ever, ever delete the VFS directories manually as this will also create problems by potentially breaking the user mode VFS and copy-on-write mappings for the application. If you suspect issues with those VFS directories, use the Repair-AppVClientPackage command instead.

Connection Group Cleanup

The same options available for an individual package are also available for a connection group using the Repair-AppVClientConnectionGroup command. In fact, you should be advised that if you repair the connection group instead of the individual packages when you are experiencing issues where you would normally repair the application, this will purge out all of the settings for all applications within the connection group. If there are applications currently in use and it is preventing you from running these repair operations you will need stop all of the package processes. Stop-AppVClientPackage will stop all virtual processes in a package and Stop-AppVClientConnectionGroup will stop all virtual processes in a group.

App-V Client Logs

The SFTLOG.TXT is gone. So are all of the other text-based logs. Knowing how to collect good log data is essential to every help desk professional especially if escalations will be involved. The good news is everything is now logged to event logs. You can view these by opening up the event viewer and navigating to Applications and Services Logs – Microsoft – AppV – Client. The default view will show the three basic event logs: Admin, Operational, and Virtual Applications.
  
 

If you would like to view the additional logs that can enabled, navigate to the view menu and select “Show Analytic and Debug Logs.” In many cases, you may need to take advantage of these.

 

As you will see, there are a tremendous amount of additional logs. Most of these are not enabled by default. You will have to expand the folder, right-click the log and select “Enable Log” to enable it. Be careful turning on a lot of these as it can potentially affect performance.

Which Log do I Use?

Well now that will depend on the type of issue that is occurring be it an error upon publishing, streaming, launching, client service start-up, etc. often, the basic logs will give you what you need to know to fix the issue, but when it doesn’t, it is time to investigate further and these additional logs can come in very handy. The question is, which log or logs should I enable? The actual error message or error code may quickly provide some insight.

The App-V 5 Error Code

Like I did in V4, I am not necessarily concerned with the entire error code. I usually only have to pay attention to the last 10 digits when looking at V5 errors ONCE I have the error in the correct Hex format. Often time, in the event logs, the error code is actually in decimal format. One of the first things you will want to do is get the error in its correct format. For example, if you see the following error in the event log:

64 notification failed with error 5746720685053444123, Package <GUID>, version <GUID>, pid
<PID>, ve id 0

The first thing I do is convert the decimal error over to hex.

 

5746720685053444123  translated to hex is 0x4FC074040000001B.

If you break it down first separating the last ten digits (04-000000001B) you diagnose this further by resolving the first two digits to the component using the table below:

 

Hex
  Code

Category

Where you might further Info

01

Integration

Client-Integration Log

02

Orchestration

Client-Orchestration Log

03

Client Service

Client-Service Log

04

Virtualization Manager

Client-VirtualizationManager Log or Client-Vemgr Log

05

Shared Components

Admin and Operational Logs

06

Catalog

Client-Catalog

07

Publishing

Client-Publishing Log, Client-PackageConfig Log, or
  FileSystemmetadataLibrary Log

08

Client Common

Admin and Operational Logs

09

Policy

PolicyLibrary Log

0A

Virtualization Subsystem

May need to diagnose using the individual virtual subsystem debug logs.

0B

Subsystem Controller

Client SubsystemController Log

0C

Streaming Manager

Any of the five streaming debug logs

0E

Client Host

 

0F

Client Configuration

Registry/PowerShell

10

Scripting

Client Scripting Log

11

Client User Interface

Client-StreamingUX Log

12

Sequencer

Only on Sequencer

13

Reporting

Client Reporting Log

14

Manifest

ManifestLibrary Log

 

 

 

 

Then the last 8 digits will usually just be a standard Windows HRESULT code. In the example above, I know the issue is somewhere in the virtualization manager and the last eight digits are 0x0000001B. The HRESULT alone does not really lead me anywhere so I would likely need to dive further into the Client-VirtualizationManager debug log.

Sometimes, you will get really lucky. For example, if the error is 0xFC03E0480070003. Well, again we know it is an issue with the virtualization manager but the HRESULT 0x80070003 is well-known – ERROR_PATH_NOT_FOUND. You know where I would then go next – Process Monitor of course!

         
 Update 12/6/2014: The App-V 5 logs have been consolidated and are organized differently as of App-V 5 SP3 – but the event and event formats are still the same. Please read more about it here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_event_logs_moved

         
 

 

 

App-V: On Virtual Services in App-V 5.0

November 12, 2013 4 comments

On the subject of services, it is probably worth mentioning some of the changes with how App-V handles virtual services in V5. First and foremost, you may have noticed there is no separate virtual service agent service running for the V5 client. You have probably also noticed that virtual services are not managed or modified through the sequencer interface. So how do you configure a service during sequencing? Well, the same as a regular service, through the services control panel or the command line (or PowerShell) during the monitoring phase. Also, only the use of the LocalSystem account is supported. Other well-known SIDs such as Network Service are not supported. Services that are virtualized will also have read-only configuration during run-time when virtualized. You will not be able to change the state of the service when it is running in the virtual environment using traditional APIs.

Since App-V requires execution of an application in the context of a user account, it limits what kinds of services can be virtualized. Services that require execution at boot time or any time prior to a user logging on will not likely be a good candidate for virtualization. There are, however, many user-mode services that can be virtualized with App-V and actually work quite well with App-V.

. . .  and then there are those services we do not want in our virtualized application package due to functional or practical reasons. I use Google Chrome’s auto-update service feature as an example. Virtual applications work best when sequenced to a steady state and updated through the App-V update process. Services that automatically update base software binaries can cause applications not to function as expected.

The App-V sequencer will capture services during the sequencing process. In previous releases of the sequencer, there was a way to review the services detected in the Services tab. At that point, you could delete the services should you not want to keep them in the package. This has changed in the V5 version of the sequencer. If you notice, when you go to the services tab, you will notice that at this stage, you are unable to remove the virtual services from this screen.


  
 Removing Services during Sequencing

If you want to remove services that are captured in the monitoring process with the V5 version of the sequencer, you will have to use a different method now. During sequencing, you need to delete the services registrations in the registry prior to closing monitoring. This will require you to know where the service registrations are stored in advance or before you close out the monitoring process. For example, if I wanted to remove the service registrations for the Google Update Service, I would open up the Services management console and the Registry Editor after installation has completed and prior to stopping monitoring. When you view the properties of the service, the Service name field will give you the short name of the service. This will reflect the name of the subkey of the service located in HKLMSystemCurrentControlSetServices


 

You can then delete this subkey to remove the service registration. In most cases, the sequencer will capture that removal and thus remove the service entry.

Removing Services from an Existing Package

If the package has already been saved, then you can modify this by opening up the package using the workflow “Update Application in Existing Package.”

 

Then during monitoring, you can open up a command prompt and run the registry editor to remove those service registrations.

Once you delete the keys under HKLMSystemCurrentControlSetServices<SERVICENAME> you will find the services are gone when you look at the Virtual Services tab.

 

In addition to the above, you can also use other registry editing utilities (such as REG.EXE) or even use the SC command if you are looking for a safer alternative for removing service registrations.

Disabling Virtual Services using Dynamic Configuration

If you do not want to open up the package to remove a service, you can simply disable the virtual services subsystem using dynamic configuration. Just set the subsystem value to “false” such as follows:

<Subsystems><Services Enabled=“false“/></Subsystems>

App-V: On COM+

November 7, 2013 4 comments

Throughout the history of App-V and Softgrid, you have likely read from many sources that COM+ cannot be virtualized. Many tools, including the App-V sequencer, contain detection logic that will also notify you of the presence of COM+ components when you are attempting to sequence an application.

COM+ evolved from DCOM (Distributed Component Object Model) and has historically been used to develop components that leverage transactional technologies including SOAP, JIT (Just-in-time) activation, queued components, and more. If you want to dive into this further, you can find some good developer references are here:

http://msdn.microsoft.com/en-us/library/ms685978(VS.85).aspx

http://msdn.microsoft.com/en-us/library/ms973847.aspx

Be careful not to confuse COM+ with an out-of-process COM server, which can be communicated with by enabled local interaction in the virtual application in 4.x or configuring out-of-process integrated COM in the deployment configuration of an App-V 5.x application.

For an application to be able to use COM+ Services, they will need to be configured within the COM+ Catalog. One easy way to do this is using the COM+ Component Services Snap-in that comes with Windows where you can configure most of the settings for COM+. Since Com+ actually generates dynamically at run time not during the actual installation, the sequencer is not able to process it, therefore is cannot be captured into a static state like other installation assets. When COM+ came on the scene in Windows 2000 with distributed transaction servers, application virtualization was not taken in to consideration.

When Microsoft developed Server App-V, the Server App-V sequencer was designed to capture COM+ components created by the application installer along with other elements such as local groups and WMI. Since there is state separation and not isolation, COM+ is not sandboxed, but laid down during deployment through its normal registrations so it can function normally at run time.

Remediating COM+ Limitations with App-V

If your sequencer happens to detect and notify you of a COM + component, it is telling you that this application may not function correctly as expected with the package as-is. Does this mean that the application cannot be virtualized with App-V and delivered via an App-V delivery system? Not necessarily. Like other components that cannot be virtualized (such as drivers,) it does not necessarily mean that you are completely out of luck. In fact, there are possible remediation options. And with App-V, we have more options to implement these remediation fixes. In a sense, you can package the component to be laid down during deployment in a similar manner (but not identical) as it is with Server App-V.

Once you are made aware of a COM+ component within an application, you will need to install the application natively on a test machine. Then you will need to launch the Component Services management console (HINT: I am always confused as to which operating system launches this so I just launch DCOMCNFG and it always launches it.) You should likely find the component or components within the COM+ Applications folder under “My Computer.”  

 

Once you locate it you can then right-click the component and select “Export.”

 

This will launch the COM+ Application Export Wizard.

 

You will then give the path and name to the destination MSI file you want to export this application to. 

 

Accept defaults and select ‘Next’ then ‘Finish’.

Now you will need to either re-sequence the application or update the existing package and during sequencing or updating, add the MSI file to the package. In the case of a V 5 package, I would usually add it into the scripts folder.

If you are using App-V 4.x, you will want to edit the OSD file and add in a script that will install the Copy out the MSI file and run the installer. You do this by adding the following beneath the <DEPENDENCY> tag.

 

        echo off n

       if exist C: goto end n

        mkdir n

        copy /y “q:mymsi.msi ” “C: ” n

 

 

        echo off n

        if not exist C: goto end n

       C:mymsi.msi /quiet n

        del /f /q C:mymsi.msi n

        :end n

 

Now, let’s be realistic. For the above to work, you must accept two siginifcant caveats. 1) The user executing the application will need to be a local administrator. This is often a deal-breaker. 2) The user will have to encounter a delay upon launch due to the installation.

App-V 5.x

Enter App-V 5 and its enhanced scripting model. On either a global publish or add package event, you can add deploy the component in a secure manner as those events will execute under the context of the SYSTEM account. You can place the MSI and the scripts installinguninstalling it into the embedded scripts folder inside the package. HINT: Since the script event only allows for one command element, my advice is to but all of the installation commands into a batch file or PowerShell script and call that script for the event. Since the scripts and package root directory in the package are automatically searched, you do not have to worry about specific paths.

     
<AddPackage>

        <Path>Powershell.exe</Path>

        <Arguments>-F deployComPlus.ps1</Arguments>

        <Wait RollbackOnError=”true” Timeout=”30″/>
     
</AddPackage>

<RemovePackage>

        <Path>Powershell.exe</Path>
       
<Arguments>-F removeComPlus.ps1</Arguments>

        <Wait RollbackOnError=”false” Timeout=”60″/>

</RemovePackage>

In the interest of full disclosure – with regards to this working seamlessly, I am 3 for 4 as I write this. In my opinion, .750 is a good batting average! Understand that this is meant to be an option for remediation as COM+ still technically cannot be virtualized.