最新消息:ww12345678 的部落格重装上线,希望大家继续支持。

AX Enterprise Portal – What information and data to collect when you want to open a support case

网络文摘 William 2115浏览 0评论

The aim of this blog post is to provide you with some suggestions on what information and data to collect and provide when opening a Microsoft support case. You can of course use these suggestions in your own organization too, whether you are a Partner or End User of Microsoft Dynamics AX. It’s usually a good idea to have a structured and repeatable approach to data collection and troubleshooting, though it can of course be hard to come up with a single template that covers all scenarios. Let’s start with some comments from our In-Market Engineering Team:

TechNet Blogs » Dynamics AX In-Market Engineering » Improve your chances for fast case turnaround

http://blogs.technet.com/b/dynamicsaxse/archive/2013/05/13/improve-your-chances-for-fast-case-turnaround.aspx

So what can you provide Microsoft support with that will help us expedite your AX Enterprise Portal case from the start?

 

1. A good problem description

Exact description of what the user experience when the issue occurs and include error messages shown in the browser.

It should include the following:

  • Background on whether the issue happens often, consistently or intermittently?
  • If the issue can be reproduced or it happen on a specific web page, then describe step by step how to reproduce the issue, including the path to get there.
  • Describe the current result and the expected result.
  • Does it happen for specific users only or all users?
  • When did the current issue begin?
  • Has there been done any changes to AX, SharePoint, Windows, network etc. prior to the issue started? If so describe the changes (e.g. deployed AX code, SharePoint updates, Windows updates etc.).
  • If you are having problems with a specific web page or process, and you have identified some X++/.NET call stacks, please provide that information.
  • We are also interested in your observations and ideas when it comes to a possible cause and what troubleshooting you have done.
  • If you have made customizations to the area you are seeing issues with, that is of course relevant to know.
  • If the error message seen in the browser include a Correlation Id, please copy the Correlation Id as text into the case description and provide an approximate time the error occurred. This will help us find the entries in the SharePoint log.

TIP:

Even if you’ve spent a lot of time putting together a very comprehensive problem description written in a Microsoft Word document, please ensure that there are a few lines in the case description in clear text that outline the main issue, rather than simply writing “see attached document”.

This will allow us to more quickly route your case to an appropriate Engineer. This is part of the normal case SCOPING process we follow here at Microsoft Support.

 

2. AX build numbers

These are a must. We need to know your AX kernel build and your AX application build. We may also need more insights into individual fixes you may have installed.

To check your current AX builds, go to:

AX CLIENT / HELP / About Microsoft Dynamics AX

 

3. SharePoint build number and edition (Foundation or Server)

This is a must. As AX Enterprise Portal is a SharePoint application we need to know the current SharePoint build.

To check your current SharePoint build, go to:

SharePoint Central Administration / System Settings / Manage servers in this farm

You will see the build number in “Configuration database version:” and the edition under “SharePoint Products Installed”.

A screen shot from Servers in Farm will be of great help (like below):

4. AX environment

Enterprise Portal issues may come from environment issues or misconfiguration, so an overview of the AX environment is important for the troubleshooting.

Provide the following info:

  • Web/Enterprise Portal servers:
    • Windows version, how many servers and the role of the servers (Central Admin/Web Frontend). Screen shot as in point 3 will be of great help here.
    • Specify any firewalls and load balancing configuration.
    • Specify user authentication (Windows/Forms/ADFS etc).
  • AOS Servers:
    • Windows version and how many servers.
    • Specify any AOS cluster/load balancing configuration.
  • Database servers:
    • Windows version.
    • SQL version.
    • Specify for both SharePoint DB and AX DB if they are on different servers.

 

 

5. Logs and diagnostics

Event logs:

For troubleshooting it is important to review the full event logs for any messages at and prior to the issue occurs.

Provide the Application and System event logs from the Web servers and AOS servers. Save the logs as .evtx files please.

SharePoint logs:

We would need also the SharePoint logs from the web Server from the time where the issue occurred (or all logs), these are located typically in the Logs folder under SharePoint file path (12,14 or 15 in the path depends on your SharePoint version)

(System Drive):Program FilesCommon FilesMicrosoft SharedWeb Server Extensions15LOGS

IIS logs:

The IIS logs for the actual timeframe (or all logs) found in C:inetpublogsLogFilesw3svc<SiteId for EP> (to find the SiteId open IIS Manager and select the Sites folder).

Automated Diagnostics:

When you create the support incident you will be asked to run a diagnostics package. Please run this on the affected web servers. It will collect info about the environment and setup. When uploaded to Microsoft it will run an automated troubleshooting to check for known issues.

Why we are requesting diagnostics: https://blogs.msdn.microsoft.com/axsupport/2013/02/07/why-is-microsoft-support-requesting-diagnostics-and-how-is-my-data-handled/

More about Diagnostics: http://blogs.msdn.com/b/emeadcrmsupport/archive/2013/04/24/diagnostic-automation-tools.aspx

During scoping or troubleshooting we might ask you to run additional diagnostic packages. For Enterprise Portal issues we usually use these diagnostics:

Enterprise Portal diagnostics: https://support.microsoft.com/en-us/kb/2974699

SharePoint Diagnostics: https://support.microsoft.com/en-us/kb/2793381

Dynamics AX baseline diagnostics: https://support.microsoft.com/en-us/kb/2181934

 

 

6. Enterprise Portal performance

Performance issues on Enterprise Portal can be caused by several components in the environment, like web farm configuration, network configuration, code issue, SQL issue etc. So if you report Enterprise Portal performance issue, then it is important to know the following in order to determine the next troubleshooting steps:

How long time does it take to get the requested page?

What is acceptable response time?

Do the users see performance issue on all pages in Enterprise Portal?

If not all pages, then specify which page/function.

If the users do the same action in AX client, do they see the same performance issue?

If you run Enterprise Portal in a browser running on the web server, do you see the same performance issue?

Do all users see the same performance issue?

If not all users are affected, then specify what is the difference between the affected users and not affected users.

If you are experiencing general performance issues, you should take a look at these blog posts first:

Managing general performance issues in Microsoft Dynamics AX: https://blogs.msdn.microsoft.com/axsupport/2014/09/11/managing-general-performance-issues-in-microsoft-dynamics-ax/

What info is needed: https://blogs.msdn.microsoft.com/axsupport/2015/09/28/ax-performance-what-information-and-data-to-collect-when-you-want-to-open-a-support-case/

 

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址