Within Update 2 of Microsoft Dynamics AX, it is now possible to check which hot-fixes are installed. From Visual Studio, under the Dynamics AX menu, select Addins > Apply Hotfix. Then in the Apply Hotfix form, select the View Installed Hotfixes tab.

However, in RTW and Update 1 it was not so straight forward to determine the hot-fixes (KBs) you have installed. So, I have created the following PowerShell script to list the fixes you have in your packages folder. Please provide me with feedback on improvement suggestions or if you find any issues with the script.

#
# This source code is freeware and is provided on an "as is" basis without warranties of any kind, 
# whether express or implied, including without limitation warranties that the code is free of defect, 
# fit for a particular purpose or non-infringing.  The entire risk as to the quality and performance of 
# the code is with the end user.
# 
$packageDirectory = "C:\AOSService\PackagesLocalDirectory";
foreach($file in Get-ChildItem $packageDirectory)
{
    $folderPath = $packageDirectory + "\" + $file;
    foreach($file in Get-ChildItem $folderPath)
    {    
        $subFolder1 = $folderPath + "\" + $file;
        if ( Test-Path $subFolder1 -PathType Container )
        { 
            foreach($file in Get-ChildItem $subFolder1)
         {
             $subFolder2 = $file;
          $subFolder2Path = $subFolder1 + "\" + $file;
                if($subFolder2 -like "AXUpdate")
                {
              $booleanOutputFolder = $true;
                    foreach($file in Get-ChildItem $subFolder2Path\*.XML)
              {
                        if($booleanOutputFolder -eq $true)
                        {
                            $booleanOutputFolder = $false;
                            Write-Host "Fixes for folder:"$subFolder1;
                        }
                        $xml = (Get-Content $file);
                        Write-Host "Found KB:"$xml.AxUpdate.KBNumbers.string "     Package #:" $xml.AxUpdate.Name;
                  }
                    if($booleanOutputFolder -eq $false)
                    {
                        Write-Host "";
                    }
                }
         }
        }
    }
}
Read-Host -Prompt "Finished: Press Enter to continue" 

The post Find which Hot-Fixes (KBs) you have installed in Microsoft Dynamics AX appeared first on Microsoft Dynamics 365 Blog.

If you find that you are missing entities listed in the Data entities form, you can try the following steps.

Run the following SQL Script:

—

— This source code or script is freeware and is provided on an “as is” basis without warranties of any kind,

— whether express or implied, including without limitation warranties that the code is free of defect,

— fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of

— the code is with the end user.

—

— Create backups of the tables first

SELECT *

INTO DMFEntity_backup

FROM DMFEntity

GO

SELECT *

INTO DMFTargetXML_backup

FROM DMFTargetXML

GO

SELECT *

INTO DMFTargetXMLToEntityMap_backup

FROM DMFTargetXMLToEntityMap

GO

SELECT *

INTO DMFTargetEntityHierarchy_backup

FROM DMFTargetEntityHierarchy

GO

— Truncate the tables

TRUNCATE TABLE DMFENTITY

GO

TRUNCATE TABLE DMFTargetXML

GO

TRUNCATE TABLE DMFTargetXMLToEntityMap

GO

TRUNCATE TABLE DMFTargetEntityHierarchy

GO

Then in AX, do the following:

Go to: Data Management and select “Framework Parameters”

Select Entity Settings, and click “Refresh entity list”

The post Data Management: Missing Entities appeared first on Microsoft Dynamics 365 Blog.

In a recent issue, a customer was reporting a problem exporting data using the data management framework. The issue was that during the export they were leaving the “Skip staging” option to “Yes”, which is the default option.

When the export of the entity was run, it reported that it had failed and there seemed to be no apparent reason why. However, the error was reported but it just wasn’t that obvious where to find it. If you have similar issues, then follow these points below:

Click “View execution log”

After selecting the execution log, you will not see any further details at this point. The key is to click “Staging log details”, even though on the export you selected the option “Skip staging” 

You will then see the error messages

The post Data Management Framework: Export fails with no apparent details on the cause appeared first on Microsoft Dynamics 365 Blog.

[Updated March 31 2017 for R2 Kernel]

The following kernel hot-fixes for Microsoft Dynamics AX 2012 R3 and R2, KB 3141722 (R3) & KB 4017756 (R2) , improve the way we handle the tables created in TempDB. As you may be aware, TempDB is a transient database, that means when SQL is started or after a cluster node failover, the TempDB database is created empty. Whenever the AOS creates a table in TempDB we also create a reference to that in an internal pool within the AOS service. The reason for this is that once a TempDB table is used, we don’t drop it, but truncate to retain an empty copy to be reused again by another session.

