Disclaimer: You won’t find this in the official documentation. It is based on my(Brandon Ahmad) opinion and experiences only from a real life abbreviated specification that I wrote for a client for their SharePoint team, which details how I wanted SharePoint 2013 setup for AX, so as to allow AX to do everything that it does while not compromising performance or troubleshooting. Not everyone will agree with me, but I stand my opinions. I’ve tested these recommendations out and had a lot of success with very good feedback from clients.

Story: This client was just starting to discover the benefits of Dynamics AX and SharePoint 2013, and I didn’t want to overwhelm them by bringing too much too early. I wanted something that left the core features enabled for AX in a performance and troubleshooting friendly way while allowing for easier updating layer. Below is a real-life document that I had written for an assignment. Note, this document was prepared for the SharePoint 2013 Team only. I made another document later for the Dynamics AX team where we went into the AX specific hook-ins once we got the infrastructure right. .

Unfortunately, the AX specific configuration differs widely depending on your companies functional uses of AX – example, are they using vendor catalogs, do the approve workflows from a website or only the client, are they hooking AX content into other content, what kind of data needs to be shared outside of AX, which users would prefer to use SharePoint forms or SharePoint workflows instead of AX workflows (Yes, there is a way to run SharePoint 2013 workflows over AX), are they using SharePoint’s record management functionality for AX document management, should SharePoint serve as a primary list, is the client more of a financial shop or a warehousing shop in terms of AX SharePoint usage.. You get the point. All of this will deeply impact how you design Enterprise Portal.

Comments are in Italics for the Document that I am posting

—————————————————————————————————————————————————————————————————————————————————————————————————

SHAREPOINT SETUP – WEB APPLICATIONS AND SERVICE APPLICATIONS:

I recommend at least 3 Web Applications for your Enterprise Portal Setup. One web application will be specific for Dynamics AX Enterprise Portal. I’ll list the recommended Service Applications. I list with Samples Names here for the web applications.

The default AX application runs in compatibility mode. In the Dynamics AX web application, I enable all the services necessary to get Enterprise Portal functionality. I like them separated so that I can isolate them, troubleshoot them better and control resources. Because this Service Application will actually post live data to AX, I’m very careful on how much I enable on it.

In the second site, AX DATA, I run a full blown SharePoint 2013 site with all of the new features of SharePoint 2013. This setup will allow for users to really Share the AX data with the rest of SharePoint. It really is the bridge between AX and the rest of our SharePoint data. One thing that I like over here is visio services. I really love the way that visio services adds process based graphs which can provide a real-time, updated view of what is going on in an organization like nothing else.

Finally, I include the MySites. This is becoming especially big in user management. I like it for HR notifications, keeping up with contractor details, and keyword functionality that will keep all people in the company (and others outside of the company) connected.

SEARCH TOPOLOGY:

I went with a standard Topology here good for most medium sized companies. Bigger companies will require an adjustment. For smaller companies, I still like this topology. It’s relatively inexpensive and can be scaled out quite easily. Plus, it gives us the ability to control the way that SharePoint search hits our AX database – something very pivotal for Enterprise Portal Performance.

When it comes to Search topology, there is nothing special about AX. The same best practices for setting up a SharePoint topology apply. AX search performance is completely dependent on SharePoint 2013 Search Topology. In other words, default topology with all components on one machine will work in the beginning, but not after a few months. Here is an extremely common topology for SharePoint 2013 search:

[ 2 Server Topology Note: will need 2 more servers for fault tolerance (not shown)]

Keypoints:

1. The content processing and analytics components should be on the same server (or vm)
2. The administration and crawl components are also together on the same server (or vm)
3. Index and Query are best on a separate server so that you can

Search Hardware:

There is nothing special for AX here. The standard 80GB Hard disk and 500GB additional disk space, 16GB of ram are recommended just as they are for other components. For guidance, I recommend visiting here(again, I apologize as you have probably already seen this):

http://technet.microsoft.com/en-us/library/jj219628

Configure Crawl Schedules:

1. You cannot use the new SharePoint 2013 continuous crawl functionality on the site for web application Dynamics AX
2. Note: Dynamics AX requires that SQL queries are run before data can be crawled.

This crawl schedule differs slightly from the default setting, and I will discuss my reasons for this during the meeting.

Note: all content must be published through Dynamics AX first. This is the responsibility of the AX Administrator.

Query Rules and Managed Properties:

Both of these topics offer a tremendous amount of enhancement. However, they are time consuming and beyond the scope of this meeting. I’d certainly see some benefit to revisiting this as the implementation matures.

[NOTE: When I architect, I have to adapt to my client’s implementation. I am 1000% about setting up Query Rules and Managed Properties. They are an extremely advantageous component of SharePoint that is often ignored. But companies have to start somewhere first. I wanted the SharePoint architecture right before I got deeper into the good stuff].

Need Further Guidance on AX Search:

Further guidance can be found here including a checklist:

http://technet.microsoft.com/EN-US/library/gg731811.aspx

DIAGNOSTIC Configurations:

Here what I aimed at was preparing SharePoint to aid AX in troubleshooting all the things that can happen in Enterprise Portal. I don’t like Event logs with too many options. At the same time, it is extremely important that we monitor things like usage over time, so that we can make projections on traffic. And there are plenty of times where we have to put together the puzzle when we see a problem with Enterprise Portal. I felt like this configuration gave us that medium line of good information but not too much information for this particular client.

Again, many of these recommendations have probably already been done

1. Please move the ULS logs of the C:/ drive to a shared drive where AX Administrators will have access to them
2. Please ensure that all AX administrators have access to ULS Viewer Tool
3. Recommend Setting the least critical event to “Warning” Status for the event log and “High” for the trace log.

   

4. At the very least, monitor all service applications, plus SharePoint Server (but this is subjective).
5. For our Usage and Health Data Collection settings, I recommend the following (to be discussed in meeting). Also, running these timer jobs during the default daily(1AM – 3AM) should be fine depending on feedback from the SQL team.

   

   End of Document