Sunday, March 29, 2020

Quick tip: Skype for Business and Microsoft Teams network assessment tool

To ensure that your network meets the requirements for using Skype for Business or Microsof Teams for audio and/or video calls, you can download and run the Skype for Business Network Assessment tool.




Sunday, March 22, 2020

Generating Azure Application Insight Key in Azure DevOps pipeline

If you want to generate an Application Insights key in your Azure DevOps pipeline - you can use the the PowerShell code snippet below in a Azure PowerShell task.


Look at Automate Azure Application Insight resources using PowerShell and New-AzureRmApplicationInsightsKeyApiKey for more details.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
Install-Module AzureRM.ApplicationInsights -force -verbose -scope CurrentUser
Import-Module AzureRM.ApplicationInsights

$resourcegroupname ='rg_func****'
$aicomponentname ='func****'
$permissions = @("ReadTelemetry", "WriteAnnotations")
$apikeydescription = 'testapikey'

New-AzureRmApplicationInsightsApiKey -ResourceGroupName $resourcegroupname 
-Name $aicomponentname -Description $apikeydescription -Permissions $permissions

Friday, March 20, 2020

Azure Application Insights for Dynamics 365 and Power Platform solution architects and consultants

A best practice which is quite often overlooked is enabling monitoring and logging capabilities in your applications or solutions. You should always monitor your applications/solutions whether they run in the cloud or on premise because you want to know when something fails (before the users start complaining) and also understand how users are working with your solutions.



Both Dynamics 365 and Power Platform have the option to enable integration with Azure Application Insights - but what is Application Insights?

Azure Application Insights  is a feature of Azure Monitor and it is basically an APM (Application Performance Management) tool. Application Insights provides standard integration with a lot of Azure components adding automatic monitoring capabilities but you can also extend it with custom monitoring so if you get an exception in your code that is unhandled Azure Application Insights will pick this up. You can use it for on-premise and cloud applications but the ease with which you can instrument your applications might differ.


You can integrate Application Insights into your model-driven apps (either Dynamics 365 first party apps which you extended or completely custom-model driven apps) by using the Javascript SDK (See Application Insights for web pages for more details). Unfortunately the old documentation on this topic has disappeared - https://azure.microsoft.com/en-us/documentation/articles/app-insights-sample-mscrm/ now does a redirect to the general document. A recent update on the Power Platform also allows you to log telemetry for your Canvas Apps using Application Insights.

Dynamics 365 can also leverage Azure components like Azure web apps, web jobs or Azure functions which will also require monitoring and logging capabilities. Depending on the type of component you might get out of the box monitoring or you might need to use code based monitoring - most scenarios are described in the documentation - https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview

Things I learned when using Azure Application Insights in the last couple of months:

Tuesday, March 10, 2020

Enabling C# 7.1 in Visual Studio 2017 projects

