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
User SID (GUID)
Server Instance ID
Event Type (Logon, Logoff, Start, Stop, Close)
Client Type (Windows Client, Sharepoint Client, Web Service, Client Service, NAS, Background, Management Client, Web Client, Unknown, Table, Phone, Desktop)
Client Computer Name
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 andSpecifies 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.
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:
Some further investigation learned this new parameter has 3 options:
0: Saves the change to the configuration file of the server instance. The
change will not take effect until the server instance is restarted.
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
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'
During development I reveived this error ‘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.
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.
your BC service should start without problems now.
Dynamics NAV, SQL Server, Windows Server and PowerShell