Managing Dynamics 365 Online Encryption Key

Today, when I navigate to edit one of the Dynamics 365 Online instances, I just noticed a new section that is available on my trial instance: “database encryption settings”

2017-03-29_1700.png

So, what can you do with this shiny new feature?

Based on the official documentation for this feature from Microsoft: https://technet.microsoft.com/en-us/library/mt492471.aspx

The manage keys feature lets you perform the following tasks.

  • Enable the ability to self-manage database encryption keys that are associated with Dynamics 365 (online) instances.
  • Generate new encryption keys or upload existing .PFX or .BYOK encryption key files.
  • Lock a Dynamics 365 (online) instance.
    System_CAPS_cautionCaution
    You should never lock an instance as part of your normal business process. While a Dynamics 365 (online) instance is locked it takes the instance completely offline and it cannot be accessed by anyone, including Microsoft. Additionally, services such as synchronization and maintenance are all stopped. An appropriate reason why you would lock an instance is when you move your database from online to on-premises. Locking the instance can make sure that your online data is never accessed again by anyone.

    A locked instance can’t be restored from backup.

  • Unlock a Dynamics 365 (online) instance. To unlock a locked instance of Dynamics 365 (online), you must upload the encryption key that was used to lock it. While a Dynamics 365 (online) instance is locked, it cannot be accessed by anyone.

 

One of the common request when I’m implementing Dynamics 365 (CRM) deployment, is the question around the security & encryption. One of the common ask is whether the platform allows customer-supplied encryption key or not? In the past, my answer is NO. It is all under Microsoft’s managed encryption key.

With this feature being made available, the answer is YES!

2017-03-29_1707.png

Read through the TechNet article above for more details of this new feature and considerations when you are implementing this BYOK 🙂

HTH!

Lesson Learned from PSA Deployment

Currently I’m in a project where our team is going to roll out Dynamics 365 Project Service Automation for one of our customers. Throughout the project, we’ve learned a lot about this new cool kid on the block 🙂

PSA_Screenshot.png

Some gotchas/lesson learned when we are rolling out this to the customer:

  1. Choose Project Template carefully. Once created, the user can’t change the project template and need do it again from the scratch (not a big hassle, but definitely I mentioned this when during the training).

  2. This is for Admin/Customizer, PSA-related controls limitation. Time Entry & Expense, WBS, schedule board, etc. They are pretty much static (hard coded), it is not honoring relabel, adding more options and even can’t add any new field. Seems like we need to treat PSA in a similar manner to other ISV solution, such as Click Dimensions, (compared to Sales/Service/Marketing that have more mature customization and configuration flexibility).

  3. Do not mess with the OOTB processes or scripts. There are lots of processes coded in javascripts and plugins where the processes behind it are not really documented. So, my lesson on it, keep it out of the box, if a customization needed, I would recommend to not touching any of the OOTB fields and create custom processes or fields instead.

  4. Pay attention to “metadata” records (Resource Role, Resource Skill, Price List, Expense Categories, etc) during deployment. Similar to Adx/portal scenario, where records are stored as configuration. To have ALM for PSA correctly, will need to pay attention to those records as part of the deployment process.

  5. One of the biggest catch that I’ve got: can’t undo approval. Approvers need to be really really careful with their approval.

For this instance, I submitted an idea entry: https://crmideas.dynamics.com/ideas/dynamics-crm/ID0000986. From the feedback from the 2 customers that we have worked with, they need this feature to make an amendment to the entries, at least before it is processed for invoice (at least a flag or something to cater this scenario).

  1. Data migration is a bit tricky, for some scenarios, we’ve got to deactivate some of the validation plugins to let the data in (need to have thorough testing on this, as I consider this as touching the OOTB process that is not well documented).

Hope this helps!