I need to develop powershell script for automating vm patches updating in azure. I know we can do it by using azure update management but is there any other way to do it? I'm new to it please help.
You could refer to this Virtual Machines - Update to update a virtual machine.
PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachines/{vmName}?api-version=2020-06-01
In addition, we could also do this in the UI and capture the request URL and request Body in the Network via F12, then convert it to power shell script.
As per this Microsoft Q&A platform question, you may use PSWindowsUpdate powershell module cmdlets.
And, if you are looking for a way to implement a way by removing dependency on Azure Automation and Azure Log Analytics then check Automatic VM guest patching (Preview).
Also, I would love to know the reason for trying to manually develop script for automating VM patches when the same is already available to us in the form of Update management solution (that is integrated with Azure Automation and Azure Log Analytics).
Related
I have some .exe files which i need to install on VMs in azure using azure automation powershell DSC. Is this possible and how can it be done? The exe files are currently stored in an azure file share.
A similar question was asked here The answer provided was:
If you want to do the install the EXE remotely then the VM needs to be configured to allow for remote management - you can do this via WinRM. See: https://www.penflip.com/powershellorg/secrets-of-powershell-remoting/blob/master/accessing-remote-computers.txt and http://tarkus.me/post/64761019099/windows-azure-vms-remote-management
Setting this up is non-trivial (you need to ensure it's secure). You could also try adding an VM extension to the VM that will do the copy. Since the VM is already provision I think the only option here would be to use DSC though I've never added a DSC extension to a VM post-provisioning, it should work. That would require authoring and staging a DSC script in addition to adding the extension but definitely less complex than enabling remote management.
You should also consider Azure automation, depending on how large scale is your automation projects are. You can find more info and tutorials here
I am working through my first Azure HDInsight tutorial. Can I do this without installing Azure Remote PowerShell on my local computer?
Can I use SSMS (2008R2) to run the PowerShell? My first attempt at that led me down the path of using a Database in Azure, but I do not think that is what I want to do (the tutorial describes setting Storage (not a Database) and then an HDInsight instance to interact with that Storage).
I am doing this tutorial: http://www.windowsazure.com/en-us/manage/services/hdinsight/get-started-hdinsight/
Thank you.
While you can use SQL Server and HDInsight together as part of a full pipeline, for the purposes of the getting started tutorial you want to think of them as two very different things.
The Storage referred to, is a standard Windows Azure Storage account, based on blobs. These then form a backing file system for the HDInsight cluster.
As far as using PowerShell goes, it is definitely the best, and easiest way to submit jobs to an HDInsight cluster. I would also recommend using a regular PowerShell console, or the PowerShell ISE to work with HDInsight as well, rather than the one available through SSMS, since the SSMS version won't load all the Azure modules by default.
There are other ways to submit jobs if PowerShell is not your thing (if you are on OS X or Linux for instance). You can use the REST API provided by WebHCAT (documentation). If you're on Windows, and prefer C# to PowerShell, you can also use the Windows Azure HDInsight Management Client from the Microsoft Hadoop SDK to submit jobs (available on codeplex and nuget). These will need you to break out Visual Studio and write a short console program to submit your job, so may be a bit heavy unless you're doing full on C# streaming Map Reduce, and so are already there.
If you're after a GUI based approach to job submission to HDInsight, you're out of luck at the moment, but your might like to check out what my team is working on at Red Gate, which will help you with submitting Hive and Pig jobs.
What are the differences between Azure PowerShell Commandlets and Command-Line Tools?
is there a difference in capabilities?
are new versions published at around the same time?
is one of them the 'preferred' way to manage Azure resources?
I am interested in managing web sites, VMs and cloud services from developer's machine and also from Ci server (TeamCity/MSBuild - starting / stopping VMs).
I've noticed that Command-Line Tools is just a small ~5MB download while PowerShell commandlets have several dependencies (~22MB) and June 2013 version still relies on Azure SDK 1.8 October 2012.
The PowerShell cmdlets work only in PowerShell (on Windows machines). They're great for automating several concurrent tasks (i.e. scripting out an entire environment), or carrying out single tasks.
The command-line tools are cross platform tools (work on Windows, Linux, etc.) These are written in node.js. They're not as good for scripting multiple actions, but are great for developers that prefer the command line to execute tasks (instead of going to the Azure management portal).
As far as I can tell, they are not on a synced release schedule. You can follow the progress of each via their github.com repositories (https://github.com/WindowsAzure/azure-sdk-tools-xplat and https://github.com/WindowsAzure/azure-sdk-tools).
It appears that Powershell is a wrapper for the node tools. If you get an error in PS it will reference a .js file.
To test this simply allow your authentication token to expire without a login. The error message in the .json file it sends you to indicates a failure in a Javascript file.
The release schedule for WIndows Azure PowerShell and the command line tools are both approximately once every 3 weeks. You can get the latest from the github repo at any time (as shown above).
After looking around for some information about managing my azure app i found csmanage and powershell commandlets. What are the difference between these applications and which one to choose?
The basis of Windows Azure Services management is REST API and beauty of using REST API is that you can wrap REST in any programming language as longs as there is networking and security infrastructure available. Most of the tools you mentioned above are using REST API underneath and using Windows Azure Service Management API. CSMANAGE and PowerShell Cmdlets are using Windows Azure Service Management API to manager Windows Azure subscriptions. You can learn more about Service Management API here.
There is also another tool call WAPMMC (Windows Azure Platform Management Tool (MMC) which is also built upon Service Management API.
Besides it there are 3rd party tools which are built using Service management API i.e. Cerebrata Powershell cmdlets.
Comparing all of above, I would say Windows Azure Powershell Cmdlets is the most powerful tool among all of these and it has been updated with bug fixes and many more features added frequently. To use it in your machine you just need to download powershell cmdlets and Windows Azure SDK in your machine as these are required.
http://wappowershell.codeplex.com/
Recently I also found a Java based tool called Burp to use REST API directly from its shell to manage Windows Azure subscription. There is no need for .net framework or Azure SDK. You just need a machine with Java runtime and Burp. I have added a blog on this regard here.
I think it depends on what you're more comfortable with. I don't think the CSManage tool is being updated that much any longer (maybe at all - unsure). The PowerShell cmdlets get a lot of attention - both from Microsoft and partners like Cerebrata.
My vote - learn PowerShell and go with the PowerShell cmdlets for working with your Windows Azure apps. Small learning curve and well worth it.
Newbie to automated azure deployment here! I have the happy task of automating our deployment to the cloud. I have also done some reading and discovered that the 2 main tools are MSbuild and Powershell. Please could anyone tell me why i would use one over the other or indeed if there are any better ways to automate the deployment. Keeping in mind that my main concern is performance and i need this deplymrnt to be as fast as possible.
Any insight would be most welcome.
I'm a fan of using PowerShell for deployments. It's pretty quick to set up and the script can be pretty straight forward.
MSBuild can be great too. I use MSBuild from TFS Team Build to kick off a PowerShell script to do the deployment. Works like a champ.
A good starting point would be http://blogs.msdn.com/b/tomholl/archive/2011/12/06/automated-build-and-deployment-with-windows-azure-sdk-1-6.aspx. This blog does a great job of showing you how to build and deploy with Team Build.
If you don't want/need the Team Build and MSBuild part, then just look at his PowerShell script. That covers the basics of getting a deployment from your dev environment to Windows Azure.
You should use Web Deploy, it only takes about a minute to deploy a fix. See these links
http://blogs.msdn.com/b/cloud/archive/2011/04/19/enabling-web-deploy-for-windows-azure-web-roles-with-visual-studio.aspx
http://channel9.msdn.com/Blogs/funkyonex/Speed-Up-Azure-Deployments-with-the-New-Web-Deployment-Feature
At SplendidCRM, we had a similar need to automate deployments to Azure, but as our need was to service our live customers, we had to develop using C#. We have been watching Azure for many years, but it was not until they provided a DNS service did it make sense to make the move. Using the Azure Resource Manager (ARM) libraries, we were able to automate VM creation, SQL database creation and DNS name creation. In addition to the Microsoft documentation for ARM, we found it particularly useful to be able to get the Microsoft source code for the PowerShell scripts that wrap ARM. This is because the documentation does not always provide a complete set of settings.
In the end, we decided to release the Azure deployment code as part of a new Ultimate edition that combines order and customer management with software deployment.