When working in my Azure labs I tend to end up with a lot of Azure App Registrations. Recently I had hundreds and hundreds of them in the directory. Its been a while since I cleaned this up. I needed to clean this out and did not want to do this manually through the portal. PowerShell to the rescue.
I pulled together a script that will place your app registrations in a variable. It will then loop through the app registrations to remove them. Note you will be prompted with a confirmation to remove each one.
In that blog post, I called out an Azure Policy on-demand evaluation PowerShell script I wrote. This PowerShell script will trigger Azure Policy to run the evaluation right away so you don’t have to wait for the next time Azure Policy will run the evaluation.
This is especially helpful when you are developing Azure Policies and you want to see if they are working properly or not. You can run the on-demand evaluation PowerShell script in Azure Cloud Shell at https://shell.azure.com/.
Well, that brings us to the end of this blog post. I wanted to make a short blog post for this script so that it would be easier to find.
Moving an Azure VM from one virtual network (VNet) to another VNet is not a new problem. If you find yourself having to do this just know it is a pain. Anyone that has faced the Vnet-to-Vnet VM Move conundrum before knows that moving a VM to another subnet is a trivial task and would think a VM move to another VNet would be the same. However, when it comes to moving a VM to a new VNet there is no supported way to do this from Microsoft and that is by design. There are some workarounds to moving a VM to a new VNet but in the end these boil down to redeploying the VM. When moving a VM to a new VNet you will need to plan for downtime.
In this blog post, I am not going to go through the steps of the workarounds for moving a VM to a new VNet. There are plenty of other blog posts out there covering how to do this manually or using ASR. If you want to read up on this there is one article I keep bookmarked by Microsoft MVP Tim Warner that you can find here. In this blog post, I am going to share and talk about a PowerShell script I pulled together to make the Vnet-to-Vnet VM Migration less painful by automating it. Download link is at the end of this blog post. I put together the script to work with PowerShell 5 using the AzureRM Module and one that works with PowerShell 7 (Core) using the AZ module.
Again, in general, the script is not moving the VM. The script is facilitating a migration of sorts by creating a new VM in new VNet while retaining the original VMs configuration and data disks. Here are the steps that are performed in the script:
(1) Gathers info on existing VM, VNet, and subnet. (2) Removes the original VM while saving all data disks and VM info. (3) Creates VM configuration for new VM, creates nic for new VM, and new availability set. (4) Adds data disks to new VM, adds nics to new VM, adds VM to the new VNet. (5)Creates new VM and adds the VM to the new VNet.
Let’s look at some other general information about the script. The script is a single script that has code for both PowerShell 5 using the AzureRM Module and PowerShell 7 (Core) using the AZ module. When you run the script it prompts you to choose what Azure module you are using. The script is interactive so it will prompt you to log in and prompt you for your Azure subscription in case you are running multiple subscriptions. The script is intended to migrate a single VM. It assumes the VM is deployed into an availability set and will migrate to a new availability set or in the existing availability set. You can also migrate to a new resource group or place the new VM in the existing resource group. Ok. Let’s dive into running the script. Here is a walk-through of running the script.
Open PowerShell and run Vnet-to-Vnet VM migration.ps1.
You will first be prompted for the following information:
Enter the Resource Group of the original VM: Enter the original VM name: Enter the new VM name: Enter the new availability set name: Enter the new VNet resource group: Enter the new VNet name: Enter the new Subnet name:
Next, you will be prompted to select your PowerShell version and Azure module as shown in the following screenshot.
The main differences
between PowerShell 5 using the AzureRM Module and PowerShell 7 (Core) using the
AZ module are the interactive login methods as well as cmdlets. Here are
screenshots of the different logins.
PowerShell 5 with AzureRM Module:
A window will pop up
for you to log into your Azure account.
Next a grid will pop
up for you to select your subscription from the list.
PowerShell 7 (Core) with AZ module:
A warning will pop up prompting you with the device login info. To log into Azure go to https://microsoft.com/devicelogin and entering the code the warning gave you as shown in the screenshot.
List of your subscriptions will output. Go ahead and copy the subscription ID you plan to use. NOTE* Ignore this if you only have one subscription.
You are prompted to enter your subscription ID. This is to set the PowerShell session to the specified Azure subscription. Again ignore this if you only have 1 subscription. Note if you leave it blank and click enter it will error. Even with the error, it will finish the rest of the script just fine.
Next in both PS 5 or
PS 7 you will see the following prompt confirming that you want to remove the
specified original VM. Confirm yes and press enter.
Virtual machine removal operation This cmdlet will remove the specified virtual machine. Do you want to continue? [Y] Yes [N] No [S] Suspend [?] Help (default is “Y”): Y
NOTE* the rest of the script will run. It will take a while so be patient. As it runs you should see some output similar to this:
WARNING: Since the VM is created using premium storage or managed disk, existing standard storage account, diagstwfyhhi3jyz54e, is used for boot diagnostics. VERBOSE: Performing the operation “New” on target “VMMove012”.
When it is all said
and done if it was successful you will see:
RequestId : IsSuccessStatusCode : True StatusCode : OK ReasonPhrase : OK
That’s it. Now go
into the Azure portal and you will see that your VM is moved to a new VNet and
will have the data disks still. Check out the following screenshots for an
example showing what the resource groups look like before and after the script
I wanted to monitor my Azure Stack environment with OMS. This would include only the Azure Stack fabric servers and the host. I did not want to manually install the OMS agent on all of these servers especially since the Azure Stack fabric is a set of known servers. So I decided to put together a quick PowerShell script to handle the install of the OMS agents including the workspace ID and key. Here are details for the script:
.SYNOPSIS This script can be used to install OMS agents on all of the Azure Stack Fabric servers. This has been tested with TP2.
.DESCRIPTION This script can be used to install OMS agents on all of the Azure Stack Fabric servers. This has been tested with TP2. This script can be run from PowerShell ISE or a PowerShell console. It is recommended to run this from an elevated window. This script should be run from the Azure Stack host. Ensure you are logged onto the Azure Stack host as azurestack\azurestackadmin. This script allows you to input your OMS workspace ID and key. The Azure Stack Fabric servers that this script will attempt to install on is:
Fabric servers can be added or removed from the array list if desired. The script will look for the OMS agent (MMASetup-AMD64.exe) in C:\OMS\ on the Azure Stack host. Ensure you create an OMS folder on your Azure Stack host and download the OMS agent to it. This script also copies the OMS agent to C:\Windows\Temp on each Fabric server. Ensure there is enough free space on the C drive on all of your fabric servers.
.PARAMETER OMSWorkSpaceID This is Guid ID for your OMS workspace, it can be found in the OMS portal at: https://mms.microsoft.com >> Overview >> Settings >> Connected Sources >> Windows Servers
.PARAMETER OMSKey This is the OMS API key for your OMS workspace. You can use the primary or secondary key. These keys can be found in the OMS portal at: https://mms.microsoft.com >> Overview >> Settings >> Connected Sources >> Windows Servers
.NOTES Script Name: AzureStackFabrickOMSAgentInstall.ps1 Version: 1.0 Author: Cloud and Data Center Management MVP – Steve Buchanan Website: www.buchatech.com Creation Date: 1-1-2017 Purpose/Change: Install OMS agents on Azure Stack Fabric servers. Updates: None
To kick off the script run from PowerShell ISE or a PowerShell console. If you run from ISE you will be prompted for the workspace ID and the key. If you run from a PowerShell console run this syntax to kick it off:
I recently built a PowerShell script that creates a discovery report for System Center Service Manager. The idea behind the script was to have something that I could run to gather all of the information I would want about a Service Manager deployment. I searched online and could not find anything so that’s when I decided to put something together.
This report can be used by consultants doing assessments or SCSM admins as an easy way to document what you have in your environment. This is a first pass at the report so it is version 1.1. I plan to add more information/functionality to the report in the future. Keep in mind I am not a PowerShell expert so feel free to take the script tweak it and share your updates with the community.
When the script is run it will output a report of System Center Service Manager in HTML format. This script should be run on a management server within your Service Manager’s management group. The script should be run with an account that has administrative access to Service Manager and the local server it will be running on.
The script will run on Service Manager 2012 SP1 and above. It uses SCSM 2012 SP1/R2 CMDLETS along with SMLets. If you don’t have the SMLets installed you can download them here: https://smlets.codeplex.com/
Discovered in the report:
These are the sections of information in the report.
Management Server Name
Service Manager Version
Management Server HDD CPU Memory
Service Manager Management Group Name
Service Manager Data Warehouse Information
Users connected to Service Manager
Service Manager Run as accounts
Service Manager User Roles
Service Manager Notification Channels
Service Manager Connectors
Service Manager Email Templates
Service Manager Subscriptions
Service Manager Groups
Service Manager Queues
Service Manager Service Offerings
Published Service Manager Request Offerings
Draft Service Manager Request Offerings
Service Manager Views
Service Manager Tasks
Service Manager Un-sealed Management Packs
Websites local to the Service Manager Server
Last 10 Service Manager error event logs
This will take you to an online example of the report.
Recently a colleague of mine Rob Plank brought some new CMDLets for Service Manager to my attention. These are a part of a PowerShell module that can be installed on your Service Manager server. They are the System Center Service Manager PowerShell Extensions also known as SCSMPx. Here is the official description for them:
“The ScsmPx module facilitates automation with Microsoft System Center Service Manager by auto-loading the native modules are included as part of that product and enabling automatic discovery of the commands that are contained within the native modules. It also includes dozens of complementary commands that are not available out of the box to allow you to do much more with your PowerShell automation efforts using the platform.”
This module contains hundreds of new commands for Service Manager.
The module was built by Kirk Munro (@Poshoholic) and sponsored by Provance.
Running that will download and install the SCSMPx and SnippetPx modules. This is for all users and requires being run from an elevated PowerShell console. This module will auto-load (PowerShell 3.0 and above) so there is no need to run Import-Module to load it.
Once this module is installed on a management server it also enables auto-loading of the native Service Manager CMDlets for Service Manager 2012 and later.
I recently was helping a client that needed to activate over 50+ servers after an OS upgrade. I did not want to do this one by one and they did not have a KMS. PowerShell to the rescue. I was able to put together a script that loops through an OU in Active Directory and activate all computers in that OU. This script will find only computers with “Windows Server” in the name. This script could be modified to find client operating systems instead.
When you run this script it will prompt you for the domain name, organizational unit, and Windows Server product key. I was able to use this in my new lab build as well. Here is the script:
Author: System Center MVP – Steve Buchanan
This script can be used to loop through an OU in Active Directory and activate all computers in that OU.
This script will find only computers with “Windows Server” in the name.
Run this script using: powershell.exe -executionpolicy unrestricted -command .\ActivateWinComputersfrAD.ps1
# Load the Active Directory PowerShell module
Import-Module -Name ActiveDirectory
# Prompt script runner for information to create variables
$domain = Read-host ‘Enter domain to be used. Format as such (DOMAINNAME)’
$computersou = Read-host ‘Enter the name of the OU to be searched.’
$Productkey = Read-host ‘Enter product key. Format as such (XXXXX-XXXXX-XXXXX-XXXXX-XXXXX)’
# Create a variable that holds all of the computers from Active Directory
$results = (Get-ADComputer -LDAPFilter “(OperatingSystem=*Windows Server*)” -SearchBase “OU=$computersou,DC=$domain,DC=com”)
# Loop through the results variable and activate all computers in that variable.
# NOTE: Dont forget to replace the $key variable with your own Windows key.