There are also different types of tables created in TempDB by the AOS to handle certain situations. The AOS service was designed to handle a failover in regards to some of these table types, however there were some that were not covered. This fix now handles all situations by introducing a new internal thread that will periodically check the internal pool of temp tables used against the actual tables residing in TempDB. If it finds that they are not present, then the pool is cleaned up.

Out of the box, this new feature is disabled, but it can be enabled by setting the string value “synctempdbpoolfrequency” in the AOS service registry settings. The value set in this key is used to determine the polling frequency of thread that validates the internal temp table pool to the TempDB tables. When setting this, chose a suitable value that will not cause an overhead to the database, a suitable suggested value would be between 30 to 60 (seconds).

The “synctempdbpoolfrequency” registry value is setup under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dynamics Server\6.0\<instance_number>\<configuration_name>

See example below where the instance was 01 and the configuration was named “Debug”

You can download this from Lifecycle Services here: https://fix.lcs.dynamics.com/Issue/Resolved?kb=3141722

As kernels fixes are cumulative, you can install any later kernel as well. The build number for this kernel is 6.3.3000.1480.

The post Improved High Availability Support for SQL Clusters appeared first on Microsoft Dynamics 365 Blog.

Overview:

There are a few blogs around detailing some issues with checklist items not getting set to status completed, but this issue has recently come up in a few cases and doesn’t seem to have been documented before. As those who have researched these problems would know, the status of the checklist items is stored in the SysSetupLog table.

The Problem:

There was a customisation in method ApplicationVersion::buildNo that added an additional string to the default build number, in this case it was the customer’s internal build details. Within the SysSetupLog table there is a field AppBuild which is 30 chars long. Now, when you click on “Mark as Complete” we are adding records for each item to the SysSetupLog with some details, including the build number that is populated into the AppBuild field. For this issue the build number returned by the method was greater than 30 characters, but when the record was written in the table, the build number was truncated to 30 characters.

It is during the rendering of the HTML page for the checklist we check the item’s status. Within the code we are using the method call SysSetupLog::findEx to find the record for the item, however this wasn’t returning anything. Within this method we try to fetch the checklist item record by matching on some passed-through parameters, but the app build is matched based on the returned value from ApplicationVersion::buildNo, see below:

static SysSetupLog findEx(identifierName   _name,

                          ClassDescription _description,

                          SysVersion       _version       = xInfo::releaseVersion(),

                          boolean          _forUpdate     = false)

{

    SysSetupLog sysSetupLog;

    ;

    if (_name) //description can be empty…

    {

        sysSetupLog.selectForUpdate(_forUpdate);

        select firstonly sysSetupLog

            where sysSetupLog.Version     == _version       &&

                  sysSetupLog.AppBuild  == ApplicationVersion::buildNo() &&

                  sysSetupLog.Name        == _name          &&

                  sysSetupLog.Description == _description;

    }

    return sysSetupLog;

}

The reason that no record was returned, was that that the build stored in the AppBuild field had been truncated, and therefore did not match the build number returned by the buildNo method.

Solution:

Ensure that the string returned by method ApplicationVersion::buildNo does not exceed 30 characters.

The post Clicking “Mark as Complete” does not update the status in the Software Update and Upgrade Checklists appeared first on Microsoft Dynamics 365 Blog.

This specific issue occurs only when using the state transfer tool in AX 2009. The problem is as follows:

• We create new records in the Shadow_DirPartyRelationship.
• The unique index on this references RefRecId.
• The RefRecId will become the RecId for DirPartyRelationship during the bulk copy in AX 2012.
• We use the SystemSequences NextVal from DirPartyReleationship to create these new RefRecIds in method – DirUpgrade::createPartyRelationship, then sub method DirUpgrade::getNewPartyRelationshipRecId.
• These RecIds are coming from the SystemSequences table in the environment used for the state transfer, and not production.
• The issue is that DirPartyReleationship is an existing table in AX 2009, so we do not copy back from the state transfer environment the SystemSequences record for that – which makes sense as there could have been newer records in production since.
• The problem then comes when there have been some new records created, e.g. customers, vendors. Some of the delta processing scripts would call these methods, mentioned above, to add in new records in Shadow_DirPartyRelationship.
• As the NextVal in SystemSequences for DirPartyRelationship is lower in production, it will use the same numbers again for the RefRecId in Shadow_DirPartyRelationship.

This potential problem can occur with all versions of AX 2012.

Workaround

After running the state transfer in production, and before you continue with the upgrade you can run the following SQL statement to update the NextVal in table SystemSequences to fix this problem:

