Saturday, August 30, 2014

Permission error when setting up additional SSRS instances

Perhaps you read my article on setting up additional SSRS instances and now you notice each time the Report Server instance is restarted it causes reports to throw a weird error like this:

"Error while setting server report parameters. Error message: The DefaultValue expression for the report parameter 'AX_CompanyName' contains an error:"

You can reproduce this by restarting the SSRS instance and try run any report. The first time it fails, but the second run goes through ok. Now, we can't have that can we?

Back in 2012 Microsoft blogged about this issue and the solution so far is to make some minor adjustments on one of the configuration files.

So let's try that and see if that fixes it.

Head over to the location where the rssrvpolicy.config file is and see if you can open and edit it. My preference is NotePad, but any text editor will obviosuly work.

This file may contain a lot of content, so try search for "Report_Expressions_Default_Permissions" and you should only find one occurrence of that test. Now the value you're looking for is "Execute" and you want to change that to "FullTrust".

Save the file and restart SSRS. Head back to AX and observe the reports run perfectly on the first run!

Good job!

Setting up multiple instances of Report Server for AX2013 R3

The documentation for setting up multiple SSRS instances covers the steps I will illustrate in this post. I did this on AX2012 R3, and in this version it is made a bit easier due to the new PowerShell command for setting up the SSRS configuration files. If you're using a version prior to AX2012 R2 CU7, I highly recommend using the freely available PowerShell scripts from this codeplex project.

Let's begin!

So I prepared by installing three named instances of SSRS, running SQL Server Setup for each instance.

Furthermore I completed the initialization of each of them by making sure they all run under business connector proxy account and had the databases and sites ready.

Next I ran AX2012 R3 Setup and installed the Reporting Extensions, which would make my first SSRS instance prepared for reporting. I opted for having the reports deployed as well.

However, the remaining instances remain without a complete configuration, so let us go ahead and prepare them as well.

Using the PowerShell command introduced after AX2012 R2 CU7 makes this easy. Simply open the Dynamics AX 2012 Management Shell and run this command:

Install-AXReportInstanceExtensions –ReportServerInstanceName AX2012_DEV -Credential contoso\daxbc

Notice that after running this command, the configuration files will be modified and they will have the necessary changes to support Dynamics AX reporting.

Run the command for all the additional instances you're setting up.

So how will each instance know what AOS they bound to? We will drop an AX configuration file into the bin-folder for each Reporting Server. The guide tells us the file needs to have a specific name, Microsoft.Dynamics.AX.ReportConfiguration.axc, so all you need to do is to either create a configuration file or pick one you've already made earlier.

I always create configuration files for all environments, so I just copied the appropriate file for each environment to the bin-folder and renamed it according to the instructions. If you have to create new configuration files using the Dynamics AX Configuration from Administrative Tools, just make sure to leave it pointing at the first original configuration when you're done. If you remember, it was pointing to the same AOS as your first SSRS instance was, and you want to keep it that way. :-)

Notice the filesize. Typically if I see a configuration file that is less than 5kB, it tells me that file does not have an updated WCF-configuration. You know the huge chunk of XML that holds the WCF-configuration inside the AX-configuration file. You really want to make sure your configuration file has a proper WCF-configuration before you continue.

Finally restart the Report Server instances and they should be good to go.

Before deploying reports, you should prepare the settings inside AX. Open a client to each of the environments still missing reporting. Head over to System Administration, Setup, Business Intelligence, Report Services, Report servers. Either create a new configuration or change the one already there. My extra environments where copies from other environments, so I simply changed the existing one. Make sure it points to the right SSRS instance, has the right URLs and is associated with the right AOS (at the bottom of that dialog - so scroll down). If the settings are correct, you should be able to press the "Create report folder"-button and observe the folder be created successfully. That is a good sign! You're ready to deploy reports now.

Deploying reports is just a matter of running another PowerShell command. The whole process may take a while, so spend the time documenting your work and feel good about your achievement.

Publish-AXReport -ServicesAOSName MYAOSSERVER -ServicesAOSWSDLPort 8103 -ReportName *

Notice the name of the server running the AOS is used, along with the WSDL-service port. You'll find the correct WSDL from the Dynamics AX Server Configuration under Administrative Tools on the AOS server.

Finally, you can test the reporting by opening a client, and try run any of the reports under System Administration, like the "Database Log". Don't worry about the report not having any data, as long as it loads.

If you encounter any issues or problems, feel free to comment on this post, or head over the community site and post your concerns on the forum.

Wednesday, August 20, 2014

Upgrade Management Reporter 2012 for ERP

So you installed Management Reporter and have it running like expected. And then later down the road you've been asked to apply the latest (cumulative) upgrade. If you, like me, installed Management Reporter using AX2012 Setup, you will notice the Management Reporter upgrade story involves using Management Reporter Setup, and not AX2012 Setup experience.

