AX DB Restore Scripts #5 – Configure Service Accounts and Help Server

Last week I embarked on a series of posts on DB restore scripts for Dynamics AX by creating a list of items in your AX database that need to be updated/reconfigured when restoring a database from a production environment to a development or QA one.

So far we have covered the majority of the most critical issues to fix when doing a DB restore, so from today on most of the scripts are basically optional. They are optional for one of the following reasons: 1. It may be common to have the same configuration in both live and dev, yet in some circumstances they may differ e.g. Business connector may remain the same if you are restoring from live to dev, but not from live to a demo VPC.
2. The data is correct but for safety or security you may want to manipulate it for a development environment. E.G. Changing all email templates to clearly indicate the source is from a dev system.

Today we will cover two topics namely re-configuring the service accounts in AX and configuring the AX help server URL.

In the Dynamics AX 2012 client, the configurations that we are going to look at are:
1. System Service Accounts, accessed via System Administration -> Setup -> System -> System service Accounts


2. Batch Jobs, accessed via System Administration -> Setup -> System -> Help system parameters

To update the settings above we need to do the following:

1. Update the SYSBCPROXYUSERACCOUNT table to reflect the business connector user’s SID, networkdomain and network alias. For this step you will need to find out the SID of the business connector either by setting it manually the first time and then running select SID from SYSBCPROXYUSERACCOUNT where NETWORKDOMAIN='[yourdomain]’ and NETWORKALIAS='[yourbcuseralias]’ or follow one of the suggestions over here
2. Update the SYSWORKFLOWPARAMETERS table to reflect the userId of the workflow execution account.
3. Update the SYNCPARAMETERS table to reflect the userId of the Microsoft Project server synchronization service account.
4. Update SYSGLOBALCONFIGURATION to reflect new help server URL if necessary.

1. If you are wanting to use an Alias/Network domain combination for either of the two execution accounts, I would recommend setting them manually in AX as they create users and permissions automatically when you do this. 
2. The above script assumes that execution accounts you are setting exist in the new system and have the necessary permissions.

The following SQL code will accomplish the above. I have parameterised the SQL for easier reuse or adjustment.

---BC Proxy Details ---
Declare @BCPSID varchar(50) = '[BCPROXY_SID]'
Declare @BCPDOMAIN varchar(50) = '[yourdomain]'
Declare @BCPALIAS varchar(50) = '[bcproxyalias]'
---Service Accounts ---
Declare @WFEXECUTIONACCOUNT varchar(20) = 'wfexc'
Declare @PROJSYNCACCOUNT varchar(20) = 'syncex'
---Help Server URL---
Declare @helpserver varchar(200) = 'http://[YOURSERVER]/DynamicsAX6HelpServer/HelpService.svc'

---Set BCPRoxy Account---
where NETWORKALIAS != @BCPALIAS --optional to display affected rows.
---Set WF Execution Account---
---Set Proj Sync Account---
---Set help server URL---
update SYSGLOBALCONFIGURATION set value=@helpserver where name='HelpServerLocation' and value != @helpserver

I hope this assists you and will be useful in your management of your AX environments.

View Next – AX DB Restore Scripts #6 – SMTP Server and DMF Folder

View Previous – AX DB Restore Scripts #4 – Reconfigure batch jobs

Back to List

Debugging Security (in the AOT)

With the various ways in AX2012 that you can allow permissions to objects it can sometimes be very difficult to diagnose why your role is not working as required. There are a number of very useful tools to use to assist in finding the problem, including the security development tool from Microsoft.

In this post however I will describe how to analyse a specific problem in a security role using the AOT.

Example: We have created a new Role that should allow users to have read only access to a number of forms including the Users form in the System Administration Module. A number of standard “Inquiry” duties were added to the role as well as a custom duty explicitly allowing view only access to the SysUserInfoDetail form. On testing of the role the user still had access to edit the users. To resolve the issue we followed the following procedure.

  1. Determine the Entry Point / Menu Item being used.
    1. Right click on the form that’s proving problematic
    2. Click Personalise
    3. Select “Information” tab.
    4. Note the MenuItemName. In this case “SysUserInfoDetail”
  2. Locate the Menu Item in the AOT
    1. Open the AOT in a development workspace
    2. Expand the “Menu-Items” node
    3. Expand the “Display” node
    4. Locate the MenuItem noted above (1.4)
  3. Determined Roles that use this MenuItem
    1. Right Click on the Menuitem
    2. Click “Add-Ins”
    3. Click “Security Tools”
    4. Click “View related security roles”Screen Shot 2015-02-25 at 4.33.59 PM
  4. Locate your custom role in the table
    Screen Shot 2015-02-25 at 4.37.18 PM
  5. From her you can determine what other duties and privileges are also providing access to this
    Screen Shot 2015-02-25 at 4.40.40 PM
  6. In our case it is the PaymVendorPaymentStatusInquire duty and VendPaymentJournal_NAGenerate privilege that is giving full access and overriding our view only permission.

I hope this will assist you in debugging your custom security roles.