UPDATE SYSTEMSEQUENCES

SET NEXTVAL = (

SELECT max(RECID) + 1 AS NEXTVAL

FROM (

SELECT REFRECID AS RECID

FROM SHADOW_DIRPARTYRELATIONSHIP

UNION

SELECT RECID

FROM DIRPARTYRELATIONSHIP

) T1

)

WHERE TABID = (

SELECT TABLEID

FROM SQLDICTIONARY

WHERE NAME = ‘DIRPARTYRELATIONSHIP’

AND FIELDID = 0

)

You need to restart the AOS Service after running the update statement above.

The post Microsoft Dynamics AX 2012 Upgrade – Using the State Transfer Tool with AX 2009, you can potentially have duplicate records created within table Shadow_DirPartyRelationship appeared first on Microsoft Dynamics 365 Blog.

This error message can be a little misleading as it implies that it is related to some security permissions not being configured correctly. In some cases this can be the case, however it can also be a problem with running CIL code. This can especially occur when you are going through the code upgrade steps.

There are a couple of solutions for this.

1. Try to complete a full CIL compile with errors.
2. If the full CIL fails or has errors, then uncheck the “Execute business operations in CIL”, under File > Tools > Options – in the Development tab, as below:

The post You may get message “Failed to create a session; confirm that the user has the proper privileges to log on to Microsoft Dynamics” during an upgrade or in-place upgrade with Microsoft Dynamics AX 2012 appeared first on Microsoft Dynamics 365 Blog.

Resolving a SQL SPID to an AX user can be useful when trying to diagnose performance or blocking issues on the database server.

As some of you are aware, in AX 2012 it is now possible to track an AX user to a specific SQL SPID.

As you are also probably aware, in AX 2009 you could get the SPIDs from the On-Line users form. However, one restriction of this was that you can only see the SQL SPIDs for the AOS that your client session was connected to. This was fine for small single AOS installations, but wasn’t very useful for larger multiple AOS server configurations.

For this reason, I’ve sometimes given customers the following process to allow these SPIDs to be captured to a log table. This process runs a frequent small batch job on each AOS server, to output the current SPIDs on each AOS to this log table.

You can then query this table, and see which SQL SPID is associated to the each AX User.

If you wish to set this up, please follow the steps below:

1) Save the code at the end of this post to a file called “PrivateProject_LogSPIDSBatchJob.xpo”, and import the XPO into AX.

(You may want to rename the class to suit your normal customisation naming conventions).

2) Create a batch group for each AOS: Administration > Setup > Batch Groups. Called these, e.g. AOS01_SPID

3) Assign the associated AOS server to each batch group. If you don’t see your server listed, go to Administration > Setup > Server Configuration, and make sure that the “Is Batch Server” option is selected.

4) Next go to Basic > Inquiries > Batch Job

5) Create a new Batch Job Record , e.g.

6) Click “View Tasks”, create a new task record for each AOS and assign class name “AAA_SPID_Log_BatchJob” and then for each record assign the unique batch group, e.g. AOS01_SPID, AOS02_SPID

7) Click, Save then close the Batch Tasks form. Back in the Batch Job form, click the “Recurrence” button. Set the reoccurrence to every 1 – 2 mins.

8) Click OK, then back in the Batch Tasks form, click button “Functions” then “Change Status” then set the batch job to Waiting.

9) I also included the class “AAA_SPID_Log_Purge_BatchJob” for purging this. This can also be setup as a normal batch job, to be run just once per day to keep the size of this table small.

Code for XPO:

Exportfile for AOT version 1.0 or later
Formatversion: 1

***Element: CLS

; Microsoft Dynamics AX Class: AAA_SPID_Log_Purge_BatchJob unloaded
; ——————————————————————————–
CLSVERSION 1

CLASS #AAA_SPID_Log_Purge_BatchJob
PROPERTIES
Name                #AAA_SPID_Log_Purge_BatchJob
Extends             #RunBaseBatch
RunOn               #Called from
ENDPROPERTIES

