Dynamics 365 Questions & Answers, Part II

In April, I published a post answering some of the more common Dynamics 365 questions asked by SBS Group customers and other partners.  I have received over 30 responses to that post in as many days so I think it is safe to assume that this is a worthwhile topic.

In this post, I will focus on questions related to Microsoft’s announcement that Dynamics 365 for Operations will be available as an on-premise solution in the second half of 2017, most likely June.  Although I believe that the advantages of a cloud-only ERP deployment almost always outweigh any disadvantages, I recognize that for some companies this just isn’t the right option.

In keeping with the question/answer format, I’ll expand on this below.

What does an On-Premise deployment of Dynamics 365 for Operations mean?

On-Premise is typically defined as software that is installed and runs on computers that are physically on the premises (in the building) of the person or organization using the software, rather than at a remote facility such as a server farm or cloud. Because the software runs on computers locally, the related data does as well. In the last 10 or so years, I have heard the on-premise term used for any deployment that is fully managed by the person or organization using the software. This means that “on-premise” deployments could also be referring to installations in a company owned or rented data center.

When Dynamics 365 for Operations was released, it was basically the next step for AX7 which was designed exclusively for a cloud-only deployment.  In November 2016 and again in February 2017, Microsoft indicated that they would be releasing on-premise options as well. In fact, they are expected to offer two more options for deploying Dynamics 365 for Operations as follows:

Cloud and Edge (Hybrid)

In this deployment scenario, the business process and transactions will be allowed to run “at the edges” with data being stored locally (on-premise).  The edges, referred to as “My Workplaces” will be managed by the customer while the cloud components will be managed by Microsoft.  This helps the customer to scale and take advantage of cloud-related services while keeping components like master data management private.  In some instances, this will help with integration to applications that can’t or shouldn’t be managed in the cloud.

The central cloud node can provide a singular view of operations across multiple “My Workplace” instances and still leverage the cloud for better business intelligence.  Cortana Intelligence will most likely not be accessible to full potential in this model if at all, but other BI tools can still be leveraged.

Local Business Data (LBD)

An LBD, local business data, deployment allows a customer to run all business processes on-premise, to support local transactions and store business data without replicating to the public cloud (Azure).

Replication of business data into the cloud no longer occurs so while data and processes are more private, the customer will lose access to many of the bells and whistles that come with Dynamics 365.  Cortana Intelligence, PowerBI and Azure Machine Learning services are all included in the list of items missing from the action in an LBD deployment.

Ultimately, customers will be able to leverage a federation of My Workplace instances under a single My Workplace to take provide better visibility and intelligence throughout the company.

Should I Implement Dynamics 365 for Operations in the Cloud or On-Premise?

The answer … at least if going live today … is quite simple.  In the cloud.  Microsoft has not released an on-premise version of Dynamics 365 for Operations yet.  They have indicated their intention to do so in the latter half of 2017, but have not provided an exact date to the public.

When they do release an on-premise version, it will be up to you and your partner to weigh the options around each and determine which is the best fit for your environment.  We can speculate on this today, but some of the details are still private and will continue to evolve right up to the public release expected in June/July of 2017.

Is there a clear comparison of these options?

It is almost impossible to compare them at this time as they have not been formally released and new information is coming available regularly.  Detail shared along the way through formal posts and reseller meetings provide enough information to facilitate good conversation, but I would caution anyone not to wrap up their due diligence until after general release.  The table below has some help information that I’ve seen shared by others from various partner conferences hosted by Microsoft:

Table-D365-OnPremise

Why would a Dynamics 365 Customer Choose to Implement On-Premise?

When looking from the outside, it isn’t obvious why any company would choose to take on the responsibility of directly managing the hardware, connectivity, security and administration of their own ERP data center.  Most companies are thrilled with the idea of avoiding upfront costs for infrastructure and related IT support services, not to mention traditional license software costs.  Most companies find the security, speed, and dependability of modern cloud providers is nearly impossible to duplicate in an in-house environment. But, many do … so why?

  • Existing Data Center Investments:  Quite often, companies have already sunk considerable investments into their hardware, physical location and IT support personnel.  Walking away from that investment can be difficult to do emotionally and financially.  Many companies compare the costs of maintaining existing data centers, or even riding it out for a few years, to the cost of moving to the cloud and find it more cost-effective to continue in-house.  This is a decision that each company needs to make based on their unique situation.
  • Not Cost-Effective Due to Other On-Premise Requirements: I’ve spoken with customers that would prefer to move their ERP to the cloud, but feel that the ROI expectations can’t be met unless they are able to move a more significant portion of their applications to the cloud.  Just moving ERP doesn’t allow them to significantly trim support staff or reduce costs associated with their physical data center.  When they are able to move the lion’s share to the cloud, they plan to switch (and many do).
  • Regulatory Requirements:  Some companies prefer to keep data and processing local to avoid the possibility of not being compliant with regulatory requirements related to their business.  Whether looking at a SaaS application (like ERP in the cloud) or data storage, your company must be confident that their customer and other information is protected.  Your cloud provider should be compliant with your industry’s privacy and security compliance needs, like HIPPA and PCI.  There are standards for companies with financial data and government, government contractors and a variety of industries where data integrity is considered hyper-critical.
  • We’ve always done it this way: If it isn’t broke, don’t fix it. Right?  One might argue that the very nature of technology is smart, measured change for cost and efficiency gains, but I often speak with clients that just can’t get comfortable with having applications and data move outside their walls.  Sometimes it isn’t as a result of due diligence, but more of a gut reaction.  Personally, I believe that the cloud offers far more value than on-premise deployments, but I would never pressure a company to operate in a way that they aren’t comfortable with.  Not everything is a math problem.
  • Heavy Customizations: Many SaaS ERP solutions do not provide an architecture that allows for heavy customizations.  In many cases, like with Microsoft Dynamics 365, a company can customize their solution and integrate other products with little issue.  However, if a customer has made substantial customizations over time, it may be that some of those customizations or integrations will not survive a move to the cloud.  We’ve become very adept at making this work for our customers, but in some cases, they opt to stick with their current solution until some of the more difficult customizations can be migrated to their satisfaction.

