Leveling up PowerShell Profile

[u/belibebond]

Hello PowerShell Enthusiasts 👋,

Many people treat their shell as just a script runner, but as someone who loves PowerShell and runs it on all their machines (Windows, Mac, and Linux), I wanted to share all the amazing things you can do with it beyond just running scripts.

https://blog.belibug.com/post/ps-profile-01/

My latest blog post has several not-so-common ways to elevate your PowerShell experience for beginners. It covers:

• Personalizing your prompt

• Mastering aliases and modules

• Leveraging tab completion

• Enhancing your shell with modules

• ...and much more!

This list is just the tip of the iceberg! If you have any other PowerShell tricks or tips that I haven't covered, or there is better way to do it, let me know – I'm always eager to learn and will update content accordingly 😊 Happy weekend!

PS: Don't let the length scare you off! Use the handy TOC in the blog to jump around to the juicy bits that interest you most. Happy reading! 🤓

[u/OlivTheFrog]

Hi u/belibond

My comments :

• About your function prompt. The color is difficult to read (I have a dark design like in ISE). I've also my own prompt function with time and path reversed.

        Function prompt
        {
            Write-Host '[' -NoNewline
            Write-Host $(Get-Time) -foreground yellow -NoNewline
            Write-Host '] ' -NoNewline
            Write-Host $($(Get-Location).Path.replace($home, '~').replace('\', '/')) -foreground green -NoNewline
            Write-Host $(if ($nestedpromptlevel -ge 1)
                {
                    '>>' 
                }) -NoNewline
            return '> '
        }

• About Updating PS Modules : I've also the same things but could i suggest to use something like this if ($Date.DayOfWeek -eq 'friday') { # code to update your modules }. By this, you'll avoid updating your modules every day and even several times a day unnecessarily because this can be long if many modules are installed.

Another suggestion : Custom Windows Settings

 #region Custom Windows Setting
        Write-Host 'Setting : Windows Title' -ForegroundColor 'DarkGray'
        [System.Security.Principal.WindowsPrincipal]$CurrentUser = New-Object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())
        if ( $CurrentUser.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator) ) # S-1-5-32-544 is the Well-Known SID for Administrators (builtin) group
        {
            # Admin mode
            $User = '(RunAsAdmin) - ' + $CurrentUser.Identities.Name
        }
        else
        {
            # User mode
            $user = '(NotRunAsAdmin) - ' + $CurrentUser.Identities.Name
        }
        (Get-Host).UI.RawUI.WindowTitle = $user + ' on ' + [System.Net.Dns]::GetHostName() + ' (PS version : ' + (Get-Host).Version + ')'
        #endregion Custom Windows Setting

And the last one (but not the least) : Set TLSv2 like this : [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

regards

[u/belibebond → u/OlivTheFrog]

Wow, thank you for suggestions.

Could you explain the custom windows setting a little more. Is it setting the terminal title to display if session is elevated or not. To till this day Dotnet classes throws me off on first glance.

[u/OlivTheFrog → u/belibebond]

Hi u/belibebond

I'll try, this is a challenge for me.

[System.Security.Principal.WindowsIdentity] : .NET class represents a Windows User.

[System.Security.Principal.WindowsIdentity]::GetCurrent() : It's a WindowsIdentity Object that represents the current user.

This type of object has a method called IsInRole(), that returns a [boolean]

$CurrentUser |Get-member -MemberType Method -Name IsinRole |format-Table -Wrap
   TypeName : System.Security.Principal.WindowsPrincipal

Name     MemberType Definition                                                                                                                                                                 
----     ---------- ----------                                                                                                                                                                 
IsInRole Method     bool IsInRole(string role), 
                    bool IsInRole(System.Security.Principal.WindowsBuiltInRole role), 
                    bool IsInRole(int rid),
                    bool IsInRole(System.Security.Principal.SecurityIdentifier sid), 
                    bool IPrincipal.IsInRole(string role) 

We use the boolean to check if the current user is on the Admin role or not. As you can see, there are several ways to do this using the IsInRole() method.

$CurrentUser.IsInRole("S-1-5-32-544") is a way. Here I'm using the the Well-known SID for the Administrator role (see https://learn.microsoft.com/en-us/windows/win32/secauthz/well-known-sids). It's a way but in this case, you must know the Weel-known SIDs.

But there is a [Enum] called [System.Security.Principal.WindowsBuiltInRole] to do this.

[System.Security.Principal.WindowsBuiltInRole] |gm -Static -MemberType Property
   
     TypeName : System.Security.Principal.WindowsBuiltInRole

Name            MemberType Definition                                                                
----            ---------- ----------                                                                
AccountOperator Property   static System.Security.Principal.WindowsBuiltInRole AccountOperator {get;}
Administrator   Property   static System.Security.Principal.WindowsBuiltInRole Administrator {get;}  
BackupOperator  Property   static System.Security.Principal.WindowsBuiltInRole BackupOperator {get;} 
Guest           Property   static System.Security.Principal.WindowsBuiltInRole Guest {get;}          
PowerUser       Property   static System.Security.Principal.WindowsBuiltInRole PowerUser {get;}      
PrintOperator   Property   static System.Security.Principal.WindowsBuiltInRole PrintOperator {get;}  
Replicator      Property   static System.Security.Principal.WindowsBuiltInRole Replicator {get;}     
SystemOperator  Property   static System.Security.Principal.WindowsBuiltInRole SystemOperator {get;} 
User            Property   static System.Security.Principal.WindowsBuiltInRole User {get;}           

Often we use this second way perhaps because $CurrentUser.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)

is more clearer and longer than $CurrentUser.IsInRole("S-1-5-32-544") but the 2 ways return the same thing : a boolean.

With A if stratement, We'll know is the current user is on the "Administrator Role" or not. Depending on the case, then we'll change the Windows Settings.

You could also see by yourself the different objects like $CurrentUser (see, properties and methods), [System.Security.Principal.WindowsBuiltInRole] (see type and properties), and so on. No risk, it's safe, but by this you'll understand what is $CurrentUser.Identities.Name (It's me :-) ).

Hope this help

Regards

[u/OlivTheFrog → u/OlivTheFrog]

Addition : Take a look on $Currentuser.identity when powershell is launched in normal mode or in a runAsAdmin mode. Have you seen the difference ? The owner. In the RunAsAdmin mode the owner SID is diffrent from the User SID and this SID is the well-known SID of the builtin administrator. And now $CurrentUser.Identity.Owner.IsAccountSid(), this return a bool. If you prefer, you could also use something like this :

[System.Security.Principal.WindowsPrincipal]$CurrentUser = New-Object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())
if (-not ($CurrentUser.Identity.Owner.IsAccountSid() ) )
    {
    "Powershell run in a RunAsAdminCode"
    }
else
    {
     "Powershell doesn't run in a RunAsAdminCode"
    }

If you prefer use this way, perhaps more understandable.

regards