With the Azure Batch PowerShell cmdlets, you can perform and script many common Batch tasks. This is a quick introduction to the cmdlets you can use to manage your Batch accounts and work with your Batch resources such as pools, jobs, and tasks.
New-AzBatchAccount creates a Batch account in a specified resource group. If you don't already have a resource group, create one by running the New-AzResourceGroup cmdlet. Specify one of the Azure regions in the Location parameter, such as "Central US". For example:
Then, create a Batch account in the resource group. Specify a name for the account in <account_name>, and the location and name of your resource group. Creating the Batch account can take some time to complete. For example:
The Batch account name must be unique to the Azure region for the resource group, contain between 3 and 24 characters, and use lowercase letters and numbers only.
Get account access keys
Get-AzBatchAccountKeys shows the access keys associated with an Azure Batch account. For example, run the following to get the primary and secondary keys of the account you created.
New-AzBatchAccountKey generates a new primary or secondary account key for an Azure Batch account. For example, to generate a new primary key for your Batch account, type:
To generate a new secondary key, specify "Secondary" for the KeyType parameter. You have to regenerate the primary and secondary keys separately.
Delete a Batch account
Remove-AzBatchAccount deletes a Batch account. For example:
PowerShell
Remove-AzBatchAccount -AccountName <account_name>
When prompted, confirm you want to remove the account. Account removal can take some time to complete.
Create a BatchAccountContext object
You can authenticate to manage Batch resources using either shared key authentication or Microsoft Entra authentication. To authenticate using the Batch PowerShell cmdlets, first create a BatchAccountContext object to store your account credentials or identity. You pass the BatchAccountContext object into cmdlets that use the BatchContext parameter.
By default, the account's primary key is used for authentication, but you can explicitly select the key to use by changing your BatchAccountContext object’s KeyInUse property: $context.KeyInUse = "Secondary".
Use cmdlets such as New-AzBatchPool, New-AzBatchJob, and New-AzBatchTask to create resources under a Batch account. There are corresponding Get- and Set- cmdlets to update the properties of existing resources, and Remove- cmdlets to remove resources under a Batch account.
When using many of these cmdlets, in addition to passing a BatchContext object, you need to create or pass objects that contain detailed resource settings, as shown in the following example. See the detailed help for each cmdlet for additional examples.
Create a Batch pool
When creating or updating a Batch pool, you specify a configuration. Pools should generally be configured with Virtual Machine Configuration, which lets you either specify one of the supported Linux or Windows VM images listed in the Azure Virtual Machines Marketplace, or provide a custom image that you have prepared. Cloud Services Configuration pools provide only Windows compute nodes and do not support all Batch features.
When you run New-AzBatchPool, pass the operating system settings in a PSVirtualMachineConfiguration or PSCloudServiceConfiguration object. For example, the following snippet creates a Batch pool with size Standard_A1 compute nodes in the virtual machine configuration, imaged with Ubuntu Server 20.04-LTS. Here, the VirtualMachineConfiguration parameter specifies the $configuration variable as the PSVirtualMachineConfiguration object. The BatchContext parameter specifies a previously defined variable $context as the BatchAccountContext object.
The target number of compute nodes in the new pool is calculated by an autoscaling formula. In this case, the formula is simply $TargetDedicated=4, indicating the number of compute nodes in the pool is 4 at most.
Query for pools, jobs, tasks, and other details
Use cmdlets such as Get-AzBatchPool, Get-AzBatchJob, and Get-AzBatchTask to query for entities created under a Batch account.
Query for data
As an example, use Get-AzBatchPools to find your pools. By default this queries for all pools under your account, assuming you already stored the BatchAccountContext object in $context:
PowerShell
Get-AzBatchPool -BatchContext$context
Use an OData filter
You can supply an OData filter using the Filter parameter to find only the objects you’re interested in. For example, you can find all pools with IDs starting with “myPool”:
This method is not as flexible as using “Where-Object” in a local pipeline. However, the query gets sent to the Batch service directly so that all filtering happens on the server side, saving Internet bandwidth.
Use the Id parameter
An alternative to an OData filter is to use the Id parameter. To query for a specific pool with id "myPool":
PowerShell
Get-AzBatchPool -Id"myPool" -BatchContext$context
The Id parameter supports only full-ID search; not wildcards or OData-style filters.
Use the MaxCount parameter
By default, each cmdlet returns a maximum of 1000 objects. If you reach this limit, either refine your filter to bring back fewer objects, or explicitly set a maximum using the MaxCount parameter. For example:
To remove the upper bound, set MaxCount to 0 or less.
Use the PowerShell pipeline
Batch cmdlets use the PowerShell pipeline to send data between cmdlets. This has the same effect as specifying a parameter, but makes working with multiple entities easier.
For example, find and display all tasks under your account:
Application packages provide a simplified way to deploy applications to the compute nodes in your pools. With the Batch PowerShell cmdlets, you can upload and manage application packages in your Batch account, and deploy package versions to compute nodes.
Dôležité
You must link an Azure Storage account to your Batch account to use application packages.
You must delete all of an application's application package versions before you delete the application. You will receive a 'Conflict' error if you try to delete an application that currently has application packages.
Deploy an application package
You can specify one or more application packages for deployment when you create a pool. When you specify a package at pool creation time, it is deployed to each node as the node joins pool. Packages are also deployed when a node is rebooted or reimaged.
Specify the -ApplicationPackageReference option when creating a pool to deploy an application package to the pool's nodes as they join the pool. First, create a PSApplicationPackageReference object, and configure it with the application ID and package version you want to deploy to the pool's compute nodes:
To update the applications assigned to an existing pool, first create a PSApplicationPackageReference object with the desired properties (application ID and package version):
Next, get the pool from Batch, clear out any existing packages, add the new package reference, and update the Batch service with the new pool settings:
You've now updated the pool's properties in the Batch service. To actually deploy the new application package to compute nodes in the pool, however, you must restart or reimage those nodes. You can restart every node in a pool with this command:
You can deploy multiple application packages to the compute nodes in a pool. If you'd like to add an application package instead of replacing the currently deployed packages, omit the $pool.ApplicationPackageReferences.Clear() line above.