How to troubleshoot failures when refreshing the publishing server on an App-V client

hotfixHere’s a new App-V KB article we published this today. If you ever need to troubleshoot client refresh issues with an App-V server then there’s no better place to start than right here:

=====

Summary

This article covers how to troubleshoot failures when refreshing a publishing server on a Microsoft Application Virtualization (App-V) client. Refreshing the publishing server is also known as refreshing the desktop configuration.
When an App-V client fails to refresh the publishing server, the following event will be logged in the Application event log:

Log Name: Application
Source: Application Virtualization Client
Event ID: 3131
Level: Error
Description:
{tid=8E0:usr=UserAccount}
Failure on Desktop Configuration Server request to URL {rtsp://appv-svr:554/} with header {Host: appv-svr
Content-Type: text/xml
AppV-Op: Refresh
} (rc 19D07F2A-0000274D).

If a refresh fails using the Application Virtualization Client snap-in, the following error occurs in addition to the Event ID 3131 in the application event log:

The Application Virtualization Client could not update publishing information from the server ServerName.
No connection could be made because the target machine actively refused it.
Error code: xxxxxxx-xxxxxx2A-0000274D

Note: The error description and code will vary.
Note: The frequency of a publishing server refresh is controlled by the provider policy on the App-V Management Server. The default policy setting is to refresh the publishing server when a user logs in. You can also manually refresh the publishing server on an App-V client by performing on the following methods:

Method 1
1. Open the Application Virtualization Client snap-in.
2. Click Publishing Servers.
3. Right-click the publishing server and choose Refresh Server.

Method 2
1. Right-click the App-V icon in the notification area and choose Refresh Applications.

More Information

Step 1: Review the Sftlog.txt file on the App-V client

On the App-V client, review the Sftlog.txt file on the App-V client. This log file may include additional information that wasn’t included in the Event ID 3131 in the Application event log.
The default location for the Sftlog.txt is: %systemdrive%\ProgramData\Microsoft\Application Virtualization Client

Step 2: Verify the publishing server settings are correct on the App-V client

To verify this, perform the following steps on the App-V client:

1. In Administrative Tools, open the Application Virtualization Client MMC snap-in.
2. Click Publishing Servers.
3. Right-click the server reporting the error and then click Properties.
4. Verify the publishing server Type.
5. Verify the server name that is specified in the Host Name box.
6. Verify the port that is specified in the Port box.

Step 3: Verify the Application Virtualization Management Server service is started on the App-V Management Server

To verify this, perform the following steps on the App-V Management Server:

1. In Administrative Tools, open the Services MMC snap-in.
2. Locate the Application Virtualization Management Server service.
3. Verify the service is Started.
4. If the service is not started, right-click Application Virtualization Management Server, and then click Start.
5. If the service fails to start, search the Microsoft Knowledge Base for the error message that is reported.

Step 4: Verify the user groups assigned to the provider policy on the App-V Management Server

To verify this, perform the following steps on the App-V Management Server:

1. In Administrative Tools, open the Application Virtualization Management Console.
2. In the navigation pane, expand the server name object, and then click Provider Policies.
3. In the details pane, double-click the required policy. For example, double-click Default Provider.
4. Click the Group Assignment tab.
5. Verify that the users are a member of one of the user groups listed or add a user group that’s missing.

Step 5: Verify the App-V client can telnet to the App-V Management Server and port.

To verify this, perform the following steps on the App-V client:

1. At a command prompt, type telnet ServerName Port, and then press ENTER.

For example, type the following command:

telnet appv-svr 554

2. If the connection succeeds, the window is blank. Press ENTER two times and you will receive the following message:

RTSP/1.0 400 Bad Request
Server: Microsoft Application Virtualization Server/x.x.x.xxxxx [Win32; Windows NT x.x ]
Date: xxx, xx xxx xxxx xx:xx:xx xxx

If the connection is unsuccessful, you receive the following message:

Could not open connection to the host, on port 554: Connect failed

If the Application Virtualization Management Server service is started but the client cannot telnet to the server, verify that port traffic between the client and the server is not restricted by a firewall or by other software. For more information, contact the network administrator.

How to troubleshoot Event ID 3017 when refreshing a publishing server

If the App-V client is unable to access the content directory or application .osd file, the publishing server refresh will succeed but the application shortcut (or icon) will not be published to the user and the following event will be logged in the application event log:

Log Name: Application
Source: Application Virtualization Client
Event ID: 3017
Level: Warning
Description:
{tid=9E8:usr=UserAccount}
Could not load OSD file
\\appv-svr\content\AppDirectory\Appname.osd

To resolve the Event ID 3017, perform the steps below:

Step 1: Verify the App-V client can access the content directory

On the App-V client, click Start, in the Search or Run line, type the UNC path of the content share (Example: \\appv-svr\content) and then press ENTER.

If the client fails to connect to the content share, verify the UNC path is correct and verify the NTFS and Share permissions on the content directory are correct by performing the steps below.

On the server hosting the content directory, verify the following NTFS and Share permissions are configured on the content directory:

· App-V Users = Read
· App-V Administrators = Read and Write
· Network Service = Read and Write

The default location for the content directory is: %systemdrive%\Program Files (x86)\Microsoft System Center App Virt Management Server\App Virt Management Server\content.

Step 2: Verify the path to the application OSD file on the App-V Management Server

To verify this, perform the following steps on the App-V Management Server:

1. In Administrative Tools, open the Application Virtualization Management Console.
2. In the navigation pane, expand the server name object, and then click Applications.
3. Right-click the application that is generating the Event ID 3017 and select Properties.
4. Verify the OSD path is correct.

Note: The OSD path should be the UNC path to the OSD file (Example: \\appv-svr\content\AppDirectory\Appname.osd)

5. Click OK to close the application properties.

Additional Resources

App-V TechCenter on TechNet: https://technet.microsoft.com/en-us/appvirtualization/default.aspx

Query Words

2A-0000274D 04-00000917 64-00000005 2A-00002745 0A-10000005 0A-10000009 0A-00002002 0A-20000194 64-00000002

=====

For the most current version of this article please see the following:

2615201: How to troubleshoot failures when refreshing the publishing server on an App-V client

J.C. Hornbeck | System Center Knowledge Engineer

App-V Team blog: https://blogs.technet.com/appv/
AVIcode Team blog: https://blogs.technet.com/b/avicode
ConfigMgr Support Team blog: https://blogs.technet.com/configurationmgr/
DPM Team blog: https://blogs.technet.com/dpm/
MED-V Team blog: https://blogs.technet.com/medv/
OOB Support Team blog: https://blogs.technet.com/oob/
Opalis Team blog: https://blogs.technet.com/opalis
Orchestrator Support Team blog: https://blogs.technet.com/b/orchestrator/
OpsMgr Support Team blog: https://blogs.technet.com/operationsmgr/
SCMDM Support Team blog: https://blogs.technet.com/mdm/
SCVMM Team blog: https://blogs.technet.com/scvmm
Server App-V Team blog: https://blogs.technet.com/b/serverappv
Service Manager Team blog: https://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: https://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: https://blogs.technet.com/sus/

clip_image001 clip_image002