Overview

This article provides information about experiencing issues when upgrading an instance. Knowing the common problems or common indicators will provide you with the tools to troubleshoot a failed upgrade.

Prerequisites

• Basic Knowledge of upgrading Evoq Environments

Information

How Do We Know That an Upgrade Has Failed?

This might sound like a simple question, but many times, it may be easy to miss. Just because an upgrade looks like it has completed, and the site is “functional” does not mean that an upgrade has been successful. 

The process of upgrading DNN is very well-documented. The first step in troubleshooting is to walk through every part of the upgrade process to make sure that you have followed through with all the prerequisites and the step-by-step process.

• Please review the Upgrading Evoq article.

Basic Troubleshooting Process

• Check the DNN Logs in the Portals/_default/Logs folder - There should be logs that are generated if an upgrade has failed, once we gather the exact error message, you should be able to narrow down which component has failed.
  • You should check this even if an upgrade has completed successfully to make sure there are no issues that stand out right away.
• Double-check that you have followed the upgrade documentation step-by-step.
• Make sure that you have used the correct upgrade package for your version and edition and (if upgrading from a later version) followed the correct upgrade path.
• If the environment is on a web-farm, follow the Web Farm Configuration Guide and shut off all other webheads and then upgrade the active webhead.

Known Upgrade Issue Scenarios

Here are a couple of scenarios you may run into during or after an upgrade.

Scenario #1

Your environment has been upgraded, but the Persona Bar shows a grey style rather than the dark navy Persona Bar that we are familiar with. 

This is a clear indicator that the upgrade has failed, and the environment should be rolled back. This usually occurs when the application thinks that the application is in a newer version than the components are currently in.

• For example, if the application was upgraded to Evoq 9.2.2 but the Persona Bar components are still in 9.1.1.

Another example is that you have used the incorrect upgrade package, such as a different edition than the edition they are currently on. For example, applying a DNN Platform upgrade package onto an Evoq environment. 

<supportagent>If a customer reports this issue, it is best to check the exact steps the customer followed, as it will be easier to see which step that they forgot to follow.</supportagent>

Scenario #2

The environment has been upgraded, but the site will not come up, and it looks like the site is hanging indefinitely. Looking at the logs, you will most likely see aborted thread errors with the stack trace.

DotNetNuke.Services.Scheduling.Scheduler.CoreScheduler.RunEventSchedule(EventName eventName)

This usually means that there is a lock on one of the schedulers, and it is preventing the site from responding. This can be resolved by shutting off the schedulers via SQL through the enabled column in the Schedule table.

<supportagent>Shutting off the schedulers before upgrading is a step laid out in the Upgrade document. If a customer reports this issue, it is best to highlight this and walk the customer through the upgrade process.</supportagent>

Scenario #3

After an upgrade, you see this message in the logs: Method not found: 'System.StringDotNetNuke.Entities.Modules.PortalModuleBase.get_ModulePath()'.

• This is usually caused by a third-party skin or module that is not compatible with Evoq 9.2. In Evoq 9.2, there were over 500+ deprecated DNN API methods that were removed from DNN and were optimized.

You will need to update all of your third-party modules/skin to be compatible with the latest version of Evoq. The vendors that have created the modules or skin will need to provide the upgraded version.

<supportagent>If the customer still reports issue, to cover all our bases, you will need to test everything along the way in a local environment to make sure that the issue the customer is seeing is not an issue with our core code. Otherwise, you may troubleshoot an issue for an extended period, and it may have just been bug related.

• If all troubleshooting options have been exhausted, you will need to download a copy of the customer's site files and database and deploy the environment in your local instance to debug the site.
• Make sure this troubleshooting checklist is followed to check the Windows Server, Database, and the Upgrade Wizard.</supportagent>

Related Articles

• Troubleshooting Checklist
• Upgrade Path