METHODS
Version: 3
SOURCE #canGoBatchJournal
#protected boolean canGoBatchJournal()
#{
#     return true;
#}
ENDSOURCE
SOURCE #classDeclaration
#class AAA_SPID_Log_Purge_BatchJob extends RunBaseBatch
#{
#
#///
#///  This source code is freeware and is provided on an “as is” basis without warranties of any kind,
#///  whether express or implied, including without limitation warranties that the code is free of defect,
#///  fit for a particular purpose or non-infringing.  The entire risk as to the quality and performance of
#///  the code is with the end user.
#///
#
#}
ENDSOURCE
SOURCE #pack
#public container pack()
#{
#
#    return conNull();
#
#}
ENDSOURCE
SOURCE #run
#public void run()
#{
#
#    SqlDataDictionary sqlDict;
#    ;
#    new SqlDataDictionaryPermission(methodStr(SQLDataDictionary, tableTruncate)).assert();
#    sqlDict = new SqlDataDictionary();
#    sqlDict.tableTruncate(tableName2Id(“AAA_SPID_Log”), false);
#    CodeAccessPermission::revertAssert();
#
#}
ENDSOURCE
SOURCE #unpack
#public boolean unpack(container packedClass)
#{
#
#    return true;
#
#}
ENDSOURCE
SOURCE #description
#client server public static ClassDescription description()
#{
#
#    return (“Purge Log Table for User SPIDS”);
#
#}
ENDSOURCE
SOURCE #main
#static server void main(Args args)
#{
#
#    SqlDataDictionary sqlDict;
#    ;
#    new SqlDataDictionaryPermission(methodStr(SQLDataDictionary, tableTruncate)).assert();
#    sqlDict = new SqlDataDictionary();
#    sqlDict.tableTruncate(tableName2Id(“AAA_SPID_Log”), false);
#    CodeAccessPermission::revertAssert();
#
#}
ENDSOURCE
ENDMETHODS
ENDCLASS

***Element: CLS

; Microsoft Dynamics AX Class: AAA_SPID_Log_BatchJob unloaded
; ——————————————————————————–
CLSVERSION 1

CLASS #AAA_SPID_Log_BatchJob
PROPERTIES
Name                #AAA_SPID_Log_BatchJob
Extends             #RunBaseBatch
RunOn               #Called from
ENDPROPERTIES

METHODS
Version: 3
SOURCE #description
#client server public static ClassDescription description()
#{
#
#    return (“Log User SPIDS”);
#
#}
ENDSOURCE
SOURCE #canGoBatchJournal
#protected boolean canGoBatchJournal()
#{
#     return true;
#}
ENDSOURCE
SOURCE #classDeclaration
#class AAA_SPID_Log_BatchJob extends RunBaseBatch
#{
#
#///
#///  This source code is freeware and is provided on an “as is” basis without warranties of any kind,
#///  whether express or implied, including without limitation warranties that the code is free of defect,
#///  fit for a particular purpose or non-infringing.  The entire risk as to the quality and performance of
#///  the code is with the end user.
#///
#
#}
ENDSOURCE
SOURCE #pack
#public container pack()
#{
#
#    return conNull();
#
#}
ENDSOURCE
SOURCE #run
#public void run()
#{
#
#    SysClientSessions clientSessions;
#    AAA_SPID_Log spidLog;
#    xSession sess, serverSess;
#    str spids;
#    int serverId;
#    ;
#
#    serverSess = new xSession();
#    serverId = serverSess.serverId();
#
#    while select clientSessions where clientSessions.Status == 1 && clientSessions.ServerId == serverId
#    {
#        sess = new xSession(clientSessions.SessionId);
#        spidLog.userId = clientSessions.UserId;
#        spidLog.SPID = sess.databaseSpid();
#        spidLog.insert();
#    }
#}
ENDSOURCE
SOURCE #unpack
#public boolean unpack(container packedClass)
#{
#
#    return true;
#
#}
ENDSOURCE
SOURCE #main
#static server void main(Args args)
#{
#
#    SysClientSessions clientSessions;
#    AAA_SPID_Log spidLog;
#    xSession sess, serverSess;
#    str spids;
#    int serverId;
#    ;
#
#    serverSess = new xSession();
#    serverId = serverSess.serverId();
#
#    while select clientSessions where clientSessions.Status == 1 && clientSessions.ServerId == serverId
#    {
#        sess = new xSession(clientSessions.SessionId);
#        spidLog.userId = clientSessions.UserId;
#        spidLog.SPID = sess.databaseSpid();
#        spidLog.insert();
#    }
#
#}
ENDSOURCE
ENDMETHODS
ENDCLASS

***Element: DBT

; Microsoft Dynamics AX Table : AAA_SPID_Log unloaded
; ——————————————————————————–
TABLEVERSION 1

TABLE #AAA_SPID_Log
PROPERTIES
Name                #AAA_SPID_Log
CreatedDateTime     #Yes
ENDPROPERTIES

FIELDS
FIELD #userId
STRING
PROPERTIES
Name                #userId
Table               #AAA_SPID_Log
ExtendedDataType
ARRAY
#userId
#
ENDARRAY
StringSize          #5
ENDPROPERTIES

