osProfile PropertyChangeNotAllowed

[axelgMS]

hey folks,
can we add a note to this page https://docs.microsoft.com/en-us/azure/virtual-machines/windows/tutorial-secure-web-server#add-a-certificate-to-vm-from-key-vault

If you try to run the following with a Specialized VM (ie. without an osProfile):

$vm=Get-AzureRmVM -ResourceGroupName $resourceGroup -Name "newvm99100323"
$vaultId=(Get-AzureRmKeyVault -ResourceGroupName $resourceGroup -VaultName $keyVaultName).ResourceId
$vm = Add-AzureRmVMSecret -VM $vm -SourceVaultId $vaultId -CertificateStore "My" -CertificateUrl $certURL
Update-AzureRmVM -ResourceGroupName $resourceGroup -VM $vm

That will fail with:

Update-AzureRmVM : Changing property 'osProfile' is not allowed.
ErrorCode: PropertyChangeNotAllowed
ErrorMessage: Changing property 'osProfile' is not allowed.
ErrorTarget: osProfile
StatusCode: 409
ReasonPhrase: Conflict

VMs created from specialized disk don't have osProfile as this is created for VM provisioning (contains the VM name, RDP user, password…. and these already exist for Specialized VMs).
So the code above only works for VMs created from a Generalized image.

You can use Resource Explorer https://resources.azure.com to check if your VM has an osProfile

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 8bf51cac-f999-cb1c-b2c8-bf5cc224ecf8
• Version Independent ID: db10a084-09b8-6d25-05e5-e8c60507e474
• Content: Tutorial - Secure a Windows web server with SSL certificates in Azure
• Content Source: articles/virtual-machines/windows/tutorial-secure-web-server.md
• Service: virtual-machines-windows
• GitHub Login: @zr-msft
• Microsoft Alias: zarhoads

[jakaruna-MSFT]

Thanks for the feedback! We are currently investigating and will update you shortly.

[Karishma-Tiwari-MSFT]

@zr-msft There are other customers who are seeing the same error as per this GitHub issue.
Can you please update the doc as appropriate. Thanks.
CC: @cynthn

[cynthn]

@Karishma-Tiwari-MSFT Zach is off working on other things. I'll add a note that folks shouldn't try this with a VM created using -attach. Thanks!

[cynthn]

@axelgMS so, this is an issue with any VM created using -attach. Is there a work-around? Can you create an osProfile for a specialized VM?

[zr-msft]

@Karishma-Tiwari-MSFT can you remove me as an assignee?

[NyashaNziramasanga]

Has this issue been resolved or a workaround found? im getting the same issue after following this article on a linux virtual machine

[Karishma-Tiwari-MSFT]

@axelgMS It looks like customers are still seeing this issue. Can you please share the details as requested by @cynthn in the replies above so that she can help update the doc. Thanks :)

[cynthn]

@NyashaNziboi and @Karishma-Tiwari-MSFT Thanks for the feedback! The original post from @axelgMS details the issue "VMs created from specialized disk don't have osProfile as this is created for VM provisioning (contains the VM name, RDP user, password…. and these already exist for Specialized VMs). So the code above only works for VMs created from a Generalized image."

The article is written using a generalized image. I will try to work in somewhere that if you aren't following the article, but trying to do this with your own VM that was created using a non-generalized disk (using -attach), then it won't work because there is no config file to update.

[cynthn]

Just to be a little clearer about what is happening here: AzVMSecret updates the "secrets" property in the "osProfile" section of the resource manager template for the VM. Virtual machines that are created by attaching an existing disk (aka spcialized disk) do not have an "osProfile" section in their VM template. No "osProfile" means there is no "secret" either.

You can go into the portal, find the VM, and then click on the Export template item in the VM pane to see the template. If you don't see an "osProfile" entry, then you will run into this same issue. (Note: "osDisk" is not the same - it should be called "osProfile".)

I'm going to talk to the engineering team about whether there is an alternative method for adding a KeyVault cert. I have a couple ideas for work-arounds, but I want to make sure I don't break anything else in the process :)

[NyashaNziramasanga]