No problem! This post by Jill Carter on MSDN Blogs explains the highlights, and I will show you some screenshots from the process. Without any hick-ups this upgrade should over in less than an hour, at least the server bits.

First head over to download page and grab the latest setup with the latest updates. You'll find an upgraded version of the documentation from there as well. At the time of writing this post, the latest documentation is from May 2014. Run, extract and run setup.

Upgrade the Server Components

As Jill explains, you need to upgrade the server bits first, so choose the Server install and run through the setup that will upgrade the services for you. After it is complete, let it open the configuration console as recommended. I highly recommend using the same user for upgrading as you used when you installed in the first place. That way the permissions should already be the properly defined and you won't get into trouble.

When the Configuration Console has loaded you will notice in the bottom left hand side the "tasks" necessary to complete for Management Reporter to be ready on the latest updated version.

So click the "Update the Management Reporter database"-text and let it help you upgrade the database schema to the latest version. A dialog will pop up and you should be able to update the schema in the context of your current user. Hit Update and wait.

Next click the final task to make sure the integration to the Dynamics AX transaction database is correctly updated. First you will provide the credentials to the Management Reporter integration user. If you remember when setting this up to begin with, you needed to have a dedicated account for Management Reporter and this account would be injected as a user within AX. Dig up your documentation and provide the credentials.

Secondly it will ask for credentials for updating the Datamart database schema. Using your current user should be sufficient.

After it is complete, start the Processing Service and open the logs for the Data Mart Integration. You may need to wait a couple of minutes and hit refresh just to have a check if things look promising (as in no horrible errors).

Upgrade the Client Components

Next we will upgrade the client bits, and I tend to install them on the same server as the server bits so I can test and see things look like expected before I install client bits on terminal servers or client machines.

Unless you closed the Management Reporter Setup, you can continue just by clicking the Client install and run through that simple upgrade process.

And again, finally open the designer and check the version number and test any reports if that is your swag.

In order to upgrade the clients, you will redo the client upgrade on any necessary client machine or terminal server, but as you just saw it was a quick and easy experience.

The upgrade I just showed you was CU9 which contains a lot of new and improved features. If you installed Management Reporter using AX2012 R2 Setup which came with CU7, you are most likely on Management Reporter CU7 and you should really consider upgrade to the latest version. Obviosuly, AX2012 CU is not the same as Management Reporter CU - but you knew that already.

Tuesday, June 10, 2014

Synchronization error when setting up AX2012 R3

This will be a quick post on an error I had when setting up a fresh AX2012 R3 installation. I was getting a bit ahead of myself and got stuck with an error when synchronizing the database.

And to help search engines find this post, the error in clear text:

Cannot create a record in Inheritance relation (SysInheritanceRelations). MainTableId: 12345.
The record already exists. 

The error is due to the fact that I didn't restart the AOS after compiling the application. Lesson is; don't rush and do it the right way the first time.
Furthermore, if you DO get stuck, try do a quick search on Life Cycle Services for a solution:

Restarted the AOS and continued the installation.

Thursday, June 5, 2014

Delete Company in AX 2009 using SQL

One of the potential tasks when upgrading to a new version of Dynamics AX (like from AX2009 to AX2012) is getting rid of obsolete companies. Microsoft shared a SQL for this a few years back. I enhanced it a little bit and added some additional statements.

Just one important remark - DO NOT RUN THIS AGAINST AX2012!

In the interest of sharing, here it is:



 Inspired by:

 Tommy Skaue



    AND A.FLAGS = 0



 PRINT (CHAR(13) + 'Removing ' + @_COMPANYID + ' from ' + @_TABLENAME + '...')

PRINT (CHAR(13) + 'Finalizing...')
PRINT (CHAR(13) + 'Done!')

Use at own risk (of course), and let me know if you find any issues with it.

Saturday, May 31, 2014

Start and Stop your AX2012 R3 Azure Demos using PowerShell

There are tons of blog posts covering how to use PowerShell to control your Azure components, services, machines, etc. Once you download and install PowerShell for Azure and try it yourself, you see how easy you can manage Azure by running some simple commands. This post is here to help you AX'ers who have already started playing with Life Cycle Services and Cloud hosted AX2012 R3 Demos. You should be aware that each demo you create will cost money while it is running, so here is a post on how you can easily start and stop them using simple scripts instead of doing it through the Azure management portal.

I am going to assume your user is admin or co-admin on Azure, or you at least have credentials for such a user. I'm also going to assume you've downloaded PowerShell for Azure and installed it.

Start by opening PowerShell for Azure.

Run this command to authenticate for the next 12 hours:


You will be prompted for credentials, and you need to provide the same credentials you would be using if you were authenticating against Azure.

Use this command to Start demos:

