As I revised for the MB2-715 exam (Microsoft Dynamics 365 Customer Engagement Online Deployment) I am creating blog posts detailing all aspects of my revision. I hope these posts will aid anyone who is also revising for this exam. In this posts I will review the concepts connected with instances.

The skills measured statement for this portion of the exam is shown below. Notice that I have highlighted the section on management of instances. Which sits within a wider section connected with the management of your total Dynamics 365 environment.

When we say instance, what do we mean? Think of an instance as your Dynamics 365 database. Meaning you can have multiple databases (instances) within each Dynamics 365 environment. One common reason for wanting multiple instances is to have a production and test environment. (referred to as non-production or sandbox instances.) Or maybe in some larger organizations multiple production instances are required, possibly to isolate data and functionality by company divisions.

If you are familiar with Dynamics 365 on-premise, in on-premise the equivalent to an online instance would be an organization.

Information for each instance is stored in a separate SQL server database. And are therefore isolated from each other. Because of this each instance can have different configuration / settings. (In addition to different user data sets, for example test systems will often contain much less data than production.) Another benefit is that each instance can be upgraded independently.

You’ll need to understand how instances fit into the hierarchy of an Office 365 / Dynamics 365 environment. When you sign up for office 365 you’ll create what is referred to as your “Tenant”. Then each tenant can have a number of subscriptions or services, for example with Dynamics 365 online you might have a subscription which grants you a number of App licenses and maybe some add-ons like additional storage. We then have instances which is the Dynamics 365 database / organization within a subscription.

Each instance will have its own name and unique url. Additionally you will describe the purpose / type of the instances. (e.g. Production or sandbox.)

Additional to Dynamics 365 you may have one or more additional “services” / subscriptions. These might include Office 365, Power BI, Skype etc etc. By having all of your subscriptions within one tenant it becomes easy to integrate the different services. Additionally users would only have one login that covers the multiple offerings available to them. Dynamics 365 can be installed online or on premise. This is an important point to keep in mind! As when thinking about the Office 365 Tenant I am referring to an online instance of Dynamics 365. Some functionality available within Dynamics 365 may rely on other services running within the same online tenant. Once example of this might be Relationship Insights is therefore only available to Online versions of Dynamics 365. (Meaning we need to be mindful that some functionality available to customers using the online version of Dynamics 365 is not available to on premise customers.)

Each subscription will have different terms and conditions. Including differing start / end dates and maybe other contractual terms. Meaning that adding a removing a subscription does not imply the other subscriptions will be impacted. For example, Making a change to your Office 365 E3 license would not directly impact your Dynamics 365 license.

And finally Security Groups within an instance are used to govern who has what access. By default all users with a Dynamics 365 license can access all of the instances within the tenant. We use security groups to restrict access to specific instances as required.

A typical hierarchy could look like this, where I have one tenant and three subscriptions. Each subscription would be for a service that has been activated in my environment. Then under my CRM online subscription a number of instances could exist. In my example I have shown one production and two sandbox environments.

As already suggested an instance can be one of two types;

• Production, for production purposes
• Sandbox, used for non-production purposes. Typically, these would include training, testing and development. (Testing upgrades etc.)

When you purchase a subscription you will receive two instances. One production and one sandbox. Additional instances can then be purchased as addons for an additional monthly fee as required. It is actually recommended that an organization has at least three instances. One for production and two non-production. One non-production sandbox would be used for user testing and training. Whilst the other would be a pure development environment.

Note: Addons cannot be purchased / provisioned on trial systems.

To administer an instance, you open Office 365 and navigate to the Dynamics admin center.

You then select the instance you wish to manage and click edit.

As you can see below you can that edit the name, url etc.

Name, being the name of the instance as shown in the CRM application

url, the unique url used when signing into CRM

Purpose, a text field used as a reference to the purpose of the instance.

Type, production or sandbox. It is possible to switch an instance type from being production to sandbox. Or sandbox to production. (Assuming you have the correct licenses to support the change.)

Security Group, security groups can be used to determine which users have access to a particular instance. For example, maybe only a limited number of users can access your development sandbox. If you do not define a security group then all users will a CRM license would have access to that instance.

Notice that below I have selected a sandbox instance. In addition to the edit button I have extra options to allow me to reset, delete or enable admin mode. These options do not apply to production instances. Production does however have a copy option to allow it to be copies to a sandbox.

Tenant Constraints

• A tenant can include a maximum of 50 production instances.
• A tenant can include a maximum of 75 sandbox (non-production) instances.
• Each production and non-production instance will have its own SQL database.
• Any licensed CRM online user can have access to any instance in the same tenant.
• A tenant is bound to a geographical area or online region. (Such as Europe, Japan, India.)
  • By default, all instances will be for the same region.
  • It is possible to request to create an instances in other geographical areas. And once granted you will need to define the online region per instance.
  • However all admin tasks would only be possible within instances within the same region. And storage will be calculated as a total across all of the regions.

The available regions will change from time to time. But the current list of geo regions available includes;

• North America (and North America 2) (NA)
  
• Europe, Middle East and Africa (EMEA)
  
• Asia Pacific Area (APAC)
  
• South America (LATAM)
  
• Oceania
  
• Japan (JPN)
  
• Canada
  
• India
  
• Germany
  
• United Kingdom
  

Rather than having multiple instances within one tenant it is possible to have multiple tenants but this has some downsides including;

• Each tenant would need to be managed separately
• Licenses only apply to one tenant, so each licensed user can only access instances in their tenant
• Licenses / subscriptions cannot be shared across tenants
• If using single sign on, each tenant can only be federated with one on-premise active directory.

As you prepare for the MB2-715 exam you will need to understand tenants, subscriptions and instances. I hope this post has given you a useful overview.