All posts by Ibrahiem Rasoelbaks

I'm a Technical Consultant working at 4PS.

The trust relation between this workstation and the primary domain failed

After restoring my Hyper-V machine the following message appeared:

The trust relationship between this workstation and the primary doain failed.

To fix this, log in with the Local Administrator account and perform the following commands:

Windows PowerShell

Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\Users\Administrator> netdom resetpwd /server:dc01
/userD:Administrator /passwordD:*

Type the password associated with the domain user:

The machine account password for the local machine has been successfully reset.

The command completed successfully.

PS C:\Users\Administrator> nltest /


Trusted DC Name \\

Trusted DC Connection Status Status = 0 0x0 NERR_Success

Trust Verification Status = 0 0x0 NERR_Success

The command completed successfully


Retrieve information with Business Central Administration Shell

The following cmdlets are at your disposal to retrieve information from the Business Central server configuration:

Module: Microsoft.Dynamics.Nav.Management

  • Get-NAVWebServerInstance: shows info about installed webclients
  • Get-NAVWebServerInstanceConfiguration: shows key values from navsettings.json
  • Get-NAVAddIn: shows registered addins in BC
  • Get-NAVApplication: shows the databaseserver, database name, applicationversion, applicationfamily
  • Get-NAVCompany: retrieves all NAV companies
  • Get-NAVDataFile: extract information from a Business Central data file
  • Get-NAVDataUpgrade: shows information about the dataupgrade, like functioncount, executionmode, progress, erros, details, state etc
  • Get-NAVServerAppConfiguration: returns the settings in an application-specific configuration file of a Business Central Server instance
  • Get-NAVServerConfiguration: shows configuration information about the server instance configuration
  • Get-NAVServerInstance: shows a list of all serverinstances, state, serviceaccount, version
  • Get-NAVServerPermission: gets the list of permissions
  • Get-NAVServerPermissionSet: gets the list of permission sets
  • Get-NAVServerSession: shows information about sessions (like users) connected to a certain server instance
  • Get-NAVServerUser: gets a list of users and related info like SID, State etc.
  • Get-NAVServerUserPermissionSet: returns permission set information for users
  • Get-NAVTableConnection: gets a list of connections to external database tables
  • Get-NAVTenant: shows information about the tenant
  • Get-NAVTenantDatabase: gets information about one or more tenant databases when using multi-tenancy
  • Get-NAVWebService: shows information about published webservices (for example objectid, objecttype, servicename, published)

Module: Microsoft.Dynamics.Nav.Apps.Management

  • Get-NAVAppInfo
  • Get-NavAppRuntimePackage
  • Get-NAVAppTableModification
  • Get-NAVAppTenant

These cmdlets are only available if you start the Administration Shell:

If you don’t (want to) use the Administration Shell and are using VS Code or PowerShell ISE for example please import the modules by running this PowerShell Cmdlet:

Import-Module 'C:\Program
Files\Microsoft Dynamics 365 Business Central\130\Service\NavAdminTool.ps1' 

Session Event table in Business Central

In the D365 Business Central database and previous NAV versions up to NAV 2013 you will find a table called ‘Session Event’. In this table session event information is stored:

When I start or close the Windows Client for example this will be logged in the Session Event table. The Session event table contains the following fields:

  • User SID (GUID)
  • Server Instance ID
  • Session ID
  • Event Type (Logon, Logoff, Start, Stop, Close)
  • Event Datetime
  • Client Type (Windows Client, Sharepoint Client, Web Service, Client Service, NAS, Background, Management Client, Web Client, Unknown, Table, Phone, Desktop)
  • Database Name
  • Client Computer Name
  • User ID
  • Comment
  • Session Unique ID (GUID)

Investigation at customer premises learns that this table could sometimes contain a lot of records (millions). Root cause could be due to extensive webservice calls that are being triggered or not optimal service tier settings. This could lead to problems sometimes.

In the fields mentioned you could also see that webservice calls are being logged in the Session Event table. Interesting especially for support ocassions is to notice which user(s) were affected by a service tier that was manually stopped. That will be logged also. In the comment field you will see this value then a service tier was stopped. When the user was connected to this stopped service tier this will be logged in the Session Event table:

The next question now rises: how is this table managed by Business Central? In Business Central there are some settings for management of the Event Session table. They are to be found in the General Tab of the service tier:

Non-Interactive Sessions Log Retain Time Interval
This is a new setting introduced in Business Central and Specifies the time interval that background and web service sessions remain in the Session Event table before they are deleted. This value has format d.hh:mm:ss. This is a very nice feature to keep control of the record count in the session event table.

Session Event Table Retain Time Interval
This setting is available since NAV2013+ and specifies the time interval that sessions in the Session Events table remain before they are deleted. This value has format d.hh:mm:ss.

Business Central System Configuration Dynamically Updateable (NST Settings)

As we all know: if you configure the Business Central service tier from the Administration tool you could receive this message when clicking on the Save button:

To take the new settings into effect the service needs to be restarted, this needed when changing for example the database name or enabling SOAP or OData webservices.

But some settings are now what Microsoft calls ‘dynamically updateable’. This is a really nice feature, because changing certain settings now don’t require a restart. For example if I change the setting ‘EnableFullALFunctionTracing’ for example you will now get new information from both the Administration tool and ofcourse from the PowerShell cmdlet:

‘ApplyTo’ Message from the Business Central Administration Tool
‘ApplyTo’ Message from the Business Central Administration Shell

Some further investigation learned this new parameter has 3 options:

  • All
  • ConfigFile
  • Memory

Copied this from Microsoft Docs:

ConfigFile or 0: Saves the change to the configuration file of the server instance. The change will not take effect until the server instance is restarted.

Memory or 1: The setting change is just applied to the server instance’s current setting state. This is only applicable for server settings which support dynamic updating. If the specified setting is not dynamically updateable this command will fail.

All or 2: Applies the change to the server instance’s current setting state (in memory) and to the configuration file. This is only applicable for server settings that support dynamic updating. If the setting does not support dynamic updating, the cmdlet will fail with an error. The change will not be applied to the current session or the configuration file.

Finally an example to use this parameters in VS Code, PowerShell ISE or the Business Central Administration Shell for example:

Import-Module 'C:\Program Files\Microsoft Dynamics 365 Business Central\130\Service\NavAdminTool.ps1'
Set-NAVServerConfiguration -ServerInstance 'BCS130Test' -KeyName 'EnableFullALFunctionTracing' -KeyValue 'True' -ApplyTo 'All'

Keep in mind that only certain settings are dynamically updatable. Most settings still require a restart after a change.

Error ‘The type NavDecimal is unknown’

During development I reveived this error ‘The type NavDecimal is unknown’:

The type NavDecimal is unknown

The error was triggered by renaming the primary key field. I tried to troubleshoot this by starting the debugger but this had no effect because my OnRename trigger didn’t had any logic. After some searching on my favorite forums Dynamics Community and Mibuso Forum I found similar errors but mine was different because I didn’t had any triggercode yet. After thorough investigation I found out that this problem was related to another old table which referred to my problemtable (Table Relation). After cleaning up the old unused table the problem was solved. It took me some time to figure this out so I thought it’s worth sharing this.

ServerInstance failed to reach status ‘Running’

In one of my previous posts I described how to install D365 Business Central. When performing an installation from scratch at customer site on their server I always choose to install without specifying any service account. This will ensure almost always a 100% succesfull install in the first time. Two other main reasons:

  • If the customer hasn’t arranged a serviceaccount yet or made a configuration mistake I can still install. This will minimize lost time ensures that an installation will always be performed. As always please to try prepare as many tasks as possible to ensure a succesfull install. You could do an prerequiste check with some kind of checklist of intakeform.
  • If the serviceaccount has a problem the setup will error and perform a rollback. This is a waste of precious time (rollback time is a lenghty proces in my opinion) and the problem has to be fixed and the setup has to be performed again.

So the very next thing to do after the setup is to change the serviceaccount for the server instance. This however introduces a problem because the serverinstance won’t start then:

Textual error:
ServerInstance ‘MicrosoftDynamicsNavServer$NST130Test’ failed to reach status ‘Running’

When checking the Windows Application log I see below is causing the problem:

Server instance: NST130Test
Cannot create the path C:\ProgramData\Microsoft\Microsoft Dynamics NAV\130\Server\MicrosoftDynamicsNavServer$NST130Test\assembly for this service instance. Make sure that permissions are set up correctly for the service account.

This means the serviceaccount has no permissions to create the path. The next thing to do then is to grant the serviceaccount Modify permissions on the C:\ProgramData\Microsoft\Microsoft Dynamics NAV\130\Server folder.

Theoretically your BC service should start without problems now.