UE-V remote data collection: How to capture ETW tracing of a settings refresh problem when applying Settings Templates


~ Paul Westervelt | Support Escalation Engineer

FIXHi everyone, this is Paul Westervelt from the Cloud & Infrastructure Solutions App-V/UE-V Support Team with a quick support tip on Microsoft User Experience Virtualization.

One of the most difficult aspects of troubleshooting UE-V is trying to capture the application of settings that have been modified on a Source System when those settings are not being applied to the secondary systems. What has us scratching our heads is that we have confirmed that the settings were made on the source system, and we see that the Settings Templates have been updated from the modified date on the corresponding PKGX files located in SettingsStoragePath, however they still don’t show up.

To find out what’s happening we’ll need to get a trace, but since the settings get applied during the login process we will need to be able to start the tracing prior to the user logging into the target system. In order to do this we can perform the traces from a remote session. By using the SysInternals utility PSExec, we are able to create a remote command window that will allow us to issue the ETW logman commands from the remote system. I explain how to do this below but here’s a reference article that explains in general what this process requires:

2782997 – How to Enable Debug Logging in Microsoft User Experience Virtualization (UE-V) (https://support.microsoft.com/en-us/kb/2782997). See Scenario 2: Tracing a Desktop Settings Issue

Our Scenario

System A = Source system
System B = Target system (the one that does not get the correct settings update)

1. System B is not in a session.
2. System A has had all the changes made and verified.

Getting Ready

Our basic process to gather the trace is the following:

1. Open an administrative command prompt on System A and use PSExec to open a remote command window to System B.
2. Create the logman trace.
3. Access System B, login and reproduce the settings issue.

Before we begin however, we will need the following configured on the 2 systems:

1. Download PSExec. The current version is 2.11 and can be found at https://technet.microsoft.com/en-us/sysinternals/bb897553.aspx.
2. Place PSExec in a local folder on both systems (e.g. C:\UEV_Trace)
3. Make sure that File and Print Sharing is enabled on both computers. This is required for the remote connection.

Gathering the Data

1. Make sure that System B is logged out and has no active sessions
2. Login to System A and modify the setting being traced
3. Confirm that the settings are changed and that the wallpaper is correct
4. Confirm that the Settings Storage location is updated
5. On System A, open an Administrative command window
6. Change folders to the location where the files were saved earlier (e.g. C:\UEV_Trace)
7. Run the following command: psexec \\system_b cmd
8. Wait until the command window title changes to \\system_b
9. Change folders to the C:\UEV_Trace folder
10. Run the following two commands in the Administrative command window:

logman create trace UEV -P "Microsoft-User Experience Virtualization-App Agent" -ow  -o uevtrace.etl
logman update UEV -P "Microsoft-User Experience Virtualization-Agent Driver"

11. In the command window run logman start UEV
12. Lock System A
13. Login to System B and reproduce the refresh issue
14. If the issue is reproduced and the setting refresh fails, complete the following:
    a. Unlock System A
    b. In the command window run logman stop UEV
    c. Collect the ETL file and transfer it to the Workspace site.
15. If the issue DID NOT reproduce, complete the following:
    a. Unlock System A
    b. In the command window run logman stop UEV
    c. Delete the ETL file
    d. Repeat all of the settings modification steps until the issue reproduces

Once we have a successful reproduction of the problem, collect the ETL file and convert it to text (human readable) using the following command:

Netsh trace convert uevtrace_00000x.etl DUMP=TXT

Since the conversion needs to be done on a system that has the UE-V client installed, it is best to go ahead and process the conversion before removing the files from the target system.

Our goal is to provide troubleshooting options and we welcome your feedback and any recommendations for making this post better.

Paul Westervelt | Support Escalation Engineer | Cloud & Infrastructure Solutions | App-V, UE-V, SCSM

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

System Center All Up: http://blogs.technet.com/b/systemcenter/

Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/ 
Data Protection Manager Team blog: http://blogs.technet.com/dpm/ 
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/ 
Operations Manager Team blog: http://blogs.technet.com/momteam/ 
Service Manager Team blog: http://blogs.technet.com/b/servicemanager 
Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

Microsoft Intune: http://blogs.technet.com/b/microsoftintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The RMS blog: http://blogs.technet.com/b/rms/
App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv
The Surface Team blog: http://blogs.technet.com/b/surface/
The Application Proxy blog: http://blogs.technet.com/b/applicationproxyblog/

The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/


Comments (0)

Skip to main content