Recently switched to a new machine, and installing all Azure powershell modules etc. I can no longer find the cmdlet New-AzureDnsRecordSet. The DNS Zone I currently have is based on service management not ARM, so I can't use the new ARM cmdlets. I can see majority of the other Azure service management commands, but not these ones.
I've tried:
Install-Module Azure
Import-Module Azure
nothing is adding those cmdlets in. The new Rm cmdlets are there, and you can see some Azure modules are there. Do I need to recreate the DNSzone with the new Rm cmdlet?
Yes, the New-AzureDnsRecordSet cmdlet has been deprecated in the latest version of Azure module as you have shown, which implies you can no longer create new Azure DNS record set in Classic (Service Management) mode.
You will need to create new Azure DNS Record Set with the new RM cmdlet (New-AzureRmDnsRecordSet) if you are using the latest Azure PowerShell version.
Hope that answers your question.
Related
I have a VSTS release pipeline which provisions a new function app with a Managed Service Identity. My solution includes a shared key vault instance for my app secrets. Key vault allows a maximum of 16 access control entries so I've taken the approach of creating an Azure AD group for applications which I will add application service principals to. All straight forward and workable in PowerShell locally, but I'm not able to figure out a way to do this using hosted build servers in the VSTS release pipeline and a Run Powershell In Azure release task.
The Azure CLI is at version 1.X on the Hosted build server and 2.x on the Hosted 2017 build server
* 1.x doesn't appear to offer AD group manipulation or graph API access
* 2.x does offer az ad group member add but the hosted 2017 build has a problem with New-AzureStorageTable which is used elsewhere in my pipeline, so I can't use it
Similarly, the Azure RM powershell module on the Hosted build server is very old and doesn't appear to support group membership manipulation. The version on the Hosted 2017 server (which I can't use) has commands like Get-AzureRmADGroup but nothing to add a user to that group.
The cmdlet Add-AzureADGroupMember, available in the AAD powershell would be a nice solution, but it's not available on either the Hosted or Hosted 2017 build servers.
I've considered both automation runbooks and direct HTTPS posts to the graph API using the OAuth token available in the release pipeline, but want to stay with PowerShell to keep the number of technologies in my release pipeline as small as possible. I'd also prefer to avoid storing credentials in a secured manner for use in a PowerShell command like Login-AzureRmAccount and rely on the identity of the Service Endpoint I defined for my release pipeline.
Suggestions appreciated.
Since the Hosted agent can’t meet your requirements, you can configure a private build agent (it’s free) on your machine: Deploy an agent on Windows.
Regarding Add-AzureADGroupMember cmdlet, you can install it by calling Install-Module -Name AzureAD through Azure PowerShell task, which works fine on Hosted agent.
Script:
Install-PackageProvider -Name NuGet -Force -Scope CurrentUser
Install-Module -Name AzureAD -Force -Verbose -Scope CurrentUser
How can I get a list of all the Active Directories in Azure using powershell? To be more precise, I am looking for the following information which is available in the Azure Portal [The following two entries] :
Also, how can I get detailed information of each of those two directories in powershell?
(I have already installed the Azure Active Directory Cmdlets)
Both options below will retrieve the available tenants, however the Azure AD Cmdlet will provide a little more information such as the Display Name and Verified Domains of the tenants.
Azure AD Modules
Cmdlet: Get-AzureADTenantDetail -All $true
Documentation: https://learn.microsoft.com/en-us/powershell/module/azuread/get-azureadtenantdetail
Azure Rm Modules
Cmdlet:Get-AzureRmTenant
Documentation: https://learn.microsoft.com/en-us/powershell/module/azurerm.profile/get-azurermtenant
Testing:
If you want to try these Cmdlets without needing to install them locally, check out Azure Cloud Shell. It'll provide you with a browser based Command Line for Microsoft Azure.
https://shell.azure.com
https://azure.microsoft.com/en-us/features/cloud-shell/
I have been trying to install the Azure Active Directory Module for Windows for Powershell. So far I have not been able to find a combination of the Sign-In Assistant and Powershell module versions that allows me to create a connection in a Powershell session. My measure for success has been to run the Connect-MsolService cmdlet to create such a connection. I have tried it both from the command line and in a script. The (few) forum and blogs posts that reference this functionality have been very contradictory.
I am using the same credentials that I use to log into manage.windowsazure.com.
As to the specifics I have the following configuration:
Windows Server 2012R2
Powershell version 4.0 ($PSVersionTable.PSVersion)
Microsoft Online Services Sign-In Assistant version 7.250.4556.0
Windows Azure Active Directory Module for Windows Azure version
1.0.8362. The version number is based on the command (get-item C:\Windows\System32\WindowsPowerShell\v1.0\Modules\MSOnline\Microsoft.Online.Administration.Automation.PSModule.dll).VersionInfo.FileVersion
My questions are as follows:
What versions work on Windows Server 2012R2?
Is there a specific .Net version that I might be missing?
Am I looking at it wrong? For example is the cmdlet
Connect-MsolService not the metric to be using? Is there another way
that I might verify that I have a connection?
My understanding is that the Powershell cmdlets, as well as all the other methods for managing Azure, are based on the REST API's. Would that be a better way to go? Of course I would not be able to dynamically enter commands, but I would be able to validate credentials etc.
Are you trying to authenicate with an MSA account? Try connecting with a Global Admin AAD account (eg. globaladminuser#tenant.onmicrosoft.com).
I'm using the PowerShell CmdLets to automate most tasks against Windows Azure Cloud Services and Windows Azure Web Sites.
For Cloud Services, I can use the Get-AzureDeployment CmdLet. However, the similar Get-AzureWebSiteDeployment CmdLet requires Git to be installed before it can run and does not seem to be designed for the same task.
As far as I can see, the Get-AzureWebSite CmdLet only ever retrieves the "Production" slot of a Windows Azure Web Site.
How is it possible to get programmatic access to the corresponding "Staging" slot ?
We are working on some PowerShell cmdlets to support website slots. We are very close to releasing it. Keep an eye on this repo on github. https://github.com/WindowsAzure/azure-sdk-tools
Current date update (Jul 19 2015):
According to Azure Docs Web Sites Staging Slots there are new CMDLets that support querying Slots:
Show-AzureWebsite -Name webappslotstest -Slot staging
And some others cmdlets extended with -Slot attribute (Create New Website, Remove, Switch Slots).
Hello I´m trying to automate AZURE VM management like Amazon EC2.
Is there any way to manage AZURE VM from Powershell like Amazon EC2 API ?.
I can´t find API easily documentation or how to do it.
Thanks in advance :)
Windows Azure Management Cmdlets lists a number of AzureVM cmdlets.
Add-AzureDataDisk : Adds a new data disk to a virtual machine object.
Add-AzureProvisioningConfig : Adds the provisioning configuration to a Windows Azure virtual machine.
Add-AzureEndpoint : Adds a new endpoint to a Windows Azure virtual machine
Export-AzureVM : Exports a Windows Azure virtual machine state to a file.
.....and tonnes more
Do these not cover what you need?
Windows Azure has a REST-based API for just about everything, including the management API. Additionally, the API has a corresponding set of Windows Azure PowerShell cmdlets that you can call, which essentially lets you automate your entire deployment via PowerShell.
The most recent version, 2.2.2, has the ability to persist subscription settings, obviating the need for repeating parameters such as subscription ID and certificate thumbprint. Michael Washam, Technical Evangelist, blogged about v2.2.2 here.