Tip #923: Where is my license key?

A client recently moved from a SPLA license to a Volume License (VS) license for CRM On Premises. They needed to replace their license key, but the Volume Licensing Service Center (VSLC) said a key code was not required for Dynamics CRM 2016.

The answer is there still is a product key, but the volume licensed installer for Dynamics CRM/365 is “pre-keyed.” This means that the product key is embedded in the installer.

To get the new key, download the installer from the VLSC portal. Run the installer to unzip the files, then cancel the installation. Open the file get the \server\amd64\license.txt. This text file will include your new key.

You can then follow these instructions to change your product key on your existing deployment.

 

 

 

Tweet about this on TwitterShare on FacebookShare on Google+

Tip #922: Connect Microsoft Teams and Dynamics 365

Recently Microsoft Teams added the ability to connect your Team channels to many other services. One of these available connections is Dynamics 365 (CRM).

From your team channel, click the ellipses button and select connectors.

From the CRM category, select Dynamics 365 (not those other guys)

Log on to your environment and select the record that you want to connect to your channel. Note–you can add multiple connections to different CRM records.

Now when someone adds a task activity to the connected record, a post with a button to view the record will be added to the Team channel.

What you need to know

  • Only certain system entities such as accounts, contacts, leads, and opportunities can be connected to Teams. Custom entities cannot be linked.
  • Based on my testing, only task activities appear on the channel wall, and only the body of the task, not the subject.

Want to extend the integration? Use Microsoft Flow. Flow includes connectors for both Teams and Dynamics 365, including the ability to generate automatic posts for almost any Dynamics record, including custom entities.

Tweet about this on TwitterShare on FacebookShare on Google+

Tip #921: Clean contacts with Dynamics 365 Outlook app

One of my favorite things about the Dynamics 365 Outlook App is the way that recipients are displayed in the app pane, and how easy it is to update or create contact records in CRM. This makes it very simple to identify when contact information is missing and validate that we have complete contact information in CRM.

<

You will see all contacts listed in the “recipients” section, along with a summary of the data in CRM for that contact. You can tell if the contact exists in CRM if it shows the chain link icon. If the data is incomplete (like in the image above it just includes the email address), I can click the hyperlink for the contact, open the CRM contact record, and update the contact information.

If the contact does not exist in CRM, you will see “unknown recipient” when you click on the contact name. You can easily add the contact to CRM by clicking the “Add to Dynamics 365” link and creating and saving the contact.

Tweet about this on TwitterShare on FacebookShare on Google+

Tip #920: Smart licensing with dual use rights

One of the key features of Dynamics 365 is the choice of the deployment platform: go online, on-premises or partner-hosted. With Dynamics 365 Online leading the way, licensing has evolved beyond simplistic “pay-per-server-plus-cal” model of the past.

For penny savvy customers, the recommended bedside reading is Dynamics 365 On-Premises Enterprise Edition Licensing Guide. If you don’t fall asleep by page 5 then the goodness is right there. It’s so good, it’s worth quoting verbatim (highlights are mine):

Dual Use Rights

One of the advantages of Microsoft Dynamics 365 is the option to deploy either in Microsoft’s cloud or in a private on-premises or partner-hosted cloud. In some cases, customers may want to deploy both modes simultaneously, for migrating a Microsoft Dynamics 365 on-premises deployment to Microsoft Dynamics 365, running private Dev/Test deployments in Microsoft Azure.

Users or devices licensed with Dynamics 365 User Subscription Licenses (User SLs) have use rights equivalent to a CAL for the purpose of accessing on-premises functionality. With Microsoft Dynamics 365 the Dynamics 365 (On-Premises) server license is included with the SLs.

In layman terms, “buy one get one free!”

Careful though

Dual Use Rights is a one-way street

