We have recently deployed a strict DMARC policy (p=reject; sp=reject) on our domains. While this adds greater security while sending e-mail and prevents spoofing, we noticed that certain mails forwarded within our organization stopped coming in.Continue reading “SendGrid, forwarding and DMARC policy”
There’s no breakthrough in this blogpost… It’s just to show you how does the new .csproj look like, what basic things can be done in msbuild and how-to setup ILRepack for common data service painlessly.
Hello there, fellow power platform customizers/developers! Have you tried to override the default open behavior in subgrid and failed?
What I’ve found in my research:
Documentation by Microsoft says: “You can now create a command definition for an entity with Mscrm.OpenRecordItem as the value of the Id attribute (<CommandDefinition> (RibbonDiffXml)), and define custom action for the command <Actions> (RibbonDiffXml). Customer Engagement will look for this command Id for an entity when you try to open a record from the entity-bound grid, and if present, will execute the custom action instead of opening the entity record (default behavior).”
IMPORTANT NOTE: This feature is supported only for Unified Interface.
Did this. No luck. What now? Google…
Sometimes we need to work with a variable inside a loop section. Whether it’s a precomputation or just a helper variable. Logic Apps allows us to do so. Yet the variable must be initialized on a global level (above all loops).
Here comes the problem:
By default, foreach runs in parallel, in 20 threads (instances). Now, because there is no such thing as mutex in Logic Apps, there is no way how to create a critical section. Critical section is a section only one thread at a time can enter. That results in dirty reads.
We can solve this problem by running the loop synchronously. You can do that by editing settings of the foreach block.
Now only one thread at a time will execute the foreach loop and no other thread will modify our variable while we work with it.
Finally, it’s the weekend and I have some time to focus on an issue which bothered our team for a few months. As always we wanted to do it the right way so it will be fast, reusable, continuous integration compatible and without spawning unnecessary workflows and plugin instances.
We have had the group-based licensing option available in preview for over a year. While this service is in preview, it makes provisioning hundreds of users from Active Directory really simple.
You simply create users in your on-premise Active Directory, assign them a valid User Principal Name, add them to the correct group and then sync them with Azure AD Connect, right? Not that fast cowboy!
As Alex blogged we are currently facing a caching bug of plugin assemblies in Dynamics 365 cloud instances (V9). You can do an in-place upgrade with Plugin Registration Tool without an exception now (see Unable to in-place update plugin in Dynamics 365 (with build or revision number changed)) but for some assemblies it just won’t propagate to your workflow definitions.
In the past we could fix it by clicking a save button in Properties tab of the assembly in Plugin Registration Tool but this does not work anymore in V9.
I have put together another workaround which is usable in release automation scenarios.
For quite a long time, we have been running a local service called SkolniLogin.cz which primarily focused on providing SSO experience for various systems at schools (primary and high schools) along with automatic synchronization with the school’s information system. Throughout the time we have hit a lot of edge scenarios, and compiled a best practices guideline.
UPDATE 19/9/18: It has been fixed in 22.214.171.124 version of Plugin Registration Tool https://www.nuget.org/packages/Microsoft.CrmSdk.XrmTooling.PluginRegistrationTool/126.96.36.199
If you use 9.0 version of Plugin Registration Tool to update your assemblies in Dynamics 365 you may encounter the following exception:
ERROR: Occurred while checking whether the assembly exists
The PluginType(00000000-0000-0000-0000-000000000000) component cannot be deleted because it is referenced by 1 other components. For a list of referenced components, use the RetrieveDependenciesForDeleteRequest.
The import of the solution XYZ failed. The following components are missing in your system and are not included in the solution. Import the managed solutions that contain these components (Active) and then try importing this solution again.
If you ever run into this exception and there are all the components already present in the environment you just need to get rid of few lines in a solution definition in the ZIP file you are trying to import.
Do this only if you are absolutely sure that you know what you are doing.