FIELD #SPID
STRING
PROPERTIES
Name                #SPID
Table               #AAA_SPID_Log
StringSize          #6
ENDPROPERTIES

ENDFIELDS
GROUPS
ENDGROUPS

INDICES
ENDINDICES
REFERENCES
ENDREFERENCES

DELETEACTIONS
ENDDELETEACTIONS

ENDTABLE

***Element: PRN

; Microsoft Dynamics AX Project : LogSPIDSBatchJob unloaded
; ——————————————————————————–
PROJECTVERSION 2

PROJECT #LogSPIDSBatchJob
PRIVATE
PROPERTIES
Name                #LogSPIDSBatchJob
ENDPROPERTIES

PROJECTCLASS ProjectNode
BEGINNODE
FILETYPE 0
UTILTYPE 45
UTILOBJECTID 50003
NODETYPE 329
NAME #AAA_SPID_Log_Purge_BatchJob
ENDNODE
BEGINNODE
FILETYPE 0
UTILTYPE 45
UTILOBJECTID 50002
NODETYPE 329
NAME #AAA_SPID_Log_BatchJob
ENDNODE
BEGINNODE
FILETYPE 0
UTILTYPE 44
UTILOBJECTID 50002
NODETYPE 204
NAME #AAA_SPID_Log
ENDNODE
ENDPROJECT

***Element: END

The post Capturing an AX User’s SQL SPID over multiple AOS servers in AX 2009 appeared first on Microsoft Dynamics 365 Blog.

The “Detect update scripts (Required)” is the first part of the Data upgrade section in the checklist.

If you get the following warning “Data Upgrade mode had already been initialized. If additional updates have been installed complete the data upgrade process for the previously installed updated before restarting the process for any additional updated” the when you for the first time click on the “Detect update scripts (Required)” step in the Data Upgrade Checklist, you will have problems as the required data upgrade scripts are not prepared.

Typically you will not see the “Presynchronize (required)” task, as shown below:

Please note that this is only an issue, if this is the first time you run this step; the warning message is a normal message for when you have already completed the data upgrade.

This problem has been seen a couple of times, and it was due to some historical data remaining in the ReleaseUpdate* tables from a restarted or incomplete AX 4.0/2009 to AX 2012 RTM upgrade. For some reason, even though some upgrades had appeared to be successfully updated to AX 2012, there was some old data remaining.

If you have this problem you can check for old data in SQL, by using the following scripts:

SELECT COUNT(*) FROM RELEASEUPDATEBULKCOPYFIELD_GLS;

SELECT COUNT(*) FROM RELEASEUPDATEBULKCOPYFIELDERRORS;

SELECT COUNT(*) FROM RELEASEUPDATEDISCOVERYSTATUS;

SELECT COUNT(*) FROM RELEASEUPDATEJOBSTATUS;

SELECT COUNT(*) FROM RELEASEUPDATEMINORSCRIPTS;

SELECT COUNT(*) FROM RELEASEUPDATESCRIPTDEPENDENCY;

SELECT COUNT(*) FROM RELEASEUPDATESCRIPTS;

SELECT COUNT(*) FROM RELEASEUPDATESCRIPTSUSEDTABLES;

If you find that there is old AX 2012 RTM upgrade records in the tables above from a previous upgrade, you can delete the records with the following steps:

1) Close the AX 2012 R2 Client

2) Stop the AOS Server

3) As with best practice, make a backup of the database as you are going to delete data.

4) Run the following SQL Script:

TRUNCATE TABLE RELEASEUPDATEBULKCOPYFIELD_GLS;

TRUNCATE TABLE RELEASEUPDATEBULKCOPYFIELDERRORS;

TRUNCATE TABLE RELEASEUPDATEDISCOVERYSTATUS;

TRUNCATE TABLE RELEASEUPDATEJOBSTATUS;

TRUNCATE TABLE RELEASEUPDATEMINORSCRIPTS;

TRUNCATE TABLE RELEASEUPDATESCRIPTDEPENDENCY;

TRUNCATE TABLE RELEASEUPDATESCRIPTS;

TRUNCATE TABLE RELEASEUPDATESCRIPTSUSEDTABLES;

5) Start the AOS and Client

6) Rerun the step “Detect update scripts (Required)” from the Data Upgrade checklist.

Disclaimer: Please ensure you have full backups of databases and files before making any changes as detailed in the steps above.

The post AX 2012 R2 In-Place Upgrade – Sometimes during the Data Upgrade Checklist the Detect Update Scripts step does not prepare any scripts to run. appeared first on Microsoft Dynamics 365 Blog.