Dual Use Rights convey Microsoft Dynamics 365 (On-Premises) Server license access rights to Microsoft Dynamics 365 SLs. Microsoft Dynamics 365 (On-Premises) CALs have no reciprocal rights to access functionality provided exclusively to Microsoft Dynamics 365 SLs, nor do Dual Use Rights imply equivalent capabilities between Microsoft Dynamics CALs and Microsoft Dynamics Microsoft Dynamics 365 SLs.

Dual Use Rights only apply to Dynamics 365 so don’t forget to license other deployment components.

Licenses for all supporting servers (e.g., Windows Server and CAL(s)) must be obtained separately.

Saving best for last

If on-premises user needs both sales and customer service functionality, you need to buy 2 separate SKUs. However, Enterprise Plan 1 license (available as online-only SL) will allow you to use either one and save a bundle!

Tweet about this on TwitterShare on FacebookShare on Google+

Tip #919: How to deal with pending alternate keys that fail

We did write about pending alternate keys in tips 894 and 894 + 3 and that it’s easy to reactivate the pending keys using solutions UI in Dynamics 365.

However, as David “Xrm.Tools” Yack reports, sometimes pending keys are really stubborn and pressing Create Index generates very introspective and philosophical “Exception: Event failed due to an exception” message. Reactivating the key does not work either because it’s only supported for failed jobs and getting an exception apparently is not really a failure.

Another toolman, Tanguy “The XRM Toolbox” Touzard, to the rescue!

This stalemate can be resolved by deleting the failed job. That seems to allow you to re-activate it and re-create the index.

Tweet about this on TwitterShare on FacebookShare on Google+

Tip #918: CRM/SharePoint integration failure

Today’s tip comes from Sean Shilling. (Send your tip to jar@crmtipoftheday.com)

We were configuring Document integration for CRM on premises 2015 (partner hosted) to SharePoint. After adding the Sharepoint site, setup failed for all entities.

The problem was related to the service account used by the Dynamics SharePoint integration. The same service account that is used for server-side sync for Exchange is used for SharePoint integration. We needed to add that account as a site collection administrator and global administrator. Once we did that all was working as expected.

Tweet about this on TwitterShare on FacebookShare on Google+

Tip #917: Too many business units

Someone recently asked me what I thought of someone adding 1,000 + business units to Dynamics 365. I told them it was a bad idea. Here’s why:

Business units are like large granite rocks–they are designed to be permanent and infrequently moved. While users can be moved between business units, it is not a trivial matter, especially if they own many records.

When you move a user from BU 1 to BU 2, the business unit association of every record that user owns changes. This can cause some surprises to other users who are members of the user’s original business unit if they have BU level read permission. The records owned by the moved user are now not available to them, but if they own child records of those records, like activities, it can cause some strange scenarios. Also, if the user owns many records, moving users between business units can be time-consuming.

Org charts - Comic by Manu Cornet - Look for the updated Apple chart :DAnother potential impact from large quantities of business units is security role updates. Each role is not just one record–a copy of each role is added to each business unit. So if you create thousands of business units, making a small change to a security role can take hours.

My recommendation is to keep your business units to a minimum–only the minimal number to facilitate true BU security requirements. For more granular user segmentation, consider the use of teams. Teams are much more flexible, they can be used to control security access to records, and users can be members of multiple teams.

Tweet about this on TwitterShare on FacebookShare on Google+

Tip #915: Reviewing the Dynamics mobile app reviews

Every fall when Apple releases new updates for their mobile operating systems, reviews like this one appear in the store:

Dynamics 365 Apple Store review
This has been an annual tradition, and has happened each year with IOS 7, 8, 9, and 10, and will likely happen whenever Apple releases iOS 11 this year.

The first rule of administering Dynamics 365 Mobile is:

Do not let your users upgrade their mobile operating systems the first day that they are released

In every one of the past 4 iOS updates, Apple changed something that broke the Dynamics app, quickly followed by an update that fixed the issue. With iOS 10, they broke Office 365 authentication, and about a week later, released an update that fixed the issue.

