Manage Power Platform deployments 2/3 - Work with Power Platform Tenants, Enviroments, Subscriptions and Dynamics 365 apps Flashcards
Multi-tenant and multi-instance Dynamics 365 deployments
Cosa cambia da Multi-Tenant a Multi-Istance?
Le app Dynamics 365 Customer Engagement ti offrono opzioni per separare i dati e l’accesso degli utenti.
- Per la maggior parte delle aziende, l’aggiunta e l’utilizzo di più istanze nell’abbonamento fornisce il giusto mix di funzionalità e facilità di gestione.
- Le aziende con posizioni geografiche separate potrebbero prendere in considerazione l’utilizzo di più tenant per separare le licenze.
- Più istanze possono condividere utenti tra istanze;
- Più Tenant NON possono condividere utenti tra istanze;
Multi-tenant and multi-instance Dynamics 365 deployments
Alcune terminologie usate in questo contesto?
Terminology
-
Tenant : Per le app Dynamics 365 Customer Engagement, un tenant è l’account che crei nell’ambiente dei Microsoft Online Services quando ti registri per un subscription.
- Un tenant contiene:
- Multiple Istance.
- Subscriptions
- Security groups
- Users
- Domini identificati in modo univoco
-
Il tenant creato per te ha un nome di dominio .onmicrosoft.com.
- contoso.onmicrosoft.com.
- Un tenant contiene:
-
Instance: Quando ti registri per una versione di prova o acquisti un abbonamento, viene creata un’istanza di produzione.
- Ogni istanza aggiuntiva di produzione o non di produzione (Sandbox) ,crea un’organizzazione separata e isolata sullo stesso tenant.
- Un’istanza ha il formato URL https://< URL name >.crm.dynamics.com.
- https://contososales.crm.dynamics.com
-
Multiregional instance: Un’istanza in una regione diversa da quella in cui risiede il tuo Tenant.
- Le istanze locali possono fornire un accesso più rapido ai dati per gli utenti in quella regione. multiregionali
-
Subscription: Un abbonamento è costituito dalle licenze e dai componenti aggiuntivi inclusi nella versione di prova o nel servizio a pagamento a cui ti sei registrato nel tuo account.
- Le Subscription possono variare in base al tipo di licenza, al prezzo e alla data di fine.
- Ad esempio, un abbonamento potrebbe essere 100 licenze di app Dynamics 365 Customer Engagement Professional e 10 licenze di app Dynamics 365 Customer Engagement Enterprise.
-
Identity: L’account utente utilizzato per accedere.
- È inoltre possibile utilizzare questa identità per accedere ad altri servizi di Microsoft Online, come Microsoft 365 o SharePoint Online.
- Gli amministratori possono decidere se desiderano gestire le identità degli utenti tra
- le app Dynamics 365 Customer Engagement e Active Directory locale.
-
User account: Un account utente assegnato da un’organizzazione (lavoro, scuola, no profit) a uno dei suoi componenti (un dipendente, uno studente, un cliente) che fornisce l’accesso a uno o più abbonamenti al servizio cloud Microsoft dell’organizzazione, come Exchange App online o Dynamics 365 Customer Engagement.
- L’accesso a un servizio in linea è controllato dalla licenza assegnata all’account utente.
- Gli account utente vengono archiviati nella directory cloud di un’organizzazione all’interno di Azure Active Directory e in genere vengono eliminati quando l’utente lascia l’organizzazione.
- Gli account aziendali differiscono dagli account Microsoft in quanto vengono creati e gestiti dagli amministratori dell’organizzazione, NON dall’utente.
- Security group: Se la tua azienda ha più istanze, puoi utilizzare i gruppi di sicurezza delle istanze per controllare quali utenti con licenza possono accedere a una particolare istanza.
Multi-tenant and multi-instance Dynamics 365 deployments
Come potremmo immaginare l’uso delle istanze?
When to use a “multi” approach for Dynamics 365 deployments
Le istanze sono simili nel concetto a un complesso aziendale a molti piani, con piani organizzati in base alle funzioni aziendali.
- Considera ogni piano dell’edificio come un’applicazione (Sales/Service/Marketing, Vendor management, Wealth management)
- Considera ogni unità all’interno di un piano come un’istanza per uno scopo specifico come produzione, formazione, test e sviluppo.
- Sono necessarie più istanze quando è richiesta la separazione di plug-in, flussi di lavoro o risorse di amministrazione che non possono essere facilmente isolati utilizzando le Business Unit.
Multi-tenant and multi-instance Dynamics 365 deployments
Esempio di una soluzione tipica che include un solo tenant ma più istanze!
Multi-Instance deployment
Una distribuzione tipica include un solo tenant.
- Un tenant può includere una o più istanze;
- Un’istanza è sempre associata a un singolo tenant.
Questo esempio utilizza due istanze per tre team: Vendite, Marketing e Servizi.
- Le vendite e il marketing condividono un’istanza in modo che le informazioni sui lead possano essere facilmente accessibili da entrambi.
- I servizi hanno una propria istanza, quindi i biglietti e le garanzie possono essere gestiti separatamente dalle campagne e da altri eventi correlati alle vendite.
Puoi fornire facilmente l’accesso a una o entrambe le istanze.
- Gli utenti delle vendite e del marketing potrebbero essere limitati alla loro istanza, mentre gli utenti del servizio con accesso esteso potrebbero aggiornare i record di escalation di supporto relativi agli account in entrambe le istanze.
Multi-tenant and multi-instance Dynamics 365 deployments
Dimmi le cose più importanti riguardo a una soluzione di deploy con un singolo Tenant Multiple Istance
Single tenant with multiple instances Overview
- Un tenant può includere fino a 50 istanze di produzione e fino a 75 istanze non di produzione (Sandbox).
- Ogni istanza all’interno del tenant riceve il proprio database SQL.
- I dati non vengono condivisi tra le istanze.
- Lo spazio di archiviazione è condiviso tra l’istanza principale e qualsiasi istanza aggiuntiva
- Tutte le istanze per un singolo tenant del cliente verranno configurate nell’area geografica in cui si sono inizialmente registrati per il proprio account.
- Il consumo di storage viene totalizzato e tracciato in tutte le istanze collegate a un tenant del cliente.
- Puoi impostare gruppi di sicurezza separati per tutte le istanze.
-
Un utente con licenza può potenzialmente accedere a tutte le istanze associate al tenant.
- L’accesso è controllato dall’appartenenza al gruppo di sicurezza dell’istanza
-
È possibile acquistare istanze aggiuntive tramite Add-On per istanze aggiuntive.
- È possibile aggiungere istanze aggiuntive solo agli abbonamenti “a pagamento”, non alle versioni di prova o ai diritti di utilizzo interno (IUR).
- Se hai acquistato l’abbonamento tramite Volume Licensing, devi rivolgerti al tuo Large Account Reseller (LAR) per acquistare l’istanza aggiuntiva.
- Non puoi unire versioni di prova o abbonamenti esistenti in un’istanza aggiuntiva; invece, dovrai spostare i tuoi dati e le personalizzazioni.
Multi-tenant and multi-instance Dynamics 365 deployments
In cosa consiste il Master Data Management?
Common use cases for multi-instance deployments: Master data management
In questo scenario, un “master” data set fornisce la gestione delle modifiche tramite central master data source.
- Questo approccio richiede che central master data siano sincronizzati con tutte le istanze in modo che ogni istanza abbia accesso alla versione più recente delle informazioni di base.
- Le modifiche richieste alle informazioni possono essere apportate direttamente all’interno del master system.
- In alternativa, gli utenti possono accedere in modo esplicito al master system o acquisire le modifiche nell’istanza locale, con tali modifiche successivamente trasmesse all’istanza master.
Richiedere che le modifiche vengano apportate a livello centrale può fornire un controllo centralizzato delle modifiche.
- Ad esempio, è possibile eseguire controlli antifrode per garantire che le modifiche vengano apportate solo da un team centrale e non da team locali che potrebbero altrimenti beneficiare di una modifica, come una modifica dei limiti di credito.
Multi-tenant and multi-instance Dynamics 365 deployments
In cosa consiste il Security?
Common use cases for multi-instance deployments: Security and privacy
Le differenze nella legislazione regionale, ad esempio dell’Unione europea (UE) o nazionale, possono comportare variazioni nei requisiti per la protezione dei dati o il mantenimento della riservatezza dei dati nelle diverse regioni o paesi in una distribuzione. In alcuni casi, legislativa
Multi-tenant and multi-instance Dynamics 365 deployments
In cosa consiste la Scalability ?
Common use cases for multi-instance deployments: Scalability
Sebbene una singola istanza delle app Dynamics 365 Customer Engagement possa aumentare e diminuire per supportare la crescita del business di un cliente, con volumi di dati o livelli di complessità molto elevati, ci sono considerazioni aggiuntive.
- Ad esempio, in ambienti con volumi estremi e/o un uso estensivo della pianificazione dei servizi, la scalabilità di SQL Server può richiedere un’infrastruttura complicata e costosa che è proibitivamente costosa o estremamente difficile da gestire.
Esistono molti scenari in cui è presente una naturale divisione funzionale nei requisiti di capacità.
- In questi casi, delegare i carichi di lavoro creando scenari di scalabilità orizzontale basati su queste suddivisioni funzionali può fornire volumi più elevati utilizzando l’infrastruttura delle merci.
Multi-tenant and multi-instance Dynamics 365 deployments
Perchè un’azienda dovrebbe tener conto di utilizzare un opzione multi-tenant e che vincoli comporta?
Multi-Tenant Deployment
Le aziende globali con modelli regionali o nazionali diversi possono utilizzare i tenant per tenere conto delle variazioni nell’approccio, nelle dimensioni del mercato o nel rispetto dei vincoli legali e normativi
Non possono essere condivisi in un approccio Multi-Tenant:
- Gli User accounts, Identities, Security groups, Subscriptions, Licenses, lo spazio di archiviazione
- I dati non vengono condivisi tra istanze o tenant.
- In uno scenario multi-tenant, un utente con licenza associato a un tenant può accedere solo a una o più istanze mappate allo stesso tenant. Per accedere a un altro tenant, un utente necessita di una licenza separata e di un set univoco di credenziali di accesso per quel tenant.
- Ogni tenant richiederà uno o più amministratori tenant con credenziali di accesso univoche e ogni affiliato tenant gestirà il proprio tenant separatamente nella console dell’amministratore.
- Più istanze all’interno di un tenant sono visibili dall’interfaccia se l’amministratore ha accesso
- Non è possibile riassegnare le licenze tra le iscrizioni tenant. Un affiliato registrato può utilizzare la riduzione della licenza in una registrazione e aggiungere licenze a un’altra registrazione per facilitare questa operazione.
- La federazione di Active Directory locale non può essere stabilita con più di un tenant a meno che non si dispongano di domini di primo livello che è necessario federare con tenant diversi
Multi-tenant and multi-instance Dynamics 365 deployments
Quali sono gli usi più comuni di un approccio Multi-Tenant?
Common use cases for multi-tenant deployment
Questo scenario si verifica in genere nelle organizzazioni con esigenze funzionali sovrapposte ma separate. Alcuni esempi comuni includono:
- Organizzazioni con divisioni aziendali diverse, ciascuna con un mercato o un modello di funzionamento tutto suo.
- Imprese globali con modelli regionali o nazionali che differiscono per tenere conto delle variazioni nell’approccio, nelle dimensioni del mercato o nel rispetto dei vincoli legali e normativi.
- In questi tipi di ambienti aziendali, un’organizzazione spesso disporrà di set di funzionalità comuni che consentono regioni, paesi o aree aziendali specifiche con un certo grado di localizzazione
- Acquisizione delle informazioni. Ad esempio, l’acquisizione del codice postale negli Stati Uniti sarebbe correlata all’acquisizione del codice postale nel Regno Unito.
Physical distribution
Per le soluzioni aziendali che devono supportare gli utenti che sono fisicamente distribuiti su grandi distanze, in particolare per le distribuzioni globali,
- l’utilizzo di una singola istanza potrebbe non essere adatto a causa delle implicazioni (come la latenza WAN) associate all’infrastruttura su cui gli utenti si connettono, che possono ha un impatto significativo sull’esperienza dell’utente.
- La distribuzione di istanze per fornire agli utenti un accesso più locale può ridurre o superare i problemi relativi alla WAN, poiché l’accesso avviene su connessioni di rete più brevi.
Multi-tenant and multi-instance Dynamics 365 deployments
Quali sono i svantaggi di un approccio multi-tenant?
Disadvantages of multi-tenant deployments
Le distribuzioni multi-tenant introducono una serie di vincoli di cui è necessario essere consapevoli:
- User accounts, identities, security groups, subscriptions, licenses, and storage non può essere condiviso tra Tenant.
- Un singolo dominio può essere associato solo con un tenant.
- Ogni tenant deve avere il proprio namespace; i namespace UPN o SMTP non possono essere condivisi tra i tenant
- Se esiste un’organizzazione di Exchange locale, non è possibile suddividere questa organizzazione tra più tenant.
- Un Global Address List consolidato non sarà disponibile, a meno che non venga gestito in modo esplicito a valle della sincronizzazione.
- La collaborazione tra tenant sarà limitata alle funzionalità di Lync Federation ed Exchange Federation
- L’accesso a SharePoint tra tenant potrebbe non essere possibile. Sebbene questo possa essere risolto con Accesso partner, l’esperienza utente viene interrotta e si applicano gli aspetti relativi alla licenza.
- Non possono essere presenti account duplicati tra i tenant o partizioni nell’Active Directory locale.
