I would like to create a virtual machine in Azure that is automatically reset to the just-deployed state after a user disconnects. I can probably do this through creating a backup image and doing a restore after the user logs out with Save-AzureVMImage, but I am wondering if there is any way to set the machine to not save state at all, as used to be the default case in old virtual machines. The reset state must include the state of the OS, not just applications, so it is bit-for-bit identical (or as practically close as possible) to an initial deployment. Right now I am re-deploying a new VM manually to achieve this goal.
Is there a way to configure a VM to behave like I want?
If not, is there a way to automate the restore process after a user logs out of the VM?
There's no such feature, but shouldn't be hard to develop something like this using Automation. The first DevOps logic I could think of is:
Create a VM image
Create a Powershell script to destroy the old and deploy a new VM from this image
Create an Automation account and create a runbook with this script
Use Webhook to trigger the runbook
Create a Powershell script to verify if no users are logged in (may need more logic in here)
Improve this script to make an HTTP POST to trigger the runbook
Assign User Logoff Script
Probably you could skip step 5 tho and step 2 actually needs to be done after step 7 because you need the script configured in the VM before snapshot.
Related
Currently, we are hosting five websites on a Linux VM. The websites reside in their separate directories and are hosted by Nginx. The SSL is terminated at Azure Application gateway which sends the traffic to the VM. If a file is updated in a remote repository, the local copy is updated by a cron task which is a simple Bash script running git pull and few additional lines. Not all five websites need to be updated at the same time.
We created the image of the VM and provisioned a VMSS set up.
What could be the easiest or standard way of deploying the codes to the VMSS? The codes also need some manual changes each time due to client's requirements.
Have a look into Azure Durable Functions as an active scripted deployment manager.
You can configure your Durable Function to be triggered via a cron schedule, then it can orchestrate a series of tasks, monitoring for responses from the deployment targets for acceptable response before continuing each step or even waiting for user input to proceed.
By authoring your complex workflow using either of C#/JavaScript/Python/PowerShell you are only limited by your own ability to transform your manual process into a scripted one.
Azure Functions is just one option of many, it really comes down to the complexity of your workflow and the individual tasks. Octopus Deploy is a common product used to automate Azure application deployments and may have templates that match your current process, I go straight to Durable Functions when I find it too hard to configure complex steps that involve waiting for specific responses from targets before proceeding to the next step, and I want to use C# to evaluate those responses or perhaps reuse some of my application logic as part of the workflow.
I logged into an existing VM, did sysprep, selected generalize + oobe, shutdown, waited for deallocation, then captured from the portal.
I created an image from the generalized disk in the Azure portal, but when it tries to start, it gets stuck in the Create state. Looking at the boot diagnostics, it appears it's asking for language, keyboard layout, etc. It is of course not possible to RDP into the machine in this state. Is there something I can add to the deployment template / automation script to get past this?
i have created one windows machine in my hyper-v after sysprep i have upload my VHD to azure account
when i am trying to login that windows machine i am unable to login the account getting disable
can any one please let me know how to login into that machine in azure account
In Adv Thanks.
Of course it is disabled.
sysprep is designed to put the OS into OEM state. All local accounts and user profiles are deleted. Because it will be the base image for all your future VMs.
This process creates a so called generalized image. The process is described here. You can read more about sysprep itself and the process of generalization here.
What you probably need (only probably, because you do not state your real use case), is a specialized image. Specialized image is the only way to just use the VM as is - with all its user profiles. You can read about that process here.
By using the specialized image your OS is left untouched with all its user profiles.
I am planning to capture my VM image in Azure to create a copy for VM deployments (I am using this to deploy multiple VM or any redeployment scenarios).
Will any data/ configurations lost during the process? Be it application wise or server. I am expecting it to work just as simple as copy and paste functionality no Gotchas. Everything within this VM is critical to my clients (Customized apps/ web services etc.)
P/S: I have done my research here: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-capture-image-windows-server/
It says it will delete my VM once I have captured the image, now this is where I am very worried about.
Process of capturing the VM will preserve the installed applications, data and most settings. However, it does clear a few things like the computer name, network settings etc, so that the same image could be used to create multiple VMs later on.
Also, this process will delete your existing VM. You have to create a new VM using the image.
If you are unsure about any required settings that may be lost in this process, strong recommendation is to create a backup of the existing VM before you begin. You can do that by doing AzCopy of all the vhds on the VM (OS and Data disks). You could delete the backup after verifying the image deployments.
There are two ways of creating Virtual Images:
Without deprovisioning it: Source VM is not destroyed. You should switch if off to avoid problems. If you create a VM from image their hostnames will clash. The idea is using this capture method for backups.
After running waagennt -deprovision on it: Source VM is destroyed in the process. You can create many VMs with no problem.This is probably what you want to do. Don't worry is harmless, apart of destroying source VM. You can always create a VM from that image. The idea is using this capture method for creating a base image and then have some kind of process to create and destroy servers (Auto Scaling).
For example you create a web server for your app and instantiate more VMs in peak times.
What does waagent exactly deprovision?
waagent -deprovision command clears some configuration on the machine. Exactly:
This command will attempt to clean the system and make it suitable for
re-provisioning. This operation performs the following tasks:
Removes SSH host keys (if Provisioning.RegenerateSshHostKeyPair is 'y' in the configuration file)
Clears nameserver configuration in /etc/resolv.conf Removes the root user's password from /etc/shadow (if
Provisioning.DeleteRootPassword is 'y' in the configuration file)
Removes cached DHCP client leases Resets host name to localhost.localdomain
Deletes the last provisioned user account (obtained from /var/lib/waagent) and associated data.
Apart of this nothing will be touch on your server.
We have a few servers in Azure that are running the same service. We would like them to be part of the same availability set. How do you add these servers together in the same availability set if they were not created in the same cloud service when they were created?
It looks like I would need to rebuild these VM's? If so that kinda sucks.
Please let me know if anyone knows a better way.
Thanks in advance.
Once a VM is created, it can't join an availability set.
However, the image for the VM is available in storage. So, new VMs can be spun up, using the image, this time adding them to the set. And rebuilding the VM from scratch is not needed.
Edit:
I've used the method above to bring up a VM, but I had forgotten that if your VM is running already, capture is the way to go. I'd suggest these steps:
Capture the image of your current VM. This will run sysprep on it, so you will want to be careful with it. (spin up a test VM and play with the steps until you feel confident to move to a production box)
Then when you create a new VM, specify your captured image and your availability set. Then the machine will come up with all your services running in the new set.