Search for a command to run...
I work as System Administrator for more than 15 years now and I love to make my life easier by automating work & personal stuff via PowerShell (even silly things like food recipes list generation).
No comments yet. Be the first to comment.
Or any other Azure service requiring special authentication strength
If you are using Azure Local (HCI), you might find the following PowerShell script AzureLocalVMImageUpdater.ps1 useful. What is it good for? The code replaces the Windows VM images in the specified Azure Local cluster(s) with the latest compatible ve...
Problem It happens that the hardware hash of your Autopilot device gets changed. Thanks to the replacement of the motherboard or some other issue. This can lead to future problems when your users need to reinstall the operating system, but the Autopi...
Learn how to use undocumented Azure APIs for massive performance gains
Keeping a secure, version-controlled backup of your Intune-managed device data, including BitLocker, LAPS, and FileVault keys, is a best practice for any modern IT team. In this post, I’ll guide you through an Azure DevOps pipeline that automates the...
If you are using PowerShell modules AzureAD, AzureADPreview, or MSOnline in your scripts you should be aware that they are gonna be retired on 30.6.2023. Moreover licensing MSOL cmdlets will stop working on 31.3.2023! So now is a good time to start replacing these modules in your scripts and the modules you are using.
What you should use from now on is Microsoft Graph SDK.
Use functions Get-ModuleCommandUsedInCode and Get-CorrespondingGraphCommand (from my module DependencySearch) like this 👇
Install-Module DependencySearch
$scriptsDir = "<pathToFolderWithYourPS1Scripts>"
# get ps1 scripts
$scripts = Get-ChildItem $scriptsDir -Recurse -File | ? Extension -in ".ps1", ".psm1" | select -exp FullName
# load modules whose cmdlets should be searched
$deprecatedModule = @()
"AzureAD", "AzureADPreview", "MSOnline", "AzureRM" | % {
$module = Get-Module $_ -ListAvailable
if ($module) {
$deprecatedModule += $module
} else {
Write-Warning "Module $_ isn't available on your computer"
}
}
# output used cmdlets and corresponding Graph API cmdlet if available
$scripts | % {
Get-ModuleCommandUsedInCode -scriptPath $_ -module $deprecatedModule | select *, @{n = 'GraphCommand'; e = { (Get-CorrespondingGraphCommand $_.command).GraphCommand } } | select * -exclude module | ft -AutoSize
}
And the result will look like this 👇 a.k.a. on the left side you'll see commands that need to be replaced and on the right side by which Graph command
For identifying scripts where commands from given (deprecated in our case) modules are used I've created a function Get-ModuleCommandUsedInCode (in module DependencySearch)
The function requires two parameters:
script path (where commands will be searched)
module(s) object (retrieved using Get-Module)
Function:
gets the name of cmdlets, functions and aliases defined in given module(s)
gets all used commands in a given file (using AST) and outputs just those defined in given module(s)
Now when we are able to extract deprecated commands using Get-ModuleCommandUsedInCode we need a way to "translate" such commands to their new Graph API version.
There is an official page with a "translation map" so I've created a function Get-CorrespondingGraphCommand that:
extracts HTML tables from this page (using ConvertFrom-HTMLTable function from CommonStuff module)
caches the result object to your user profile
uses such information to get the corresponding Graph API command
Thanks to functions Get-ModuleCommandUsedInCode and Get-CorrespondingGraphCommand that were explained in previous sections you are now able to easily identify all your scripts where those deprecated modules are used, moreover, you know which cmdlet from Microsoft Graph SDK should be used instead (in case there is some 😁).
Hopefully, that will make your migration journey easier 🙂