AX 2012 R2 - Minor issue (Startup Procedures SQL Server)

Most technical resources working with AX 2012 R2 are probably aware of the fact that AX deploys a Stored Procedure to the Master database to grant permissions to TempDb to the Service Account hosting tht AOS Service (instance). This is necessary since TempDb is created at startup, but be aware that the setup routine (AX AOS) adds one procedure for each AOS instance installed. Since these Stored Procedures are launched each time the SQL instance is started, it makes no sense to do this for each AOS instance. Let's say you have 10 AOS instances in Your environment utilizing the same Service Account. SQL Server will then execute the same statement 10 times during the startup sequence for the SQL Server instance. I discovered this by enabling Trace Flag 1204 and 1222 (records Dead Lock situations in the SQL Log).

Example (4 AOS instances, 1 on SQL Server used for full X++ compilation):

Stored Procedures created in the Master db:

 



Note that these Stored Procedures are identical if you use one Service Account for all AOS instances (would make sense to have one for each Service Account used).

Inside the Stored Procedure we find the following check:

if (@dbaccesscount <> 0) 

The variable @dbaccesscount holds the number of logins matching the Service Account found in TempDb. And it then grants the required roles for the Service Account if @dbaccesscount is not equal to 0... In my mind the criteria should simply be if (@dbaccesscount = 0).

You have the possibility to either change the logic (breaks the support rule?) or you could do like me and disable all except one of them. By disable I mean ALTER the procedure from launching as a Startup Procedure by running sp_procoption.

Again remember that You should have one Startup Procedure for EACH Service Account used, but it's not required to execute the same grant statement more than ONCE for each Service Account used.

Finally - Why bother? I like to have the systems clean and as efficent as possible, and it's not worth spending extra CPU cycles especially in virtual environments.

So long

AX 2012 R2 CU6 Enterprise Portal deployment on SharePoint Enterprise 2013, episode x

