With regard to the Configuration Manager console, this role is one of the less visible components, and troubleshooting from here is minimal. From the Monitoring workspace, we can browse to System Status | Site Status and get a quick indicator on the status of the Application Catalog website point. This status is based on a cumulative count of status messages for the component SMS_PORTALWEB_CONTROL_MANAGER and refreshes by default every day at 00:00, so bear this in mind when using this as it is only a point in time indication and may not truly represent the current status. Incidentally, we can change this interval using the Status Summarizers window in the site properties. Also be aware that if we right-click or use the ribbon to show messages, then the status message viewer displays relevant messages for the site system itself and not necessarily the individual component. Moving on from here, we can specifically view the component's status by browsing to the System Status | Component Status view and selecting or filtering on SMS_PORTALWEB_CONTROL_MANAGER. This will again give us an indication of status, either OK, Warning, or Failed. If we go to the properties of this component in the same view, then we can observe the thresholds defined for each status. These, by default, are as follows:

We can, of course, change these threshold levels in the Component Status Summarizer properties, which can be found in Administration | Site Configuration | Sites. As with all views in the Monitoring workspace where there are aggregated status indicators, be sure that the counters are reset if changes have been made to resolve problems, otherwise the status indicators may not turn green until up to 24 hours later.

Moving on a little further, we can show specific messages for the SMS_PORTALWEB_CONTROL_MANAGER component using either the ribbon or right-click menu. This, of course, gives us a greater level of detail than the monitoring indicators but not as much as the log files that are provided. As this particular role is quite static in terms of frequency of configuration change, the common status messages in this view generally give information about component availability. The Status Message Viewer will also display information regarding the success of your role's installation. A common mistake for this particular role seems to be not fully installing and configuring the prerequisites, specifically around IIS and ASP.NET 4.0. Let us not forget, however, that this particular role is in fact a tangible role that can be seen and touched by the end user, and so, inevitably, this can mean that any problems with this role are automatically highlighted to you through the helpdesk.

There are three log files dedicated to this site system role, two for the initial installation or setup and one for the ongoing running of the component. The SMSPORTALWEBSetup.log and portlwebMSI.log files are found by default in %ProgramFiles%Microsoft Configuration ManagerLogs and contain information about the installation and uninstallation of the Application Catalog website point site system role. Don't forget that even if the installation wizard shows as completed and the role is added to the console, we should really check the SMSPORTALWEBSetup.log file to ensure that we have a successful installation. This is signified by these three lines at the end of the log file:

portlweb.msi exited with return code: 0
Installation was successful.
~RoleSetup().

If we see anything other than a return code 0 for the portlweb.msi then we should make note of the return code and use the Windows Installer Errors Reference mentioned in Chapter 1, The Configuration Manager Troubleshooting Toolkit. We can also look at the more detailed portlwebMSI.log file and see exactly what went wrong. Generally, we can look for the return code we noted and then work back from that point to see what may have caused the failure to install or uninstall.

Once we have achieved a successful installation we can use the ServicePortalWebsite.log file found by default in %ProgramFiles%SMS_CCMCMApplicationCatalog to investigate the cause of any issues with the Application Catalog website point. Typically, this log file would contain information about website starts and stops along with heartbeat checks and any HTTP responses in the case of a failure. A normally functioning role would typically repeat something like this in the ServicePortalWebsite.log file every hour:

