Sometimes we overlook the security aspects of the things that are not directly related to F&O, specially regarding resources like networking, storage accounts, dev VMs, Microsoft Entra ID (this is Azure AD’s new name!) or using Bastion.
And we don’t do that because we just don’t care about security, but because we’re Dynamics 365 people, and sometimes we might lack the knowledge in other things. If you’re lucky, you’ll have an in-house security team that’ll take care of that, otherwise we need to train ourselves a bit.
This is the first time I’ve used Microsoft Sentinel, and I’m for sure missing on a lot of things and features. Time to learn!
If you’re integrating Dynamics 365 Finance & Operations with 3rd parties, and your organization or the 3rd party one are using a firewall, you might’ve found yourself in the scenario of being asked “which is the production/sandbox IP address?”.
So, what should I do if I have a firewall and need to allow access to/from Dynamics 365 F&O or any other Azure service? The network team usually doesn’t like the answer: if you can’t allow a FQDN, you should open all the address ranges for the datacenter and service you want to access. And that’s a lot of addresses that make the network team sad.
In today’s post, I’ll show you a way to keep an eye on the ranges provided by Microsoft, and hopefully make our life easier.
We’ve been working with the F&O development VMs for a long time, specially Microsoft partners that need to be able to quickly and easily change between different customer environments, and using the VHD is a bit more complicated in that scenario.
And of course, we use Remote Desktop Protocol to connect to these VMs. RDP is insecure due to its weak encryption, widespread use, and the lack of security features built-in to the protocol. So hackers often target RDP to gain unauthorized access to systems. You can learn more about securing your VMs in Best practices for defending Azure Virtual Machines.
Today, we will walk through the steps of configuring Azure Bastion for Dynamics 365 Finance and Operations development VMs.
In the previous post, we learned about my proposal of an architecture for Azure API Management for integrations. And I closed the post with a pending thing, which was details on how to deploy and configure all the Azure resources the solution uses.
And in today’s post we’re going to see how all the resources are created, linked together and configured to have a fully working API logging solution, and how we can deploy everything using Bicep.
I’m back with additional information about Azure API Management! More Azure content, and I’ll probably continue to produce posts regarding Azure in the future.
I believe there are numerous ways to learn new things, and for me, two of them are writing blog posts and using new technologies to solve problems at work. Of course, my goal is to attempt to apply the Azure themes I write about to Dynamics 365.
Today, I’m presenting an architecture approach for integrations, leveraging API Management and various other Azure components, for Dynamics 365 or anything else that has an endpoint.
Let’s talk about logs in Dynamics 365 Finance and Operations. And I don’t mean the built-in database logs we’ve had since the old Axapta days. I’m talking about plain logs, a table and a form to see how/why data is changing, or logging external calls to OData or custom web services endpoints in the ERP.
It’s something that I’m sure almost all developers at some point have had to do. The customer wants to record CRUD events, you suggest enabling the DB log, but the customer wants a new form to see the data. Or maybe you’re monitoring all the calls to your custom web services.
In today’s post, I want to talk about using Azure API Management (APIM) along Dynamics 365 Finance and Operations.
Azure API Management is a hybrid, multi-cloud management platform for APIs across all environments. This means that, after deploying an APIM account, you can create an API that can serve services from one system or multiple.
In this post, I’ll add an extra step to the database refresh: restore a data package (DP). Why? Because I’m sure we all need to change some parametrization or some endpoints in our test environments after a prod refresh.
If you receive the LCS email notifications for your projects you already know this: all Tier 1 virtual machines from Microsoft’s subscription will be gone as early as 1 December! What do you mean gone? This is what the emails say: As communicated previously, Microsoft is removing the use of Remote Desktop Protocol (RDP) to access environments managed by Microsoft. As RDP access is required for development, going forward customers will be required to develop using…
This is another post about solving Dynamics 365 problems using external tools. However I’m starting to think as everything Azure-related as not external at all. In this case I’ll show different scenarios using Azure functions with Dynamics 365.