none
Application Catalog - Cannot connect to the application server.

    Question

  • I have SCCM 2012 up in a development environment running on 3 separate VMs.

    SCCMPSQA - Primary Site

    SCCMDPQA1 - Distribution Point

    SCCMSQLQA - SQL Server

    Software Center works great, can see and download advertised programs no problem.  When I go to http://sccmpsqa/CMApplicationCatalog I get the following error.

    "Cannot connect to the application server"

    "The website cannot communicate with the server.  This might be a temporary problem.  Try again later to see if the problem has been corrected.  If this problem continues, contact your help desk."

    Troubleshooting steps to date:

    1. Verify WCF Installed with HTTP Activation
    2. Uninstalled/Reinstalled WCF with HTTP Activation
    3. Uninstalled/Reinstalled IIS Components
    4. Removed App Catalog Roles from Primary Site
    5. Installed App Catalog Roles to Distribution Point - Same Issue
    6. Repeated Steps 1-3 for Distribution Point
    7. Removed App Catalog Roles from Distribution Point
    8. Installed App Catalog Roles back to Primary Site
    9. Ran %windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i -enable

    Not sure if this is helpful but the only odd thing I see in ServicePortalWebSite.log is the following message.

    [10, PID:6372][07/26/2012 10:04:27] :System.ServiceModel.Security.SecurityNegotiationException: The caller was not authenticated by the service.

    Figuring it has to do with WCF somehow as that's all I can find on google but so far nothing I've done with WCF has worked.

    Roles are being configured with HTTP and using all the default names.

    Client Push, Remote Control, Reporting, and Software Distribution are all working great, just this one thing isn't working. I'll appreciate any help or any place to go look.

    Thursday, July 26, 2012 3:36 PM

Answers

  • Based on the certMgr.log snippet, it seems that there are two different intranet FQDN addresses used to access the machine where the roles are installed. The primary site tries to contact the machine by using an intranet FQDN and fails to do so. It may be the case here that the intranet address stored in the system does not match the server address.  

    I'd suggest looking at the properties of the Site System to make sure the intranet name of the server is correct and unchecking the internet name option if you do not have internet-facing roles on this site system. You can also try installing the roles on a new remote server to see if the correct intranet FQDN is used for the new machine. If this doesn't help, I'd strongly suggest contacting CSS to investigate the issue further.

    • Marked as answer by RyanPizzi Friday, July 27, 2012 3:35 AM
    Friday, July 27, 2012 2:32 AM

