10. Troubleshooting

10.1. Diagnostic Mode

Note

Diagnostic Mode will collect additional information that will help troubleshoot the issues.

If module doesn’t work as you expect, it’s worth to enable “Diagnostic Mode”. This will output logs that describes how the module is working. They can also diagnose issues that can occur like: config errors, failed login process, etc. Logs are created in file that is located in ~\Portals\_default\LogsYYYY.MM.DD.logs.resources, see log example below:

_images/troubleshooting-diagnostic-mode_01.png

Logs are created only when plugin is working in “Diagnostic Mode”, to enable it please follow steps below:

  1. Open log4net configuration file DotNetNuke.log4net.config, it can be found in DNN root folder, see figure below:

    _images/troubleshooting-diagnostic-mode_02.png

  2. Inside that file set log level to ALL, see code snippet below:

    <root>
    <level value="ALL" />
    <appender-ref ref="RollingFile" />
</root>

  3. Open “AD-Pro Authentication-> Module options-> Other Settings” tab and enable attribute “Diagnostic Mode”, see figure below

    _images/troubleshooting-diagnostic-mode_03.png

  4. Now logging mechanism is turned on, reproduce the sign-in process and check the log file.

10.2. How generate diagnostic logs

Please follow the instructions below on how to generate valuable logs.

  1. First enable diagnostic mode, to do that see instructions from section Diagnostic Mode

  2. Log file is usually very big, which makes it difficult to parse. To remove unncecessary informations, delete log file, before you will reproduce the issue.

    Default path to log file is: ~\Portals\_default\Logs\YYYY.MM.DD.resoures

  3. Reproduce the issue to generate log entries.

  4. Compress log file, and send it to support@glanton.com

10.3. JavaScript issues

10.3.1. Overview

User interface is created at the top of AngularJS framework. JavaScript can be moody although it’s very fast. If you will see interface issues, for example view can’t be loaded or displayed, buttons aren’t responding, it’s worth to check JavaScript errors. Depending what browser you are using, check following articles that are describing how to display these errors in your browser:

If you have any problems with your plugin, please send above error messages to support@glanton.com

10.3.2. Edit & Delete buttons doesn’t work

When you can’t update module settings, and JavaScript throws error like Method Not Allowed... or requests throws 405 HTTP error code, please make sure that WebDAV is disabled. To disable WebDAV, please add following lines to the web.config file, in the section system.webServer-> modules add following line:

<modules>
    <remove name="WebDAVModule"/> <!-- add this -->
    ...
</modules>

in the section system.webServer-> handlers add following line:

<handlers>
    <remove name="WebDAV" />
    ...
</handlers>

the ExtensionlessUrl-Integrated-4.0 handler under the system.webServer-> handlers also applies the verb PUT:

<handlers>
    ...
    <remove name="ExtensionlessUrl-Integrated-4.0" />
    <add name="ExtensionlessUrl-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    ...
</handlers>

Here you can read more about WebDAV.

If this will not help add following code snippet to the web.config:

