Spend by Procurement Category SSRS Report error

Many reports in Dynamics AX 2012 use the SQL Analysis Services database/cubes to process and analyze data. While you may have deployed your base reports successfully and the majority of them work, you may run into issues with these reports which utilize SSAS to present data.

This focuses in particular in the Procurement and Sourcing module in AX 2012 > Reports > Statistics > Spend Analysis reports. These contain several reports which analyze and present data through SSAS. We ran into an issue in particular with the Spend by Procurement Category SSRS report. Although the users had AX security to access this data, they ran across an error when attempting to run this report in AX.

We found that was actually a product of SSAS security, and not AX security.

Solution:
Go to your SSAS server and add users/AD groups to the required role in the SSAS database, making sure to give at least Read access and possibly drill-through access to the cubes necessary. This should allow users to run the report(s) from AX.

The Technet link below gives more description on this security:

http://technet.microsoft.com/en-us/library/aa570082.aspx

EP Issue: The webpage cannot be found

Periodically you may run across an issue in Enterprise Portal where a user opens a screen or clicks on a button and a HTTP 404 error box appears saying something to the effect of 'The webpage cannot be found'.

This can mean that the actual web page definition has been removed from EP somehow. We have found that if security is not set in a specific way in Enterprise Portal, a page could be inadvertently deleted through the portal itself.

Solution:

1. To identify the web page definition that is missing, right click on the error dialog screen and find the URL of the page. Since it is generally a pop-up box/window, it will not show up in the web address header. That URL will tell you the page definition in question. You want to find the name of the definition that ends in '.aspx'. This could be 'TrvItemization.aspx' for example. 
2. Go to the AX development workspace > open the AOT > Web > Web Files > Page Definitions and find the object with the same name from step 1. Right-click on the object and Deploy Element. It should give you an infolog saying it was successful.
3. Once deployed, go to the EP server itself where the webpage is hosted and do an IISRESET. 
4. Re-enter EP and try again to see it is resolved. 

How to avoid:

1. To avoid this issue, make sure user security on EP is set appropriately to only allow Read access for general users. Even 'Contribute' access can lead to inadvertent deletion of these pages. 
2. If your users need to be able to interact with Sharepoint to add documents to a shared library that shows up in AX role centers, you can limit this Read access to the EP folders/objects only. 
• Go to the EP link you want to lock down (for example: Expense page) > Site Actions > Site Permissions > All Site Content > click on Enterprise Portal folder > Library (top) > Library Permissions > Select the AD group to edit > Edit User Permissions > change to 'Read' > click ok. You will need to 'Stop inheriting permissions' from the higher level EP security.
• This should still allow users to interact with expense reports (or the EP function you are limiting access to), while not allowing deletion of any pages inadvertently.

EP Issue: The User Control *name.ascx* has caused a compilation error.

Continuing with EP deployment issues seen during an implementation and deployment to higher environments; an issue can occur where an error occurs within Enterprise Portal on various commands and processes that says:

'The User Control *name.ascx* has caused a compilation error. To view the details about this error, enable debugging in the web.config file or view the Windows event logs.'

This issue is caused by a similar problem we covered in a previous post (EP Issue: Web Control is not deployed)

An example where this can be encountered is on creation of a new Expense Report line. This boils down to missing files in one of the EP folders on the Enterprise Portal web server. These files are located at 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Template\Layouts\ep'.

Solution:

1. Copy the files from a working EP environment from the folder and paste them into the environment folder that is not working. Obviously take backups of everything before doing any of this. 
2. Run IISRESET on EP server

EP Issue: The Web Control *name* is not deployed. Verify that the Web Control is listed in the AOT

In preparation for a go-live of Dynamics AX 2012, part of the process is moving your current/tested Model Store up to Production during cutover (or some time shortly before). This also requires a re-deploying of any Enterprise Portal enhancements you may have made.

However, there is a possibility that during this deployment and subsequent testing, several issues can arise on your Production EP portal for various pages. EP can seem like a bit of a black box when it comes to these error messages but one in particular we encountered that has an easy solution.

After a deployment, users accessing Enterprise Portal could encounter a message at the top of the page which says:

'The Web Control *name* is not deployed. Verify that the Web Control is listed in the AOT'.

The reason for this issue is technically given by the error, although you may have actually run the deployment of EP from System Admin > Setup > EP > Deployments. The problem is that in some scenarios, it has been found that this deployment will NOT deploy all controls, and in fact will remove/replace any that are out there, which could lead to a much smaller number of files generated/deployed to EP than there should be.

The scenario we ran into was that the full deployment of EP web controls actually removed the current Proxies files and replaced them with new ones, but did not create all as intended. The deploy ended up generating about 329 files, instead of the expected 1,312. This is the reason for the error.

To check this, go to the server where Enterprise Portal is installed (where the website sits). Check the 'C:\inetpub\wwwroot\wss\VirtualDirectories\33456\App_Code\Proxies' folder. Your port number may be different depending upon your setup/installation. Just do a quick look at the file count in that folder (usually bottom right of folder when open). Then compare that count to the same folder in one of your EP servers for an environment where EP works. The good one should have many more files than your 'bad' one.

