Tailor Microsoft 365 Cmdlets to Your Business

Did you know that employees spend up lot of time searching for information or figuring out how to use tools that don’t align with their daily work? When it comes to IT administration, this inefficiency extends to command-line tools like PowerShell. Administrators rely on Microsoft 365 PowerShell cmdlets to manage SharePoint, Exchange, and Teams, but these commands often feel disconnected from a company’s unique terminology and workflows.

Every company has its own domain language—a set of terms and processes specific to its industry and internal culture. Employees speak this language daily, so administrative tools should reflect it too. Yet, Microsoft’s out-of-the-box PowerShell cmdlets don’t always align with the way businesses operate. This can make scripts harder to understand and apply, leading to confusion and inefficiencies.

Two script folders, one bigger than the other by Jaime López using Designer

Instead of forcing employees to adapt to Microsoft’s naming conventions, why not bring PowerShell in line with your company’s language? By customizing and wrapping Microsoft 365 PowerShell cmdlets into company-specific commands, administrators can make scripts more intuitive, easier to use, and more aligned with business needs. This article will guide you through the process step by step—helping you turn standard PowerShell commands into something meaningful for your organization.

By the end of this guide, you’ll realize how simple it is to adapt PowerShell cmdlets to your company’s domain language. Your scripts will not only be more readable and easier to use, but they’ll also resonate with your team—saving time, reducing errors, and making administration more efficient. Let’s dive in!

Using the Standard Microsoft 365 PowerShell Commands

When working with Microsoft 365 PowerShell, you often use built-in cmdlets to configure and manage services. While these commands are powerful, they may require repetitive input, especially when applying standard configurations across multiple sites or libraries. In this section, we’ll explore this challenge using the Set-SPOListVersionPolicy cmdlet as an example.

Applying a Standard Configuration

Imagine your company has a standard policy for versioning in SharePoint Online libraries. The policy states that each document library should:

• Allow up to 150 major versions.

• Expire versions after 365 days.

To apply this policy, you would typically use the following PowerShell command:

Set-SPOListVersionPolicy -SiteUrl $SiteUrl -List $LibraryName -EnableAutoExpirationVersionTrim $true -MajorVersionLimit 150 -ExpireVersionsAfterDays 365

This command ensures that versioning settings comply with company policy. However, consider the effort involved in applying this configuration manually to multiple libraries across different sites. Each time, you must enter the same parameters, ensuring there are no typos or inconsistencies.

Now, think about scaling this process. If your organization has hundreds or thousands of libraries, repeating this command for each one is time-consuming and prone to errors. Standardization is critical, but manually applying it is inefficient.

The Need for a Custom Approach

Using built-in PowerShell cmdlets is helpful, but without automation, managing large-scale configurations can become tedious. In the next sections, we’ll explore how to simplify this process by creating a custom PowerShell cmdlet that integrates company-specific terminology and automates repetitive tasks.

Saving It in a File

To improve efficiency and readability, we can take our PowerShell command and turn it into a reusable script file. Instead of manually entering the command each time, we define a custom cmdlet that standardizes the process. This makes administration easier and reduces the chances of errors.

Creating a Reusable PowerShell Script

We’ll create a new script file named Configure-DocumentLibraryVersioning.ps1. This script will define a custom cmdlet that accepts four parameters:

• SiteUrl: The URL of the SharePoint Online site.

• LibraryName: The name of the document library to configure.

• MajorVersionLimit: The maximum number of major versions allowed (default: 150).

• ExpireVersionsAfterDays: The number of days before versions expire (default: 365).

By setting default values for the last two parameters, administrators can quickly apply the standard policy without specifying them each time. Here's the script:

# Configure-DocumentLibraryVersioning.ps1
param (
	[string]$SiteUrl,
	[string]$LibraryName,
	[int]$MajorVersionLimit = 150,
	[int]$ExpireVersionsAfterDays = 365
)

Set-SPOListVersionPolicy -SiteUrl $SiteUrl -List $LibraryName `
	-EnableAutoExpirationVersionTrim $true `
	-MajorVersionLimit $MajorVersionLimit `
	-ExpireVersionsAfterDays $ExpireVersionsAfterDays

# Example usage
# Configure-DocumentLibraryVersioning -SiteUrl $SiteUrl -LibraryName $LibraryName

Now, instead of typing the full command each time, administrators can call the script with just the site URL and library name. If they need to adjust versioning settings, they can override the default values by specifying them as arguments.

Expected Outcome

With this approach, configuring SharePoint Online document libraries becomes faster and more consistent. The script ensures that every library follows the company’s policy without requiring administrators to remember or manually input all parameters.

More Policies to Come

As organizations grow, they often need more flexibility in managing document versioning. A one-size-fits-all approach may not work for different teams or projects. To address this, we can enhance our PowerShell script by introducing predefined versioning policies. This allows administrators to choose from multiple policy levels, ensuring consistency while adapting to varying business needs.

Expanding the Script with Policy Levels

Instead of manually specifying version limits and expiration settings, we can introduce a PolicyLevel parameter. This parameter will accept predefined values such as "Standard," "Extended," and "Minimal," each with its own settings. This makes the script easier to use while enforcing company policies.

Here’s how the improved script looks:

# Configure-DocumentLibraryVersioning.ps1
param (
	[string]$SiteUrl,
	[string]$LibraryName,
	[ValidateSet("Standard", "Extended", "Minimal")]
	[string]$PolicyLevel = "Standard"
)
    
switch ($PolicyLevel) {
	"Standard" {
		$MajorVersionLimit = 150
		$ExpireVersionsAfterDays = 365
	}
	"Extended" {
		$MajorVersionLimit = 500
		$ExpireVersionsAfterDays = 730
	}
	"Minimal" {
		$MajorVersionLimit = 50
		$ExpireVersionsAfterDays = 30
	}
}

Set-SPOListVersionPolicy -SiteUrl $SiteUrl -List $LibraryName `
	-EnableAutoExpirationVersionTrim $true `
	-MajorVersionLimit $MajorVersionLimit `
	-ExpireVersionsAfterDays $ExpireVersionsAfterDays

