Ereignisse
Power BI DataViz Weltmeisterschaften
14. Feb., 16 Uhr - 31. März, 16 Uhr
Mit 4 Chancen, ein Konferenzpaket zu gewinnen und es zum LIVE Grand Finale in Las Vegas zu machen
Weitere InformationenDieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
Dynamics 365 Finance + Operations (on-premises) supports running business processes in customer data centers. With this deployment option, application servers and the Microsoft SQL Server database run in the customer’s data center.
This article helps you plan and prepare for your on-premises deployment.
Wichtig
Dynamics 365 Finance + Operations (on-premises) isn't supported on any public cloud infrastructure, including Microsoft Azure Cloud services. However, it's supported to run on Microsoft Azure Stack HCI and Microsoft Azure Stack Hub.
The features in cloud deployments and on-premises deployments differ. These differences affect your planning. The differences are described in the following topics:
Microsoft Dynamics Lifecycle Services (LCS) is an application management portal that provides tools and services for managing the application lifecycle. Customers and partners use LCS to manage both cloud and on-premises deployments. You can use LCS for the following tasks:
For more information about LCS, see Lifecycle Services resources.
There are four types of environments that you need to plan for. This section describes the four environments and how to access and deploy them.
You can sign up for a demo environment to learn about the system. The demo environment is applicable to both cloud and on-premises deployments. For more information, see Sign up for preview subscriptions.
The development experience is the same for cloud and on-premises deployments. To access a developer environment, see Deploy and access development environments.
Business users and functional team members validate application functionality by using a sandbox environment. This functionality includes customizations and data that was brought forward from Microsoft Dynamics AX 2012 environments. To deploy an on-premises sandbox environment, see Set up and deploy on-premises environments home page.
At a minimum, an on-premises sandbox environment requires:
The production environment is the live deployment that your users and customers have access to. To deploy a production environment, see Set up and deploy on-premises environments home page.
At a minimum, an on-premises production environment requires:
An on-premises deployment uses Azure Service Fabric standalone clusters. Service Fabric is the next generation Microsoft middleware platform for building and managing enterprise-class, high-scale applications. Service Fabric standalone clusters can be deployed on any computer that is running Windows Server.
An on-premises deployment has a standalone cluster for each sandbox environment and a standalone cluster for each production environment. The following roles or node types are deployed into both types of clusters:
The following diagram shows the node types deployed in a Service Fabric standalone cluster.
To learn more about Service Fabric, see the following topics:
Review the system requirements in System requirements for on-premises deployments and be aware of the number of machines that are required for on-premises deployments.
Before you begin the hardware and infrastructure sizing process for an on-premises environment, familiarize yourself with the System requirements for on-premises deployments and Set up and deploy on-premises environments home page to gain a solid understanding of the underlying infrastructure. Pay close attention to the system setup best practices for optimum performance. After you have reviewed the documentation, you can start the process of estimating your transactional and concurrent user volume and sizing your environment based on the average core throughput.
The core factors that affect sizing are:
The more detailed data that you collect, the more precisely you can estimate sizing. Hardware sizing, without supporting data, is likely to be inaccurate. The minimum data that you need to collect is the peak transaction line load per hour. The factors that affect sizing are shown in the following diagram.
From left to right, the first and most important factor needed to accurately estimate sizing is a transaction profile or a transaction characterization. It’s important to find the peak transactional volume per hour. If there are multiple peak periods, then these periods need to be accurately defined.
As you understand the load that impacts your infrastructure, you also need to understand more detail about these factors:
To determine your sizing requirements, you must know the peak volume of transactions that you need to process. Most auxiliary systems, like Management Reporter or SSRS, are less mission critical. As a result, this article focuses primarily on AOS and SQL Server.
In general, the compute tiers scale out and should be set up in an N+1 fashion, meaning if you estimate three AOS, add a fourth AOS. The database tier should be set up in an Always On highly available setup.
You should always utilize SQL Server in either a cluster or mirroring setup. The second SQL node should have the same number of cores as the primary node. Failover is only supported in an active\passive configuration.
For AD FS sizing, see the AD FS Server Capacity documentation. A sizing spreadsheet is available for planning the number of instances in your deployment.
The recommended minimum requirements of two nodes should suffice for most integration uses. In scenarios involving high levels of integrations, more than two nodes may be required. When this happens, you can scale up accordingly.
In most cases, unless used extensively, the recommended minimum requirements using two nodes should work well. Only in cases where there's heavy use will you need more than two nodes, after which you can scale as needed.
For the current release of Finance + Operations, only one SSRS node can be deployed. Monitor your SSRS node while testing and increase the number of cores available for SSRS as needed. Make sure that you have a preconfigured secondary node available on a virtual host that is different than the SSRS VM. This is important if there's an issue with the virtual machine that hosts SSRS or the virtual host. If this is the case, the node would need to be replaced.
The Orchestrator service is the service that manages your deployment and the related communication with LCS. This service is deployed as the primary Service Fabric service and requires at least three VMs. This service is colocated with the Service Fabric orchestration services. This should be sized to the peak load of the cluster. For more information, see Plan and prepare your Service Fabric Standalone cluster deployment.
Mission critical services like the AOS should be hosted on Virtual hosts that have dedicated resources – core, memory, and disk.
The following authentication methods are used with on-premises deployments:
For the IT organization, it enables you to provide sign-on and access control to both modern and legacy applications, on-premises and in the cloud, based on the same set of credentials and policies.
For the user, it provides seamless sign-on using the same, familiar account credentials.
For the developer, it provides an easy way to authenticate users whose identities live in the organizational directory. This means you can focus your efforts on your application, not authentication, or identity.
For more information, see Active Directory Federation Services.
The on-premises deployment option for Finance + Operations stores core customer data on-premises. Core customer data is a subset of the customer data definition provided in the Microsoft Trust Center.
The following table outlines the services that are used to store customer data in Azure data centers located in the United States. Services includes Lifecycle Services (LCS), Microsoft Office sign up portal, and Microsoft Entra ID. These services enable initial onboarding, initiation, tracking of support incidents, and service updates and upgrades. All other customer data, referred to as core customer data, is stored on-premises.
Supporting services | Customer data definition |
---|---|
Microsoft Dynamics Lifecycle Services | Project content and files are stored in a project. This includes application configuration data, code, metadata, and data assets that include the application and business process models. |
Microsoft Office signup portal | Customer information that is collected during the onboarding process. |
Microsoft Entra ID | Authentication for LCS and Azure DevOps. |
Additional services or components can be configured to extend an on-premises deployment as needed; however, configuration choices may cause core customer data to be transferred outside of the customer’s data center. For example, configuring data management features that are used to integrate external services with an on-premises deployment may result in the transfer of core customer data outside the on-premises deployment.
After you’ve completed the planning activities mentioned in this article, you can begin the procedures listed in the Onboard section of the On-premises deployment home page.
Be sure to refer to the On-premises deployment home page throughout your implementation for more information about planning, deployment, maintenance, and troubleshooting.
Ereignisse
Power BI DataViz Weltmeisterschaften
14. Feb., 16 Uhr - 31. März, 16 Uhr
Mit 4 Chancen, ein Konferenzpaket zu gewinnen und es zum LIVE Grand Finale in Las Vegas zu machen
Weitere InformationenTraining
Lernpfad
Lösungsarchitekt: Microsoft Power Platform-Lösungen entwerfen - Training
Erfahren Sie, wie ein Lösungsarchitekt Lösungen entwirft.
Zertifizierung
Microsoft Certified: Dynamics 365: Finance and Operations Apps Developer Associate - Certifications
Sie implementieren und erweitern Finanz- und Betriebs-Apps in Microsoft Dynamics 365.