I guess I was lucky when I managed to successfully install AX 2012 R2 CU6 EP on SharePoint 2013... After this, we concluded that the first issue was solved (rememeber the missing method in class SRSReportHelper?) and a co worker went to a customer to do the install. Guess what? It failed with a new error (I'll update this post with the details later)!

After a lengthy support process with Microsoft trying all sorts of clever tricks (tweaks), we recieved a couple of hotfixes (both application and binaries) that finally solved the issue. I don't exactly know if it was a combination of the tweaking and one/all hotfixes, but my co worker finally managed to successfully install EP in two separate installations. And right now it seems that we are experiencing yet another issue (a little bit early to conclude).

The reason for sharing this, is to warn about going to customers without testing the installation on the exact same software combinations as on the customer side and that you are prepared to discover new issues. This burns a lot of time (impossible to estimate the number of hours required) and it does not make a good impression at the customer side (trust me - they expect that we are experts, but that's almost impossible with the current maturity of EP on SharePoint 2013). I regret to say this, but Microsoft must put more effort into this combination and provide much more information on TechNet on how to successfully install EP on SharePoint 2013. The current information is outdated and references needed KB articles (hotfixes) that in fact are included in CU6, but NOT DOCUMENTED IN the release notes for CU6!

I'm tempted to recommend choosing SharePoint 2010 if possible until Microsoft makes installing EP on SharePoint 2013 to a more enjoyable ride and maybe also update the site template to SharePoint 2013 (is still 2010). Field testing the compability with SharePoint 2013 is NOT the way to do this since both partner and customers are suffering big time.

All issues we have discovered are related to site creation (EP deploys fine without site creation during installation, but as soons as you try to create the site either after deploying EP or as part of the installation, it fails).

I will update this post or post a follow up when I have the details.

Follow up (November 5th 2013):

It seems Microsoft was lucky this time - no hotfixes was required and my collegue managed to get EP installed on SharePoint 2013 together with Microsoft support. We used AX 2012 R2 CU6 with binary build 6.2.1000.3198 released in September. I don't have further details about the magic configuration change done, but it seemed to be related to a combination of an SharePoint Update changing something around the requirements for the Claims Service. I have to look into the support incident to get to the details and right now, I'm too busy to dig into this.

What makes a good Dynamics AX Project Manager?

Not a technical issue this time, but something important to every implementation project - the Project Manager role...

I stumbled accross this while reading Dilip's blog on Dynamics AX and I thought this was worth sharing as a side step to all the struggle with hotfixes in AX 2012 R2, Enterprise Portal/SharePoint 2013, Load Balancing Services etc. :-)

Links:

• The Cognitive Blog - What makes a good Dynamics AX Project Manager?
• Pwc Blogs - The challenges of implementing Microsoft Dynamics AX (pdf)

AX 2012 R2 (CU6) - Analysis Services Wizard freezes when deploying a customized project

Microsoft has solved an issue where the Analysis Services Wizard in AX freezes when you try to deploy a customized project. I experienced this issue as resent as yesterday and after implementing the latest kernel hotfix (KB 2866383 giving build# 6.2.1000.1837), the wizard seems to work as expected.

This fix could be related to AX 2012 R2 in general and not only post CU6 (I don't have more information).

Expect some heavy CPU and Memory load when running the wizard in Update mode (watch the processes in Task Manager to verify that the AX processes is alive and running, and remember that the GUI in the AX Client still is single threaded and a 32-bit process).

AX 2012 R2 CU6 - Updated labels in the SYS layer (SYP)

A quick post explaining my approach based on several other posts in the AX community.

With regards to the "missing labels", it's all about making sure the AOS instance is stopped and started BEFORE you fire up the AX Client to perform the post actions after updating the Model Store. By doing this, you make sure that the label files are synchronized in the file system on the AOS server based on the newly updated labels in the Model Store.

So if You are faced with a form (The Model Store has been modified) showing only label ID's when launching the AX Client, close the AX Client and restart the AOS instance to force the synchronization. This was all I did to solve this.

Looking at the Event Log > Application, you should find an entry (Source > Dynamics Server nn, Event ID > 3002, Type > Information) with a description like this:

Object Server nn : One or more local label files are out of sync with the label files in the model store.

The AOS has copied the correct files to its local directory and the startup of the AOS will proceed.

Copies of files are made in: D:\Program Files\Microsoft Dynamics AX\60\Server\AXTech\bin\Application\appl\Standard\.

File(s) copied from the model store are: AxFPKar.ald;AxFPKcs.ald;AxFPKda.ald;AxFPKde.ald;AxFPKde-at.ald;AxFPKde-ch.ald;AxFPKen-au.ald;AxFPKen-ca.ald;AxFPKen-gb.ald;AxFPKen-ie.ald;... (truncated for better readability)

AX 2012 R2 CU6 Enterprise Portal deployment on SharePoint Enterprise 2013

This is a follow up on a previous post (AX 2012 R2 - Issue Deploying Enterprise Portal on SharePoint 2013).

It seems like KB 2851881 is the key to get the deployment to succeed and this fix is included in AX 2012 R2 CU6. The information in Enterprise Portal on Microsoft SharePoint 2013 [AX 2012]  seems to need an update after the release of CU6, since KB 2830441 (setup) and KB 2824690 (Claims Mode authentication) was not needed or actually included in CU6 (not described as part of the update). My guess is that KB 2830441 is included and that KB 2824690 is only needed in environments utilizing Claims based authentication.

After many hours of work, I was finally able to install and deploy Enterprise Portal on SharePoint Enterprise 2013 in a new environment based on AX 2012 R2 with CU6 slipstreamed (Windows Server 2012).

Short summary of the steps taken (bypassing details for all SQL Server services):

1. Install and configure AX 2012 R2 core solution with CU6 slipstreamed (complete initial check lists)
2. Optionally install and configure additional AX components (I included Reporting Extensions and Help Server in addition to the Client, Debugger and Management Utilities on each of the dedicted servers in my PoC environment consisting of many servers)
3. Install and configure SharePoint (see details below)
4. Install AX Client, Debugger (optionally) and Management Utilities (I met some new issues never seen before at this stage, but I solved this by manually installing the prerequisites)
5. Create new configurations and verify access to AX (a Best Practise of mine)
6. Install Enterprise Portal (I choosed to have the installer Configure and Create the Web Site) and wait until setup is finished (can take some time)

Details related to SharePoint

• Run the SharePoint 2013 Products Preparation Tool (separate program in SP 2013, account for several restarts of the server)
• Install SharePoint Enterprise 2013 (Complete, do not run the SP Products Configuration Wizard)
• Download KB 2767999 (March Update for SP Server that seems to be required or the minimum for AX 2012 R2 EP)
• Apply KB 2767999
• Download KB 2817414 (June Update for SP Server)
• Apply KB 2817414
• Run the SP Products Configuration Wizard (I used "Create a new server farm")
• Run the SP Configuration Wizard from Central Admin or manually configure the services you need (I used the Wizard approach and I didn't create the Site Collection at this step)
• Create the Site Collection (Team Site, SharePoint 2013 mode)
• Start the Claims to Windows Token Service (the AX Prerequisite Validation Utility gives a warning if this service is not running)

I should mention that I'm not an SharePoint expert...

Valuable sources

• Initial deployment administrative and service accounts in SharePoint 2013 (>)
• Install SharePoint 2013 on a single server with SQL Server (link) (>)
• Updates for SharePoint 2013 (>)

Proof (the message given in the light red area "Experience all that SharePoint 2013 has to offer. Start now or Remind me later" is expected, since the site template for EP is not yet updated to SharePoint 2013).

AX 2012 R2 Installation Issue AOS (Firewall)

I recently experienced a strange issue when installing a new AOS instance (AX 2012 R2 CU6) on Windows Server 2012 Standard.

Microsoft has described the firewall requirements for AX 2012 R2 on TechNet (Firewall settings for Microsoft Dynamics AX components [AX 2012]), but they seem to be missing one IMPORTANT rule allowing the new AOS to access the registry remotely, read/write to the Event Log and configure the databases (worth another post later). It took me a while to identify the exact rule to enable, but it was quick and easy to identify that the issue was related to the Windows Firewall on the database server  (by disabling the firewall in the Domain Profile). The missing rule is also depending of the roles and features You have promoted on the server, but in my case, the rule Remote Event Log Management (TCP 445) was Disabled. Enabling this rule, solved my issue. You could of course define a separate rule depending on the requirements in the actual environment.

The Remote Registry Service is involved  (see below information regarding System.IO.IOException: The network path was not found > RegistryKey.OpenRemoteBaseKey)in this phase of the installation and on Windows Server 2012, this service is by default configured to start when triggered (needed) > Automatic (Triggered Start).  The Remote Registry issue has been described by others like MVP Brandon George (related to SQL Server 2012 AlwaysOn Availability Groups). This is also mentioned in a comment on the TechNet article referenced above.

Symptoms

1. The Windows Installer (MSI) never shows up when AX Setup tries to install the AOS Component

2. AX Setup reports the installation as successful

3. Neither the Service or the Server Configuration application is installed

4. The DynamicsSetupLog contains the following information

2013-07-05 10:11:51Z  === Starting execution phase ===
2013-07-05 10:11:51Z Executing 'Application Object Server (AOS)' this pass.
2013-07-05 10:11:51Z Queueing for installation: Application Object Server (AOS)
2013-07-05 10:11:51Z Component installation task completed successfully.
2013-07-05 10:11:51Z === Setting up Application Object Server (AOS) ===
2013-07-05 10:11:51Z Adding account 'domain\service account' as a login in Microsoft SQL Server.
2013-07-05 10:11:51Z Creating stored procedures for remote sql server. LoginName: 'domain\service account'.
2013-07-05 10:11:51Z Creating stored procedure 'CREATETEMPDBPERMISSIONS_AX-AOS02_01'.
2013-07-05 10:11:51Z Creating stored procedure '[dbo].[CREATESERVERSESSIONS]'.
2013-07-05 10:11:51Z Creating stored procedure '[dbo].[CREATEUSERSESSIONS]'.
2013-07-05 10:11:51Z Creating stored procedure '[dbo].[getNumInternal]'.
2013-07-05 10:11:51Z Creating stored procedure '[dbo].[sp_GetNextRecId]'.
2013-07-05 10:11:51Z isolation level = read committed snapshot
2013-07-05 10:11:51Z Adding account 'domain\service account' as a login in Microsoft SQL Server.
2013-07-05 10:11:51Z Adding account 'domain\service account' as a login in Microsoft SQL Server.
2013-07-05 10:11:51Z Granting AOS account access to database AXTech_model on server SQL Server
2013-07-05 10:12:56Z ******************************************************************************************************
2013-07-05 10:12:56Z Component installation task stopped due to an error.
2013-07-05 10:12:56Z ******************************************************************************************************
2013-07-05 10:12:56Z ******************************************************************************************************
2013-07-05 10:12:56Z The network path was not found.

2013-07-05 10:12:56Z ******************************************************************************************************
2013-07-05 10:12:56Z ******************************************************************************************************
2013-07-05 10:12:56Z System.IO.IOException: The network path was not found.
2013-07-05 10:12:56Z    at Microsoft.Win32.RegistryKey.Win32ErrorStatic(Int32 errorCode, String str)
2013-07-05 10:12:56Z    at Microsoft.Win32.RegistryKey.OpenRemoteBaseKey(RegistryHive hKey, String machineName)
2013-07-05 10:12:56Z    at System.Diagnostics.EventLog.GetEventLogRegKey(String machine, Boolean writable)
2013-07-05 10:12:56Z    at System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly)
2013-07-05 10:12:56Z    at System.Diagnostics.EventLog.SourceExists(String source, String machineName)
2013-07-05 10:12:56Z    at System.Diagnostics.EventLog.VerifyAndCreateSource(String sourceName, String currentMachineName)
2013-07-05 10:12:56Z    at System.Diagnostics.EventLog.WriteEntry(String message, EventLogEntryType type, Int32 eventID, Int16 category, Byte[] rawData)
2013-07-05 10:12:56Z    at System.Diagnostics.EventLog.WriteEntry(String message, EventLogEntryType type, Int32 eventID)
2013-07-05 10:12:56Z    at Microsoft.Dynamics.AX.Framework.Tools.ModelManagement.AxUtilEventLog.Log(EventLogEntryType eventLogType, AxUtilEventLogType logType, String message)
2013-07-05 10:12:56Z    at Microsoft.Dynamics.AX.Framework.Tools.ModelManagement.AxUtilEventLog.LogSuccess(AxUtil util, AxUtilEventLogType eventLogType, AxUtilAction action, IAxUtilEventLogEntry logEntry)
2013-07-05 10:12:56Z    at Microsoft.Dynamics.AX.Framework.Tools.ModelManagement.AxUtil.GrantPermission(String schemaName)
2013-07-05 10:12:56Z    at Microsoft.Dynamics.Setup.Support.SetupQueue.AOSInstaller.GrantAOSAccounttoDatabase(String databaseServer, String databaseName)
2013-07-05 10:12:56Z    at Microsoft.Dynamics.Setup.Support.SetupQueue.AOSInstaller.AosPreInstallActions()
2013-07-05 10:12:56Z    at Microsoft.Dynamics.Setup.Support.SetupQueue.AOSInstaller.PerformWork()
2013-07-05 10:12:56Z    at Microsoft.Dynamics.Setup.Support.SetupQueue.InstallationClass.DoWork(Object sender, DoWorkEventArgs e)
2013-07-05 10:12:56Z    at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
2013-07-05 10:12:56Z ******************************************************************************************************
2013-07-05 10:12:57Z S260FinishedInfo

2013-07-05 10:14:14Z  === Setup was completed successfully.
2013-07-05 10:14:14Z  === Setup logging ended: 7/5/2013 10:14:14 AM ErrorLevel/ExitCode: '0' ===

AX 2012 R2 - Issue Deploying Enterprise Portal on SharePoint 2013

I recently struggeled with an issue when deploying Enterprise Portal on SharePoint 2013 related to a missing method (removeFromCache) in class SRSReportHelper (the deployment logic is referencing a non existing method).

Likely solution:

• KB 2851881 - Error is thrown when trying to generate Power View Reports (update in \SYP\Classes\SrsReportHelper)

- Or -

• KB 2850972 - Cumulative Update 6 for AX 2012 R2 (KB 2851881 is included)

I have not yet verified the hotfix, but I will do that this week (hence "Likely solution").

Hopefully this will save valuable time trouble shooting this issue.

Update:

I'm working my way through a CU6 advanced update right now (Hyper-V on my laptop) and I can verify that the missing method finally is defined and without testing deploying the EP site yet, things looks more promising. From my point of view, this is a really bad example of quality assurance from Microsoft (end of discussion).

Here is what the class SRSReportHelper looks like after implementing CU6 that contains the fix:

Follow up RapidStart Connector issue (previous blog post)

I experienced this issue again today and the following Update Statements (10 columns), let me successfully start the RapidStart Connector Service:

UPDATE DIRPARTYTABLE SET accountingpersonnel_jp = 'x';
UPDATE DIRPARTYTABLE SET companyrepresentative_jp = 'x';
UPDATE DIRPARTYTABLE SET importvatnum = 'x';
UPDATE DIRPARTYTABLE SET intrastatcode = 'x';
UPDATE DIRPARTYTABLE SET isconsolidationcompany = 0;
UPDATE DIRPARTYTABLE SET iseliminationcompany = 0;
UPDATE DIRPARTYTABLE SET packmaterialfeelicensenum = 'x';
UPDATE DIRPARTYTABLE SET taxauthority_ru = 'x';
UPDATE DIRPARTYTABLE SET taxrepresentative = 'x';
UPDATE DIRPARTYTABLE SET vatnum = 'x';

I can't explain the exact reason, but hopefully this rather pragmatic approach can save others from spending valuable time tshooting the RapidStart Connector Service.

If anyone can explain the reason, please feel free to share your comments (moderated).

My best guess is that you have to manually define at least one company with all necessary (mandatory) information before starting the RapidStart Connector Service. Or use this Q&D approach.

AX 2012 R2 - RapidStart Connector Issue

I was recently challenged with my first RapidStart Connector installation and configuration for AX 2012 R2 (RTM). I don't know if this was the correct solution, but it solved my issue. I found people having similar issues, but no solution. And remember that this is written by a non developer :-)

Symptom:

After activation and service startup or later attempts to start the Connector service (On Premise), the Connector fails to start with the following message (activation went well and was registered on the RapidStart Services site in Azure):



 

 

 

 

 

 

 

 

 

Approach:

 

First I verified that the necessary network traffic was allowed trough the firewall (this was a hosted solution). A rule for outgoing traffic on TCP ports 9350-9354 (range) was added as described by others and outgoing traffic on TCP port 443 was already allowed (I think the activation step uses https/TCP 443).

 

After this, I could focus more on AX. Since the RapidStart Connector relies on the AifGDS (General Document Service) and the AppConfigServices, I decided to activate logging for these services (I think the latter only is used when some kind of configuration data is sent from RapidStart Services to AX).

 

This showed that there indeed was an Exception logged for the AifGDS Service every time I tried to start the service.

 

Hmm, how does the CompanyInfo table look in the Table Browser in the AOT? Well it turned out to show the value Unretrieved ...

 

 

 

Ok, next step - check the table in the database. Hmm, no table called CompanyInfo found... Back to the AOT and check the table properties. OK Table Inheritance and base table was DirPartyTable. Back to the database and query the DirPartyTable. There I found the columns and after checking the value for the first exception logged for the Service, it turned out to be a SQL NULL value.

 

Solution:

 

Next step - (rather experimental) updated the column with a dummy value ('A') and another attempt to start the Connector Service - failed again, but with a similar exception logged for another column in the same table (remember not CompanyInfo but DirPartyTable in the database). Updated the column and started the service again - same status and exception logged for another column. I was finally progressing! Repeated this process for all columns (I guess it was around 15 columns in total) and FINALLY the Connector Service started successfully! Final verification showed that the endpoint was active in the RapidStart Services.

 

Brief analysis from a non developers perspective:

 

It clearly seems to be some kind of relationship between the License Configuration (no functionality for Japan was activated in the License Configuration) and the XML schema for the AifGDS Service. AX 2012 has a fixed schema (all standard tables will always exist in the database with the standard columns) and deactivated columns is NULLed out (SQL NULL values). Since the service was operational after updating the columns with dummy values, it clearly shows that some relationships still exists. A large improvement compared to earlier versions of AX, but still some things to consider (maybe the underlying document class should be modified, but that would end up in a modification). On the other hand AX 2012 R2 seems to have undergone some major changes with regards to Table Inheritance and hierarchies that also could cause some issues if not handled correctly. I have also seen some indications that changes to the License Configuration introduces some issues when synchronizing the database (a lot of warnings for views and errors for datasets) and that there seems to be a lot of dependencies in this area also.

 

Hopefully this will help others experiencing the same issue or at least point in the right direction. What I can say for sure is that AX 2012 R2 contains some major changes...