Write-Host "Versioning policy '$PolicyLevel' configured for library '$LibraryName' at site '$SiteUrl'." -ForegroundColor Green

# Example usage:
# Configure-DocumentLibraryVersioning -SiteUrl $SiteUrl -LibraryName $LibraryName -PolicyLevel "Extended"

The PolicyLevel parameter allows administrators to choose between three predefined policies:

• Standard: Allows 150 major versions and expires them after 365 days.

• Extended: Allows 500 major versions and expires them after 730 days.

• Minimal: Allows 50 major versions and expires them after 30 days.

Expected Outcome

With this enhancement, administrators can quickly apply versioning policies based on organizational requirements. Instead of manually setting values each time, they can simply select a policy level that aligns with their needs. This approach improves efficiency, reduces errors, and ensures that SharePoint libraries adhere to company standards with minimal effort.

My Own Choice: Multiple Cmdlets, Easy Understanding

While using a single script with a PolicyLevel parameter offers flexibility, an even clearer approach is to create separate scripts for each versioning policy. By doing this, administrators can instantly recognize what each script does without needing to read through its logic or adjust parameters. This method enhances readability and simplifies execution, making it ideal for teams with varying levels of PowerShell expertise.

Organizing the Scripts

Instead of relying on a single script with multiple policy options, we will create three dedicated PowerShell scripts:

• Configure-DocumentLibraryStandardVersioning.ps1

• Configure-DocumentLibraryExtendedVersioning.ps1

• Configure-DocumentLibraryMinimalVersioning.ps1

Each script will handle one policy level, making it clear what settings will be applied. This structure aligns with best practices by ensuring each script serves a single, well-defined purpose. It also reduces the chances of mistakes since users don't have to select a policy level manually.

Here’s how the scripts are structured:

Standard Versioning Policy

# Configure-DocumentLibraryStandardVersioning.ps1
param (
	[string]$SiteUrl,
	[string]$LibraryName
)

Set-SPOListVersionPolicy -SiteUrl $SiteUrl -List $LibraryName `
	-EnableAutoExpirationVersionTrim $true `
	-MajorVersionLimit 150 `
	-ExpireVersionsAfterDays 365

Write-Host "Standard versioning policy configured for library '$LibraryName' at site '$SiteUrl'." -ForegroundColor Green

Extended Versioning Policy

# Configure-DocumentLibraryExtendedVersioning.ps1
param (
	[string]$SiteUrl,
	[string]$LibraryName
)

Set-SPOListVersionPolicy -SiteUrl $SiteUrl -List $LibraryName `
	-EnableAutoExpirationVersionTrim $true `
	-MajorVersionLimit 500 `
	-ExpireVersionsAfterDays 730

Write-Host "Extended versioning policy configured for library '$LibraryName' at site '$SiteUrl'." -ForegroundColor Green

Minimal Versioning Policy

# Configure-DocumentLibraryMinimalVersioning.ps1
param (
	[string]$SiteUrl,
	[string]$LibraryName
)

Set-SPOListVersionPolicy -SiteUrl $SiteUrl -List $LibraryName `
	-EnableAutoExpirationVersionTrim $true `
	-MajorVersionLimit 50 `
	-ExpireVersionsAfterDays 30

Write-Host "Minimal versioning policy configured for library '$LibraryName' at site '$SiteUrl'." -ForegroundColor Green

Expected Outcome

With this approach, administrators no longer need to worry about setting parameters or selecting policy levels. Each script has a clear and defined purpose, making it easy to execute the correct policy with minimal effort. This method improves script maintainability, reduces potential errors, and provides a straightforward way to enforce SharePoint Online versioning policies across the organization.

Conclusion

Customizing PowerShell cmdlets with your company’s domain language transforms standard commands into intuitive, easy-to-use tools. Instead of relying on generic Microsoft 365 PowerShell commands, you’ve learned how to create tailored scripts that align with your organization’s processes. From simplifying repetitive tasks to making scripts more readable, this approach improves efficiency, reduces errors, and ensures that IT operations resonate with the way your company actually works.

By implementing these techniques, you’re not just improving script usability—you’re fostering a more seamless digital workplace. Now it’s your turn! Try adapting PowerShell cmdlets to your company’s language and share your experience. If you found this guide helpful, don’t forget to like, comment, and share it with your network. Let’s make PowerShell work for us, not the other way around! 🚀