We can inject configuration into containers using Kubernetes config maps and secrets. These objects can be consumed by a pod as environment variables, command-line arguments, or as configuration files mounted in a volume. For the subject of this article, we will focus on mounting multiple config maps/secrets into a single directory on a pod. Mounting a configmap or secret in a Volume is relatively straightforward (for anyone familiar with Kubernetes primitives).

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.

This will be the first article in a series about maintaining Azure tenants and subscriptions. If you currently, or have ever, worked in a large Azure environment, you know how easily resource creep can occur. Resource Groups, VM disks and network interfaces, network security groups, etc. can easily fall out of sight and be forgotten about. This isn’t a big concern for resources that are free of cost, like resource groups.

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.

Azure Policy allows us to control what actions users can perform regarding creating and managing resources in Azure. We can define policies for naming standards, require that certain extensions be installed on virtual machines, audit various resources for certain configurations… the possibilities are endless. In this article, well focus on defining what locations users can deploy resources in. To get started, login to the Azure Portal and search for “Policy”.

Let’s say you have a VM in Azure North Central. You created this VM from a custom image that you maintain in an Azure image repository. Now, what if you wanted to create that same VM in Azure South Central, and use the same reference image? A standard image repository is limited to the region that it exists in. The answer here is to create a Shared Image Library, add the image to it, and then configure the image to replicate to other Azure regions.

In Redhat/Fedora/Cent, GRUB can be protected by running the grub-md5-crypt command and pasting the outputted password hash into the grub.conf file. vSphere 6.0 password protects grub by default. If you change the root password in the VAMI, the GRUB password is changed to match. If you do not change the root password, the GRUB password is “vmware”. To reset the GRUB password, we need to boot into a Cent or Redhat live CD.