Troubleshooting Application Issues
Troubleshooting an application error is a common administrative practice that doesn’t involve VDS itself, but is greatly assisted by VDS and the level of control it provides administrators. While NetApp VDS does not troubleshoot these issues for Customers, our experience allows us to advice administrators after identifying some basic information like the following in order to dig deeper and troubleshoot with end users and/or third parties.
Name of the user experiencing the issue
Name of the application the user was working with
The server the user’s session was on
Steps to reproduce the issue
Reviewing Your Tools
After identifying the server the User was using, check your monitoring solution to validate that resource (CPU and RAM) consumption is within normal levels. You can also validate that application-specific requirements (a special service that will cause issues if it isn’t running) are functional. In situations like this, advanced settings like up/down monitoring of said services may have been triggered.
As an administrator with access to both the servers and Azure Active Directory, you have access to review what has been discovered and what policies are set. In the event something unforeseen is present, it could be affecting your application.
Some applications require additional components, like a service account that remains logged in indefinitely or a VPN to a piece of physical equipment (say, an on-site network appliance or a piece of manufacturing equipment or diagnostic utility). In these situations, application-specific errors may be caused by something other than the way the application was installed or how its settings are configured.
Extending Access to Third Parties
Applications and/or their databases are often installed, configured and supported by either the software vendor (ISV) themselves or a third party expert in that software’s configuration, management and integrations. In these situations you will want to extend temporary administrative access to a these steps: Providing Temporary Access to 3rd Parties
It is a best practice to shut down these third party accounts after the upgrade or update is completed or after the issue is resolved.
In many cases, this level of troubleshooting will require that a software maintenance contract with the ISV. If this is not in place, the ISV may not assist you until this is in place.
|It is also possible that the troubleshooting issue could be related to the hardware (desktops, laptops, thin clients, etc.) end users are working with. An example could be that upgrading a user’s laptop could lock the machine in the eyes of a thin client configuration file, meaning that end users cannot access the tools that allow them to log into their virtual desktop. In this case, a maintenance contract for hardware may be required before the manufacturer will assist you.|