Solution:

1. Copy all of those Proxies from the working environment folder and paste them into the folder for the offending environment. 
2. Perform an IISRESET on the EP server
3. Re-open EP and it should be resolved. 

*Note: Save a backup of these folders/files externally in case the issue occurs again

Enterprise Portal in a multi-AOS environment

Scenario: A client has multiple AOS servers in their environment and you, as the system admin, have set up their cluster configuration in a way so that all of them are well-utilized. Some of the AOS servers are set as 'Load Balanced' which users will hit with their AX clients to spread the load, while others are set to 'Non-Load Balanced' and used as dedicated batch servers. (see Dynamics AX 2012 Cluster Configurations)

This client is also using Enterprise Portal. Perhaps for time and expense, purchasing, etc. However, periodically they see random timeouts, Error messages, etc. Some times a page will work, but when they click a button or refresh their view, suddenly an error appears or 401 web error.

One possibility is that your Enterprise Portal instance is pointed at a Load Balanced AOS server in your cluster. EP points to ONE AOS server, and that is defined at EP install time. Many times during installation of EP, installers will point at AOS 1. And often times, AOS 1 will be a user server (Load Balanced). Enterprise Portal does not like being pointed at a Load Balanced server. What we have found is that when EP is installed pointing at a server that ends up designated as Load Balanced, is that a user may be able to open a web page just fine at first in EP, but when they click somewhere or refresh, suddenly there is an error. We believe this is due to EP hitting a load balanced server when page is opened (AOS 1), then a button is clicked or refreshed and it ends up getting AOS 2 on that next call to AX (load balanced, remember?). EP gets confused and doesn't remember where it started from initially, then gives up.

Upon install of EP, point it specifically at a server you know will be a Non-Load Balanced server in your cluster configuration. This will avoid the problem. If EP is already pointed at a Load Balanced server, you can either move around the cluster configurations for that AOS, or need to reinstall EP.

Dynamics AX 2012 Cluster Configurations

If you have dealt with larger scale implementations of AX, you have likely installed multiple Application Object Servers for a single environment. With that, comes decisions about how those AOS servers should be utilized. Each client's project will have their own special set of circumstances which will determine how these multiple AOS servers should be utilized, but there are really only two options on the cluster configuration within AX for these servers.

1. Load Balanced
2. Non-Load Balanced

The trick is understanding all of the activities that will be performed by the client using AX. Will the client be doing most of their work manually within the AX client without much in the way of automation? i.e. manually entering Sales orders, purchase orders, planning, etc. Or will they be utilizing the batch functionality of AX heavily in areas such as AIF imports from outside systems for transactions, master planning, warehouse systems, etc. Once you have a good feel for the separation of Automated vs. Manual, that will help you decide the best Cluster Configuration of your AOS servers within the AX application. 

If the client is going to be more manual and fewer integrations/batch jobs, set up at least one of the AOS servers as Batch enabled and 'Non-Load Balanced' in the cluster configuration (System admin module). This will stop users from connecting to the batch server with an AX client. The rest of the AOS servers can be set to 'Load Balanced'. We like to separate user servers from servers that batch jobs run on. There are a lot of reasons for doing this which most technical AX admins will know but mostly they have to do with segregation of responsibility in your AOS cluster. If an AOS's system resources get tapped or crashes, the first piece of evidence for troubleshooting could be taken care of immediately (in most cases) where you would know if it is User created issue in the client, or a batch job issue that caused it. 

If the client is going to have a lot of integrations with outside systems and the bulk of their transactions will be imported (i.e. sales orders, purchase orders, warehouse trans, financial uploads, etc.), you would want to lean more heavily on setting up Non-Load Balanced, batch enabled servers, at least 2 dedicated. Ultimately a single AOS can support many user sessions, but having batch jobs on user AOS servers can lead to some issues, especially at peak transaction time. Remember you can always change these settings on the fly inside AX without restarting AOS services. Keep in mind you can also set a Load Balanced server that users can connect to as a batch server as well, and then set the server to ONLY do batch jobs during the evening hours, leaving the daytime for users and nighttime for typically heavy nightly processes (invoicing, planning, etc.).

Ultimately, if a client has purchased multiple AOS licenses, segregation of responsibilities is the way to go so they get the best bang for their buck. 

AOS crash when attaching a receipt to Expense Report in Enterprise Portal

During an AX 2012 R3 installation, an issue was encountered when testing the Expense Reporting functionality through Enterprise Portal. A user could enter an expense report just fine, however once they attached a receipt to the report, Enterprise Portal would go down and be unavailable.

The AOS service which EP was pointing at crashed as a result of attaching a receipt to an expense report. What we found was that the 'Enable the hot-swapping of assemblies for each development session' checkbox was CHECKED on the AOS Server Configuration. Once a new Server Configuration was created with this checkbox off and AOS restarted, the errors no longer occurred.