Share This Post

Troubleshooting On-premises Deployments – Part 4

With MS Dynamics 365 On-premises Deployments, business processes and transactions can be managed in your local data centers and the business data can be accumulated in an own or a partners data center, without the replication and connection of business data into the Microsoft cloud.

This article is a continuation of Troubleshooting Dynamics 365 F&O On-premises Deployments. On-Premise Microsoft Dynamics 365 is essentially deployed on private servers, ensuring absolute control and management of the huge information stored on the internal databases.

Troubleshooting Dynamics 365 On-premises Deployments Steps (Continued)

31. An “Unable to Find Certificate” Error Occurs when you Run Test-D365FOConfiguration.ps1

If you receive an “Unable to find certificate” error when you run Test-D365FOConfiguration.ps1, check whether certificates or thumbprints are being combined for multiple purposes. For example, you will receive this error if the client certificate and the SessionAuthentication certificate are combined.

We recommend that you not combine certificates. For more information, see the certificate requirements, and check the acl.csv file for domain.com\user versus domain\user (for example, NETBIOS structure).

32. The Client and Server can’t Communicate because they don’t have a Common Algorithm

If the client and server can’t communicate because they don’t have a common algorithm, verify that the certificates that are created use the specified provider, as explained in the “Plan and acquire your certificates” section of the appropriate setup and deployment for your environment.

33. Find a List of Group Managed Service Accounts

To find a list of all groups and hosts, run the following command.

Get-ADServiceAccount -Identity svc-LocalAgent$ -Properties PrincipalsAllowedToRetrieveManagedPassword

34. AddCertToServicePrincipal Script Fails on Import-Module

Error:

AddCertToServicePrincipal script failing on Import-Module : Could not load file or assembly ‘Commands.Common.Graph.RBAC, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) may have multiple versions of the same module installed.

Steps: To resolve this issue, follow these steps.

  • Run the following command in Windows PowerShell.

Uninstall-Module -Name AzureRM
Install-Module AzureRM

  • Close the Windows PowerShell window, and try to run the script again.

35. ReportingServicesSetup.exe Error

Error:

ReportingServicesSetup.exe Error: 0 : Application fabric:/ReportingService is not OK after 10 minutes
Application: ReportingServicesBootstrapper.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.

Reason: If you receive this error, strong name validation is enabled in the Reporting server, but it should not be enabled.

Steps: To resolve this issue, run the config-PreReq script on the Reporting server machine.

36. Apply Deployable Packages During Deployment

Package deployment fails because of a “path too long” exception

Because of a 260-character limit in Microsoft Windows, deployment will fail if a package has a longer name, or if the Dynamics 365 On-premises Deployments share has the full FQDN path. If the character limit is greater than than mentioned, you will get the following error:

System.IO.PathTooLongException: The specified path, file name, or both are too long. Fully qualified file name must be lesser than 260 characters and the directory name must be lesser than 248 characters. at System.IO.PathHelper.GetFullPathName

To work around this issue, shorten the package name and then apply the package again. Alternatively, shorten the overall length of the share path for the Dynamics 365 On-premises Deployments assets.

Package deployment fails because of a serialization error

During package deployment, you might receive the following error:

Serialization version mismatch detect, make sure the runtime DLLs are in sync with the deployed metadata. Version of file ‘XXX’. Version of DLL ‘XXX’

In this scenario, the version of the environment where the package was developed might vary from the version of the environment that the package is being deployed in.

To resolve this issue, keep the development or build environments on the same version as the deployed on-premises environment. You can check the package version by looking in the Additional details section in the Asset library where the package is uploaded.

To fix the error, generate the package on a version that is the same as or earlier than the version that is deployed in the Dynamics 365 On-premises Deployments environment.

Package deployment works in a one-box environment but not in the sandbox environment

A one-box environment might have all the modules installed, whereas the sandbox environment might have only the modules that are required in order to run your production environment.

If the package that was built in the dev environment has a dependency on modules that are present in the one-box environment but not in the sandbox environment, the package won’t work in the sandbox environment.

To resolve this issue, look at all the modules that you’re dependent on, and make sure that you don’t pull any farm adapter or any other module that isn’t required in the production environment. The best practice is to take the package from the build box.

37. An Error Occurs when you Sign in to On-premises Environments

  • Platform update 12: Turn off the Skype integration by going to System administration > Setup > Client performance options. When you go to the app, append ?debug=true to the URL, as shown in the following example: https://ax.d365ffo.onprem.contoso.com/namespaces/AXSF/?debug=true
  • Platform update 8 and Platform update 11: A known issue for the Skype application programming interface (API) affects the ability to sign in to Dynamics 365 On-premises Deployments environments. Microsoft is investigating a resolution for this issue. To resolve this issue, you can add ?debug=true to the end of the URL, as shown in the following example: https://ax.d365ffo.onprem.contoso.com/namespaces/AXSF/?debug=true

38. The Local Agent Stops Working after the Tenant for the Project from LCS is Changed

Follow these steps to configure the local agent with the updated tenant.

  • Uninstall the local agent.

.\LocalAgentCLI.exe Cleanup <path of localagent-config.json>

  • Follow the steps in the “Configure LCS connectivity for the tenant” section of the appropriate setup and deployment for your environment.
  • Create a new LCS connector in the new tenant.
  • Download the local-agent.config file.
  • Install the local agent.

