Search This Blog
March 17, 2025
Update admin user in Dev box
June 07, 2024
[Solved] Dynamics 365FO DB restore error Line 1 The permission 'KILL DATABASE CONNECTION' is not supported in this version of SQL Server.
Error Details: The error message for BacPac DB restore is as follows:
Dynamics 365FO DB restore error Line 1 The permission ‘KILL DATABASE CONNECTION’ is not supported in this version of SQL Server. Alternatively, use the server level ‘ALTER ANY CONNECTION’ permission.
Step 1: Navigate to the folder where your BACPAC file is saved and change the file extension from .bacpac to .zip.
Step 2: Open the zip file and copy the model.xml file to a different location. Open the copied file in a text editor such as Notepad, VS Code, or Visual Studio. (Avoid editing the file directly in the zip folder or the original file).
Step 5: Change the file extension of the zip file back to .bacpac (reverse of Step 1).
Step 6: Go to the downloaded SQLPackage folder and execute the following command:
SqlPackage.exe /a:import /sf:J:\MSSQL_BACKUP\PreProdDB.bacpac /tsn:localhost /tdn:AxDB_PreProd2005 /p:CommandTimeout=1200 /TargetUser:"axdbadmin" /TargetPassword:"<DbPassword>" /TargetTrustServerCertificate:True /mfp:"ModelCopy.xml
DB import should be successful this time.
June 17, 2023
Step-by-Step Guide to Azure App Registration Process
Introduction:
Azure App
Registration is a crucial step when developing applications that integrate with
Azure services. It allows your application to authenticate and access resources
securely within the Azure ecosystem. In this blog post, I will provide a
comprehensive, step-by-step guide to the Azure App Registration process,
helping you understand the necessary steps to register your application.
App registration
is required for a lot of purposes in D365FO, for example
1. To set up Warehouse mobile
2. Setup out of box Power BI report
3. Postman configuration
4. Various integration scenarios
Prerequisite: Just one, get the admin account and
use the same account for all the steps, this account should have access to D365FO
as well. (I know it's not mandatory but I
would recommend this.)
Step 1:
Access the Azure Portal:
To begin the
Azure App Registration process, log in to the Azure Portal
(https://portal.azure.com) using your Azure account credentials. Once logged
in, you'll have access to the Azure dashboard.
Step 2:
Navigate to Azure Active Directory:
From the
Azure dashboard, locate and select "Azure Active Directory" from the
list of available services. Azure Active Directory is a comprehensive identity
and access management solution provided by Microsoft. (To make sure you choose the right directory).
Step 3:
Choose "App Registrations":
Within Azure
Active Directory, navigate to the "App registrations" section. This
section allows you to manage all your application registrations. You can search for the same in the top search bar.
Step 4:
Click "New Registration":
Click on the
"New Registration" button to initiate the app registration process.
You will be prompted to provide essential details about your application.
Step 5:
Fill in Application Details:
In this
step, you need to provide the following details:
-
"Name": Enter a unique name for your application.
-
"Supported account types": Choose the appropriate account type (such
as "Accounts in this organizational directory only" or "Accounts
in any organizational directory"). Mostly it will be within the same organization.
-
"Redirect URI": Specify the URI where Azure will redirect users after
authentication. This is typically the URI of your application. In our case, it
will be the URL of D365FO environment.
Step 6:
Register the Application:
After
providing the necessary details, click on the "Register" button to
create the application in Azure. Azure will generate a unique "Application
(client) ID" that you will need to use during the development and
configuration of your application.
Step 7:
Configure API Permissions:
To access
Azure resources from your application, you need to grant it appropriate
permissions. In the app registration page, navigate to "API
permissions" and click on "Add permission." Here, you can
select the APIs and permissions required for your application. This section is used if you are going to use this for Power BI.
Step 8:
Grant Admin Consent:
Once you
have configured the necessary API permissions, you need to obtain consent from
an Azure administrator. Click on the "Grant admin consent for <your
organization name>" button to initiate the consent process.
Step 9:
Generate Client Secrets:
If your
application requires a client secret, such as when using the OAuth 2.0 client
credentials flow, navigate to the "Certificates & secrets"
section within the app registration page. Here, you can create and manage
client secrets securely. Copy the value securely as it will not visible after
this step and you need this for most of the applications eg. the Warehouse mobile
app, and Power BI configuration.
Step 10:
Application Configuration (Optional):
After
completing the app registration process, you can configure additional settings
specific to your application, such as branding, authentication options, and
more. Explore the app registration page and adjust the settings as per your
requirements.
Conclusion:
The Azure
App Registration process is a vital step when building applications that
integrate with Azure services. By following this step-by-step guide, you can
successfully register your application in Azure Active Directory, configure
necessary permissions, and obtain the required credentials for secure
authentication and access to Azure resources. Properly registered applications
can take advantage of various Azure services and APIs while ensuring a
streamlined and secure development process.
December 23, 2022
How to generate CAR report D365FO
December 22, 2022
QuickFix: How to check component of a deployable package
February 16, 2022
[Solved] Application login redirects to other domain than customer's domain #MSD365FO
December 03, 2021
[Solved] Your connection is not private, issue while browsing DEV box
Your connection is not private
Attackers might be trying to steal your information from
April 01, 2021
How to get meta data of an Data Entity MSDynD365
January 28, 2021
QuickFix: Maintenance mode doesn't activate
Hi Folks,
While trying to bring your Tier-1 environments in maintenance mode using SSMS, system may take longer than expected even after multiple time ISS reset using CMD.
Try this, Open Visual studio (type DevEnv in windows search bar) and click 'Dynamics 365' menu then select ‘Restart IIS Express’ this will bring your system into maintenance mode immediately.
April 23, 2020
QuickFix -11: Extensible Data security in D365FO
June 01, 2016
Extensible Data Security Framework in MS Dynamics AX 7
September 07, 2013
Axapta Application file extensions
Dynamics Ax Application file extensions
In Axapta we found a lot of file extensions are used. Each and every extension have a logical name, so you can easily identify their purpose. The extensions have 3 characters.Most of these files are located in the application folder (AX 2009):
C:\Program Files\Microsoft Dynamics AX\50\Application\Appl\[your_application]
The first character indicates the owner of the file:
a: application
k: kernel
The second character indicates the content of the file:
l: label
o: object
t: text
d: developer documentation
h: help
And the third character indicates the type of file:
d: data
i: index
c: cache
t: temporary
Using this logic, we can easily name all file extensions, and understand their purpose.
In the application folder:
ALD : Application Label Data files
These files contain the labels and label comments for a specific language of a label file.
ALC : Application Label Cache files
These files contain the application label cache. These files can be deleted when the AOS is stopped.
ALI : Application Label Index files
The .ali files contain an index to the .ald files. These files can be deleted when the AOS is stopped.
ALT : Application Label Temporary files
These files contain new labels before they are committed to the .ald file.
AOI : Application Object Index file
The AOI file contains an index to the AOD files. You can delete this file when the AOS is stopped. Be sure to delete this when you have copied layers from one AX installation to an other.
ADD : Application Developer Documentation Data files
These files contain the documentation that is found under the Application Developer Documentation node. These files are localized, just like label files.
ADI : Application Developer Documentation Index files
This is the index to the ADD file.
AHD : Application Help Data files
The AHD file contains the documentation aimed at the end user. In the AOT, this is found in the “Application Documentation” node.
AHI : Application Help Index files
This is the index to the AHD file.
AOD : Application Object Data file
This is the ‘AX layer file’, each of these files represents one layer.
KHD : Kernel Help Documentation files
These files contain the kernel help documentation you can find in the AOT in the tree node System Documentation.
KHI : Kernel Help Index files
The KHI file is the index to the Kernel Help file.
Located in Server/bin:
KTD extension: Kernel Text Data file
This file contains system text strings. These are used in the interface of AX and for system messages.
KTI extension: Kernel Text Index file
This is the index to the KTD file.
-Harry
April 22, 2013
Configuration and Security Keys in Axapta
Configuration and Security Keys in Axapta
Security KeysMicrosoft Dynamics AX consists of a number of modules. For example, General Ledger, Project, and Administration. To make it easier for an administrator to set up security keys, they are organized the same way for all modules. Only nine security keys are allowed for each module in the Navigation Pane.
Security keys allow administrators to set security on a user group level. Minimizing access on a user group level helps to reduce the attack surface against potential attacks.
Applying Security Keys
The main reasons to apply user-level security are to:
- Allow users to do only their designated tasks.
- Protect sensitive data in the database.
- Prevent users from inadvertently breaking an application by changing code or objects on which the application depends.
- Tables
- Views
- Menus
- Menu items
- Form controls
- Report controls
- Expand the Data Dictionary node in the Application Object Tree (AOT).
- Right-click the Security Keys node, and then select New Security Key.
- Right-click the security key object, and then click Properties.
- Rename the security key by modifying the Name property.
- Right-click the object, and then click Create from the shortcut menu.
- Right-click the object, and then click Save from the shortcut menu.
- Right-click the object again, and then click Check In. This opens the Check in form.
Property | Rules |
ID | Always ship a security key with the same ID as it has been shipped with before. If you try to create a new security key with an ID that has already been used for a security key in Microsoft Dynamics AX, an error will occur. |
Name | One of the nine security keys on a branch (the parent) should take the name of the module. For example, BOM. The other keys (up to eight more on a branch) should have the name of the module followed by one of the following suffixes: Daily, Journals, Inquiries, Reports, Periodic, Setup, Misc, or Tables. For example, BOMReports, BOMSetup, and LedgerPeriodic. Enterprise Portal keys should have a prefix of EP followed by the name of the role. For example, EPAdmin and EPConsultant. Additional security keys for the role should take one of these suffixes: Misc, Info, Report, or Task. For example, EPAdminInfo and EPConsultantTask. Application Integration Framework (AIF) keys should be the same as the name used for the service. The format is the module that the service is contained in, the document name, followed by Service. For example, in the Sales module, SalesSalesOrderService. If you attempt to create a security key with a name that has already been used for a security key in Microsoft Dynamics AX, an error will occur. |
Label | Mandatory property. |
AnalysisVisibility | Mandatory property for top-level security keys (keys that have no parent key). Set to High for any key that corresponds to a core module in Microsoft Dynamics AX, for example, Ledger. Set to Low for keys associated with tables that will not usually be used for reporting. Set to None for keys associated with system functionality that should not be shown for end-user reporting. |
Configuration Keys
Configuration keys should be defined so that the installation can be set up with only the features needed for each particular installation. By disabling configuration keys, administrators can reduce the potential surface of attack, thereby helping to increase the security of their Microsoft Dynamics AX installation.
Configuration keys allow administrators to enable or disable features in the application for all users. Disabling features helps to minimize the attack surface against potential attacks.
Applying Configuration Keys
Configuration keys are applied to:
- Tables
- Fields
- Indexes
- Views
- Menus
- Menu items
- Form controls,
- Report controls
- Extended data types
- Enumerations
Creating Configuration Keys
To create a configuration key
- Expand the Data Dictionary node in the AOT.
- Right-click the Configuration Keys node, and then select New Configuration Key.
- Right-click the configuration key object, and then click Properties.
- Rename the configuration key by modifying the Name property.
- Right-click the object, and then click Create on the shortcut menu.
- Right-click the object, and then click Save on the shortcut menu.
- Right-click the object again, and then click Check In. This opens the Check in form.
Property | Rules |
ID | Always ship a configuration key with the same ID as it has been shipped with before. If you attempt to create a new configuration key with an ID that has already been used for a configuration key in Microsoft Dynamics AX, an error will occur. |
Name | Follow the standard Naming Conventions. If you attempt to create a configuration key with a name that has already been used for a configuration key in Microsoft Dynamics AX, an error will occur. |
Configuration and Security Keys Best Practice Checks
-HarryJanuary 02, 2013
How to Restrict Multiple Time login of a same user
Hi Folks,
Many times intentionally or unintentionally
a user may open multiple session of AX. That surly impact your performance. So
here is a fix,
1. Go to AOT
2.
Open class ‘Info’
3.
Copy Paste the Following Code in startupPost method.
void startupPost ()
{
// To restrict user login form second login
xSession session;
SysClientSessions SysClientSessions;
UserId currentUserId;
int counter;
;
currentUserId = curUserId();
if(currentUserId!="Admin")// only Admin
User is allowed to login multiple time
{
while select SysClientSessions
where SysClientSessions.userId == currentUserId
&&
SysClientSessions.Status == 1 // 1 : Login 0 :
Logout
{
session = new xSession(SysClientSessions.SessionId,
true);
if (session && session.userId())
{
counter++;
}
}
if(counter>=2)
{
Box::stop("Already Logged-in : The same user id
can't log in twice.");
infolog.shutDown(true);
}
}
}
Please take backup of your application before copying code
-Harry
void startupPost ()
Please take backup of your application before copying code
-Harry
December 05, 2012
Dynamics Ax Layers
Dynamics Ax Layers
Dynamics AX 2009 consists of sixteen application object layers that contain all theelements you see in the AOT.
These layers can be looked at as an onion with multiple layers. In the middle is the
core application in the SYS layer and the outermost layer is the user layer USR.
Therefore, when any application element is being executed the system will look at
the outermost code layer first to see if there is any code for that element; if not, it peels a layer off the onion, and tries the next layer. When it hits a layer where the element exists, it will use the code from this layer, and will not continue to peel off layers to find code for that element in the innermost layers.
Layers with their description
SYS The standard application is implemented at the lowest level,
the SYS layer.The application objects in the standard
application can never be deleted.
GLS Country/region specific changes will be developed in GLS
Layer.For e.g as you all know that Tax structure differs
from country to country.So such localization functionality
can be developed in GLS layer.
HFX HFX is an application object patch layer reserved by
Microsoft for future patching or other updates.
SL1, SL2,or SL3 A layer where the distributor can implement
vertical partner solutions.
BUS When a business partner creates their own generic solution,
their modifications are saved in the BUS layer and the top-
level application objects are used.
VAR Value Added Resellers (VAR) can make modifications or new
developments to the VAR layer as specified by the customers
or as a strategy of creating an industry-specific solution.
Such modifications are saved in the VAR layer.
CUS The supervisor or administrator of an end user installation
might want to make modifications that are generic to the
company. Such modifications are saved in the CUS (CUStomer)
layer.
USR End users might want to make their own modifications, such
as in their reports.These modifications are saved in the USR
layer.
-Harry
November 16, 2012
How to run Client Batches on AX 2009
How to run Client Batches on AX 2009
In AX 2009 the batch engine has been changed to run as a service.The batch services do only process server batches they don't process client batches aynmore.
There might still be some situations where you would like to run client batches.
The following description explains how to do this.
- Create a new batch group 'Client' which is used for client batches later.
(Administration -> Setup -> Batch groups) - Add this batch group to an AOS acting as batch server.
(Administration -> Setup -> Server configuration)
This is needed to change the status from 'Waiting' to 'Ready' on the batch tasks and to 'Execute' on the batch jobs.
The batch server will not process any client batches. - Start the legacy batch client
(Basic -> Periodic -> Batch -> Processing) - Select the new created batch group 'Client' and press 'OK'
-Harry
November 08, 2012
Create Alert using X++ codes
Create Alert using X++ codes
Try following code......
static
void
CreateAlertUsingCode(Args _args)
{
EventInbox inbox;
;
inbox.initValue();
inbox.ShowPopup = NoYes::Yes;
inbox.Subject =
"This is the Alert subject"
;
inbox.Message =
"This is the Alert message"
;
inbox.AlertedFor =
"This alert is just information no links are available"
;
inbox.SendEmail =
false
;
inbox.UserId = curuserid();
inbox.TypeId = classnum(EventType);
inbox.AlertTableId = tablenum(Address);
inbox.AlertFieldId = fieldnum(Address, Name);
inbox.TypeTrigger = EventTypeTrigger::FieldChanged;
inbox.CompanyId = curext();
inbox.InboxId = EventInbox::nextEventId();;
inbox.AlertCreatedDateTime = DateTimeUtil::getSystemDateTime();
inbox.insert();
}
- Harry
September 08, 2012
Security Keys in Ax
Security Keys in Ax
Dynamics Ax provides following keys to provide the security for your application1.License Keys :
It is the First Level Security , specifies what all featues/modules/developemnt tools we can access in the standard product. License Keys will be used after installation to unlock the product. License Keys will be issued by the microsoft for partners/vendors to develop vertical/generic solutions.
2.Configuration Keys :
It is Second Level Security , To Enable/Disable the object/feature for all the users.
3.Security Keys :
These keys used for enable/disable any object/features to group of users.
4. Record Level security :
Basically it deals with the data , if you want to restrict the viewing of records per user group than we setup record level security.
-Harry
August 08, 2012
Update multiple records with 'Fill Utility'
Update multiple records with 'Fill Utility'
Note:- FOLLOW THIS STEPS ON YOUR OWN RISK,I WILL NOT BE RESPONSIBLE FOR ANY GOOF UPS. SO PLZ BE CAREFULL DURING THESE STEPS.The Fill utility enables authorized users and/or administrators to mass-update records, similar to the find and replace functionality. We can use an alternative method also to Update Multiple records in Grid.
this utility assists administrators or users during implementations/Development or when business process changes affect multiple records.
Cautions:
1> It is recommended practice to take backup of entire database before performing this 'Fill Utility' operation.
2> It is recommended to use this feature during implementations/Development (or) when business process changes affect multiple records.
3> Please follow the standard procedure to enable this configuration. This may require restart of AOS & Data dictionary sync to make sure changes take immediate effect.
4> Be aware that changing numerous records at the same time can be time-consuming.
Enable configuration key:
Path: Dynamics Ax > Administration > Setup > System > Configuration > Under Administration tree (Enable 'Fill Utility' option)
Fill Utility usage:
Open the form that contains the field to update.
Example: Dynamics Ax > Accounts Receivable > Common forms > Customer details > Select required customer record > payment tab
Right click on the field 'Ledger account' field > Record info
Click button 'Fill Utility'
We can select the criteria here
Click button 'OK'
Validate the records and click 'OK'
Select new 'Terms of payment' = N045 (here we have to specify new terms of payment)
Click 'OK'
Caution: Be aware that changing numerous records at the same time can be time-consuming.
Fill Utility log:
Path: Dynamics Ax > Basic > Inquiries > Fill Utility log
Security key: Adminfillutility
This completes 'Fill Utility' feature details from usage.
This a very useful to update multiple records at the same time.
- Harry