All replies

  • Thursday, July 26, 2012 3:39 PM
  • Rather than go from memory I re-verified each prerequisite.

    Service and website point are both on the primary site.  Confirmed all the reqs for the Application Catalog Web Service Point and Application Catalog Website Point.

    I re-reran %windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe –i –enable just on the offchance it had been missed before.  Confirmed same error is happening.


    Thursday, July 26, 2012 4:05 PM
  • Thursday, July 26, 2012 5:33 PM
  • I've tried the various suggestions on that page.  To date I've only used the default names in hosting the pages, also have tried changing the names just in case.  I've reinstalled WCF a number of times as well as run the aspnet_regiis.exe -i -enable command.
    Thursday, July 26, 2012 6:23 PM
  • The error "The caller was not authenticated by the service." may show up while the primary site configures the Application Catalog roles, which typically takes a few minutes. Does this error show up in the log for the new requests to the Application Catalog ? Also, is SMS_EXECUTIVE service running on the primary site ?
    I would also suggest browsing to each of the Application Catalog roles directly using http://localhost on the machine where the roles are installed as outlined in this blog post to verify that each role is up and running.



    Thursday, July 26, 2012 6:40 PM
  • I thought perhaps it just took time for everything to install but logs showed successful.  Just in case I let it sit for a day and also restarted the system just for kicks.

    Verified SMS_EXECUTIVE is running.

    Going to http://localhost/CMApplicationCatalog

    "Cannot connect to the application server"

    Going to http://localhost/CMApplicationCatalogSvc

    "HTTP Error 401.3 - Unauthorized"

    "You do not have permission to view this directory or page because of the access control list (ACL) configuration or encryption settings for this resource on the Web server"

    "Error Code: 0x80070005"

    "Logon Method: Anonymous"

    "Logon User: Anonymous"

    Following the instructions however, going to http://localhost/CMApplicationCatalogSvc/ApplicationOfferService.svc

    Shows alright, says "This is a Windows Communication Foundation Service"  I do get a "Metadata publishing for this service is currently disabled"  But not sure if that's normal or not.

    Very good link though, bookmarking that for sure.  Went through it and checked everything but none of that appears to be the cause of my issues.  All green in the component status, checked the logs and nothing is really shouting out an issue.

    After verifying all the prerequisites I uninstalled/reinstalled both app catalog roles and still running in to the same issue.

    Thursday, July 26, 2012 7:12 PM
  • Below is the log the is produced by ServicePortalWebSite.log when I try to connect

    [7, PID:1360][07/26/2012 14:16:55] :System.ServiceModel.Security.SecurityNegotiationException: The caller was not authenticated by the service.
    Server stack trace: 
       at System.ServiceModel.Security.IssuanceTokenProviderBase`1.DoNegotiation(TimeSpan timeout)
       at System.ServiceModel.Security.SspiNegotiationTokenProvider.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Security.TlsnegoTokenProvider.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
       at System.ServiceModel.Security.SymmetricSecurityProtocol.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
       at System.ServiceModel.Channels.SecurityChannelFactory`1.ClientSecurityChannel`1.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
       at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.DoOperation(SecuritySessionOperation operation, EndpointAddress target, Uri via, SecurityToken currentToken, TimeSpan timeout)
       at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.GetTokenCore(TimeSpan timeout)
       at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout)
       at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
    Exception rethrown at [0]: 
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at System.ServiceModel.ICommunicationObject.Open(TimeSpan timeout)
       at System.ServiceModel.ClientBase`1.System.ServiceModel.ICommunicationObject.Open(TimeSpan timeout)
       at Microsoft.ConfigurationManager.SoftwareCatalog.Website.PortalClasses.Connection.DefaultApplicationOfferService.Open()
       at Microsoft.ConfigurationManager.SoftwareCatalog.Website.PortalClasses.AppView.GetApplications(Int32& totalNumberRows, ApplicationProperty sortBy, Dictionary`2 filterBy, String searchBy, Int32 maximumRows, Int32 startRowIndex, Boolean sortAscending, ApplicationClassicDisplayName classicNameFields, Boolean useSecondarySort)
       at Microsoft.ConfigurationManager.SoftwareCatalog.Website.PortalClasses.AppListView.GetApplications(Int32& totalNumberRows, ApplicationProperty sortBy, Dictionary`2 filterBy, String searchBy, Int32 maximumRows, Int32 startRowIndex, Boolean sortAscending, ApplicationClassicDisplayName classicNameFields, Boolean useSecondarySort)
       at Microsoft.ConfigurationManager.SoftwareCatalog.Website.ApplicationViewService.GetApplications(Int32& totalNumberRows, ApplicationProperty sortBy, String[] filterBy, ApplicationProperty filterByProperty, String queryString, Int32 maximumRows, Int32 startRowIndex, Boolean sortAscending, ApplicationClassicDisplayName classicNameFields, Boolean useSecondarySort, String reserved)System.ServiceModel.FaultException: The request for security token could not be satisfied because authentication failed.
       at System.ServiceModel.Security.SecurityUtils.ThrowIfNegotiationFault(Message message, EndpointAddress target)
       at System.ServiceModel.Security.SspiNegotiationTokenProvider.GetNextOutgoingMessageBody(Message incomingMessage, SspiNegotiationTokenProviderState sspiState)

    Thursday, July 26, 2012 7:17 PM
  • I noticed you have already tried reinstalling the roles, but I'd suggest to try the following steps:
    - Remove both Application Catalog roles
    - Monitor SMSAWEBSVCSetup.log and SMSPORTALWEBSetup.log to make sure the following shows up in both logs: "Deinstallation was successful."
    - Add the Application Catalog roles back with default parameters
    - Monitor the same set of logs and wait for the following line: " Installation was successful."
    - Wait for ~5 min to let the Primary site configure Application Catalog roles
    - Check that awebctl.log and portlctl.log both report "status code 200, text: OK"
    - Verify that there are no errors recently reported in CertMgr.log

     

    Thursday, July 26, 2012 7:29 PM
  • Will do, doing that now

    Thursday, July 26, 2012 7:29 PM
  • Installation successful on both SMSAWEBSVCSetup.llog and SMSPORTALWEBSetup.log.

    portlctl.log

    Call to HttpSendRequestSync succeeded for port 80 with status code 200, text: OK SMS_PORTALWEB_CONTROL_MANAGER 7/26/2012 2:36:05 PM 3168 (0x0C60)

    AWEBSCTL.log

    Call to HttpSendRequestSync succeeded for port 80 with status code 200, text: OK SMS_AWEBSVC_CONTROL_MANAGER 7/26/2012 2:33:50 PM 4260 (0x10A4)

    certmgr.log

    Cannot get copy of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\AWEBSVC registry key on server SCCMDPQA1.playpen.local.  The operating system reported error 2: SMS_CERTIFICATE_MANAGER 7/26/2012 2:34:30 PM 3556 (0x0DE4)


    Thursday, July 26, 2012 7:41 PM
  • Based on the certMgr.log snippet, it seems that there are two different intranet FQDN addresses used to access the machine where the roles are installed. The primary site tries to contact the machine by using an intranet FQDN and fails to do so. It may be the case here that the intranet address stored in the system does not match the server address.  

    I'd suggest looking at the properties of the Site System to make sure the intranet name of the server is correct and unchecking the internet name option if you do not have internet-facing roles on this site system. You can also try installing the roles on a new remote server to see if the correct intranet FQDN is used for the new machine. If this doesn't help, I'd strongly suggest contacting CSS to investigate the issue further.

    • Marked as answer by RyanPizzi Friday, July 27, 2012 3:35 AM
    Friday, July 27, 2012 2:32 AM
  • Great!  You were correct, the distribution point for some reason had the FQDN for the primary site.  Changed that and all is working.  Much appreciated and thank you.
    Friday, July 27, 2012 3:36 AM
  • Hi, am facing the same issue but am received the error in awebsctl.log as,

    Call to HttpSendRequestSync failed for port 80 with status code 404, text: Not Found

    Kindly help me to resolve the issue.

    Thanks,

    JCKhan

    Monday, May 13, 2013 10:51 AM
  • I had a very similar issue with a customer's setup...they had previous built the server and I think had left some configuration items.

    The bindings in IIS had 80,443,8530, and 8531.  SCCM and WSUS were only using 80 and 443.  After removing these bindings, all is well.

    Maybe someone else will find this helpful.

    D


    d

    Monday, July 29, 2013 2:41 PM