Hi @cynthn, I am happy to try the workarounds you have in mind until a solution is deployed, Im using a Linux Virtual Machine using osDisk.

[cynthn]

@NyashaNziboi The only work around that I'm relatively sure will work is not pretty :)

You'd basically need to generalized the VM in question (run Sysprep), then create an image of the VM, then create a new VM from that image. That would give you a VM with an osProfile that could be updated with the secret.

But, that basically destroys the original VM (it can't be rebooted). If this is just a VM that you are playing around with, it might be okay. But, I don't think it is ideal. If you wanted to try it, I would recommend making copies of the original VHDs before doing anything.

I'm still waiting to hear back from engineering about other possible alternatives :)

[MitchellNZ]

Also interested in this issue. I am in a situation where I can't afford to lose the original VM (in case I have issues re-creating it from the image).

I have tried to get myself a copy of the VM with an osProfile by doing the following (however, I haven't had any luck getting it to work correctly):

1. Creating a snapshot of the original VM disk.
2. Using that snapshot to create a new VM (which obviously has no osProfile).
3. Generalizing that VM (created from the disk snapshot) and creating a VM image from that.
4. Using that generalized image to create a new VM.

This process gets stuck on the final step when creating the new VM. It eventually just times out on the creation and throws an error saying that it "might" have worked. But as soon as I try SSH into it, I have no luck.

Would love to hear a possible alternative to this, that doesn't involve destroying my original VM!

[axelgMS]

@MitchellNZ can you paste the exact error message you had at the end of the new VM creation?
How did you generalize the VM created from the disk snapshot? can you share the exact steps?
What do you see in the Boot Diagnostics section / VM screenshot for the new VM?

[MitchellNZ]

@axelgMS Unfortunately I didn't save a copy of the full error message Azure was giving me on creation, and I have given up on this for now. However, I did manage to find this line in the logs:

ERROR Provisioning failed: [ProvisionError] Giving up, ovf-env.xml was not copied to /var/lib/waagent/ovf-env.xml after 1800s

Another recurring error I see in the logs is:

localhost login: [ 141.284919] cloud-init[1332]: failed run of stage modules-final
[ 141.285731] cloud-init[1332]: ------------------------------------------------------------
[ 141.286567] cloud-init[1332]: Traceback (most recent call last):
[ 141.288283] cloud-init[1332]: File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 650, in status_wrapper
[ 141.290791] cloud-init[1332]: ret = functor(name, args)
[ 141.291804] cloud-init[1332]: File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 479, in main_modules
[ 141.294000] cloud-init[1332]: init.fetch(existing="trust")
[ 141.295716] cloud-init[1332]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 349, in fetch
[ 141.301975] cloud-init[1332]: return self._get_data_source(existing=existing)
[ 141.303784] cloud-init[1332]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 250, in _get_data_source
[ 141.305817] cloud-init[1332]: util.del_file(self.paths.instance_link)
[ 141.307880] cloud-init[1332]: File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1682, in del_file
[ 141.309913] cloud-init[1332]: raise e
[ 141.311638] cloud-init[1332]: File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1679, in del_file
[ 141.313692] cloud-init[1332]: os.unlink(path)
[ 141.315443] cloud-init[1332]: IsADirectoryError: [Errno 21] Is a directory: '/var/lib/cloud/instance'
[ 141.320089] cloud-init[1332]: ------------------------------------------------------------

To generalize the VM I clicked the Capture button on the Azure portal. This had a warning that told me to first run sudo waagent -deprovision+user to prepare the Linux guest OS on the virtual machine.
So I SSH connected to Linux VM and ran that command (which seemed to work fine).

After that, I stopped the VM and clicked the Capture button from the Azure portal again, and this time I completed it to create the VM image.

My VM/Linux knowledge is quite limited (software developer attempting this setup!) I never got to the stage of seeing any deeper boot diagnostics logs, sorry. I was unable to SSH into the VM like I could my original one, and I was never getting any response from web requests (created VM with SSH, HTTP and HTTPS enabled).

Creation was also done via the Azure portal workflow, selecting the VM image as the base.

Hope this helps, if you want anymore info, just let me know.

[axelgMS]

Here are the generic steps to correctly generalize a Linux image:
https://docs.microsoft.com/en-us/azure/virtual-machines/linux/create-upload-generic
and you'll find other doc for each specific distro.

Your error has its source code here

and your call stack seems similar to that issue [Ubuntu 18.04 --deprovision causes host name to become localhost #1398 ](Ubuntu 18.04 --deprovision causes host name to become localhost #1398 )

[Mwiedmeyer]

So after nearly 8 months, the answer is 'Don't do that'???

This is common scenario.

Can they not reproduce the behavior and FIX it?

AWS is looking better and better,

Thank heavens the VMs I have that display the same problem are non-prod machines.

Not moving any production workloads to Azure until this is addressed.

Re-building all of my Prod machines from scratch is a deal killer. :-(

[jsblake]

Is there any news on this issue? The workaround of sysprepping and rebuilding the VM is not acceptable

[cynthn]

@jsblake VMs created using the "attach" functionality still can't use the procedure as it is written. My understanding is that you have to use another method to pass the secret to the VM (probably using custom script extension). You still don't get an OS profile if you create a VM using a "specialized disk" that gets attached to a VM.

We recently added specialized disk support to shared image gallery, so I know the lack of an osProfile is still an issue in some cases. I am trying to get details together for a work around, but it will take some time.

[mimckitt]

#reassign: @micahmckittrick-msft

[mimckitt]

I added a note that this tutorial only works for Generalized images.

I created a backlog doc item to look into work arounds if you want to accomplish the same using a specialized disk. Once that is created I will publish that doc and link it to this one.

[somuit91]

I am facing same issue, Using Specialized VHD, I am unable to add OSProfile. How can i change the Hostname/computername of the VM?

[ehm-wehb]

Am I missing something or has it been over two years with no resolution to this? I have a specialized image and am running into this same error when deploying via cli. Just doing a simple az vm create:
az vm create --resource-group myresourcegroup --name testvm --image "/subscriptions/tenant/resourceGroups/myresourcegroup/providers/Microsoft.Compute/galleries/BaseImage/images/Base-v-1-1-Unattend/versions/1.1.0"

Results in:

Deployment failed. Correlation ID: c8f50229-0335-4a73-af14-a92fe364d7e4. {
  "error": {
    "code": "InvalidParameter",
    "message": "Parameter 'osProfile' is not allowed.",
    "target": "osProfile"
  }
}

[VikasPullagura-MSFT]

@cynthn @mimckitt Can you please check and add your comments.

[mimckitt]

We added a note to the doc. Specialized images do not have an OsProfile so you cannot update something that does not exist. To do this you need to generalize the image.

As per changing the host name of the computer, you can do that from inside the guest os by going to my computer

[jsblake]

We added a note to the doc. Specialized images do not have an OsProfile so you cannot update something that does not exist. To do this you need to generalize the image.

As per changing the host name of the computer, you can do that from inside the guest os by going to my computer

The original issue related to setting an SSL certificate from a keyvault, which the method used would set the keyvault secret on the VM itself.

There is a better way now (and maybe even back when this issue was opened) using the Azure KeyVault VM Extension instead of modifying the secrets on the VM object itself, however

[deepakjgupta]

In my case, I created a VM using an Azure Template. Then had to delete and re-create the VM by re-attaching the same OS disk because it was incorrectly created as part of an Availability Set. This caused the osProfile section to get deleted. Now I'm trying to add the VM back to "Update Management" but am unable to do so because the properties for that are in the osProfile section.

Any thoughts on how to resolve this?

[martinbellett]

ran into the same issue after deleting a vm and restoring from backup. the osprofile property is missing and cant be added after. same issue also happens when migrating vm's from onprem to azure.

[prashanthmiryala]

I also have same issue my situation is completely different.
we have a VM on which we do SKU change periodically with automation, we did enabled Update (Azure update manager) to install patches automatically. later we are unable to change SKU automatically with (Changing property 'osProfile' is not allowed) error.
but able to change SKU manually.
could someone help what is the resolution here.