SoftwareCatalog website - application instance dispose ...
No cached apps to serialize (caching not enabled or no apps in cache)
SoftwareCatalog website stop ...
SoftwareCatalog website - application instance dispose ...
SoftwareCatalog website start ...
DefaultApplicationOfferService - retrieving client proxy using endpoint SecureBinding_IApplicationOfferService
FindCertificate - Found certs via FindByThumbprint, count = 1
DefaultApplicationOfferService - opening channel via client proxy
DefaultApplicationOfferService - opened service session urn:uuid:109b8ac0-5962-41b3-b376-fbe1317cc9d1
ServiceProxy - BeginCheckServiceHeartbeat
ServiceProxy - BeginCheckServiceHeartbeat done
AppCacheableBase - configured writable app directory set to: C:Program FilesSMS_CCMCMApplicationCatalogContentImagesAppIcons
ASP.NET application cache will NOT be used (either cache dir not found, asp.net cache is not set, or cache setting in web.config is <= 0
ServiceProxy - EndCheckServiceHeartbeat done
Warmup complete
No language specified in Request.UserLanguages
SoftwareCatalog website - requested resource: ~/default.aspx, api-version: ""
No current build version found so will try to get one
Got 5.0.8239.1000 build version

Any configuration issues with the role will be reported in this log file and should be investigated and remediated accordingly, but generally speaking this tends to be a trouble-free role. We can check role configuration in the registry by looking at the ComputerHKEY_LOCAL_MACHINESOFTWAREMicrosoftSMSPORTALWEB key.

This can often be worth a check for incorrect information in the case of a configuration-related error because, along with a lot of other roles, the site database will expect one configuration and the site system server will also have a configuration, which in this case is stored in the registry. Sometimes there can be a mismatch between the database and the site system server, particularly if there have been multiple installations and uninstallations. We can also reference the logging subkey and extend the log file size and history if required. This also applies to the web service point, and we will look at how to do this in the next section.

If we take a look at the role configuration in Administration | Site Configuration | Servers and Site System Roles, we can see that there is actually very little in terms of configuration that we can actually change. We just see the web application name, its website, and the port numbers. In fact, we can't actually change anything, so with that in mind we can be reasonably confident that if the role previously worked and it is not working now, then the issue is very likely to be elsewhere.

If this is the first installation of the role and it therefore has not worked previously, then we can check to ensure that the installation has completed using the following log files, which can be found by default in %ProgramFiles%Microsoft Configuration ManagerLogs:

The MSI log, which details the output from the Microsoft Installer, is the more detailed of the two. The setup log shows a slightly more summarized output from the installation process. Remember that when we run through the installation from the Configuration Manager console and we get a green tick, it does not necessarily indicate that the role is installed; it merely shows that the role has been added to the console and the installation has been started. We are essentially looking for the last three lines of the setup log file to read as follows:

awebsvc.msi exited with return code: 0
Installation was successful.
~RoleSetup().

This represents a successful installation. If we have something different, then check the return code and work from there. A common issue with the installation of this role seems to be when the last three lines show an exit code of 123:

WCF is not activated
Installation Failed. Error Code: 123
~RoleSetup().

As the error suggests, one of the prerequisite features, which is Windows Communication Foundation (WCF), has not been installed or activated. In this case, we should check this in our server roles and features and ensure we have all the necessary prerequisites for our operating system version. Be aware that these can be slightly different for pre and post Windows Server 2012.

As this role is again a web application, we can use the same troubleshooting methods that apply to any standard IIS application and any error codes can be referenced from the HTTP status code lists we talked about in Chapter 1, The Configuration Manager Troubleshooting Toolkit. There are, however, some specific log files for this server role, which can found in the logs folder of the application, which is stored by default on the server where the role is installed, in the %ProgramFiles%SMS_CCMCMApplicationCatalogSvc folder.

Inside the logs folder there is the ServicePortalWebService.log file which contains some information about the ApplicationOfferService and the DeviceManagementService, which are the two components of this web application. This log file can be extended in size and the amount of history stored by changing the default decimal values in the registry from 8 MB (8000000 bytes) and one history file. The registry key we need is at ComputerHKEY_LOCAL_MACHINESOFTWAREMicrosoftSMSAWEBSVCLogging.

Let's take a look at the following screenshot:

Generally speaking, this role is not usually prone to frequent errors, so we should deal with each one as it comes. As with anything, the more frequently we change the component and its configuration, the greater the chance of something going wrong.