<modules runAllManagedModulesForAllRequests="true">
  <!--IISFIX: Whatever this is, it causes 405 Method Not Allowed errors on IIS when using PUT. (Microsoft's broken by defult)-->
  <remove name="WebDAVModule"/>
</modules>
<handlers>
     <!--IISFIX: ASP.net is broken by default. By default they will not accept verbs from the client.
     First we have to rip out everything related to ASP.net-->
    <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit"/>
    <remove name="ExtensionlessUrlHandler-Integrated-4.0"/>
    <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit"/>
    <remove name="SimpleHandlerFactory-ISAPI-2.0-64"/>
    <remove name="SimpleHandlerFactory-ISAPI-2.0"/>
    <remove name="SimpleHandlerFactory-Integrated"/>
    <remove name="SimpleHandlerFactory-Integrated-4.0"/>
    <remove name="SimpleHandlerFactory-ISAPI-4.0_64bit"/>
    <remove name="SimpleHandlerFactory-ISAPI-4.0_32bit"/>
        <!-- IISFIX: Now that we're ripped out everything related to ASP.net, put them back correctly.-->
    <add name="SimpleHandlerFactory-ISAPI-4.0_32bit" path="*.ashx" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0"/>
    <add name="SimpleHandlerFactory-ISAPI-4.0_64bit" path="*.ashx" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0"/>
    <add name="SimpleHandlerFactory-Integrated-4.0" path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0"/>
    <add name="SimpleHandlerFactory-Integrated" path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode"/>
    <add name="SimpleHandlerFactory-ISAPI-2.0" path="*.ashx" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness32" responseBufferLimit="0"/>
    <add name="SimpleHandlerFactory-ISAPI-2.0-64" path="*.ashx" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness64" responseBufferLimit="0"/>
    <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0"/>
    <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0"/>
    <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0"/>

    <!--IISFIX: WebDAV is also buggy, and interferes with client requests-->
    <remove name="WebDAV"/>

</handlers>

10.3.3. Settings panel not loaded

If website is working at the top of HTTPS protocol and it’s behind the load balancer there could be issue where the user interface is not displayed at all. Usually it’s because JavaScript files reqired by the AD-Pro plugin are trying to be requested via HTTP protocol instead of HTTPS. To confirm that please check the source code of the DNN page where the Glanton plugin is (click CTRL+U), and look for a string SERVER_DOMAIN or SERVER_DOMAIN_JS, see attached picture.

_images/troubleshooting-javascript_view_01.png

To correct this issue the DNN website needs to know that we are using HTTPS.

  1. Sign in as DNN Administrator or Host.

  2. Go to “Security” menu, see figure below.

    _images/troubleshooting-javascript_view_02.png

  3. Click on tab “More” then “SSL SETTINGS”. Enable option “SSL Enabled” and save settings, see figure below.

    _images/troubleshooting-javascript_view_03.png

  4. To confirm check the page source once again.

10.3.4. View can’t be loaded

If you see situation like on figure below, where only upper part of interface is loaded and instead of bottom part of interface is displayed message Top level state template, probably it’s caused by minified js file.

_images/troubleshooting-javascript_02.png

To fix that issue sign in as DNN host and go to menu “Servers-> Server Settings”. At the bottom is section responsible for reducing Java Script files, please disable Minify JS attribute. See figure below for more info.

_images/troubleshooting-javascript_03.png

10.3.5. Multiple versions of AngularJS

There could be situation where DNN page is requesting two different versions of AngularJS library. For example two third-party plugins (module and skin), both wants AngularJS library, but in different versions. From “AD-Pro Authentication” perspective this could lead to issue like on figure below:

_images/troubleshooting-angular_01.png

Web browser console will display error like on figure below:

_images/troubleshooting-angular_02.png 
Uncaught TypeError: angular.module(...).component is not a function...

If AngularJS library is loaded from DNN skin, we can temporary replace skin by following steps below:

  1. Go to page where “Module options” is.

  2. Add following parameter to the query string in url: ?SkinSrc=%5BG%5DSkins/Xcillion/Inner now url can look af follow:

    http://dnn800.test/AD-Pro/Authentication/ctl/Edit/mid/414?SkinSrc=%5BG%5DSkins/Xcillion/Inner

In this case was used Xcillion skin, but it can be any other skin that doesn’t have AngularJS dependency.

10.4. SSO - providers order

When all configuration steps for the SSO was done, but you keep getting windows popup asking you to enter user credentials, possible it’s worth to change providers order.

  1. Go to IIS and open Authentication tab for the ~\DesktopModules\GS_ADProAuthentication\WinAuthSignIn.aspx file.

  2. Select Windows Authentication.

  3. Click on Providers.

  4. Inside popup Providers, swap places for Negotiate and NTLM.

  5. Apply settings by clicking on OK button, see figure below:

    _images/troubleshooting-authentication-providers-order_01.png

Before you test SSO make sure that cache is deleted in IIS, DNN and web browser.

10.5. Sign-in process hangs

If there is situation where:

  • a group of users can’t sign-in,
  • DNN logs doesn’t contain any info why user can’t sign-in,
  • DNN web application restarts right after sign-in process starts,

The reason fo that situation can be that the user is part of an AD group which had the same group nested inside it, so the group was a member of itself. In other words user belongs to group(s), that are nested each other.

In this case Active Directory sends error to DNN that automatically restarts, without reporting anywhere about source of that issue. To fix that, please first isolate user or bunch of users, then focus on groups that they belongs, under tab Member Of.

10.6. Log off issues

If there are any issues at the sign off process, it’s worth to consider set dedicated log off page. It’s important that log off page should have permissions View Page for All Users, see image below.

_images/troubleshooting-logOff_02.png

To set up custom log off page follow steps below:

  1. Sign in to DNN as Admin or Host.
  2. Go to Admin->Site Settings
  3. Select User Account Settings tab, then Login Settings section.
  4. Under Redirect After Logout attribute, set new log off page.

See figure below for more info:

_images/troubleshooting-logOff_01.png

10.7. Username Already Exists

At the login process DNN can throws message like UsernameAlreadyExists or DuplicateUsername, or:

Login process failed!  Can't create user, error code: UsernameAlreadyExists
Login process failed!  Can't create user, error code: DuplicateUsername

Even if user is deleted through user interface, there can be still orphaned records in database. Despite the fact that user is not listed under the “Admin->User Accounts” menu, please make sure that specified user records doesn’t exist in following tables:

[Users],
[aspnet_Membership]
[aspnet_Users]
[UserProfile]

10.8. Unable to locate controller

If user interface is not responding and web browser console displays message like:

Unable to locate a controller .../GS_ADConnectionManager/API/AdCs/AdCs_GetAll.
Searched namespaces: GS.ADConnectionManager.Rest.

Screenshots from web browser console below:

_images/troubleshooting-locate-controller_01.png

and

_images/troubleshooting-locate-controller_02.png

This issue often appears after DNN upgrade process. Even if routes are properly registered by RouteMapper, DNN can’t execute these WebAPI requests, and throws error message Unable to locate controller.

_images/troubleshooting-locate-controller_03.png

To fix this issue please apply following change to the web.config file. Under <system.web> in <compilation> node, toggle dissable/enable optimizeCompilations attribute.

_images/troubleshooting-locate-controller_04.png

First optimizeCompilations set to to false. Save file, refresh website. Then the error went away so you could set it back to true.

10.9. 0x800050000 issue

The error code 0x800050000 usually is displayed when module can’t access to the ADSI provider in IIS. If the permissions matched up, just to be sure force the directory to propagate the permissions to the files again. So even though the permissions appeared correct that was the choke point, resetting those permissions solved the issue.

Please see here for more info