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!
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 18.104.22.168 version of Plugin Registration Tool https://www.nuget.org/packages/Microsoft.CrmSdk.XrmTooling.PluginRegistrationTool/22.214.171.124
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.
When you have a OneNote notebook shared with an entire group or site in SharePoint (or with few people in OneDrive for Business) you might want to be able to set permissions on a section or section-group level. While this functionality isn’t for some reason available directly from the UI, it is definitely possible. Read on to learn how!
To be honest, managing authentication in Linux for multiple users/admins can be a huge pain. Different companies use various tools – generally, they use a centralized tool to distribute developer’s SSH keys. This can still be a pain, however if the company has Azure AD (or Office 365), why not to use those accounts for authentication?
In previous article, we have looked at the possibility to connect Dynamics 365 on-premise directly with Azure AD, which is on one hand really cool, on the other, it doesn’t provide all the features like mobile apps integration. In this article, we are going to explore a production ready solution by leveraging Active Directory Federation Service and Azure AD as a Claims Provider Trust.