As more information comes to light regarding Dynamics 365 for Operations on-premise deployments, I’ll share it with you here.  We are excited to see Microsoft making this option available and helping our customers determine the best option for their business.

If you would like to discuss this in person, please feel free to reach out to me directly at rmorrison@sbsgroupusa.com.

register for webcast

Best regards,

Robbie Morrison
Chief Solution Strategist, SBS Group

About Robbie
Robbie Morrison has spent nearly 20 years helping customers build and deploy elegant technology and business solutions.  From start-ups to enterprise-class organizations worldwide, his knowledge of the Microsoft Dynamics ecosystem and products helps SBS Group customers maximize ROI on technology investments.  Robbie

Today, Robbie serves SBS Group customers in his role as Chief Solution Strategist where he provides thought leadership and manages the development of B2B solutions.  Robbie received his MBA from the University of Georgia, Terry College of Business.
https://www.linkedin.com/in/robbiemorrison

Prerequisites for a Simple Dynamics CRM 2013 On-Premise Installation

Microsoft Dynamics CRM 2013 is an amazing solution, however one of the main reasons it is so amazing is because it leverages cutting edge technology.  This can make for a complex on-premise installation.

If you choose to have a consultant perform the installation for you (highly recommended), then you have three choices for their access:

  1. Make them a domain admin and give them the keys to the kingdom
  2. Take the control-freak approach, and lock them down as much as possible
  3. Try to reach a middle-of-the-road compromise

For those of you that choose path #2, please take a look at Priscilla Tse’s blog.  Not only does it talk about installing with minimum permissions, but also without internet access.  Speaking for myself, I hope I never have to do one of these installations!

The approach that I want to propose here is a middle-of-the-road compromise (#3).  In a simple on-premise installation, we start with a dedicated SQL Server (possibly shared with an ERP or other database) and a dedicated CRM Server.  These can (and usually are) virtual servers, which really isn’t relevant from a permissions perspective.  For the purpose of this simple installation, we will assume there is only one domain for all servers, and that an IFD (Internet Facing Deployment) will not be created.

The following needs to be configured prior to the installation.

  1. Domain User Account
  2. AD Organizational Unit (OU)
  3. CRM Installation Account
  4. CRM Service Account
  5. Exchange Email
  6. Remote Access, if applicable

Domain User Account

For our simple installation, a domain user account with local admin rights to both the SQL Server and the CRM Server is preferred.  This account can be used for on-going support.

AD Organizational Unit (OU)

CRM requires an organizational unit (OU) in the Active Directory domain.  This OU can be created during the CRM Installation if the CRM Installation Account has sufficient permissions.  For assistance in creating an OU, navigate to Microsoft TechNet and search for “create OU”.

CRM Installation Account

The CRM Installation Account will be used for the installation of CRM on the CRM Server.  It must be a domain user with local admin rights to both the CRM Server and the SQL Server.  Once the installation is completed, a corresponding CRM System Administrator account will be created in the CRM application.   This user should have organization and security group creation permissions in AD.  If the OU is already created, then this user only needs permissions to create security groups for the specified OU.

CRM Service Account

There are 6 CRM Services.  In a simple installation these can all be managed by the same domain account.  This account should be dedicated to the CRM services only and can not be used to setup a CRM user account.  The password should never expire, and it cannot be a Managed Service Account.

Exchange Email

New with CRM 2013 is Server-Side Sync.  A simpler solution, this approach requires an on-premise Exchange 2010 or greater server using the Exchange Web Services protocol.  It does not work if SMTP and POP3 protocols are intermixed with Exchange.  It also does not work for the creation of mass email marketing campaigns.  For a complete list of supported email configurations for server-side synchronization, please reference this MSDN Library post.  If Server-Side Sync is not an option, then the traditional Mail Router should be configured and will need a dedicated EMail Account.

Additional References:

Please note that this blog did not address system requirements.  Those change as frequently as Microsoft releases new software versions.  Please refer to the Dynamics CRM 2013 Implementation Guide located in the Microsoft Download Center (search for “crm 2013 implementation”).  Reference the enclosed Planning document.  Be prepared – Version 6.0.2 is 154 pages long.

For an up-to-the-minute list of compatible software versions, please reference Article 2669061 on the Microsoft Support Site.  While Dynamics CRM works best if kept up-to-date, it is not advisable to install it with a version of software that has not been tested to be compatible.  As with any compatibility list, just because a product is not listed, does not mean it won’t work – just that it hasn’t been tested (which directly correlates to supportability).

For additional technical questions on the topic of CRM, feel free to contact us.

%d bloggers like this: