How to solve: Manifest Unknown pulling a Windows container from Azure Container Registry

Currently I am helping different customers in implementing containerized delivery for their .NET applications on Windows hosts. One important part of the containerized delivery infrastructure is the so-called Container Registry. There are different on-premise and cloud registry products available for storing your company owned Windows Container Images like the Nexus Repository, Artifactory for on-premise situations and the Docker Trusted Registry, Azure Container Registry, AWS Container Registry and Google Container Registry for cloud scenario’s. Because we are creating a new cloud platform based on Microsoft Azure we also decided to make use of the Azure Container Registry for storing our Windows container images. While making the delivery pipeline work, we faced the following issue in pulling earlier pushed container images from the Azure Container Registry. A not very user friendly message.. We pushed our image with the 29 version tag successful to the Azure Container registry as shown below. So what’s going on? I navigated to the Azure portal to

Powershell script to make use of @CurrentIteration query token in TFS queries

Since the introduction of Visual Studio 2013 update 5, a new query token (@CurrentIteration) is available to automatically identify the current iteration of your iteration path, based on today’s date. By using this query token in queries that are related to the current iteration/sprint, you will save a lot of time in managing those queries (as mentioned in my previous blogpost). However, once upgraded to Visual Studio 2013 update 5 or higher, you have to manually update your queries to make use of this new @CurrentIteration query token. This may cost you a lot of time. For that reason, I’ve made a powershell script to automatically implement the @CurrentIteration query token for the shared queries of your team project (see the code below or the attached zip file). After downloading/unzipping, just specify your own values for the different variables and run the powershell script. EnableCurrentIterationQueryToken  

How to deal with the current sprint/iteration in TFS queries?

During my work as an ALM consultant, I get a lot of questions about how to define a stable iteration (and area) path structure in your TFS Team Project. I thought it would be helpful, to share with you one of the things I always discuss with teams that are working with the SCRUM or Agile process template; dealing with the current sprint/iteration. So what’s the problem? Once teams are working with the Agile planning tools of TFS, most of the (shared) work item queries they are working with, are related to the current sprint/iteration they’re working on. Think of a query which shows us the open defects of the current iteration. Or take for example the set of default SCRUM queries that are delivered when creating a new Team Project based on the SCRUM process template. Because of this overbalance of sprint/iteration related queries, it is important that the defined iteration path structure and

Changing the Default CheckIn Action in TFS

For some weeks ago, I had a team ask me if it was possible to change the default CheckIn action for relating a work item to a check-in in TFS. After finding different solutions, I thought it would be helpful to share with you the different options I found. So what’s the problem? As you will know, when you want to relate a work item with your check-in in TFS, you have to choose between two CheckIn actions: Associate or Resolve. The first one, Associate, is used to just link the work item with the future changeset. The second one, Resolve, also automatically closes the work item on check-in. By default, your Visual Studio client will select the Resolve action on check-in. For some situations this is very helpful. However, when you want to use the Associate action most of the time, it is very annoying and inefficient to change the CheckIn action each time