Get-AzureService | Where-Object {$_.Label -match "AX2012R3"} | `
Foreach-Object { Start-AzureVM -ServiceName $_.ServiceName -Name "*" –Verbose }

If you change the filter part ("AX2012R3"), you could control a subset of your services based on some naming pattern or convention.

Use this command to Stop the demos:

Get-AzureService | Where-Object {$_.Label -match "AX2012R3"} | `
Foreach-Object { Stop-AzureVM -ServiceName $_.ServiceName -Name "*" –Force –Verbose }

Isn't that cool?

Now for the bonus part. When you create these demos, you access them through RDP-files. Here is a PowerShell command to download the RDP-files and save them to disk:

Get-AzureService | Where-Object {$_.Label -match "AX2012R3"} | `
Get-AzureRole -InstanceDetails | Where-Object {$_.RoleName -Match "DEMO" } | `
Foreach-Object { Get-AzureRemoteDesktopFile -ServiceName $_.ServiceName -Name $_.InstanceName `
-LocalPath (Join-Path "C:\Temp" ($_.InstanceName + ".rdp")) }

Pretty neat, ey? :-)

Monday, April 28, 2014

Upgrading AX2012 R2 to AX2012 R3

Dynamics AX2012 R3 is just a few days away, so I am thrilled to share some information around the upgrade story from AX2012 R2 to AX2012 R3. I realize most people will probably upgrade from RTM or pre-AX2012, but there might be a few of you who plan to upgrade from R2.

The upgrade story from AX2012 RTM (R0/R1) will be more or less the same as when upgrading to R2. The significant part was the fact the entire Dynamics AX Database was split in two, one database for business data and one for the application (aka Modelstore).

What is interesting with the R2 to R3 upgrade is that we now have two databases to begin with. Microsoft has solved this by doing the following:

1) Create a R3 Upgrade Baseline named YOURDB_UpgradeR3Baseline
2) Export the R2 Modelstore to disk
3) Import the R2 Modelstore to the R3 Upgrade Baseline
4) Replace all the Microsoft models in the actual modelstore with new shiny fresh R3 models!

From there you have more or less the same upgrade story as you would have when upgradring RTM to R2 or R3. The story is divided in two stages:

1) Code upgrade
2) Data upgrade

If you've done R2 upgrades, you will remember that code upgrade is recommended to do this in a isolated environment. It doesn't have to be on a dedicated server, as long as you know how to keep the environments separated. The code upgrade should be done on a copy of the newly configured R3 Modelstore, and the whole idea is to make sure you end up with an upgraded R3 modelstore that keeps the element IDs. Otherwise, you'll end up with having to start over.

The key thing to understand here is that setup will install and replace the Microsoft models in SYS and SYP (plus some other MS layers if applicable). You will need to have R3 compatible ISV models before you start. Your job will be handling the rest of the layers.

The code upgrade is done in a cyclic manner, and the upgrade guide explains it beautifully;

1) Import modelstore
2) Delete top most layers
3) Upgrade current layer
4) Export current layer models
5) Back to step 1 and start working on next layer.

You will do this from the VAR-layer, through CUS and finally USR.

One of the new features in R3 is the improved Code Automerge feature, and for this you will need to install the Team Explorer for Visual Studio 2012. It is not part of the prerequisites as of this writing.

Just to give you an idea on what you can expect when installing R3 during an in-place upgrade, I will provide some screenshots.

I will assume you've duplicated your R2 databases and you've prepared a new server. Obviously you won't be able to mix 6.2 dlls with 6.3 dlls, so you need a new server in order to do the in-place upgrade.

First you choose a Database upgrade:

You then choose to Configure an existing database:

You point to your prepared, but yet not upgraded R2 database. Do not fill in Baseline, because Setup will make one for you.

You will need to provide a location for where the exported modelstore from R2 will be saved.

When this part is completed, you will install the AOS, a Client, Debugger and Management Utilities - all tools necessary for compiling. The debugger will be used for the code upgrade part. Remember I chose to do both the code and the data upgrade on the same server.

Now, I did select the newly created R3Baseline for the first AOS installed, but only to show you the naming convention Microsoft used for the database. The baseline database comes to play when you are in the code upgrade phase. So I did eventually reconfigure my second AOS to use the baseline when I upgraded my layers to R3.

Finally, you define the Instance and ports.

The upgrade for AX2012 is pretty intense, and a lot of steps and details to remember. Lucky for us, the current upgrade guide is very well written and guides you through the process. I expect Microsoft to publish a comprehensive whitepaper for the R3 upgrade story, covering both source to target upgrades, but also RTM and R2 to R3 upgrades. Take the time to read it and understand it. And if you have questions, don't be afraid to ask on the community site.

Finally, I just want to add there a many neat new things in R3 from the technical perspective, so get excited. :-)