In this article, we’ll take a quick look at chaining two pipelines together in Azure Devops, so that the completion of one pipeline, triggers the other to run. Microsoft documentation is leaps and bounds ahead of where it used to be. However, I still feel like there is a lot of room for improvement, as it took me a while to figure this out. Our two pipelines will exist in the same repository.

If you need to update the secret for a service principal in Azure Devops, prior to it expiring, you may be surprised to find that this cannot be done via the Azure Portal. In this article, I’ll show you two methods for updating a secret for a service principal prior to expiration. Update the secret via the Azure Devops Portal: Go to “Service Connections” in the Azure Devops portal Find the SPN you want to update, then click “Manage Service Principal” Then on the service principal page, click Certificates & Secrets Create a “New Client Secret”, take note of the value Delete the ‘old’ secret Return to the Service Connection in the Azure Devops portal Click Edit - click the verify button.

This post will cover a secure method for accessing secrets in Azure DevOps pipelines. Why Azure Key Vault? Azure Key Vault is an Azure cloud service used to securely store secrets, keys, and certificates. A secret can be any string of characters, such as API keys, passwords, URLs, etc. Azure Key Vault encrypts data at rest and in transit using HTTPS. Depending on the type of Key Vault you are using, data at rest is encrypted using software encryption (AES 256) or HSM-backed keys.

In this post, we’ll take a look at deploying a highly available sFTP solution to Azure Kubernetes with user files stored in an Azure NFSv4 File Share. The sFTP application reads user credentials from a file named users.conf, containing secrets from an Azure Key Vault. Here is the link to my Github account where you can download the code mentioned in this article: https://github.com/rnemeth90/kubernetes-sftp We will work through the following steps in this article:

When deploying new software releases to servers or (insert -as-a-service> here), it’s a good idea to either deploy the releases in a controlled manner or to have a quick rollback plan. This article will be diving into blue/green deployments, canary deployments, ring-based deployments, and feature tag deployments. Blue/Green Deployments Blue/green deployments are a deployment model where a new application version never gets deployed to the production servers (green) directly. Instead, it gets deployed to another set of servers (blue) first.

This article assumes that you have already created a pipeline in Azure Devops and have it linked to an Azure Devops repo. You will need to create a variable named $vmpassword and assign it the value stored in your key vault. To create a release pipeline that will automatically create a VM (using the password stored in key vault for the local administrator account), do the following: Create a new release pipeline 3.

I setup a self hosted agent for Azure Devops this morning on Server 2012 R2 (legacy Visual Studio dependencies…) and found that I was unable to start the service. The error I received was “Error 1 Incorrect Function” when attempting to start the service in services.msc. I was attempting to run the agent from within my user profile downloads folder. I originally was not aware the service would be running from this directory.

I recently passed the AZ-303 exam. Below are some of the resources I used to prepare for the exam. In addition to the links below, I also used Alan Rodrigues’ course on Udemy. https://www.udemy.com/course/az-102-azure-administrator-certification-transition/ The Udemy course and Microsoft Docs are enough to pass the exam. The course has some good practice exams and labs that align well with what you’ll see on the real exam regarding difficulty. I was scoring in the high 90’s on the Udemy exams.

I recently ran into a situation in my lab environment that required I resync all (2000+) user accounts to Azure AD. Though this sounds complex and daunting, its actually quite simple. T The basic steps involve disabling sync, and then removing the user objects. This can all be done with two PowerShell commands: 1) Set-MsolDirSyncEnabled -EnableDirSync $false 2) Get-MsolUser -All | Remove-MsolUser -force The account that you are currently running the commands as will not be removed.

If you are using VM Scale Sets in Azure, you know how important it can be to quickly obtain an instance IP address. This can of course be done using the Azure Portal. However, I am often working in a shell or VSCode, and I do not want to leave the comfort of my shell to login to the portal. There are a few options we have for retrieving information about a VMSS and its instances without using the Azure Portal.