So if you administer a Dynamics 365 deployment with a bunch of mobile users, either plan on downtime every fall or warn your users not to hit the update button as soon as they see the update is available.

Tweet about this on TwitterShare on FacebookShare on Google+

Tip #914: Deprecated dialogs

Deprecated dialogs podcast tapeTipster note: I have submitted today’s post as a suggestion for the Dynamics team. Please vote for this idea here. And while you are there, submit a few of your own. Together we can make this Dynamics world a better place.

In the recent “important changes coming to Dynamics 365” article, one of the deprecated items listed is dialogs.

Dialogs are deprecated and are replaced by mobile task flows (available as of the December 2016 update), and business process flows. Both task flows and business process flows will continue to evolve to make the transition easier.

We briefly mentioned this in tip 910. As we mentioned, this is no reason to panic, in the past, deprecated features have stayed in the platform for as long as 2-3 releases after their death sentence has been announced. It is just a notice to start planning for replacing these features in your deployment.

But what is the replacement for dialogs? The article suggests task flows and process flows, and while these are options for replacement of many types of dialogs, in their current form, they are not adequate replacements for all dialog scenarios. Let’s consider several common dialog scenarios and how a task or process flow might replace them:

  1. Defined user actions on single records (think imitating or replacing system “close x” dialogs): adding fields to a process flow to collect data for things like qualifying a lead, closing and opportunity, or resolving a case can be a viable option, as long as this action is only done one time per record. As the final step to a process that closes out the record, process flow is a pretty elegant user interface. However, what if that action is performed multiple times per record? Unlike a dialog, users are not going to launch multiple instances of a BPF against the same record. If my dialog is used to initiate a user requested action multiple times against a record, business process flows are not a good fit in their current form, unless I concoct some method to clear out the fields used to initiate the action on the BPF.
  2. Multi-record update wizards: One of the more popular uses of dialogs is presenting a user with a form that consolidates multiple records into a single dialog, making it easy for a user to simultaneously update multiple records in a single step. For multiple clients, I have configured a “meeting close” dialog that simultaneously updates the related regarding account and contacts, adds a note, creates one or more opportunity, and closes the appointment. While task flows come close to this, their bound controls mean that you can only have fields from a single record per page of the task flow, they lack the ability to intelligently run in context of the record you are on, and they don’t support looping child processes, so if I want to give the user the ability to create 1-N opportunities, I have to hard code the number in the task flows, and they only work on mobile, so I cannot make a wizard-based process that works for all users in all UI contexts.

So before “pulling the plug” on dialogs for good, the following are our suggestions on what should change to make task flows and process flows a more viable replacement for dialogs:

  • Free task flows to work with all user interfaces, not just mobile. Users want a consistent experience between mobile and web, and web users need wizard-based processes to make their lives easier too. I like your easy button, put it in the web too.
  • Give the option to have a task flow run in context of a record. Don’t take away the ability to have it run from outside of a record–that is actually a good thing in some contexts. But give us the ability to have a task flow launch in context of a record when that makes sense, and make it as easy to call from a form script or command bar button as a dialog is.
  • Make it intuitive to update OR create records from a task/process flow. As Donna Edwards mentions in this great post, it is possible to create records from a task flow, however, you can’t dictate whether a user is creating or updating a record when you design the task flow, and since the user must select the record to be updated from a lookup field, the process is not intuitive, especially if there are multiple related records without distinct record names.
  • Allow for child flows or looping processes: Consider the scenario where you are presenting the user with a wizard that can be used to quickly create multiple child records. That’s easy with dialogs. My suggestion is to add the ability to call child process or task flows and pass variables to them contextually. This would close the gap of not being able to have users execute a sub-process an infinite amount of times, and would allow process and task flow designers the ability to reuse subprocesses like we currently do with dialogs and workflows.
Tweet about this on TwitterShare on FacebookShare on Google+