Publishing Refresh succeeded but where are my icons? Troubleshooting some common publishing issues in Microsoft App-V
If you are running Microsoft App-V in what is now referred to as a traditional App-V Server-based infrastructure, desktop configuration is controlled by an App-V Management Server. Depending on local client configuration and provider policy, the client will periodically refresh its configuration against the server. This was once called DC Refresh and is now referred to as Publishing Refresh. During Publishing Refresh, the App-V client receives the list of applications to be published (APPLIST.XML) and from this will cache the icons and the OSD files by retrieving them from the locations specified in the APPLIST.XML that is received from the server. The locations of the OSD and Icons can come directly from the locations specified in the APPLIST.XML data or they can come from the use of OSDSourceRoot and IconSourceRoot registry values which allow a client computer to receive its ICO and OSD files from an alternate location. The App-V client then creates the appropriate shortcuts and registers file type associations based on the information generated by the App-V Server. This is a rather simplified description of the process so for a more detailed explanation I would recommend reading the following document:
In addition, the following blog post from last year is also an excellent reference:
https://blogs.technet.com/softgrid/archive/2009/02/17/a-story-of-a-publishing-refresh-request.aspx
When there is an error during the “refresh” portion of the process (communicating with the server to retrieve the APPLIST.XML) causing the refresh not to complete successfully, you will see an error in the user interface. Often these errors relate to authentication, networking issues, XML malformation, or general misconfiguration. But sometimes problems will occur during the “publishing” portion of the publishing refresh. When you refresh, you may not get any errors but you still may not have the entire application configuration you would expect. This is an issue we see every now and then from customers where they ask “refresh is succeeding but where are all my icons?” Or they say “some applications may appear where they are supposed to be but others do not.” If you find yourself in this situation then here are some tips on how to troubleshoot these kinds of issues:
Troubleshooting Publishing Problems
Often, a standard SFTLOG.TXT log will give you exactly what you need to troubleshoot these problems. Switching to a verbose log will dump the AppList.XML and other information that will make the log file quite large and more cumbersome to parse. While publishing problems do not generate errors in the user interface, there are always positive and negative result codes (rc codes) in the SFTLOG.TXT file even under its default log level.
When you encounter these issues, navigate to the SFTLOG.TXT file and look for lines containing the following string “The app manager could not create an application from” to determine where the publishing errors are in the SFTLOG.TXT. The majority of these errors come from issues accessing and/or parsing OSD files and icons.
Common Issue #1: The app manager could not create an application from “APPLICATIONNAME.osd' (rc 0C405564-00000002).
These issues are caused by the client application manager being unable to access either the icons or the OSD file based upon the locations sent by the server or what may be specified as an overriding value in the OSDSourceRoot or the IconSourceRoot.
Common Issue #2: The app manager could not create an application from 'APPLICATIONNAME.osd' (rc 07708144-0000000E).
When this happens, you can get the specific error string above this message. The most common one is:
The Application Virtualization Client could not parse the OSD file ‘<GUIDNAME>.osd'. Reason: Newer client required (rc 07708104-0000000E)
This issue happens when the OSD for the application has a client requirement that exceeds the current client version. This may happen more often now with the 4.6 sequencer being backward compatible for existing 4.5 clients. For example, if you sequence an application in 4.6, the default tag for CLIENTVERSION will be 4.6.0.0 as shown below:
<DEPENDENCY>
<CLIENTVERSION VERSION="4.6.0.0"/>
</DEPENDENCY>
You will need to change this to 4.5.0.0 if you plan on deploying this application on 4.5 clients.
Common Issue #3: The app manager could not create an application from 'APPLICATIONNAME.osd' (rc 00000C45-00000107).
This happens when the Client Application Manager cannot parse the XML in the OSD file for the application. Like with common issue #2, you will get further information above this error such as:
The client has encountered an XML parsing problem. The error code is 0xC00CE557.
Reason: Invalid xml declaration.
Source Text: <?xml version="1. 0" standalone="no"?>, (near line 1, character position 6).
Often these errors will point to the specific line and character position containing the error.
Common Issue #4: The app manager could not create an application from 'APPLICATIONNAME.osd' (rc 0C405564-00000003).
This can happen if the path of the global data directory is invalid. The OSD Cache folder either does not exist or cannot be accessed due to redirection. For example, the OSD Cache folder may have been manually removed. Verify the global data directory is located in an accessible folder and has not necessarily been redirected to a network share.
Common Issue #5: The app manager could not create an application from 'APPLICATIONNAME.osd' (rc 07708A44-00000007).
This error, depending on the version may also be preceded by the following line:
The Application Virtualization Client could not parse the OSD file '<GUID>.osd'. Reason: No valid implementation for this machine (rc 07708A04-00000007)
This issue occurs when the OSD contains specific OS implementation values but the App-V client’s operating system is not included. The <OS VALUE> tag is under the <IMPLEMENTATION> element in the OSD. The supported updated values for 4.6 can be found here:
Hope this helps!
Steve Thomas – Senior Support Escalation Engineer
