• Red Flags

    Hur skall man hantera en incident? Skall man bygga nytt eller skall man laga det som är trasigt. Detta är ämnet i dagens avsnitt

    Markus Lassfolk  @lassfolk  http://isolation.se/

    Mikael Nyström @mikael_nystrom  https://deploymentbunny.com/

    Viktor Hedberg @headburgh https://hedbergtech.se/

    Johan Persson @JoPe72 https://blog.johanpersson.se

     

    Jingle av David Lilja (cutpaste.org)

  • Sovereign Cloud

    I detta avsnitt av The Nerd Herd pratar vi om Microsoft blogpost som släpptes i veckan om Soveriegn Cloud och hur man skall hantera europeriska företag i datacenter som ägs av amerikanska företag

     

    Blogposterna: 
    https://blogs.microsoft.com/blog/2025/06/16/announcing-comprehensive-sovereign-solutions-empowering-european-organizations/

    https://blogs.microsoft.com/on-the-issues/2025/04/30/european-digital-commitments/

     

    Markus Lassfolk  @lassfolk  http://isolation.se/

    Mikael Nyström @mikael_nystrom  https://deploymentbunny.com/

    Viktor Hedberg @headburgh https://hedbergtech.se/

    Johan Persson @JoPe72 https://blog.johanpersson.se

     

    Jingle av David Lilja (cutpaste.org)

  • Dualwrite – Beware of the reverse

    I am setting up Dualwrite at a customer and I got an issue the other day. The customer wants to be able to create customers from Dynamics 365 CE and syncing them to Dynamics 365 for FO. We had done all of the initial syncs and done multiple test for creating Accounts in CE and the synced perfectly to FO.

    When I was trying to figure out a way to manage Financial Dimension population while creating accounts I tried creating the customer directly in FO, just to test a thing… and it failed!!

    I tried again from CE and it worked… but not from FO. We had been so focused on testing one direction but not the other… Doh!

    So, what was the issue? I got this error:

    Unable to write data to entity accounts.Writes to CustCustomerV3Entity failed with error message Request failed with status code BadRequest and CDS error code : 0x80048d19 response message: Error identified in Payload provided by the user for Entity :'accounts', For more information on this error please follow this help link https://go.microsoft.com/fwlink/?linkid=2195293 ----> InnerException : Microsoft.OData.ODataException: Cannot convert the literal '' to the expected type 'Edm.Int32'. ---> System.FormatException: Input string was not in a correct format.
    

    and then it continued with a stack trace… Hmmm…

    So I started brainstorming with a colleague: It is obviously a data type missmatch and when I turn off the mapping for Account, it works. Going through the mapping we had added a few transform mappings so we started there. It turns out that all of these we 1 to 1 mappings. The problems was that there three fields were not on the initial “customer creation sidebar”. In CE these were made mandatory but in FO, they were not.

    I took a look at the mappings for these 3 fields and one stood out. It had no mapping for the empty value.

    This meant that when going from FO to CE I tried to convert and empty string to an integer and since there was no transform for the empty field and no default it could not be written to CE.

    The easiest way to add an empty mapping to null is to edit the JSON version of the mapping (I did not know this was possible until a short while ago)

    [
    	{
    		"transformType": "ValueMap",
    		"valueMap": {
    			"Dealer": "787980000",
    			"End user": "787980001",
    			"Nat OEM": "787980002",
    			"Reg OEM": "787980003",
    			"Int OEM": "787980004",
    			"Integrator": "787980005",
    			"Contractor": "787980006",
    			"Other": "787980007",
    			"": null
    		}
    	}
    ]
    
    
    
    
    
    

    Add the last line and do not forget the comma at the end of the previous line

    That was it… I saved it and restarted the mapping. We verified it… Worked!!!

    That was it for today… see you around

  • The Arctic Hackathon experience

    When I first received the invitation to be a judge at the Arctic Cloud Developer Challenge in Oslo, my initial reaction was one of hesitation: “I’ve never done this, this is a bit scary.” But then I re-framed my thinking: “I’ve never done this… Cool!” That shift in perspective led me to one of the most memorable experiences of my career.

    The hackathon took place in beautiful Holmenkollen, just outside Oslo, where 15 teams gathered to compete in what would prove to be an extraordinary event. The teams, ranging from solo developers to groups of six, competed across six different categories with the chance to earn 33 different badges. While Dynamics 365 and Power Platform formed the foundation, teams weren’t limited to just these technologies – they incorporated everything from IoT and ProCode to AI in their solutions.

    This year’s theme transported us into the magical world of Harry Potter, and the teams certainly rose to the occasion. The creativity was astounding: we saw everything from a digital Sorting Hat to a comprehensive intranet for Hogwarts. Some teams even ventured to the darker side of magic, creating a digitized assassin portal for dark wizards and a Howler service complete with a public API. The Weasley twins would have been proud to see their mischievous spirit living on in a Facebook-style clone designed just for wizards.

    The energy throughout the event was electric. Even after our first day wrapped up and dinner was served at 21:30, many participants returned to their stations, continuing to build and refine their projects. The dedication was inspiring – teams worked around the clock, but what struck me most was how they supported one another despite the competition. The spirit of collaboration and mutual learning created an atmosphere that was truly magical.

    The competition was incredibly close – in the end, just nine points separated the second-place team from the winners. But beyond the competitive aspect, what I witnessed was the pure joy of creation and innovation. Teams were fully immersed in their projects, pushing boundaries, and most importantly, learning from each other.

    As I sit here at Oslo S station, waiting for my train back to Sweden, I’m exhausted but filled with an overwhelming sense of happiness. Someone asked me at the closing party (and what a party it was!) how I felt about stepping out of my comfort zone. I can honestly say I haven’t been this happy or had this much fun in a long time.

    ## Key Takeaways from the Event

    One of the most significant lessons from this hackathon was the importance of flexibility in the creative process. While having a basic framework is essential, the most innovative solutions emerged when teams were given the freedom to think outside the box. Rigid scope definitions can often stifle creativity and limit potential solutions. By allowing teams to explore and adapt their approaches as they worked, we witnessed truly unique and innovative solutions that might never have materialized under stricter constraints. I think the benefit of adopting this mindset in a delivery scenario would be of great benefit. It would create happier employees and customers when the focus in making the solution “something extrordinary”.

    The strict time constraints of the hackathon, rather than being a limitation, proved to be a catalyst for excellence. When teams knew they had just three days to deliver, it forced them to focus on what truly mattered, make quick decisions, and maintain a steady momentum. The pressure of the deadline seemed to sharpen their creativity rather than hinder it, leading to more focused and innovative solutions. Sometimes in a delivery to customer decisions tend to extend into a whole line of meeting and the urgency gets a bit lost. Having a clear deadline for a decision an then applying an agile mindset to allow us to go back and revisit the decision rather than requiring every decision to be perfect from the start would not only create efficiency but would also encourage a culture of psychological safety.

    Another fascinating observation was the effectiveness of smaller teams. Throughout the event, we noticed that smaller, tighter-knit teams often demonstrated stronger cohesion and more efficient collaboration. With fewer team members, each person naturally took on more responsibility and felt a greater sense of ownership in the project’s success. This heightened sense of personal investment and belonging seemed to fuel their motivation and drive better outcomes. The intimate team dynamic also appeared to facilitate quicker decision-making and more agile problem-solving.

    Sometimes the best experiences come from saying “yes” to things that initially seem intimidating. This weekend proved that stepping out of your comfort zone can lead to extraordinary adventures and meaningful connections. As I head home, I’m taking with me not just memories, but also new friendships and a renewed appreciation for the magic that happens when passionate developers come together to create.

  • AADSTS50011: The redirect URI ‘https://D365FOenv.operations.eu.dynamics.com/’ specified in the request does not match the redirect URIs

    Last week I needed to set up a new Dynamics 365 for Finance and Supply Chain environment and I for a strange error message which took some time to figure out.

    AADSTS50011: The redirect URI 'https://enadvdemo01.operations.eu.dynamics.com/' specified in the request does not match the redirect URIs configured for the application '00000015-0000-0000-c000-000000000000'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.

    (since I am not an EntraID expert I might be some details wrong in the explanation but this is what I think the issue is)

    The issue here is that when you are working with D365FO, which is a Microsoft Saas-ish service, there is a Service Principal created for Microsofts application in your Entra ID tenant. When you set up a new environment, the URL for that environment is added to that Service Principal as two ReplyUrls. One for the base URL and one for the OAuth endpoint.

    Apparently there is a limit (255) for how many of these URLs you can have for the Service Principal. This means that when you have deployed enough environments the property fills up. I am guessing that there might be a clean-up routine for these but that it might sometimes fail.

    The solution is to remove a couple of old ones and manually add the new ones.

    1. Log into the Azure Portal

    2. Start the Cloud Shell

    3. In the Cloud Shell, run the following commands

    connect-azuread
    
    $AADRealm = "00000015-0000-0000-c000-000000000000"
    Get-AzureADServicePrincipal -Filter "AppId eq '$AADRealm'"

    Find old, retired URLs here and run the following

    $EnvironmentUrl = "https://newenv.operations.eu.dynamics.com"
    
    $OLDEnvironmentUrl = "https://retired env.operations.eu.dynamics.com"
    
    $SP = Get-AzureADServicePrincipal -Filter "AppId eq '$AADRealm'"
    
    $SP.ReplyUrls.Remove("$OLDEnvironmentUrl")
    $SP.ReplyUrls.Remove("$OLDEnvironmentUrl/oauth")
    
    $SP.ReplyUrls.Add("$EnvironmentUrl")
    $SP.ReplyUrls.Add("$EnvironmentUrl/oauth")
    
    Set-AzureADServicePrincipal -ObjectId $SP.ObjectId -ReplyUrls $SP.ReplyUrls

    This will remove the retired URLs and add the ones for the new environment

    Links:
    Error AADSTS50011 – The reply URL specified in the request does not match the reply URLs configured for the application <GUID>. | Microsoft Learn
    Solved: AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application: ‘00000015-0000-0000-c000-000000000000’.

  • Windows Server 2025

    I detta avsnitt tar vi oss en titt på en del av de nya funktionerna Windows Server 2025. Eftersom vi inte hinner med allt nytt finne resten i release notes

    Markus Lassfolk  @lassfolk  http://isolation.se/
    Mikael Nyström @mikael_nystrom  https://deploymentbunny.com/
    Viktor Hedberg @headburgh https://hedbergtech.se/
    Johan Persson @JoPe72 https://blog.johanpersson.se
    Jingle av David Lilja (cutpaste.org)

  • WSUS försvinner?

    I detta avsnitt av The Nerd Hers pratar vi om att Microsoft har sagt att WSUS inte längre kommer att finnas kvar

  • Cannot insert duplicate key row in object ‘dbo.msdyn_dualwriteentitymapBase’ with unique index ‘ndx_for_entitykey_Alternate Key’.

    Surprise… I am back on DualWrite troubleshooting again.

    I got today’s error when I try to move the solution for DualWrite mappting solutions to a new power platform environment.

    Solution "DualWrite Mapping Solution" failed to import: ImportAsHolding failed with exception :Cannot insert duplicate key exception when executing non-query: System.Data.SqlClient.SqlCommand Exception: System.Data.SqlClient.SqlException (0x80131904): **Cannot insert duplicate key row in object 'dbo.msdyn_dualwriteentitymapBase' with unique index 'ndx_for_entitykey_Alternate Key'**. **The duplicate key value is (0, eng_[accounts - Dynamics 365 Sales prospects], 1.0.1.3,** Jan 1 1900 12:00AM). The statement has been terminated.

    DISCLAIMER: You should NEVER edit code in PRODUCTION and I know it is important with a proper ALM process (thanks Carina for telling me to clarify this). Also, in this setup there is no DualWrite connected DEV environment.

    The issue in this case was that I am an idiot and I manually created a mapping customization in Production (you did what???? You always say that we should not do things in production!!!!) with the same version number as the one in UAT (are you kidding me???). When I then tried to import the solution from UAT to PROD I got the error (serves you right!!!) because it had the same name and version (Is that so ).

    The solution was to re-save the customization in UAT with a new version number, added it to the solution. I then re-exported the solution from UAT and moved it to PROD with no errors.

    Thanks for today

    /”The Idiot”

  • Hårt MFA krav för Admins

    HejHej

    I detta avsnitt av TheNerdHerd diskuterar vi lite om krav från Microsoft på att alla Global Admins måste ha MFA

    Markus Lassfolk  @lassfolk  http://isolation.se/

    Mikael Nyström @mikael_nystrom  https://deploymentbunny.com/

    Viktor Hedberg @headburgh https://hedbergtech.se/

    Johan Persson @JoPe72 https://blog.johanpersson.se

     

    Jingle av David Lilja (cutpaste.org)

  • Article: Using Open Source Software in Your Dynamics Implementation

    The idea behind this article started for a couple of reasons. The first thing that happened was that Alex Meyer released his [D365FO Admin Toolkit] (https://github.com/ameyer505/D365FOAdminToolkit) on GitHub. The second thing that happened was that I read the brilliant article [Scary, Dangerous Creepy Tools by Jonas Rapp ] (https://jonasr.app/dangerous-tools/)) These two things made me think about the benefits and challenges of using open source in Dynamics 365 for finance and supply chain. (Since then, there have been others, such as Jonas Feddersen Melgaard‘s [D365FinanceToolbox](https://github.com/jofme/D365FinanceToolbox))

    First of all, I will dive into some background… About 10 years ago, I left the “IT Infrastructure” world and ventured into the Dynamics world. On the infrastructure side, Open Source Software is a big thing. The majority of web servers on the internet run on Linux, a lot of our Internet appliances (such as firewalls and routers) run on Linux, more than half the world’s cell phones have a base in Open Source, and a lot of components such as Curl, OpenSSH, and Mermaid are used by millions of business users every day since they are all baked into commercial products. In fact, 60% of all compute cores in Microsoft Azure run some version of Linux.

    So the question is, why is it OK to use Open Source Software built by the community everywhere else but not in Dynamics… “Because it is our super-duper critical ERP System, of course!!!!”. Well, I would argue that there are more important systems in your organization (not to belittle your ERP system) that use at least a couple of Open Source components. That means that the actual issue is not the code itself… it is something else. This article will try to understand the blockers and why they might not be relevant.

    Mentioning the fact that a lot of commercial closed source software uses Open Source components, I agree, is a bit dis-honest. However, it makes a good point, and I think it puts a finger on the real issue here: Responsibility. When a company embeds a 3rd party component in the software, they assume responsibility for it. They agree to patch it (which is not always done), and they agree to take responsibility for the end product to the customer. We will come back to the question of responsibility later in this text.

    The Benefits

    There are a couple of benefits of using software made by someone else in our solution. The most obvious one is the same as the argument for ISV software. We do not need to start building something from scratch, which means we can free up time for our project and for our developers to do other things.

    There is also the quality argument. If someone has built it and many others use it, the risk of it being broken is smaller than if everyone builds their own solution to a common problem. Working iteratively on a common software base over time will hopefully make it less likely to break. Another argument here will be, “But we are solving our own unique issues,” and that might be so… but not all of your challenges are unique. If you have an issue in Dynamics, then it might be that others have the same issue and that they need to solve it, too.

    There is also the question of missing features in the product. When Microsoft adds new features to Dynamics, they need to prioritize them, and if not enough organizations want a feature, then it will not bubble to the top in the priority list, and thus, it will not be built. Community-developed features will help bridge the gap and also indicate Microsoft’s customers’ desire for the product. On the consumer side of tech, there is a concept called [Sherlocking (https://en.wikipedia.org/wiki/Sherlock_(software)#Sherlocked_as_a_term). That is when (In this case) Apple implements a function that a 3rd party software developer has built into iOS or MacOS.

    The Challenges

    Earlier, I compared Open Source Software to ISV solutions, and to be honest, there is one big difference… responsibility. When you buy an ISV solution from a vendor or let a partner build and implement your solution for you, someone else always assumes responsibility for the code written. But as for all contracts, there are always disclaimers. This applies even to Dynamics’ license agreement. There are some things that are not covered by the agreement. The responsibility always lands on the end customer in the end, and you, as an end customer, need to be ready to assume that responsibility. If we assume that the responsibility falls on the customer in the end, there is basically no difference between Microsoft, ISV, Partner, Open Source, or Customer-created code. We still need to test it and ensure it is maintained and updated. The main difference is that we (as an organization) can not affect Microsoft’s, ISVs’, or (in some cases) the Partners’ Code. We are, however, able to make changes to the Open Source Solution.

    I know there are ISVs that supply the source code for their solution… Is that the same as using Open Source? Well, not exactly, but sort of… There are ups and downsides to this. If we buy the solution from the vendor and have a support agreement, we should avoid editing the code; it blurs the lines of responsibilities. With that being said, there is still a benefit in that we can speed up the troubleshooting process because we can debug and help provide the solution to the vendor. However, the real benefit of getting access to the codebase for an ISV solution is if something happens to the vendor and they go out of business. In that case, we can choose to continue supporting the solution ourselves.

    The Commitments

    As we have seen in this article, there are some things we need to think about when we start using Open Source Software. As always, we need to make sure the software holds up to the same level of quality that we need; we need to keep it updated (and with that comes, of course, testing and code review, in the same way as with our own code), but I also think that there is another level of commitment here and that is that if we find a bug in the code, we should also be a “good citizen” of the community and at lease report a bug (maybe even with a proposed solution) or even write a fix and submit a pull-request back to the project to get the fix into the code base… if it benefits us, it will probably benefit others.

    “So that means that we should use our precious time writing code for others?” Yes, with the time we save having others write code and test it for us, we absolutely should pitch in and help. I am absolutely convinced that we will spend less time in the long run while at the same time helping others do the same.

    The Conclusions

    Using third-party Tools always needs to be a deliberate choice, and going with an Open-Source Solution comes with its own challenges. However, we also need to understand that building all of our own customizations from scratch means that we will use a “one-off” solution that does not always adhere to best practices. In that case, we are on our own, but when we use a solution that is built by the community, at least we can figure out the solution together.