Today, when I tried to compile one of the Visual Studio projects in our solution - I received the exception "Feature 'default literal' is not available in C# 7.0. Please use language version 7.1 or greater". (For more info see default literal in C# 7.0)



To enable C# 7.1 you need to following these steps:

  • Right click on your project and select Properties, next navigate to the build tab and click Advanced

  • Next you can either choose C#7.1 from the list or choose C# latest minor version (latest).

Monday, March 09, 2020

Dynamics 365 and Power Platform monthly reading list January 2020

Dynamics 365 and Power Platform - 2020 Wave 1 topics

Starting April 2020, new features in Dynamics 365 and Power Platform will be activated, but you can already try out some of the new features by enabling early access - for a full list of available features see 2020 release wave 1 features available for early access
Technical topics (Configuration, customization and extensibility)

Forms Pro Quick tip: switch between Microsoft Forms Pro and Microsoft Forms

Microsoft Forms Pro is an enterprise survey tool which leverages both Microsoft Forms and the Common Data Service (For more details see Getting started with Microsoft Forms Pro: customer feedback is the ultimate truth.)

Once you are assigned a Forms Pro license, it is not so obvious that you can still use Microsoft Forms (at least not for me) To switch between Microsoft Forms Pro and Microsoft Forms you should select your photo in the Office 365 header and then select Switch to Forms



Thursday, February 06, 2020

Quick tip: keep your Dynamics 365 development tools up to date using Nuget

I recently encountered an issue when I tried switching the view of the registered plugins & custom workflow activities in the Plugin Registration Tool.



When updating to the latest version using the PowerShell script listed on Download Dynamics 365 development tools from Nuget the error got resolved. Lessons learned: make sure that you keep your Dynamics 365 development tools up to date.

Monday, February 03, 2020

Lessons learned about Dynamics 365 solution layering - Part 1


This is the first in a series of blog posts on Dynamics 365 solutions and solution layering in which I will cover the basics about Dynamics 365 solutions and gradually delve deeper into the mysterious world of the inner workings of Dynamics 365 solutions.

In my opinion,  based on how managed solutions and solution layering work - I think that in the majority of cases you should only use a single managed solution to avoid issues down the line. Read on to see why...


This blog post assumes that you are using managed solutions to deploy to all environments and only have unmanaged solutions in your development environment.

Dynamics 365 solutions fundamentals

If you work with Dynamics 365/CDS solutions, you should be aware of the concept of solution layering. Solution layering occurs on import of solutions when a specific component is affected by a change within one or more solution. Solution layering will determine the kind of behavior that a user will see in Dynamics 365.

The figure above shows how layering works: at the bottom, you have the standard CDS solutions on top of which you might have some first party apps installed like Dynamics 365 Sales/Customer Service etc... If you deploy custom managed solutions, they will go on top based on the order in which they are installed. Direct customizations and unmanaged solutions are always at the top but there is no real layering of unmanaged solutions - they all end up directly modifying the base behavior.

Solution layers describe the dependency chain of component from the root solution introducing it, through each solution that extends or changes the component’s behavior. Solution layers are created through extension of an existing component (taking a dependency on it) or through creation of a new component or version of a solution. So it is very important to understand that layers should be considered on a per component basis.

In April 2019, Microsoft introduced a new user interface component which visualizes the different solution layers which are impacting the behavior of a specific component - View solution layers for a component. Below is an example of the solution layers of the case form which was quite an interesting example.


Going beyond the basics

But what happens if two or more solutions define solution components differently? This article  - Introduction to solutions - conflict resolution explains the two conflict resolution strategies - Merge and Top Wins. The article is also valid for online according to Microsoft support - even though it was written for Dynamics 365 on premise and last updated in December 2017.


When importing a managed solution with the overwrite customization option, it is possible to override the "top wins" conflict resolution  but this does not apply to components which apply a “merge strategy” - for more details see Understand how managed solutions are merged

So you need to be very careful when adding components which apply a merge strategy in multiple solutions with different publishers since the merge behavior might cause unexpected side effect such as creating a separate active layer on top which would block your customization to appear to the user.

An active layer can emerge in two scenarios - a direct customization was done in the instance but it seems that it is also possible that a managed active layer is created when using only managed solutions without direct customizations in the system. This happens when managed solutions in one system, with different publishers (the Microsoft solutions count as a different publisher) are trying to update the same component. It is a defense mechanism that Microsoft has built in when there are object inconsistencies across managed solutions.

The general recommendation is that you keep the number of managed solutions with common components (e.g. forms with a different form layout) to a minimum. This will avoid merging issues across the layers.

Single solution to rule them all?


Taking into account all of the above it seems that you would opt to use a single managed solution to deploy to other environments.

Single solution approach
Pros:

  • Easier to version control
  • Avoid solution layering issues
  • Less environments needed
  • Easier to promote across environments
Cons:

  • Longer duration of solution import
  • Long list of components


I do think that a single solution might make sense in the majority of cases but there are of course exceptions to this rule.  I would recommend you to take a look at the Solution Lifecycle Management: Dynamics 365 for Customer Engagement Apps whitepaper and especially the section on solution boundaries which outlines some of other valid scenarios for having multiple solutions e.g.  the scenario where you need to deploy to multiple regional production instances with small variations with a core solution approach and on top local solutions  or the scenario where you need to release subsets of applications on different cadence/timeline.