How to use a recurring Integration Endpoint for importing data
D365FFO On-Prem: ConfigTemplate.xml Deep Dive
The initial document and ConfigTemplate.xml from Microsoft and LCS is actually pretty good. The instructions are somewhat high level in some areas leaving a few details out and also there is very little assistance when it comes to the configTemplate.xml file. Below are some additions I made to the standard file from LCS which I hope will help others. It is also available for download if you prefer.
<?xml version="1.0" encoding="UTF-8"?>
<!-- Configuration Template for a Microsoft Dynamics 365 for Operations, On-premises deployment
with additions from @NathanClouseAX from atomicax.com
This is an example of a 7-node cluster without a sub domain and none of the extra hassle that can entail
Domain: atomicax.com
AOSs:
TESTAOS01, TESTAOS02, TESTAOS03
192.168.1.100, 192.168.1.101, 192.168.1.102
Orchestrators:
TESTORCH01, TESTORCH02, TESTORCH03
192.168.1.110, 192.168.1.111, 192.168.1.112
SSRS:
TESTSSRS01
192.168.1.120
MR:
TESTMR01
192.168.1.130
-->
<Config>
<ADServiceAccounts>
<!-- the short version for the domains upper most level. If you have sub.domain.com, you would still use just "domain" rather than "sub.domain"
or "contoso" rather than testAX.contoso.com -->
<DomainName>atomicax</DomainName>
<!-- Local Deployment Agent Service Account
Naming: A quick callout here is we have a limit of 15 characters for service names so you should establish your nomenclature for all different environments with that in mind.
If you want to have a local agent account per environment, you'll need to change this to something like svc-SFCLATEST$ for service fabric cluster local agent for TEST or svc-SFCLASAND for a sandbox -->
<ADServiceAccount type="gMSA" name="svc-LocalAgent$" refName="gmsaLocalAgent">
<DNSHostName>svc-LocalAgentd365ffo.atomicax.com</DNSHostName>
</ADServiceAccount>
<!-- Financial Reporting Application Service Account -->
<ADServiceAccount type="gMSA" name="svc-FRAS$" refName="gmsaFRAS">
<DNSHostName>svc-FRASd365ffo.atomicax.com</DNSHostName>
</ADServiceAccount>
<!-- Financial Reporting Process Service Account -->
<ADServiceAccount type="gMSA" name="svc-FRPS$" refName="gmsaFRPS">
<DNSHostName>svc-FRPSd365ffo.atomicax.com</DNSHostName>
</ADServiceAccount>
<!-- Financial Reporting Click Once Designer Service Account -->
<ADServiceAccount type="gMSA" name="svc-FRCO$" refName="gmsaFRCO">
<DNSHostName>svc-FRCOd365ffo.atomicax.com</DNSHostName>
</ADServiceAccount>
<!-- AOS Service Account - gMSA -->
<ADServiceAccount type="gMSA" name="svc-AXSF$" refName="gmsaAXSF">
<DNSHostName>svc-AXSFd365ffo.atomicax.com</DNSHostName>
</ADServiceAccount>
<!-- AOS Service Account - Domain Account
I also recomend that you create a domain account called AXAdmin and protect all certs to the domain admin and AXAdmin accounts. Details below.-->
<ADServiceAccount type="DomainUser" name="svc-axtest" refName="axserviceuser" />
</ADServiceAccounts>
<Certificates>
<!--
Attribute: generateSelfSignedCert
True: When true, a self signed cert will be generated by command .\New-SelfSignedCertificates.ps1 -ConfigurationFilePath .\ConfigTemplate.xml from https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/deployment/setup-deploy-on-premises-pu12#configurecert
False: Use this when you already have a cert that you would like to use. For instance, the localAgent cert is generated once and reused so you will generate one for your first environment but not for your second. -->
<Certificate type="ServiceFabric" exportable="true" generateSelfSignedCert="true">
<!-- Specify the friendly name of the certificate during import operations -->
<Name>stard365ffo.atomicax.com</Name>
<!-- Specify the file name of the pfx that will be used in export and import operations. If not specified, the name property will be used -->
<FileName>stard365ffo.atomicax.com</FileName>
<!-- Specify the dns names for ax, service fabric and the wild card for the dns zone created to host these services -->
<DNSName>axd365ffo.atomicax.com;sfd365ffo.atomicax.com;*.atomicax.com</DNSName>
<Subject>*.atomicax.com</Subject>
<Thumbprint></Thumbprint>
<!-- Specify list of semi-colon seperated domain users or group (e.g. contoso\adminuser) that will be given permission to access the pfx files without a password.
Protecting these to the domain admin guarantees you'll be able to move them around with that account but I also recommend that the service account for the environment be on the protectTo list as well as the generic AXAdmin account.
The protectTo user can import and export the certs as needed without a password so this makes the certs portable to a subset of users-->
<ProtectTo>atomicax\administrator;atomicax\svc-axtest;atomicax\axadmin</ProtectTo>
</Certificate>
<Certificate type="ServiceFabricClient" exportable="true" generateSelfSignedCert="true">
<!-- This is the cert referenced in the last item here: http://www.atomicax.com/article/d365ffo-prem-suggestions-based-few-installs -->
<Name>clientd365ffo.atomicax.com</Name>
<Thumbprint></Thumbprint>
<ProtectTo>atomicax\administrator;atomicax\svc-axtest;atomicax\axadmin</ProtectTo>
</Certificate>
<Certificate type="ServiceFabricEncryption" exportable="true" generateSelfSignedCert="true">
<Name>axdataenciphermentcert</Name>
<Thumbprint></Thumbprint>
<ProtectTo>atomicax\administrator;atomicax\svc-axtest;atomicax\axadmin</ProtectTo>
<Provider>Microsoft Enhanced Cryptographic Provider v1.0</Provider>
<CertificateType>DocumentEncryptionCert</CertificateType>
<KeyUsage>DataEncipherment</KeyUsage>
</Certificate>
<Certificate type="SessionAuthentication" exportable="true" generateSelfSignedCert="true">
<Name>SessionAuthentication</Name>
<Thumbprint></Thumbprint>
<ProtectTo>atomicax\administrator;atomicax\svc-axtest;atomicax\axadmin</ProtectTo>
</Certificate>
<Certificate type="DataEncryption" exportable="true" generateSelfSignedCert="true">
<Name>DataEncryption</Name>
<Thumbprint></Thumbprint>
<ProtectTo>atomicax\administrator;atomicax\svc-axtest;atomicax\axadmin</ProtectTo>
</Certificate>
<Certificate type="DataSigning" exportable="true" generateSelfSignedCert="true">
<Name>DataSigning</Name>
<Thumbprint></Thumbprint>
<ProtectTo>atomicax\administrator;atomicax\svc-axtest;atomicax\axadmin</ProtectTo>
</Certificate>
<Certificate type="FinancialReporting" exportable="true" generateSelfSignedCert="true">
<Name>FinancialReporting</Name>
<Thumbprint></Thumbprint>
<ProtectTo>atomicax\administrator;atomicax\svc-axtest;atomicax\axadmin</ProtectTo>
</Certificate>
<Certificate type="ReportingService" exportable="true" generateSelfSignedCert="true">
<Name>ReportingService</Name>
<Thumbprint></Thumbprint>
<ProtectTo>atomicax\administrator;atomicax\svc-axtest;atomicax\axadmin</ProtectTo>
</Certificate>
<Certificate type="Orchestrator" exportable="true" generateSelfSignedCert="true">
<!-- This cert only needs to be created once then it will be reused for all other environments. Having a decent ProtectTo value here will prevent headaches later in other environments -->
<Name>OnPremLocalAgent</Name>
<Thumbprint></Thumbprint>
<ProtectTo>atomicax\administrator;atomicax\svc-axtest;atomicax\axadmin</ProtectTo>
</Certificate>
</Certificates>
<DbServer>
<Security>
<!-- userName is the actual SQL user used -->
<User refName="axdbadmin" type="SqlUser" userName="axdbTESTadmin" />
</Security>
</DbServer>
<Databases>
<!-- dbName is the actual name for the database -->
<Database refName="axDB" dbName="AXDBTEST">
<!-- The backup file must be placed in a folder/share where the user running the scripts and the user running SQL server process have read access
https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/deployment/setup-deploy-on-premises-pu12#configuredb
You have to import this into your LCS project as part of the demo data database. Read the link above carefully. -->
<BackupFile>\\atomcaxfile01\Test\backup\AxBootstrapDB_Empty.bak</BackupFile>
<DbTuning>
<DBFileGrowthMB value="200" />
<LogFileGrowthMB value="500" />
<LogFileSizeGB value="5" />
</DbTuning>
</Database>
</Databases>
<ServiceFabricCluster>
<!--
Service fabric documentation links
General guidance for on-premises service fabric cluster:
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-creation-for-windows-server
Service fabric prerequisites and determing fault and upgrade domains:
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-standalone-deployment-preparation
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-resource-manager-cluster-description
Cluster Certificate:
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-windows-cluster-x509-security
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security#x509-certificates-and-service-fabric
-->
<ClusterName>Dynamics365Operations - Test 7 Node Cluster</ClusterName>
<NodeType name="AOSNodeType" primary="false" namePrefix="AOS" purpose="AOS">
<VMList>
<!-- Name: should be the DNS name for that node.
IP address: should match the IP address for the DNS name
Fault Domain: This allows the node duties to be distributed when their is a fault. You should have each Orchestrator in a different fault domain or distribute them as much as possible. You should also do that with the AOSs.
Upgrade Domain: Similar to fault domains but applies to updates. You should have each Orchestrator in a different update domain or distribute them as much as possible. You should also do that with the AOSs
For more on Fault and Upgrade Domains, go to https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-resource-manager-cluster-description
This specific deployment would look like this when complete: https://twitter.com/NathanClouseAX/status/983507945492271104
-->
<VM name="TESTAOS01" ipAddress="192.168.1.100" faultDomain="fd:/fd0" updateDomain="ud0" />
<VM name="TESTAOS02" ipAddress="192.168.1.101" faultDomain="fd:/fd1" updateDomain="ud1" />
<VM name="TESTAOS03" ipAddress="192.168.1.102" faultDomain="fd:/fd2" updateDomain="ud2" />
<!-- reconfigure fds and uds
<VM name="TESTAOS04" ipAddress="192.168.1.103" faultDomain="fd:/fd3" updateDomain="ud3" />
<VM name="TESTAOS05" ipAddress="192.168.1.104" faultDomain="fd:/fd4" updateDomain="ud4" />
<VM name="TESTAOS06" ipAddress="192.168.1.105" faultDomain="fd:/fd5" updateDomain="ud5" />
<VM name="TESTAOS07" ipAddress="192.168.1.106" faultDomain="fd:/fd6" updateDomain="ud6" />
<VM name="TESTAOS08" ipAddress="192.168.1.107" faultDomain="fd:/fd7" updateDomain="ud7" />
<VM name="TESTAOS09" ipAddress="192.168.1.108" faultDomain="fd:/fd8" updateDomain="ud8" />
-->
</VMList>
</NodeType>
<NodeType name="OrchestratorType" primary="true" namePrefix="Orch" purpose="Orchestrator">
<VMList>
<VM name="TESTOR01" ipAddress="192.168.1.110" faultDomain="fd:/fd0" updateDomain="ud0" />
<VM name="TESTOR02" ipAddress="192.168.1.111" faultDomain="fd:/fd1" updateDomain="ud1" />
<VM name="TESTOR03" ipAddress="192.168.1.112" faultDomain="fd:/fd2" updateDomain="ud2" />
<!-- reconfigure fds and uds
<VM name="TESTOR04" ipAddress="192.168.1.113" faultDomain="fd:/fd3" updateDomain="ud3" />
<VM name="TESTOR05" ipAddress="192.168.1.114" faultDomain="fd:/fd4" updateDomain="ud4" />
<VM name="TESTOR06" ipAddress="192.168.1.115" faultDomain="fd:/fd5" updateDomain="ud5" />
<VM name="TESTOR07" ipAddress="192.168.1.116" faultDomain="fd:/fd6" updateDomain="ud6" />
<VM name="TESTOR08" ipAddress="192.168.1.117" faultDomain="fd:/fd7" updateDomain="ud7" />
<VM name="TESTOR09" ipAddress="192.168.1.118" faultDomain="fd:/fd8" updateDomain="ud8" />
-->
</VMList>
</NodeType>
<NodeType name="ReportServerType" primary="false" namePrefix="Rep" purpose="BI">
<VMList>
<VM name="TESTSSRS01" ipAddress="192.168.1.120" faultDomain="fd:/fd2" updateDomain="ud2" />
<!-- reconfigure fds and uds
<VM name="TESTSSRS02" ipAddress="192.168.1.121" faultDomain="fd:/fd1" updateDomain="ud1" />
<VM name="TESTSSRS03" ipAddress="192.168.1.122" faultDomain="fd:/fd2" updateDomain="ud2" />
<VM name="TESTSSRS04" ipAddress="192.168.1.123" faultDomain="fd:/fd3" updateDomain="ud3" />
<VM name="TESTSSRS05" ipAddress="192.168.1.124" faultDomain="fd:/fd4" updateDomain="ud4" />
<VM name="TESTSSRS06" ipAddress="192.168.1.125" faultDomain="fd:/fd5" updateDomain="ud5" />
<VM name="TESTSSRS07" ipAddress="192.168.1.126" faultDomain="fd:/fd6" updateDomain="ud6" />
<VM name="TESTSSRS08" ipAddress="192.168.1.127" faultDomain="fd:/fd7" updateDomain="ud7" />
<VM name="TESTSSRS09" ipAddress="192.168.1.128" faultDomain="fd:/fd8" updateDomain="ud8" />
-->
</VMList>
</NodeType>
<NodeType name="MRType" primary="false" namePrefix="MR" purpose="MR">
<VMList>
<VM name="TESTMR01" ipAddress="192.168.1.130" faultDomain="fd:/fd1" updateDomain="ud1" />
<!-- reconfigure fds and uds
<VM name="TESTMR02" ipAddress="192.168.1.131" faultDomain="fd:/fd1" updateDomain="ud1" />
<VM name="TESTMR03" ipAddress="192.168.1.132" faultDomain="fd:/fd2" updateDomain="ud2" />
<VM name="TESTMR04" ipAddress="192.168.1.133" faultDomain="fd:/fd3" updateDomain="ud3" />
<VM name="TESTMR05" ipAddress="192.168.1.134" faultDomain="fd:/fd4" updateDomain="ud4" />
<VM name="TESTMR06" ipAddress="192.168.1.135" faultDomain="fd:/fd5" updateDomain="ud5" />
<VM name="TESTMR07" ipAddress="192.168.1.136" faultDomain="fd:/fd6" updateDomain="ud6" />
<VM name="TESTMR08" ipAddress="192.168.1.137" faultDomain="fd:/fd7" updateDomain="ud7" />
<VM name="TESTMR09" ipAddress="192.168.1.138" faultDomain="fd:/fd8" updateDomain="ud8" />
-->
</VMList>
</NodeType>
</ServiceFabricCluster>
</Config>
