When you are amid a pesky IT issue, it can be difficult determining whether the problem is down to a bug/system fault or human error. Like this recent example involving Azure Data Factory illustrates, it is generally best to assume the latter, to avoid any prolonged difficulty.
The ability to consume Application Insights data from directly within Power BI is an excellent feature in what is already a pretty outstanding product. However, there will likely be some steps that you have to follow to ensure that your reporting solution is secured, using an appropriately privileged API key.
We saw a few weeks ago how to utilise Azure Active Directory (AAD) Security Groups to manage Azure SQL database access at scale. When using this feature, you must ensure database changes are deployed out using an AAD administrator account or similar, a task which may be difficult to achieve in an Azure DevOps Pipeline.
Azure SQL Server has long supported the ability to use Azure Active Directory user accounts to access and work with databases. What you may not know is that it is also possible to add users via membership of a security group, a feature which, I believe, is incredibly useful for managing large-scale deployments.
The Dynamics 365 Customer Engagement/Common Data Service connector for Azure Data Factory can, in most cases, fit into your data integration needs. However, it is worth highlighting the two field types which are, specifically, not supported; namely, the Customer and Owner field types.
By default, the Dynamics 365 Customer Engagement connector for Azure Data Factory V2 exposes a predefined list of fields, that must have data mapped to them for any Copy Data task to complete successfully. This behaviour can be impractical depending on your particular scenario; fortunately, there is a way in which you can override this.
Azure Data Factory V2 not just has 1, but three separate connectors that all claim to hook up to Dynamics 365 Customer Engagement/Dynamics CRM! So which connector is the "right" one to use and what differences do they have? With a little help from Alan Partridge, we can clear up any confusion...
Validating your Azure templates manually can be a challenging task to complete at scale. Fortunately, with the functionality available within Azure Pipelines, this entire process can be fully automated. This post will show you just how easy it is to implement automatic validation an deployment of your Azure templates within a CI process.
When working with Azure templates for the first time, there's always a risk of misconfiguring a setting. All fine when testing, until you realise you have been charged an unexpected amount on your credit card. In this post, I provide an example of this in practice when working with Stream Analytic Job resources.
Working with variables within your Azure DevOps Pipeline can give you a high degree of latitude when planning your software deployments. When utilised as release variables, additional functionality is exposed, allowing you to alter the conditional flow within your pipeline dramatically. In this week's post, we'll find out how to use them in practice.