.\LocalAgentCLI.exe Install <path of localagent-config.json>

39. Redeploy SSRS Reports

Delete the entry in SF.SyncLog, and then restart one of the AOS machines. The AOS machine will execute DB Sync again and then deploy reports.

40. Add axdbadmin to tempdb after a SQL Server Restart via a Stored Procedure

When SQL Server is restarted, the tempdb database is re-created. Therefore, there will be missing permissions. Run the following script to create a stored procedure on the master database.

\—–
USE [master]
GO
CREATE procedure [dbo].[CREATETEMPDBPERMISSIONS] as begin exec (‘USE tempdb; declare @dbaccesscount int; select @dbaccesscount = COUNT(*) from master..syslogins where name = ”axdbadmin”; if (@dbaccesscount <> 0) exec sp_grantdbaccess ”axdbadmin”; ALTER USER [axdbadmin] WITH DEFAULT_SCHEMA=dbo; EXEC sp_addrolemember N”db_datareader”, N”axdbadmin”; EXEC sp_addrolemember N”db_datawriter”, N”axdbadmin”; EXEC sp_addrolemember N”db_ddladmin”, N”axdbadmin”; exec sp_grantdbaccess ”contoso\svc-AXSF$”; ALTER USER [contoso\svc-AXSF$] WITH DEFAULT_SCHEMA=dbo; EXEC sp_addrolemember N”db_datareader”, N”contoso\svc-AXSF$”; EXEC sp_addrolemember N”db_datawriter”, N”contoso\svc-AXSF$”; EXEC sp_addrolemember N”db_ddladmin”, N”contoso\svc-AXSF$”;’) end
GO
EXEC sp_procoption N'[dbo].[CREATETEMPDBPERMISSIONS]’, ‘startup’, ‘1’
\—–

41. The Internal Time Zone Version Number that is Stored in the Database is Higher than the Version that is Supported by the Kernel (13/12)

This database synchronization error can cause an old platform build (Platform update 12) to be deployed on top of a database that had a newer build (Platform update 15).

To resolve this issue, note the SYSTIMEZONESVERSION value.

select * from SQLSYSTEMVARIABLES where parm = ‘SYSTIMEZONESVERSION’

Update the value to the version that was returned in the error message.

update SQLSYSTEMVARIABLES set VALUE = 12 where parm = ‘SYSTIMEZONESVERSION’

42. Printing Randomly Stops

Make sure that all network printers that have been installed on the AOS server are running as the Windows service account that the AXService.EXE process is running as.

43. Ax-DatabaseSynchronize is not Populated with the Events

In Platform update 20 and later there is database integration log issue where the synchronization logs aren’t written under Ax-DatabaseSynchronize in Event Viewer.

To resolve this issue, go to <SF-dir>\AOS_<x>\Fabric\work\Applications\AXSFType_App<X>\log. For example, go to C:\ProgramData\SF\AOS_11\Fabric\work\Applications\AXSFType_App183\log. Here, you can see the output from DatabaseSynchronize in the Code_AXSF_M_<X>.out files. Troubleshoot any issues that pertain to this component.

44. Error: There was an Error During CodePackage Activation. Service Host Failed to Activate. Error:0x8007052e

You might get the following error during a new installation:

Error event: SourceId=’System.Hosting’, Property=’CodePackageActivation:Code:EntryPoint’. There was an error during CodePackage activation.Service host failed to activate. Error:0x8007052e

This error will cause the AXSF service to fail with the same error. To resolve this issue, follow these steps.

  • In the agent share path, find the netstandard.dll file. For example, this file might be at \wp\<name>\StandaloneSetup-<ver>\Apps\AOS\AXServiceApp\AXSF\Code\bin\netstandard.dll.
  • On each AOS server, open a Command Prompt window as an administrator, and run the following command.

“C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\gacutil.exe” -i <path from step 1.>\netstandard.dll /f

  • Delete AXBootstrapperApp from Service Fabric.
    • Delete the fabric:/Bootstrapper/AXBootstrapper service.
    • Remove the fabric:/Bootstrapper application.
    • Unprovision the AXBootstrapperAppType type.
  • Redeploy the environment from LCS.

When you go through LCS servicing operations, you might receive the following error:

The process cannot access the file ‘C:\Program Files\Microsoft SQL Server\MSRS13.MSSQLSERVER\Reporting Services\ReportServer\bin\Microsoft.Dynamics.AX.Framework.Services.Platform.Client.dll’ because it is being used by another process.

This issue occurs because Reporting Services has a lock on a Microsoft Dynamics .dll file. You must have service pack 2 installed and no additional cumulative updates or hot fixes must be installed.

For more information on Microsoft Dynamics 365 F&O On-premises Deployments Troubleshooting, please contact us. For getting the continuation of the previous steps please refer to the previous articles: https://msdynamics.net/dynamics-deployments/troubleshooting-on-premises-deployments-part-1/ and https://msdynamics.net/dynamics-deployments/troubleshooting-on-premises-deployments-part-2/ and https://msdynamics.net/dynamics-deployments/troubleshooting-on-premises-deployments-part-3/

Share This Post

Leave a Reply

avatar
  Subscribe  
Notify of
Skip to toolbar