How to Change Login Messages on Windows Using PowerShell

Key Takeaways

• Customizing Windows login messages enhances security and user experience.
• The provided PowerShell script offers a swift method to update login titles and messages.
• Admin privileges are required due to changes in the system registry.
• The script is compatible with Windows 10 and Windows Server 2016 onwards.
• While Group Policy Objects can perform similar tasks, this script provides quicker, more agile adjustments.
• Misuse, like sharing sensitive information via login messages, can pose security threats.
• Always test the script in a sandboxed environment before wide deployment.
• Platforms like NinjaOne further facilitate management and deployment of such scripts across large networks.

With an ever-evolving landscape of security needs and user experience enhancement, IT administrators find themselves searching for more refined tools to manage systems effectively. One area often overlooked but essential is the customization of login messages on Windows. The ability to change login messages in Windows is vital, as it can communicate necessary information to users, bolster security, and provide a layer of personalization in a corporate environment.

Background

Our focal point for today’s discussion is a PowerShell script designed to update the login message on Windows systems. This small but powerful script underscores a blend of security and user experience improvement. By controlling the title and message users see upon login, IT professionals and Managed Service Providers (MSPs) can relay critical updates, warnings, or just deliver branding cohesion across the fleet of machines under their purview.

The Script

#Requires -Version 5.1

<#
.SYNOPSIS
    Changes the logon title and message.
.DESCRIPTION
    Changes the logon title and message.
.EXAMPLE
     -Title "My Title" -Message "My Logon Message"
    Set the title and message.
.EXAMPLE
    PS C:> Set-LogonMessage.ps1 -Title "My Title" -Message "My Logon Message"
    Set the title and message.
.OUTPUTS
    None
.NOTES
    Minimum OS Architecture Supported: Windows 10, Windows Server 2016
    Release Notes: Renamed script and added Script Variable support, updated Set-ItemProp
By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use.
    Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. 
    Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. 
    Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. 
    Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. 
    Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. 
    Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. 
    EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).
.COMPONENT
    OSSecurity
#>

[CmdletBinding()]
param (
    [Parameter()]
    [String]$Title,
    [Parameter()]
    [String]$Message
)

begin {
    if ($env:title -and $env:title -notlike "null") {
        $Title = $env:title
    }

    if ($env:message -and $env:message -notlike "null") {
        $Message = $env:Message
    }
    function Test-IsElevated {
        $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
        $p = New-Object System.Security.Principal.WindowsPrincipal($id)
        if ($p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator))
        { Write-Output $true }
        else
        { Write-Output $false }
    }
    function Set-ItemProp {
        param (
            $Path,
            $Name,
            $Value,
            [ValidateSet("DWord", "QWord", "String", "ExpandedString", "Binary", "MultiString", "Unknown")]
            $PropertyType = "DWord"
        )
        # Do not output errors and continue
        $ErrorActionPreference = [System.Management.Automation.ActionPreference]::SilentlyContinue
        if (-not $(Test-Path -Path $Path)) {
            # Check if path does not exist and create the path
            New-Item -Path $Path -Force | Out-Null
        }
        if ((Get-ItemProperty -Path $Path -Name $Name)) {
        # Update property and print out what it was changed from and changed to
            $CurrentValue = Get-ItemProperty -Path $Path -Name $Name
            try {
                Set-ItemProperty -Path $Path -Name $Name -Value $Value -Force -Confirm:$false -ErrorAction Stop | Out-Null
            }
            catch {
                Write-Error $_
            }
            Write-Host "$Path$Name changed from $CurrentValue to $(Get-ItemProperty -Path $Path -Name $Name)"
        }
        else {
            # Create property with value
            try {
                New-ItemProperty -Path $Path -Name $Name -Value $Value -PropertyType $PropertyType -Force -Confirm:$false -ErrorAction Stop | Out-Null
            }
            catch {
                Write-Error $_
            }
            Write-Host "Set $Path$Name to $(Get-ItemProperty -Path $Path -Name $Name)"
        }
        $ErrorActionPreference = [System.Management.Automation.ActionPreference]::Continue
    }
}
process {
    if (-not (Test-IsElevated)) {
        Write-Error -Message "Access Denied. Please run with Administrator privileges."
        exit 1
    }
    try {
        Set-ItemProp -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" -Name "legalnoticecaption" -Value $Title -PropertyType String
        Set-ItemProp -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" -Name "legalnoticetext" -Value $Message -PropertyType String
    }
    catch {
        Write-Error $_
        exit 1
    }
}
end {
    
    
    
}

 

Detailed Breakdown

Let’s delve into the mechanics of the script:

• Cmdlet Binding and Parameters: The script is designed as a PowerShell function using the CmdletBinding attribute. This means the script can be used as a reusable function and can accept parameters, specifically the title and message for the login prompt.
• Administrator Check: Two embedded functions are utilized, Test-IsElevated and Set-ItemProp. The former checks if the script is run with administrator privileges, vital since modifying registry keys (which the script does) requires elevated permissions.
• Registry Modifications: The Set-ItemProp function either modifies existing registry values or creates new ones. The script targets two primary keys, legalnoticecaption (for the title) and legalnoticetext (for the message), which govern the login message on Windows.

Potential Use Cases

Imagine an IT admin for a global corporation wants to alert all users about upcoming server maintenance. Rather than rely on emails that might be ignored, they deploy this script across all workstations. When employees log in the next day, they’re greeted with the alert, ensuring maximum visibility.

Comparisons

While Group Policy Objects (GPO) can also be used to set login messages, this script offers a more agile approach. GPOs might take time to propagate and may not be suitable for rapid changes. The PowerShell script, on the other hand, can be swiftly executed on a machine-by-machine basis or deployed widely via a system management tool.

FAQs

• Can this script be run on any Windows machine? 
  It’s designed for Windows 10 and Windows Server 2016 and above. Earlier versions may not support the involved cmdlets.
• Is it necessary to run the script with administrative rights? 
  Yes, since it modifies the system registry, elevated permissions are mandatory.

Implications

While the script aids in communication and branding, misusing it can result in confusion or even potential security issues. Broadcasting sensitive information in a login message is not advisable. Moreover, frequent changes can desensitize users to these messages, potentially diluting their impact.

Recommendations

• Ensure clarity and brevity in your login messages.
• Test the script in a controlled environment before broad deployment.
• Maintain regular backups of your system registry.

Final Thoughts

Using tools like this script is only a fragment of the comprehensive IT management toolkit. Platforms like NinjaOne amplify these efforts by providing an integrated environment for deploying, managing, and monitoring scripts like this across vast networks, ensuring consistency, security, and enhanced user experience.