通过

Error code: 0000C81B - When connecting to the App-V Management Web Service server from the App-V Management Console

  • 项目

I recently came across an issue where a change to the IIS Request Filtering settings triggered the error code: 0000C81B when launching the App-V Management Console while hardening an App-V environment using a  DISA IIS STIG checklist.

App-V Environment:

  • Windows Server 2008 Ent R2 SP1
  • SQL Server 2008 Ent R2 SP1
  • App-V (Server) 4.5 SP2 HF02 [version: 4.5.3.200311

STIG Information:

If you're not familiar with STIGs, here's a quick overview:

The Security Technical Implementation Guides (STIGs) and the NSA Guides are the configuration standards for DOD IA and IA-enabled devices/systems.

A STIG Security Checklist, typically a companion of a STIG, is essentially a document that contains instructions or procedures to manually verify compliance to a STIG. STIGs have been under optimization efforts since 2008 to begin to combine the STIG and STIG Security Checklist into one document.

Additional information can be found here: https://iase.disa.mil/stigs/index.html

STIG Checklist Item:

The following is from the STIG guidance:

    • Open the IIS Manager.
    • Click on the site name.
    • Double-click the Request Filtering icon.
    • Click Edit Feature Settings in the Actions pane.
      • If the “Allow unlisted file extensions” checkbox is set to unchecked, this is not a finding.
      • If the site has operational reasons to set “Allow unlisted file extensions” to checked, and has supporting documentation signed by the IAO, this is not a finding.

If the site has “Allow unlisted file extensions” checked and does not have supporting documentation signed by the IAO, this is a finding.

The Issue

When launching the App-V Management Console, the user is presented with the App-V console login box and asked to supply the Web Service Host Name; as if the user hasn't previously connected to the Management Console. Upon entering the name and connection information, then clicking OK; the user is presented with the following error message:

 The sftmmc.log will display an error similar to the following when you attempt to launch the console:

4/12/2012 9:51:54AM https://appvserver01/
ManagementConsole.MCException: The remote server returned an error: (404) Not Found. ---> System.Net.WebException: The remote server returned an error: (404) Not Found.

Upon initial troubleshooting, I used the following KB Article, (https://support.microsoft.com/kb/930465) it describes a few possible methods for resolving this issue. It is recommended you try the methods listed in the KB article first before attempting the following fix. Unfortunately for me, these did not resolve my issue.

 

Workaround:

I identified the root cause was because the "Allow unlisted file extensions", was unchecked. After checking the box for Allow unlisted file extensions, the console was able to launch with no problems.

Launch IIS Management Console > Select Default Web Site > double-click Request Filtering > click Edit Feature Settings (in the Actions Pane) > check the box for Allow unlisted file extensions > click OK.

I did NOT need to restart IIS or the App-V Management Service for this change to take affect.

Resolution [Extension identified!]

 Upon further analysis, I was able to determine the required extension we need to allow is [.rem]. problem solving steps I took to find the extension:

1. Open IE and go to https://appvserver01.contoso.local (the FQDN of your App-V server)

2. I was prompted with this error page:

3. Next step was to review the log files located in the %windir%\inetpub\logs\LogFiles\W3SVC1\ directory. There may be a handful in there, so you may just want to open the latest log in the directory.

4. In the log I was able to track down the extension I needed. It's [ .rem]. The log snippet below has the highlighted information...

5. Now, all I had to do was add the [ .rem] extension into the IIS Request Filtering Section of IIS and we should be good to go!

6. Now try to launch your App-V console! I did not have to restart IIS for this to work.

Comments

  • Anonymous
    April 12, 2012
    Sup,  Good job.