D365 Finance and Operations: The request channel timed out while waiting a reply after 00:59:59.

Récemment, j’écrivais un article sur comment trouver les messages d’erreur lors de l’exécution d’une job export entity to database qui échoue: Export failed while copying data from target to staging.

J’ai diagnostiqué un autre cas ou l’export échouait avec l’erreur suivante:

The request channel timed out while waiting a reply after 00:59:59. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding.

Dans une architecture WCF, la valeur du SendTimeout est établie par le client. Dans ce cas-ci, le client est le service AOS et le serveur est Data Import Export Framework service. Afin de modifier la valeur du SendTimeout du côté client, il faut modifier le fichier suivant:

Fichier: Microsoft.Dynamics.AX.Framework.Tools.DMF.ServiceProxy.dll.config

Microsoft-Hosted
  • G:\AosService\WebRoot\bin\
Cloud-Hosted
  • K:\AosService\WebRoot\bin

Ensuite il faut redemarrer IIS.

Dynamics AX 2012 R3: An error (1332) occurred while enumerating the group membership.

Lors du déploiement des rapports SSRS d’un environnement Dynamics AX 2012 R3, j’ai reçu le message d’erreur suivant:

Warning: The security group Administrator contains a member that is causing the following error : An error (1332) occurred while enumerating the group membership. The member’s SID could not be resolved.



L’erreur m’empêchait de déployer les rapports SSRS. Une recherche sur Internet indique que le paramètre -SkipReportServerAdminCheck pour faire partie de la solution, mais je n’ai pas essayer.

Ensuite, je sais que mon compte était membre d’un groupe de domaine et ce groupe était membre du groupe administrateur local. Donc, j’étais bel et bien administrateur de la machine, mais comme le message l’indique, il y a un problème lors de l’énumération des membres du groupe administrateur local. L'erreur est explicite, il semble y avoir un membre du groupe administrateur local qui n’existe plus dans l’Active Directory et ceci cause probleme, mais j’ai oublier de vérifier cela avant d’appliquer la solution suivante: j’ai ajouté mon compte dans le groupe administrateur local et ensuite j’ai fait le déploiement et ça l’a fonctionner.

D365 for Finance and Operations: Export failed while copying data from target to staging

Un utilisateur rapporte un problème lors de l’exécution d’une job export entity to database. La tache rapporte un warning, mais lorsqu’on clique sur Execution Details, on peut y voir que certaines entités ont complètement échoué.




Afin de voir les détails de l’échec, on peut cliquer sur View execution log.


Toutefois, il n’y a rien dans la section log text.


Dans ce cas, je suis chanceux, ce n’est un environnement de production et je peux aller sur le serveur AOS. Je peux y trouver l’information dans le journal d’évènement sous Application and Services Logs > Microsoft > Dynamics > AX-DIXFRuntime

Dans ce cas-ci, voici les erreurs que j’ai trouvées:

Export failed while copying data from target to staging

Exception from HRESULT: 0xC0010009



Pour corriger ce problème, il faut augmenter la valeur du SqlCommandTimeOut du fichier DMFConfig.xml  qui se trouve dans: 
  • C:\Program Files (x86)\Microsoft Dynamics AX\70\DataImportExportFramework\


Ensuite, il faut redemarrer les services Batch Management Service et Data Import Export Framework Service.

Power BI : Tenant identifiers may not be an empty GUID

J’effectuais des tests dans mon labo et je voulais utiliser une base de données Azure SQL comme source de données pour Power BI Desktop. Afin de m’authentifier, je voulais utiliser mon compte Azure Active Directory


Toutefois, j’obtenais toujours le message d’erreur suivant:

AADSTS90002: Requested tenant identifier ‘00000000-0000-0000-0000-000000000000’ is not valid. Tenant identifiers may not be an empty GUID.


Je savais qu’il faut configurer un Azure AD Admin sur le serveur Azure SQL via le portail afin de supporter l’authentification AAD. Disons que j’ai chercher longtemps la raison pourquoi ce ne fonctionnais pas parce que je croyais que j’avais configure un Azure AD Admin. Eh bien, je ne l’avais pas faite et c'est la raison pour laquelle je recevais ce message d’erreur.


D365 for Finance and Operations: Grosseur de la base de données de production

Afin de connaitre la grosseur de la base de données Azure SQL d’un environnement de production, il suffit d’aller dans le Projet LCS et cliquer sur Full Details sous l’environnement de production.


Ensuite, cliquer sur Full system diagnostics dans la section Monitoring.


Ensuite, cliquer sur Report et sélectionner l’envionment de Production.



Dans la section Ax Database File, vous allez y trouver la grosseur des fichiers de la base de données.



Prenez ce chiffre * 8 / 1024 / 1024 et ça vous donne la grosseur de la base de données en GB.

115505152 * 8 / 1024 / 2014 = 881.23 GB