You can often learn interesting things by looking at release notes. While reading the "what's changed" list for the msgraph-sdk-powershell project (Microsoft Graph PowerShell module), three things stood out:

Re-establish Separate Auth Paths for WAM Enabled/Disabled by @ramsessanchez in #3542 Can we hope for continued improvements with WAM support in PowerShell?

fix: update msal dependencies by @gavinbarron in #3548 Of interest to me due to my work on mitigating MSAL version conflicts for Maester and the DLL Pickle module.

Add BleuCloud, DelosCloud, and GovSGCloud sovereign cloud environments, remove deprecated Germany cloud by @Copilot in #3523 What are these new names???

Looking Deeper​

Sovereign Cloud Changes​

The EU has been keeping Microsoft busy, and in PR #3523, we see their latest developments spinning up, thanks to this GitHub Copilot prompt:

Microsoft is building two new fully instanced national partner clouds in France an Germany. To support customers and ISV of these clouds to easily connect to these clouds the built-in environments should be updated to include the correct endpoints. In addition the current built-in environment for Germany (Blackforest) is not longer available and should be removed to avoid confusion for customers of the new national partner cloud in Germany which is owned and operated by Delos Cloud.

Subtasks in this plan include cleanup of deprecated Microsoft-managed environments and name clarifications:

• Remove the old Germany (Blackforest) environment from GraphEnvironmentConstants.cs
• Update GraphSettingsTests.cs to reflect new built-in environment count (6 instead of 5)
• Update NationalCloudHandlerTests.cs to test DelosCloud instead of removed Germany
• Add GovSGCloud sovereign cloud environment
• Update tests to reflect 7 built-in environments
• Fix PowerShell test to use DelosCloud instead of Germany
• Update GovSGCloud comment to "Sovereign Government Cloud"

Customers of national cloud partners will be able to add user-defined environments for these new partner clouds using the following commands:

France

Add-MgEnvironment  -Name BleuCloud
-AzureAdEndpoint <https://login.sovcloud-identity.fr/> `
-GraphEndpoint <https://graph.svc.sovcloud.fr/>

Germany

Add-MgEnvironment  -Name DelosCloud
-AzureAdEndpoint <https://login.sovcloud-identity.de/> `
-GraphEndpoint <https://graph.svc.sovcloud.de/>

GovSGCloud

Add-MgEnvironment  -Name GovSGCloud
-AzureAdEndpoint <https://login.sovcloud-identity.sg/> `
-GraphEndpoint <https://graph.svc.sovcloud.sg/>

Output

Name        AzureADEndpoint                    GraphEndpoint                           Type
----            ---------------                    -------------                           ----
USGovDoD        https://login.microsoftonline.us   https://dod-graph.microsoft.us          Built-in
USGov           https://login.microsoftonline.us   https://graph.microsoft.us              Built-in
China           https://login.chinacloudapi.cn     https://microsoftgraph.chinacloudapi.cn Built-in
Global          https://login.microsoftonline.com  https://graph.microsoft.com             Built-in
BleuCloud       https://login.sovcloud-identity.fr https://graph.svc.sovcloud.fr           Built-in
DelosCloud      https://login.sovcloud-identity.de https://graph.svc.sovcloud.de           Built-in

Questions​

What I don't see in the PR is any work on the Singapore environment that Copilot references (is this a hallucination or discovered fact?) or an explanation of what GovSGCloud is reserved for. Let me know if you have any insights into these developments or if you are waiting to migrate workloads to them!

Keep learning and discovering! Have a great day, friends!

Sam

