At one of my customers, we are still (happily) using Microsoft Web Deploy to deploy our web applications to IIS. This works great and is all nicely automated and integrated in our Azure DevOps pipelines. Until the moment it no longer works. Something that happened last month when trying to deploy one of our projects. A look at the web deploy logs showed us the following error message: Web deployment task failed. ((2/11/2024 15:00:08) An error occurred when the request was processed on the remote computer.)(2/11/2024 15:00:08) An error occurred when the request was processed on the remote computer.Unable to perform the operation. Please contact your server administrator to check authorization and delegation settings. Time to contact the server administrator... Unfortunately that’s my team in this case. So let’s investigate. We logged in on the web server and checked the event logs. There we got some extra details: A tracing deployment agent exception occurred that was propagat
In software development, change requests(CR) often get a bad reputation. As developers and architects it can feel frustrating to have to redesign and change existing features(especially if the change request has a big impact on the existing system). However, we should see them as a positive sign for a product's success, evolution, and continued relevance. Let’s explore why… Reason 1 - Our system is used! The fact that we get a CR means that at least someone tried our system and even better they see value in using it further because they want to improve it. When users ask for changes, it's because they're actively engaging with the software. They’re uncovering real-world use cases and scenarios that may not have been anticipated during initial design. This feedback loop confirms that the software is doing something valuable—and that users believe it can do even more. Reason 2 – We have learned something! Software, by its nature, is built to be flexible and adaptabl