SSRS 2008 Setup Option for Dynamics AX 2009
With deploying Role Centers, and specifically around SQL Server Reporting Services (SSRS) 2008 for Dynamics AX 2009, we have seen all kinds of existing whitepapers, blog entries, etc. That help get Role Centers up and running.
Reporting Services is a part of the underlying technology that enables Role Centers to work.
With Dynamics AX 2009 and SQL Server 2005, as part of SSRS setup we had the IIS Pool Identity that we set to the .Net BC. We also had to setup an execution account that the Reporting Service executed under, and that had correct Kerberos Security SPN's created.
With SQL Server 2008, Reporting Services, we no longer have a SSRS site in IIS, and therefore no longer an AppPool identity to set for the .Net BC. What does you do then?
Well if the .Net BC account is also your execution account for SSRS, what the service 'logon as' is set too, then your fine. However what if you Want a seperate account for your .Net BC, that is different from the account used for esxecution of the Reporting Service?
This is where the execution account, in the Reporting Services comes into play. Wait though!
In the setup, have we not seen where when this is set, we see issues with Role Centers, specifically SSRS based web parts not working? Yes, but with SQL Server 2008 Reporting Services, and this desired setup, then we have to supply the execution account be that of the .Net BC.
Doing so enables us to have a seperate account for the execution of the SSRS service, that is different from the .Net BC account, while still enabling Kerberos security work and Reporting Services Web Parts to be fired correctly that point back into Dynamics AX.
So in short.:
"Visit the Dynamics AX Community Page today!"
Reporting Services is a part of the underlying technology that enables Role Centers to work.
With Dynamics AX 2009 and SQL Server 2005, as part of SSRS setup we had the IIS Pool Identity that we set to the .Net BC. We also had to setup an execution account that the Reporting Service executed under, and that had correct Kerberos Security SPN's created.
With SQL Server 2008, Reporting Services, we no longer have a SSRS site in IIS, and therefore no longer an AppPool identity to set for the .Net BC. What does you do then?
Well if the .Net BC account is also your execution account for SSRS, what the service 'logon as' is set too, then your fine. However what if you Want a seperate account for your .Net BC, that is different from the account used for esxecution of the Reporting Service?
This is where the execution account, in the Reporting Services comes into play. Wait though!
In the setup, have we not seen where when this is set, we see issues with Role Centers, specifically SSRS based web parts not working? Yes, but with SQL Server 2008 Reporting Services, and this desired setup, then we have to supply the execution account be that of the .Net BC.
Doing so enables us to have a seperate account for the execution of the SSRS service, that is different from the .Net BC account, while still enabling Kerberos security work and Reporting Services Web Parts to be fired correctly that point back into Dynamics AX.
So in short.:
- You can have a seperate account that runs the Reporting Service, that is different from the .Net BC account.
- In SQL Server 2008, no AppPool identity to set.
- Instead of AppPool identity, setup the Execution Account as the .Net BC account.
After having correct Kerberos Security, with SPN's setup, then this will enable the desired mentioned configuration.
One other point with SQL Server 2008 Reporting Services, do everything through the 'Reporting Services Configuration Manager'. This includes restarting the services, and setting accounts and settings. It's not recommended that you restart the Reporting Service, through the Service MMC. Doing so cause order of service startup actually to sometimes mess up.
That's all for now, but check back soon as more to come!
Labels: .Net BC, Dynamics AX 2009, Microsoft, Quick Tip, Reporting Services, Role Centers, SQL Server 2008, Web Parts
posted by brandon | 4:27 PM
1 Comments:
Interesting! :-)
Could you also do a (re)post on when Kerberos is needed, and why it is needed. The Whitepaper explains a lot, but perhaps you can explain it with your words. :-)
Post a Comment
<< Home