I have an Azure Image, which when I use Azure Powershell to create a VM from, despite me setting the ComputerName in the script, the VM is created without setting the ComputerName to the provided value.
Script:
$ImageName = 'MyImage'
$RsgName = 'MyRsg'
$VmName = 'MyNewVM'
$DiagnosticStorageName = 'diagnosticsstore5048'
$cred = Get-Credential -Credential 'TheAdmin'
$Image = Get-AzureRmImage -ImageName $ImageName -ResourceGroupName $RsgName
# Get NIC
$nic = Get-AzureRmNetworkInterface -ResourceGroupName $RsgName
# Configure the new VM
$Vm = New-AzureRmVMConfig -VMName $VmName -VMSize 'Standard_A2_v2'
$Vm = Set-AzureRmVMSourceImage -VM $Vm -Id $Image.Id
$Vm = Set-AzureRmVMOSDisk -VM $Vm -Name $VmName'-disk' -StorageAccountType 'StandardLRS' -DiskSizeInGB '128' -CreateOption FromImage -Caching ReadWrite
$Vm = Add-AzureRmVMNetworkInterface -VM $Vm -Id $nic.Id
$Vm = Set-AzureRmVMBootDiagnostics -VM $Vm -Enable -ResourceGroupName $RsgName -StorageAccountName $DiagnosticStorageName
$Vm = Set-AzureRmVMOperatingSystem -VM $Vm -Windows -ComputerName 'dor' -Credential $Cred -ProvisionVMAgent
New-AzureRmVM -VM $Vm -ResourceGroupName $RsgName -Location 'West Europe' -DisableBginfoExtension
Last time I run the script to create the VM, it left the new VM with a computer name of 'WIN-I80O6J22ENS'
The Image was created as per the process here: https://learn.microsoft.com/en-gb/azure/virtual-machines/windows/capture-image-resource?toc=%2Fazure%2Fvirtual-machines%2Fwindows%2Fclassic%2Ftoc.json
UPDATE
Alot of people think that I am not Generalizing the image correctly, so I wanted to add here how I am doing it.
Inside the VM I run:
Start-Process -FilePath $env:windir\System32\Sysprep\Sysprep.exe -ArgumentList "/generalize /oobe /shutdown /unattend:$env:windir\System32\Sysprep\unattend.xml"
Unattend.xml only has one setting in it which is to step the TimeZone.
Once this is completed and the VM OS has shut down, I run the following to get the VM, stop it, and set it to Generalized:
# Shutdown Source VM & Generalize
$SourceVM = Get-AzureRmVM -ResourceGroupName $SourceRsg -Name $SourceVMName
$Null = Stop-AzureRMVM -ResourceGroupName $SourceRsg -Name $SourceVMName -Force
Write-Host 'Stopped Source VM'
Set-AzureRmVm -ResourceGroupName $SourceRsg -Name $SourceVMName -Generalized
Write-Host 'Set Source VM to Generalized'
I have noticed that when the last command is ran, the output is:
OperationId :
Status :
StartTime :
EndTime :
Error :
It doesn't actually say if it was successful or not?
After this I create the Image from the VM disk.
It might be caused by the image not being "Generalized".
Take a look at the Create a managed image of a generalized VM in Azure guide.
Hope it helps!
If you have a specialized image, the Computer name will be missing because the old computer name and the new computer name share the same RID and SID number and on a ideal situation each virtual machine deployment has different RID and SID number. The Computer name can be displayed if the image is a generalized.
Check this article for more information:
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/create-vm-specialized
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/capture-image-resource
The point everyone is trying to make, from your description of the issue, it seems the Image was not generalized correctly or aspect of the generalization failed.
The script work fine on my end, so the only issue is with the image. Screenshot
Try another deployment from that image an see is you get the same computer name (WIN-I80O6J22ENS).
If you get the same name that is a sure confirmation of issue with generalization.
If the name changes it might mean that the machine you imaged has a policy that is not accepting the name 'dor' so the system is generating default name.
Either way issue is not with the Powershell or Azure. Hope this helps.
Related
I created a custom, generalized (using Sysprep), Windows 11 image from an Azure hosted VM and stored it in a custom Azure Compute image gallery.
c:\Windows\system32\sysprep\sysprep.exe /quiet /generalize /oobe /quit
It works when I use the custom gallery image to create Azure hosted VMs with 4 cores and 16GB RAM (Standard_D4s_v5).
It DOES NOT work when I try to use it in Hyper-V on my local system with the same cores and RAM.
I download the custom image from the gallery using the method described here.
$version = Get-AzGalleryImageVersion -ResourceGroupName $ResourceGroupName `
-GalleryName $GalleryName -GalleryDefinitionName $GalleryDefinitionName `
-Name $GalleryImageVersionName -ErrorAction Stop;
$diskConfig = New-AzDiskConfig -Location $Location -CreateOption FromImage `
-GalleryImageReference #{ Id = $version.Id };
$diskName = Split-Path -Path $version.StorageProfile.Source.Id -Leaf;
$disk = New-AzDisk -ResourceGroupName $ResourceGroupName -DiskName $diskName `
-Disk $diskConfig -ErrorAction Stop;
$diskAccess = Grant-AzDiskAccess -ResourceGroupName $disk.ResourceGroupName `
-DiskName $disk.Name -Access Read `
-DurationInSecond (New-TimeSpan -Minutes 60).TotalSeconds -ErrorAction Stop;
$vhdPath = "c:\downloads\$diskName.vhd";
Get-AzStorageBlobContent -Uri $diskAccess.AccessSAS -Destination $vhdPath `
-ErrorAction Stop;
Once that downloads I set up a VM locally with the code below.
$vm = New-VM -Name "TestVM" -VHDPath $vhdPath -MemoryStartupBytes 16GB `
-ErrorAction Stop;
$vm = $vM | Set-VM -ProcessorCount 4 -AutomaticCheckpointsEnabled $false `
-CheckpointType Standard -PassThru -ErrorAction Stop;
$vm | Start-VM -ErrorAction Stop;
It says it starts but when I connect to it using the Hyper-V Virtual Machine Connection window all it shows is a blank screen with a flashing cursor.
Evidence leads me to believe that this is not a graphics card issue (which other stack overflow articles address):
If I let it run for a few minutes and try to do a shutdown the operation fails with a "The device is not ready for use" error.
I've tried this on two different hosts and see the same thing.
Both of the hosts I've tried it on I can successfully run an image I created using Disk2VHD.
Note: I have also used the /mode:vm argument in the SysPrep command but it had no effect on the outcome.
Any ideas on how to get this to work?
The key to resolving this was understanding two things:
HyperVGeneration : V2
Windows 11 Hyper-V hosting requirements: VHDX
The following produces a running Win-11 VM:
$vhdxPath = "c:\downloads\$diskName.vhdx";
Convert-VHD -Path $vhdPath -DestinationPath $vhdxPath -VHDType Dynamic -ErrorAction Stop;
$vm = New-VM -Name "TestVM" -VHDPath $vhdxPath -MemoryStartupBytes 16GB -Generation 2 -ErrorAction Stop;
$vm = $vm | Set-VM -AutomaticCheckpointsEnabled $false -CheckpointType Standard -PassThru;
$vm | Set-VMProcessor -Count 4 -ExposeVirtualizationExtensions $true -PassThru;
$vm | Start-VM;
I'm new to Azure. I'm trying to create resources in Azure using powershell.
My requirement is to create an image from a VM. I have followed to ways to do it :
Process 1: Do it manually
Generalize the VM : Login to VM -> Open command prompt -> cd %windir%\system32\sysprep --> run sysprep.exe --> Check generalize button--> Shutdown.
Create snapshot : Go to Azure portal-> Go to the VM which is generalized --> Click on Capture button --> Give image name and mention resource group and click on Create.
This will create an Image.
Process 2: Do it with powershell
# create session of the VM
$UserName = "$IPAddress\$adminUsername"
$Password = ConvertTo-SecureString $adminPassword -AsPlainText -Force
$psCred = New-Object System.Management.Automation.PSCredential($UserName, $Password)
$s = New-PSSession -ComputerName $IPAddress -Credential $psCred
# Run SysPrep for generalizing the VM
$sysprep = 'C:\Windows\System32\Sysprep\Sysprep.exe'
$arg = '/generalize /oobe /shutdown /quiet'
Invoke-Command -Session $s -ScriptBlock {param($sysprep,$arg)Start-Process -FilePath $sysprep -ArgumentList $arg} -ArgumentList $sysprep,$arg
#Stop the VM
Stop-AzureRmVM -ResourceGroupName $ResourceGroupName -Name $virtualMachineName -Force
# Generalize the VM
Set-AzureRmVM -ResourceGroupName $ResourceGroupName -Name $virtualMachineName -Generalized
# Create the Image
$vm = Get-AzureRmVM -Name $virtualMachineName -ResourceGroupName $ResourceGroupName
$image = New-AzureRmImageConfig -Location $location -SourceVirtualMachineId $vm.ID
New-AzureRmImage -Image $image -ImageName $ImageName -ResourceGroupName $ResourceGroupName
Both the processes will create a Image. But the problem I'm facing here is when I spin VM from the image created from Process 1 , it is created successfully without any issue.
But when I spin VM from image created from Process2 , it is getting created but with below error message :
Provisioning failed. OS Provisioning for VM 'VM Name' did not finish
in the allotted time. However, the VM guest agent was detected
running. This suggests the guest OS has not been properly prepared to
be used as a VM image (with CreateOption=FromImage).
Can anyone tell me what it is I'm doing wrong with powershell script, that I'm getting this error.
Time seems to be the issue.
Sysprep normally takes 10 - 15 minutes, you have no sleep time. You are shutting down VM as soon as the sysprep script is sent, no time to actually sysprep system.
You can either put a sleep time or a loop to check when VM is in a Stopped state.
There are quite a few docs on papering and creating VMs from images in Azure. As the error suggests, you likely missed a step.
If you are uploading a VHD from on prem to use in Azure, start with these docs
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/prepare-for-upload-vhd-image
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/upload-generalized-managed
If the VM you are capturing an image of is already in Azure and working, then start with these
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/capture-image-resource
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/create-vm-generalized-managed?toc=%2fazure%2fvirtual-machines%2fwindows%2ftoc.json
The last link shows you how to create the VM from that image via the portal or a simple PS command
New-AzVm `
-ResourceGroupName "myResourceGroup" `
-Name "myVMfromImage" `
-ImageName "myImage" `
-Location "East US" `
-VirtualNetworkName "myImageVnet" `
-SubnetName "myImageSubnet" `
-SecurityGroupName "myImageNSG" `
-PublicIpAddressName "myImagePIP" `
-OpenPorts 3389
So I have been trying to create a VM from Linux VHD and getting this error.
Following this
https://pebkac.io/2016/10/mikrotik-chr-in-azure-part-two/
Dinesh has resolved the problem, per comments on this.
It seems that the NIC creation may have been long running.
According to your error, please ensure NIC Interface is created successful.
$InterfaceName = "nic-chr-test"
$Interface = Get-AzureRmNetworkInterface -Name $InterfaceName -ResourceGroupName
You could the result of $Interface, if this is NULL, please create NIC firstly.
Also, you could try to use this template or scripts in this
template.
[Worked for me , needed to add the network interface to vm. Here is the cmdlet
Assuming you already created $nic - network interface earlier
PS C:\azure> $vm = Add-azurermvmnetworkinterface -vm $vm -id $nic.id
PS C:\azure> new-azurermvm -resourcegroupname $rgname -location $location -vm $vm
Add the NW interface for the VM
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.id
I am trying to add the WinRs support using the publically available ARM Template
I get the following error
Changing property 'windowsConfiguration.winRM.listeners' is not allowed
Then I tried using the powershell script mentioned in this article at the end. I'm not sure if it's just me who found the script to be a little wrong, cos it wasn't sorking so I changed it to as below
$vm = Get-AzureRmVM -ResourceGroupName "dscwitharm" -Name "dscwitharm"
$credential = Get-Credential
$secretURL = (Get-AzureKeyVaultSecret -VaultName "nithishvault" -Name "dscwitharmwinrs").Id
$vm = Set-AzureRmVMOperatingSystem -VM $vm -Windows -ComputerName "dscwitharm" -Credential $credential -WinRMHttps -WinRMCertificateUrl $secretURL
$sourceVaultId = (Get-AzureRmKeyVault -ResourceGroupName "dscwitharm" -VaultName "nithishvault").ResourceId
$CertificateStore = "My"
$vm = Add-AzureRmVMSecret -VM $vm -SourceVaultId $sourceVaultId -CertificateStore $CertificateStore -CertificateUrl $secretURL
Update-AzureRmVM -ResourceGroupName "dscwitharm" -VM $vm
And I still get the same error. What am I missing?
> Changing property 'windowsConfiguration.winRM.listeners' is not allowed
This seems to be a known issue and I found a work around. The following template uses a customScript extension to execute PowerShell to create a self signed certificate and configure WinRm over HTTPS.
https://github.com/Azure/azure-quickstart-templates/tree/master/201-vm-winrm-windows
This is indeed a different approach from what the documentation article recommends ARM Tempate
I am provisioning an Azure VM using powershell script, and specify to inject a powershell extension. This behaviour worked ok last time on 1st June, but yesterday when I tried again, the VM in the Azure Management had a status of "Running (Installing Extensions)", and it didn't change after an hour at which point I gave up and deleted the deployment.
I have a very basic script for deploying the VM and also an empty powershell script that I inject (all this setup worked before):
$username = "VMUser1"
$password = "SomethingAsPa$$1"
$imagename = "a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-R2-201404.01-en.us-127GB.vhd"
$name = "unqvmname"
$serviceName = "unqvmname"
$location = "North Europe"
$fileUrl1 = 'http://portalvhds3r84wq5g3925q.blob.core.windows.net/scripts/dummy.ps1'
$vm = New-AzureVMConfig -Name $name -InstanceSize Small -ImageName $imageName
$vm = Add-AzureProvisioningConfig -VM $vm -Windows -AdminUsername $username -Password $password
$vm = Set-AzureVMCustomScriptExtension -VM $vm -FileUri $fileUrl1 -Run 'dummy.ps1' -Argument 'arg1_some_data'
New-AzureVM -ServiceName $serviceName -Location $location -VMs $vm
The $fileUrl1 is a empty powershell file.
Running this will end up in a VM that gets hanged in a "Running (Installing Extensions)" status. Does anyone else happen to have this problem and know a solution?
Today 6 June 2014, all came back to normal. The VMs are being created and the extension scripts run with success.