Import-Module Maester
Connect-Maester -Service All -TenantId $MyTenantId
Connect-MicrosoftTeams: ~\Documents\PowerShell\Modules\Maester\1.3.90\public\Connect-Maester.ps1:284
Line |
 284 |                    Connect-MicrosoftTeams > $null
     |                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | One or more errors occurred. (An HttpListenerException occurred while listening on
     | http://localhost:52723/ for the system browser to complete the login. Possible cause and
     | mitigation: the app is unable to listen on the specified URL; run 'netsh http add
     | iplisten 127.0.0.1' from the Admin command prompt.)
Connect-MicrosoftTeams: ~\Documents\PowerShell\Modules\Maester\1.3.90\public\Connect-Maester.ps1:284
Line |
 284 |                    Connect-MicrosoftTeams > $null
     |                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | An HttpListenerException occurred while listening on http://localhost:52723/ for the
     | system browser to complete the login. Possible cause and mitigation: the app is unable to
     | listen on the specified URL; run 'netsh http add iplisten 127.0.0.1' from the Admin
     | command prompt.
Connect-MicrosoftTeams: ~\Documents\PowerShell\Modules\Maester\1.3.90\public\Connect-Maester.ps1:284
Line |
 284 |                    Connect-MicrosoftTeams > $null
     |                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | The request is not supported.
Connect-MicrosoftTeams: ~\Documents\PowerShell\Modules\Maester\1.3.90\public\Connect-Maester.ps1:284
Line |
 284 |                    Connect-MicrosoftTeams > $null
     |                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | One or more errors occurred. (An HttpListenerException occurred while listening on
     | http://localhost:52723/ for the system browser to complete the login. Possible cause and
     | mitigation: the app is unable to listen on the specified URL; run 'netsh http add
     | iplisten 127.0.0.1' from the Admin command prompt.)

The process still opened a browser, which proceeded to show a "localhost refused to connect" error.

The timing of this felt like it may have been patch related, but I do frequently test prerelease software and it honestly could have been anything. Then I was fortunate to see a Twitter/X post from Bryan Dam and a reply from Susan Bradley that validated the theory.

That post and the Cisco Duo article 9527 that Susan Brady shared (Why is Duo Desktop not detected on my Windows device after installing updates to Windows 11?) was the confirmation that I needed. (Additional information: #2815434 on askwoody.com.)

The October 14, 2025 KB5066835 update is definitely breaking apps and authentication processes that utilize the localhost loopback listener. I removed the two updates that the Cisco Duo article mentioned, rebooted, and the issue immediately went away.

I haven't found a publicly visible statement from Microsoft yet, but this explanation is included in the Windows release health message center:

Following installation of updates releases on or after October 14 (the Originating KBs listed above), server-side applications that rely on HTTP.sys may experience issues with incoming connections. As a result, IIS websites might fail to load, displaying a message such as "Connection reset – error (ERR_CONNECTION_RESET)", or similar error. This includes websites hosted on http://localhost/, and other IIS connections.

Here's one way to resolve the issue until a new security patch or hotfix is released:

Use WUSA to Remove the Patches​

# Remove specific Windows Updates
$KBs = 'KB5066835', 'KB5065789'

foreach ($KB in $KBs) {
    Write-Host "Attempting to uninstall $KB..."
    Start-Process -FilePath "wusa.exe" -ArgumentList "/uninstall /kb:$($KB -replace 'KB','') /quiet /norestart" -Wait
}

Or simply:

wusa /uninstall kb:5066835
wusa /uninstall kb:5065789

Use DISM to Remove the Patches​

# Remove updates using DISM
$KBs = 'KB5066835', 'KB5065789'

foreach ($KB in $KBs) {
    Write-Host "Attempting to remove $KB using DISM..."
    Start-Process -FilePath "dism.exe" -ArgumentList "/Online /Remove-Package /PackageName:$KB /Quiet /NoRestart" -Wait
}

Use the PSWindowsUpdate PowerShell Module​

I used the PSWindowsUpdate PowerShell module to remove the patches:

Install-PSResource -Name PSWindowsUpdate
Remove-WindowsUpdate -KBArticleID 5066835
Remove-WindowsUpdate -KBArticleID 5065789

After uninstalling, you will need to reboot your computer.

I'm sure there are many more details to spell out and more affected applications to list, but I wanted to get this post out quickly to help others that were struggling with this issue. Please add others that you know of in the comments!

Thank you!

Sam

Installation​

The first thing you will need to do is download and install the .NET (dotnet) tool from Microsoft:

# Download Microsoft's dotnet tool install script to the TEMP directory.
$DownloadPath = Join-Path -Path $env:TEMP -ChildPath 'dotnet-install.ps1'
Invoke-WebRequest 'https://dot.net/v1/dotnet-install.ps1' -OutFile $DownloadPath

# Remove the MOTW (mark of the web).
Unblock-File -Path $DownloadPath

# Install current stable release (STS) of the dotnet tool in your profile directory.
.$DownloadPath -InstallDir '~/.dotnet' -Channel 'STS'

# Clean up the download.
Remove-Item -Path $DownloadPath -Confirm:$false

Install PowerShell using the dotnet tool:

dotnet tool install --global PowerShell

If you have Windows Terminal installed, you should now see a new profile for this:

Using a Script​

Copy and paste if you'd like, but here's the whole thing wrapped in a script that also checks if the dotnet tool is already installed:

if ( (Get-Command -Name 'dotnet' -ErrorAction SilentlyContinue) ) {
    Write-Verbose 'dotnet is already installed.'
} else {
    $DownloadPath = Join-Path -Path $env:TEMP -ChildPath 'dotnet-install.ps1'
    try {
        Invoke-WebRequest 'https://dot.net/v1/dotnet-install.ps1' -OutFile $DownloadPath
        Unblock-File -Path $DownloadPath
    } catch {
        Write-Error "Failed to download dotnet-install.ps1 to '$DownloadPath'."
        throw $_
    }

    try {
        .$DownloadPath -InstallDir '~/.dotnet' -Channel 'STS'
    } catch {
        throw $_
    }
}

try {
    dotnet tool install --global PowerShell
    $env:PATH += ';' + [System.IO.Path]::Combine($HOME, '.dotnet', 'tools')
} catch {
    throw $_
}

if (Test-Path -Path $DownloadPath) {
    Remove-Item -Path $DownloadPath -Confirm:$false
}

This script is also available on GitHub at SamErde/PowerShell/General/Install-PowerShellAsDotNetTool.ps1

Installing LTS​

What if your organization has a requirement that only LTS versions of software may be installed? I should (and will) update the above script with a parameter to specify LTS or STS, but for the sake of time, here are the steps.

# Download Microsoft's dotnet tool install script to the TEMP directory.
$DownloadPath = Join-Path -Path $env:TEMP -ChildPath 'dotnet-install.ps1'
Invoke-WebRequest 'https://dot.net/v1/dotnet-install.ps1' -OutFile $DownloadPath

# Remove the MOTW (mark of the web).
Unblock-File -Path $DownloadPath

# Install the .NET Tool with support for the LTS version of .NET ('STS' is the default).
.$DownloadPath -InstallDir '~/.dotnet' -Channel 'LTS'

When installing PowerShell with the .NET (dotnet) Tool, you can specify the --version 7.4.11 parameter, but there is no option to simply install the LTS version. Let's find a way to get the latest LTS release of PowerShell:

$LTSVersion = (Invoke-RestMethod -Uri https://aka.ms/pwsh-buildinfo-lts).ReleaseTag.Replace('v','')
dotnet tool install --global PowerShell --version $LTSVersion

As a alternative, we can also get the LTS version number from the metadata.json file in the PowerShell repository: (Invoke-RestMethod -Uri 'https://raw.githubusercontent.com/PowerShell/PowerShell/master/tools/metadata.json').LTSReleaseTag.Replace('v','').

Both of these two URIs that I queried provide some details about PowerShell releases, as you can see in this screenshot:

You should now have a fresh installation of PowerShell as a .NET tool on either the LTS or STS release.

Limitations​

PowerShell as a .NET tool is easy to setup, but it does have some limitations.

• Updates must be managed via dotnet tool update instead of WinGet, Windows Updates, or the Microsoft Store.
• PowerShell remoting and WinRM might be unreliable or unsupported.
• Base PowerShell modules may not be available or may have reduced functionality due to missing dependencies.
• Modules such as Microsoft.Graph may fail due to dependencies on the full PowerShell host.
• GUI-based modules that rely on Windows Forms or WPF won't work.

Closing Thoughts​

Despite these limitations, this can be a useful tool for development and testing, or when you need a lightweight installation option that doesn't require local admin rights.

What is the Microsoft Artifact Registry (MAR)?​

MAR is a public registry for housing Microsoft's official artifacts, such as container images. MAR enhances security by ensuring only Microsoft can publish official packages, eliminating risks like name squatting. It also improves software supply chain integrity by offering greater transparency and control over artifact provenance.

Far from being just a PowerShell module repository, MAR is a container registry that provides application frameworks, CI/CD runners, container images, SDKs, and more. At this time, the only PowerShell modules that I have found in it so far are the Az module and its myriad of sub-modules.

Microsoft do have plans to publish more PowerShell modules to the MAR. We do not know how soon the different product teams will publish their modules to it, but they will first have to update their release pipeline to do so. For now, here's what you need to know:

Support for MAR was added to the Microsoft.PowerShell.PSResourceGet v1.1.1 release on 2025/03/07. You may need to update if you have not already.

Getting Started with the Microsoft Artifact Registry​

Here's how you can start using it:

$MARUrl = 'https://mcr.microsoft.com'
Register-PSResourceRepository -Name MAR -Uri $MARUrl -ApiVersion ContainerRegistry -Trusted:$true

Now you can even set the MAR to have a higher priority than the PSGallery by running Set-PSResourceRepository -Name MAR -Priority 10 (or any number lower than the current priority of the PSGallery).

You can confirm that this worked by running Get-PSResourceRepository.

Limitations​

The Microsoft.PowerShell.PSResourceGet module does have some limitations when working with the MAR and other Microsoft container registries. It does not support the following search functionality that you can use with the PowerShell Gallery:

• Find by tag value Find-PSResource -Tag TagValue -Repository ACRDemoRepo

• Find by command Find-PSResource -Command CommandName -Repository ACRDemoRepo

• Find by DSC resource name Find-PSResource -DscResourceName ResourceName -Repository ACRDemoRepo

• I did not expect wildcard searches to work, but surprisingly, this approach does work sometimes: Find-PSResource -Repository MAR -Type Module -Name "Az*"

Let's install a couple of modules as a test. If you have followed along and changed the priority of the MAR, the Install-PSResource command will try the MAR first.

Install-PSResource -Name Az.CognitiveServices -Scope CurrentUser
Install-PSResource -Name Az.Automation -Scope CurrentUser -Repository PSGallery

You can see here that it installed the Az.CognitiveServices module and its dependency (Az.Accounts) from the MAR automatically. The Az.Automation module was installed from the PSGallery because that source was specified in my command.

That's it for now! For more information, check the official documentation on Microsoft Learn.

Thanks to Sean Wheeler for the tip and the great documentation, as always!

Have a great day! ☀️🙏

param (
    [System.Obsolete("'Mode' is being replaced by a more flexible set of parameters. It will be removed in a future release. Please use 'Get-Help Test-Obsolete' or visit <https://day3bits.com/2025-02-17-using-obsolete-parameters-in-powershell/> for more information.")]
    [int16]$Mode
)

When this parameter is used in a function, the user is warned that it is obsolete, but it will still continue to work.

Here is a full example of the Obsolete attribute in use:

function Test-Obsolete {
    param (
        # Test mode parameter.
        [Parameter(Mandatory)]
        [Obsolete("'Mode' is being replaced by a more flexible set of parameters. It will be removed in a future release.`n`nPlease use 'Get-Help Test-Obsolete' or visit <https://day3bits.com/2025-02-17-using-obsolete-parameters-in-powershell/> for more information.")]
        [ValidateNotNullOrEmpty()]
        [ValidateRange(0, 5)]
        [int16]
        $Mode
    )

    Write-Output "You chose mode ${Mode}."
} # end function Test-Obsolete

The output of this function will look like this:

PS C:\Code> Test-Obsolete -Mode 3
WARNING: Parameter 'Mode' is obsolete. 'Mode' is being replaced by a more flexible set of parameters. It will be removed in a future release.

Please use 'Get-Help Test-Obsolete -Full' or visit <https://day3bits.com/2025-02-17-using-obsolete-parameters-in-powershell/> for more information.
You chose mode 3.
PS C:\Code>

You can download this sample function (Test-Obsolete.ps1) and a few hundred others from my PowerShell repository.

This is just one of those little things you can do to improve the experience for people who use your code. Take advantage of it to make your PowerShell code 1% better every day!

Have a great day! ☀️🙏

Since moving to the Charlotte area, I've been searching for an active user group focused on these interests. I haven't found one yet, so why not start one? Building a community takes a community, which is why I'm sharing this request:

Vision​

To get things started, here is the initial vision that I would love your feedback on:

Who is this group for?​

• Support Specialists / Technicians
• Systems / Network Administrators
• Systems / Network / Infrastructure Engineers
• Solutions Analysts
• Solutions Architects
• Leaders of any of the above
• People aspiring to be any of the above

There are no superstars here. We're all at different points on our journey, all experiencing a different phase of life. Everyone has something to contribute and things to learn!

What topics could we discuss?​

I have my favorites, but any of the following could be great topics to discuss!

Sounds Good!​

Are you interested in joining or helping? I would love to continue the conversation! Please take two minutes to let me know here.

Cheers!

Sam

Photo by Annie Spratt on Unsplash

The syntax in Windows PowerShell is pretty basic. You can provide a parent path and a child path.

Join-Path
    [-Path] <String[]>
    [-ChildPath] <String>
    [-Resolve]
    [-Credential <PSCredential>]
    [-UseTransaction]
    [<CommonParameters>]

You may not have realized that it supports wildcards in the parent and child paths, and can return an array of strings that represent paths.

Join-Path -Path "$Home\AppData\Local*" -ChildPath "Microsoft*" -Resolve

It can also accept multiple parent paths and return multiple resolved paths:

Join-Path -Path C:\, C:\Windows, $env:LOCALAPPDATA -ChildPath "Temp" -Resolve

The difference between Windows PowerShell and PowerShell becomes apparent when you want to join more than one child path. PowerShell added the AdditionalPath parameter, which allows you to add virtually unlimited child paths like this:

# Join multiple child paths in PowerShell
Join-Path -Path $HOME -ChildPath "Documents" -AdditionalChildPath 'PowerShell'

# Join multiple child paths with an array of additional child paths
[string[]]$AdditionalChildPaths = @('Personal','PSPreworkout','src','PSPreworkout','Public')
Join-Path -Path C:\ -ChildPath 'Code' -AdditionalChildPath $AdditionalChildPaths

# Or even the very ugly but still functional:
Join-Path \ a b c d e f g h 1 2 3 4 5 6

Since Windows PowerShell doesn't have the AdditionalPath parameter, how can we do this on older systems? There are a few ways to expand its functionality:

# Join multiple child paths in Windows PowerShell (or PowerShell) by piping to the next Join-Path:
Join-Path -Path $HOME -ChildPath "Documents" | Join-Path -ChildPath "PowerShell" | Join-Path -ChildPath "Modules"

# Or, even worse: join multiple child paths in Windows PowerShell (or PowerShell) by nesting commands:
Join-Path -Path $HOME -ChildPath "Documents" | Join-Path -ChildPath (Join-Path -Path "PowerShell" -ChildPath "Modules")

I like to dig into things like this when writing scripts that should be able to work cross-platform and on both editions of PowerShell. The last two examples shown above do work on Windows PowerShell 5.1, but can get hard to follow once you go more than two paths deep.

You might notice an emerging theme when we look into one more option that works on PowerShell, Windows PowerShell, and across platforms: .NET again! The System.IO.Path type's Combine method takes a list of path segments and joins them easily.

# Join multiple child paths in any version of PowerShell on Linux, macOS, or Windows
[System.IO.Path]::Combine($HOME,"Documents","PowerShell","Modules")

# The same as above, but with a variable
[string[]]$Segments = @($HOME,"Documents","PowerShell","Modules")
[System.IO.Path]::Combine($Segments)

That looks like a nice, clean option that runs almost anywhere and is easy to read!

Photo by Jens Lelie on Unsplash

Get-ADTrust -Filter *

<# Example Output:
    Direction               : BiDirectional
    DisallowTransivity      : False
    DistinguishedName       : CN=example.com,CN=System,DC=domain,DC=com
    ForestTransitive        : True
    IntraForest             : False
    IsTreeParent            : False
    IsTreeRoot              : False
    Name                    : example.com
    ObjectClass             : trustedDomain
    ObjectGUID              : 00000000-0000-0000-0000-000000000000
    SelectiveAuthentication : False
    SIDFilteringForestAware : False
    SIDFilteringQuarantined : False
    Source                  : DC=domain,DC=com
    Target                  : example.com
    TGTDelegation           : False
    TrustAttributes         : 8
    TrustedPolicy           :
    TrustingPolicy          :
    TrustType               : Uplevel
    UplevelOnly             : False
    UsesAESKeys             : False
    UsesRC4Encryption       : False
#>

Now for the embarrassing part of this post: for a painfully long time, I thought the target domain's NetBIOS name and domain SID were not returned by the Get-ADTrust cmdlet. 🤦‍♂️

Guess what, Past Sam Erde? It is there. You just need to look closer. 🕵️‍♂️

This cmdlet can return the flatName property, which is the target domain's NetBIOS name, and securityIdentifier, which is the target domain's SID. All you needs is Get-ADTrust -Filter * -Properties flatName,securityIdentifier. To remind myself, let's display the results in a pretty table with labels that make sense:

Get-ADTrust -Filter * -Properties Source,Target,flatName,securityIdentifier | Format-Table Source, Target, @{Name = "NetBIOSName"; Expression = {$_.flatName}}, @{Name = 'DomainSID'; Expression = {$_.securityIdentifier}} -AutoSize

Cool! Now then--what I was going to write about was 'a really cool solution to get this "missing" information using a .NET type.' The original premise of my post was wrong, but let's still talk about that option. Using a .NET type instead of the Get-ADTrust cmdlet is going to be very useful when the ActiveDirectory PowerShell module is not available and you cannot install it. It can also be more efficient to use, especially when pulling invalid trusts. For example, Get-ADTrust is a bit slower and waits for a timeout or error when it cannot validate the target domain. You probably won't notice the difference in most cases, though. Let's just look at the code!

$Forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
$TrustRelationships = $Forest.GetAllTrustRelationships()
$TrustRelationships.TrustedDomainInformation

<# Example Output:

    DnsName         NetBiosName     DomainSid                                Status
    -------         -----------     ---------                                ------
    example.com     EXAMPLE         S-1-5-21-000000000-1234567890-1234567890 Enabled
#>

I honestly like this approach better!

If one-liners are your thing, we can do that as well: [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().GetAllTrustRelationships().TrustedDomainInformation.

By using the System.DirectoryServices.ActiveDirectory.Forest type from .NET, we can directly interact with Active Directory objects and retrieve trust details without relying on the ActiveDirectory PowerShell module.

What do you think? Have you already moved your Active Directory scripts away from depending on the ActiveDirectory module? Let me know!

Regardless of how you update, you may find that it takes a terribly long time to update these modules. Minutes, even!!! 😱 Many people have probably followed the same steps that I did to get here, and many of us have wasted hours while waiting for the Update-Module and Update-Help commands to finish.

# We installed ALL OF THE THINGS 🧹🤪
Install-Module -Name Az
Install-Module -Name Microsoft.Graph

When we use these commands, we don't just install one module or two modules. As of this writing:

• The Az module includes 171 service submodules.
• The Microsoft.Graph PowerShell module includes 38 service submodules.

We just installed 211 modules on our system, and many of us will only ever use 10-20 of them! This is where my click-baity title comes in. 😜

My advice to you now is to review the modules installed on your system and uninstall any that you do not use. Start with Get-InstalledModule to view a list of all modules that you have installed.

If you need to remove modules that were installed for the AllUsers scope, then you will need to begin this process with an elevated PowerShell session.

If your list is very long, and possibly includes multiple versions of each, manually removing the unused ones could be a very tedious process. Here's a quick way to clean the slate before only installing the ones that you will actually use:

$AzGraphModules = Get-InstalledModule -Name Az,Az.*,Microsoft.Graph,Microsoft.Graph.* -ErrorAction SilentlyContinue
foreach ($module in $AzGraphModules) { Uninstall-Module -Name $module.Name -AllVersions -Force }

This may take a few minutes to run. After completing, you should see a much shorter list when running Get-InstalledModule. At this point, you can re-install only the modules that you will likely need, and expand the list as your needs grow. I would suggest starting with the following ones:

• Az.Accounts
• Az.Resources
• Az.Tools.Predictor
• Microsoft.Graph.Applications
• Microsoft.Graph.Authentication
• Microsoft.Graph.Groups
• Microsoft.Graph.Users
• Microsoft.Graph.Identity.DirectoryManagement
• Microsoft.Graph.Identity.SignIns

Whether you install this list, or others, installing them in batch is fairly straightforward with an array:

$ModulesToInstall = @('Az.Accounts','Az.Resources','Az.Tools,Predictor','Microsoft.Graph.Applications','Microsoft.Graph.Authentication','Microsoft.Graph.Groups','Microsoft.Graph.Users','Microsoft.Graph.Identity.DirectoryManagement','Microsoft.Graph.Identity.SignIns')
foreach ($module in $ModulesToInstall) { Install-Module -Name $module -Scope CurrentUser }

Check your results with Get-InstalledModule. (What other modules do you have installed? Let me know!) You can now reap the benefits of having fewer PowerShell modules installed:

• Faster Auto-Import and Tab-Completion: With fewer modules, PowerShell has fewer cmdlets and functions to load and index, which can speed up the auto-import process and make tab-completion more responsive.
• Reduced Memory Usage: Each module loaded into a PowerShell session consumes memory. By removing unused modules, you can reduce the overall memory footprint of your PowerShell environment.
• Avoiding Conflicts: Having many modules installed can sometimes lead to cmdlet name conflicts, where multiple modules define cmdlets with the same name. Reducing the number of installed modules can help avoid these conflicts.
• Improved Security: Unused modules might not be regularly updated, potentially leaving security vulnerabilities unpatched. Removing them reduces the attack surface and helps maintain a more secure environment.
• Simplified Management: Fewer modules mean less complexity in managing updates and dependencies, making it easier to keep your environment up to date and stable.

Try it out and let me know if you notice the difference!

During the first quarter of 2024, Microsoft announced some unfortunate changes to the developer program. There have been many posts about how far fewer people will have access to this amazing learning and developing resource. I won't dive into that again in this post. For now, I wanted to create an easy reference for one other question that often comes up: "if it's E5, but not all services are actually included, which ones are?" (Spoiler: Microsoft Defender for Endpoint is still excluded.) The announcement states:

Updated service plans. The Microsoft 365 developer subscription now includes service plans that were previously missing. For a complete list of the service plans that are included, see Product names and service plan identifiers for licensing.

If you've ever visited that page, you know how hard it is to read! This seems like a great opportunity for a GitHub action to scrape and remodel the table. For now, here's a quick copy/paste of the friendly names for all service plans included with the DEVELOPERPACK_E5 SKU.

Avatars for Teams
Avatars for Teams (additional)
Azure Information Protection Premium P1
Azure Information Protection Premium P2
Azure Rights Management
Commercial data protection for Microsoft Copilot
Common Data Service
Common Data Service for Teams
Customer Lockbox
Customer Lockbox (A)
Data Classification in Microsoft 365
Exchange Online (Plan 2)
Graph Connectors Search with Index
Information Protection and Governance Analytics - Premium
Information Protection for Office 365 - Premium
Information Protection for Office 365 - Standard
Microsoft 365 Advanced Auditing
Microsoft 365 Apps for enterprise
Microsoft 365 Audit Platform
Microsoft 365 Communication Compliance
Microsoft 365 Defender
Microsoft 365 Lighthouse (Plan 1)
Microsoft 365 Phone System
Microsoft Azure Multi-Factor Authentication
Microsoft Bookings
Microsoft Clipchamp
Microsoft Communications DLP
Microsoft Customer Key
Microsoft Data Investigations
Microsoft Defender for Cloud Apps
Microsoft Defender for Identity
Microsoft Defender for Office 365 (Plan 1)
Microsoft Defender for Office 365 (Plan 2)
Microsoft Entra ID P1
Microsoft Entra ID P2
Microsoft Excel Advanced Analytics
Microsoft Forms [Plan E5]
Microsoft Information Governance
Microsoft Insider Risk Management
Microsoft Intune Plan 1
Microsoft Loop
Microsoft ML-Based Classification
Microsoft MyAnalytics (Full)
Microsoft Planner
Microsoft Records Management
Microsoft Search
Microsoft StaffHub
Microsoft Stream for Office 365 E5
Microsoft Teams
Mobile Device Management for Office 365
Nucleus
Office 365 Advanced eDiscovery
Office 365 Cloud App Security
Office 365 Privileged Access Management
Office 365 SafeDocs
Office for the Web
Power Apps for Office 365 (Plan 3)
Power Automate for Office 365
Power BI Pro
Power Virtual Agents for Office 365
Project for Office (Plan E5)
Purview Discovery
RETIRED - Microsoft Communications Compliance
RETIRED - Microsoft Insider Risk Management
SharePoint (Plan 2)
Skype for Business Online (Plan 2)
Sway
To-Do (Plan 3)
Viva Learning Seeded
Whiteboard (Plan 3)
Yammer Enterprise

If you're reading this, I hope you've been fortunate enough to have your developer tenant renewed for now!

Happy learning! Sam

Photo by Ken Suarez on Unsplash

For me, one such project has been Locksmith, which I had the pleasure of joining earlier this year. While working on an enhancement for the Locksmith PowerShell module, I had to ask myself for the first time, can I return multiple objects from a PowerShell function?

The answer is yes, you can return multiple objects from a PowerShell function, and there are multiple ways to do it.

Here is one simple example:

function Get-Food {
    $TreeFruit = @("Apple","Orange","Peach")
    $Squash = @("Pumpkin","Acorn Squash","Winter Squash")
    $RootVegetable = @("Potato","Sweet Potato","Turnip","Radish")

    Return $TreeFruit, $Squash, $RootVegetable
}

$Food = Get-Food

This function doesn't do anything other than return three arrays, but you get the idea. You can return any kind of object, or a mix of different object types. Cool!

…but there's a problem! If you run this code, you’ll notice something that could be an issue: the objects that are returned in $Food look like an ambiguous list.

Apple
Orange
Peach
Pumpkin
Acorn Squash
Winter Squash
Potato
Sweet Potato
Turnip
Radish

The array names are gone, so if you want to reference a specific type of food from the results, you have to find a creative way to get it. What if you need to enumerate the TreeFruit array, and then enumerate the RootVegetable array later in a different function?

We can try using imatch to find arrays that might contain words we know:

$TreeFruit = $Food -imatch "Apple"
$Squash = $Food -imatch "Squash"
$RootVegetable = $Food -imatch "Turnip"

This isn't very friendly code and also depends on you knowing one of the values, which defeats the whole point to begin with.

We could try rebuilding the arrays by referencing the index of each object returned:

$TreeFruit = $Food[0]
$Squash = $Food[1]
$RootVegetable = $Food[2]

While this does work, it is still unfriendly, error-prone, and requires you to already know the order of objects being returned. And what if the objects returned aren't arrays? They could be integers or booleans. It is a very unreliable way to manage code for any project, especially one being developed by a team.

After an embarrassingly long time, a light finally came on in my head.

I then put the name of the object (the array, in this case) in the key and stored the actual object (arrays) in the value.

Our function can be thus written to return a hash table like this:

function Get-Food {
    $TreeFruit = @("Apple","Orange","Peach")
    $Squash = @("Pumpkin","Acorn Squash","Winter Squash")
    $RootVegetable = @("Potato","Sweet Potato","Turnip","Radish")

    @{
        TreeFruit     = $TreeFruit
        Squash        = $Squash
        RootVegetable = $RootVegetable
    }
}

$Results = Get-Food

This is especially useful because of the easy way you can reference the values of hash tables by their key names:

> $Results['TreeFruit']
Apple
Orange
Peach

> $Results['Squash']
Pumpkin
Acorn Squash
Winter Squash

> $Results['RootVegetable']
Potato
Sweet Potato
Turnip
Radish

Now you can get fancy and do whatever you want with those results:

Write-Output @"
  Tree Fruit:
  $($Results['TreeFruit'] -join ', ')

  Squash:
  $($Results['Squash'] -join ', ')

  Root Vegetables:
  $($Results['RootVegetable'] -join ', ')
"@

Which gives you this:

Tree Fruit:
Apple, Orange, Peach

Squash:
Pumpkin, Acorn Squash, Winter Squash

Root Vegetables:
Potato, Sweet Potato, Turnip, Radish

I like it! Let's get back to Locksmith so you can see it put to practical use. My goal was to call a number of scans from a private function and then return the results of each scan back to the main function. We needed to be able to reliably reference each result as a named array for the next steps.

$Results = Invoke-Scans -Scans $Scans

The Invoke-Scans function does its work and then returns the results with the following:

# Start Condensed Example
[array]$AuditingIssues = Find-AuditingIssue -ADCSObjects $ADCSObjects
[array]$ESC1 = Find-ESC1 -ADCSObjects $ADCSObjects -SafeUsers $SafeUsers
[array]$ESC2 = Find-ESC2 -ADCSObjects $ADCSObjects -SafeUsers $SafeUsers
# End Condensed Example

# Later, at the end of the function:
# Return a hash table of array names (keys) and arrays (values)
@{
    AllIssues = $AllIssues
    AuditingIssues = $AuditingIssues
    ESC1 = $ESC1
    ESC2 = $ESC2
    ESC3 = $ESC3
    ESC4 = $ESC4
    ESC5 = $ESC5
    ESC6 = $ESC6
    ESC8 = $ESC8
}

Back in the main Invoke-Locksmith function, we can now work with these results much more easily. As noted above, hash table values can be pulled by referencing their key name, like $Results['ESC1'], which will return all findings in the $ESC1 array.

Alternatively, we can save them as new variables in the main function, making things even easier for repeated use.

$AllIssues      = $Results['AllIssues']
$AuditingIssues = $Results['AuditingIssues']
$ESC1           = $Results['ESC1']
$ESC2           = $Results['ESC2']
$ESC3           = $Results['ESC3']
$ESC4           = $Results['ESC4']
$ESC5           = $Results['ESC5']
$ESC6           = $Results['ESC6']
$ESC8           = $Results['ESC8']

That's it! That's the tip. Return multiple named objects from a function but using a hash table to name and store them. Let me know if this helps with any of your projects, or if you have an even better way to do it!

Be sure to check out the Locksmith project if you're interested in Active Directory, Active Directory Certificate Services, or PKI in general.

Peace. Sam

Photo by Adrian Schwarz on Unsplash