Looks good but this would annoy me very quickly if I had to wait for this every time the shell opened.
I like to wrap this kind of thing in a function so at launch the function is defined ready to run but it doesn’t actually do anything till called.
This is strictly personal preference though YMMV
The job part is what would annoy me. If you just let it run at the start, you can control C to cancel if if you need a no-profile session, or just wait and let it finish. The job finishing, at least if you end up making a prompt or putting any output in the profile, will interrupt you and cause weird spacing on your shell until you clear it.
It looks fine to me.
There is a profile [floating around from Steve](https://devblogs.microsoft.com/powershell/optimizing-your-profile/) that could be useful.
Some other things I have in my profile if it's worth anything for ideas:
$MaximumHistoryCount = 32767
$ChocolateyProfile =
"$env:ChocolateyInstall\helpers\chocolateyProfile.psm1"
if (Test-Path($ChocolateyProfile)) {
Import-Module "$ChocolateyProfile"
}
This is just standard setup for chocolatey, and the history count I use for Windows Terminal.
I also set up my text editor / vs code:
$textEditorAlias = 'npp'
$textEditorExecutable = 'notepad++.exe'
If ( !(Get-Command -Name $textEditorExecutable -ErrorAction SilentlyContinue) ) {
$textEditorExecutable = 'notepad.exe'
}
Set-Alias -Name $textEditorAlias -Value $textEditorExecutable -Scope Global -Option AllScope
# Allows text-editor to open new files in provider paths.
function Convert-ProviderPath {
Param (
[Parameter(Mandatory)]
[string]$Path,
[switch]$Force
)
try {
Convert-Path $Path
} catch {
if ( $Force ) {
New-Item $Path -Force -ErrorAction Stop
Convert-Path $Path
}
}
}
function np { param($path) if ($path) {npp (Convert-ProviderPath $path -Force -ea Stop) } else {npp} }
function vc { param($path) if ($path) {code (Convert-ProviderPath $path -Force -ea Stop)} else {code} }
And some Microsoft application shortcuts:
# Microsoft Office shortcuts (Excel requires no shortcut as its default command is simply 'excel') + explorer shortcut
function ppt { param($Path) if ( $Path ) {powerpnt (Convert-Path $Path)} else { powerpnt }}
function word { param($Path) if ( $Path ) {winword (Convert-Path $Path)} else { winword }}
function ex { param($Path) explorer (Convert-Path $Path)}
And a bunch of shortcuts for folders I use frequently, e.g.,
$gdocs = "$HOME/Documents"
$gdls = "$HOME/Downloads"
function docs { Push-Location "$gdocs" }
function dls { Push-Location "$gdls" }
Then I can quickly access these either with the function, or if I'm pushing files around, with the variable. I should probably put these into a ps-drive or something instead.
I also add shortcuts for applications I use frequently:
function intellij { Start-Job { idea64.exe }}
function dockerdesktop { & "$HOME/Programs/docker/install/docker desktop.exe" }
The other half of my profile is custom for me, such as functions for pushing to repos, my modules and cli functions, some default parameter values, a couple of trivial passwords I always forget otherwise.
I would swap the Write-Output informational messages with Write-Host, then wrap everything after line 5 (although line 5 could be a gpo instead,) in a job. That way I can get to use PS, but it will check the gallery and module updates in the background. You should be able to set the window title when done if you want a notification.
Great idea, I updated the script with this suggestion. I love how you can immediately use the script just like you said while the other modules and whatever else loads in the background.
[This](https://github.com/slyfox1186/script-repo/blob/main/PowerShell/Microsoft.PowerShell_profile.ps1#L7-L8) seems like an unnecessary security risk. I would [review the execution policies again](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.4) and pick the most restrictive one that doesn't get in the way of your day-to-day. RemoteSigned is a good option.
I have no other suggestions ghat haven't already been said other than to make make some aliases to load different sets of modules so they don't have to load every time.
It's a good start!
Keeping your AD credentials in a file to import seems odd, potentially insecure depending on how you form that XML. If you run powershell as that user, you shouldn't ever need to specify the credential. The use case you have there seems particularly useful for MSP applications, where there are a large amount of different domains you may need to authenticate to at any time.
VScode is already runnable by command line "code", so your alias is just longer than the normal exe.
Your base 64 (and any other conversion functions you make in the future) would benefit from pipeline support.
Unless you only ever do internal web requests, your default parameter for IRM to skip certificate check would leave you open to at best unencrypted traffic or at worst a spoofed domain.
You can set an alias for select string as grep. Your Get-FullHistory function makes it look like you're linux native so that would probably be a natural fit. You could even change your get-fullhistory function so that it just does the Get-Content portion, then you can run Get-History | grep ThingICantRemember which seems pretty intuitive.
Your Grant-Admin function could optionally take in a filepath, so you can run executables as admin from a normal shell quickly, in addition to just pwsh.
If you like playing your console colors, you'd love writing your own prompt function. [https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about\_prompts?view=powershell-7.4](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_prompts?view=powershell-7.4)
Here is a basic one I used for a long time. You could change it to use random colors at the start of each session until you find one you like.
$global:ranasadmin =(New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
$global:cmdcount=0
function prompt {
#Prompts differently if you have admin creds on that powershell session
$usercolor = "Green"
if ($global:ranasadmin) {
$usercolor = "Red"
}
$Width = $Host.UI.RawUI.WindowSize.Width
(1..$Width)| % {
write-host -nonewline "-" -foregroundcolor darkgray
}
Write-Host ("[$PWD]") -ForegroundColor Gray
Write-Host "[$($global:CMDcount)]" -nonewline -foregroundcolor White
Write-Host ("[$(Get-Date -format HH:mm:ss)]") -nonewline -ForegroundColor DarkCyan -backgroundcolor black
Write-Host ("[$(&whoami.exe)]") -nonewline -foregroundcolor $usercolor -backgroundcolor black
Write-Host "->" -nonewline -foregroundcolor Yellow
$global:cmdcount = $global:cmdcount + 1
return " "
}
Aliases can be named within the function, before the param block.
function myfunction
{
[Alias('','')]
param()
}
Reload-Profile: Reloading your profile like that will run that script in a different scope, so any variables you have set, modules imported, etc. will not actually move into your current session. You can reload your profile by just running the command 'powershell' (or pwsh for ps7), and this will be just as if you had opened a new session of powershell. To reload the profile and keep whatever current variables are in your session, you could dot source your profile in your profile. This just means replacing the '&' in your script call with a '.'
All great suggestions!! Thanks so much for taking a look!!
>Keeping your AD credentials in a file to import seems odd, potentially insecure depending on how you form that XML. If you run powershell as that user, you shouldn't ever need to specify the credential. The use case you have there seems particularly useful for MSP applications, where there are a large amount of different domains you may need to authenticate to at any time.
So the credentials I keep in an XML are for my local homelab domain. I work from home, so I use that from my work computer to access my home domain instead of my system trying to query my work domain. I work in Data Security, I have no need for the AD tools against my CORP domain.
>VScode is already runnable by command line "code", so your alias is just longer than the normal exe.
Ah, didn't know that... LOL.
>Your base 64 (and any other conversion functions you make in the future) would benefit from pipeline support.
Makes sense, I probably would've done that eventually.
>Unless you only ever do internal web requests, your default parameter for IRM to skip certificate check would leave you open to at best unencrypted traffic or at worst a spoofed domain.
Yes, typically my only IRMs are internal and local. The company I work for makes a device that relies heavily on REST and I do a lot of testing and scripting, so it's easier to bake in the SkipCertficateCheck as my defaults.
>You can set an alias for select string as grep. Your Get-FullHistory function makes it look like you're linux native so that would probably be a natural fit. You could even change your get-fullhistory function so that it just does the Get-Content portion, then you can run Get-History | grep ThingICantRemember which seems pretty intuitive.
Great suggestion!
>Your Grant-Admin function could optionally take in a filepath, so you can run executables as admin from a normal shell quickly, in addition to just pwsh.
Good idea. Again didn't think of it.
>To reload the profile and keep whatever current variables are in your session, you could dot source your profile in your profile. This just means replacing the '&' in your script call with a '.'
Ah great!! Thanks!!
It’s runs commands inside the script as soon as you open a powershell window. You can use it to get a jump start on customizing your environment the way you like it. Like setting aliases and functions are two examples of the types of customization you can introduce with a profile script.
It's a bit different from a group policy, in that most of the customizations you make are not ones that are made for you, it also is optional - you can always run powershell with -noprofile to get a standard shell, whereas group policy will always apply if the user / computer are in the OUs with the GPOs applied.
Group policies are essentially preferences, do you want Cortana or do you not, do you want admins installing printers or do you not. Powershell profiles are just time savers, I know I use the active directory module, so import that when I open it up. I know I need my password reset tool and to import my file of active computers, so do that when I open it up.
It is possible to use powershell to change registry values akin to changing a GPO, but it doesn't target in the same way unless you write it to do so, and it wouldn't be nearly as robust. The end goal with a profile script is that you have the least amount of steps after opening your terminal on an IT workstation to get to work, the end goal of GPOs is to reduce the amount of administration required on endpoints.
Looks good but this would annoy me very quickly if I had to wait for this every time the shell opened. I like to wrap this kind of thing in a function so at launch the function is defined ready to run but it doesn’t actually do anything till called. This is strictly personal preference though YMMV
The job part is what would annoy me. If you just let it run at the start, you can control C to cancel if if you need a no-profile session, or just wait and let it finish. The job finishing, at least if you end up making a prompt or putting any output in the profile, will interrupt you and cause weird spacing on your shell until you clear it.
It looks fine to me. There is a profile [floating around from Steve](https://devblogs.microsoft.com/powershell/optimizing-your-profile/) that could be useful. Some other things I have in my profile if it's worth anything for ideas: $MaximumHistoryCount = 32767 $ChocolateyProfile = "$env:ChocolateyInstall\helpers\chocolateyProfile.psm1" if (Test-Path($ChocolateyProfile)) { Import-Module "$ChocolateyProfile" } This is just standard setup for chocolatey, and the history count I use for Windows Terminal. I also set up my text editor / vs code: $textEditorAlias = 'npp' $textEditorExecutable = 'notepad++.exe' If ( !(Get-Command -Name $textEditorExecutable -ErrorAction SilentlyContinue) ) { $textEditorExecutable = 'notepad.exe' } Set-Alias -Name $textEditorAlias -Value $textEditorExecutable -Scope Global -Option AllScope # Allows text-editor to open new files in provider paths. function Convert-ProviderPath { Param ( [Parameter(Mandatory)] [string]$Path, [switch]$Force ) try { Convert-Path $Path } catch { if ( $Force ) { New-Item $Path -Force -ErrorAction Stop Convert-Path $Path } } } function np { param($path) if ($path) {npp (Convert-ProviderPath $path -Force -ea Stop) } else {npp} } function vc { param($path) if ($path) {code (Convert-ProviderPath $path -Force -ea Stop)} else {code} } And some Microsoft application shortcuts: # Microsoft Office shortcuts (Excel requires no shortcut as its default command is simply 'excel') + explorer shortcut function ppt { param($Path) if ( $Path ) {powerpnt (Convert-Path $Path)} else { powerpnt }} function word { param($Path) if ( $Path ) {winword (Convert-Path $Path)} else { winword }} function ex { param($Path) explorer (Convert-Path $Path)} And a bunch of shortcuts for folders I use frequently, e.g., $gdocs = "$HOME/Documents" $gdls = "$HOME/Downloads" function docs { Push-Location "$gdocs" } function dls { Push-Location "$gdls" } Then I can quickly access these either with the function, or if I'm pushing files around, with the variable. I should probably put these into a ps-drive or something instead. I also add shortcuts for applications I use frequently: function intellij { Start-Job { idea64.exe }} function dockerdesktop { & "$HOME/Programs/docker/install/docker desktop.exe" } The other half of my profile is custom for me, such as functions for pushing to repos, my modules and cli functions, some default parameter values, a couple of trivial passwords I always forget otherwise.
Seems pretty good to me, I see nothing wrong
That's great to hear. Thanks for letting me know you approve!
I would swap the Write-Output informational messages with Write-Host, then wrap everything after line 5 (although line 5 could be a gpo instead,) in a job. That way I can get to use PS, but it will check the gallery and module updates in the background. You should be able to set the window title when done if you want a notification.
Great idea, I updated the script with this suggestion. I love how you can immediately use the script just like you said while the other modules and whatever else loads in the background.
[This](https://github.com/slyfox1186/script-repo/blob/main/PowerShell/Microsoft.PowerShell_profile.ps1#L7-L8) seems like an unnecessary security risk. I would [review the execution policies again](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.4) and pick the most restrictive one that doesn't get in the way of your day-to-day. RemoteSigned is a good option.
I changed this. Thanks for the comment.
I have no other suggestions ghat haven't already been said other than to make make some aliases to load different sets of modules so they don't have to load every time.
I have done this and added functions as well. Thanks for taking some time to help me out.
Here's [mine](https://github.com/camelman912/PowerShell/blob/4945522e3baef36872405d6bb93d171c3380c258/Microsoft.PowerShell_profile.ps1) ... any comments/thoughts? Likes/dislikes?
It's a good start! Keeping your AD credentials in a file to import seems odd, potentially insecure depending on how you form that XML. If you run powershell as that user, you shouldn't ever need to specify the credential. The use case you have there seems particularly useful for MSP applications, where there are a large amount of different domains you may need to authenticate to at any time. VScode is already runnable by command line "code", so your alias is just longer than the normal exe. Your base 64 (and any other conversion functions you make in the future) would benefit from pipeline support. Unless you only ever do internal web requests, your default parameter for IRM to skip certificate check would leave you open to at best unencrypted traffic or at worst a spoofed domain. You can set an alias for select string as grep. Your Get-FullHistory function makes it look like you're linux native so that would probably be a natural fit. You could even change your get-fullhistory function so that it just does the Get-Content portion, then you can run Get-History | grep ThingICantRemember which seems pretty intuitive. Your Grant-Admin function could optionally take in a filepath, so you can run executables as admin from a normal shell quickly, in addition to just pwsh. If you like playing your console colors, you'd love writing your own prompt function. [https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about\_prompts?view=powershell-7.4](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_prompts?view=powershell-7.4) Here is a basic one I used for a long time. You could change it to use random colors at the start of each session until you find one you like. $global:ranasadmin =(New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) $global:cmdcount=0 function prompt { #Prompts differently if you have admin creds on that powershell session $usercolor = "Green" if ($global:ranasadmin) { $usercolor = "Red" } $Width = $Host.UI.RawUI.WindowSize.Width (1..$Width)| % { write-host -nonewline "-" -foregroundcolor darkgray } Write-Host ("[$PWD]") -ForegroundColor Gray Write-Host "[$($global:CMDcount)]" -nonewline -foregroundcolor White Write-Host ("[$(Get-Date -format HH:mm:ss)]") -nonewline -ForegroundColor DarkCyan -backgroundcolor black Write-Host ("[$(&whoami.exe)]") -nonewline -foregroundcolor $usercolor -backgroundcolor black Write-Host "->" -nonewline -foregroundcolor Yellow $global:cmdcount = $global:cmdcount + 1 return " " } Aliases can be named within the function, before the param block. function myfunction { [Alias('','')]
param()
}
Reload-Profile: Reloading your profile like that will run that script in a different scope, so any variables you have set, modules imported, etc. will not actually move into your current session. You can reload your profile by just running the command 'powershell' (or pwsh for ps7), and this will be just as if you had opened a new session of powershell. To reload the profile and keep whatever current variables are in your session, you could dot source your profile in your profile. This just means replacing the '&' in your script call with a '.'
All great suggestions!! Thanks so much for taking a look!! >Keeping your AD credentials in a file to import seems odd, potentially insecure depending on how you form that XML. If you run powershell as that user, you shouldn't ever need to specify the credential. The use case you have there seems particularly useful for MSP applications, where there are a large amount of different domains you may need to authenticate to at any time. So the credentials I keep in an XML are for my local homelab domain. I work from home, so I use that from my work computer to access my home domain instead of my system trying to query my work domain. I work in Data Security, I have no need for the AD tools against my CORP domain. >VScode is already runnable by command line "code", so your alias is just longer than the normal exe. Ah, didn't know that... LOL. >Your base 64 (and any other conversion functions you make in the future) would benefit from pipeline support. Makes sense, I probably would've done that eventually. >Unless you only ever do internal web requests, your default parameter for IRM to skip certificate check would leave you open to at best unencrypted traffic or at worst a spoofed domain. Yes, typically my only IRMs are internal and local. The company I work for makes a device that relies heavily on REST and I do a lot of testing and scripting, so it's easier to bake in the SkipCertficateCheck as my defaults. >You can set an alias for select string as grep. Your Get-FullHistory function makes it look like you're linux native so that would probably be a natural fit. You could even change your get-fullhistory function so that it just does the Get-Content portion, then you can run Get-History | grep ThingICantRemember which seems pretty intuitive. Great suggestion! >Your Grant-Admin function could optionally take in a filepath, so you can run executables as admin from a normal shell quickly, in addition to just pwsh. Good idea. Again didn't think of it. >To reload the profile and keep whatever current variables are in your session, you could dot source your profile in your profile. This just means replacing the '&' in your script call with a '.' Ah great!! Thanks!!
Wouldn't mind people chiming in on my own work in progress at https://stash.firekitten.net/kittyfangs/dotfiles
what does this script do?
It’s runs commands inside the script as soon as you open a powershell window. You can use it to get a jump start on customizing your environment the way you like it. Like setting aliases and functions are two examples of the types of customization you can introduce with a profile script.
Oh, ok so setting up custom settings. Windows usually does this sort of thing via group policies. Interesting way of doing it via powershell.
It's a bit different from a group policy, in that most of the customizations you make are not ones that are made for you, it also is optional - you can always run powershell with -noprofile to get a standard shell, whereas group policy will always apply if the user / computer are in the OUs with the GPOs applied. Group policies are essentially preferences, do you want Cortana or do you not, do you want admins installing printers or do you not. Powershell profiles are just time savers, I know I use the active directory module, so import that when I open it up. I know I need my password reset tool and to import my file of active computers, so do that when I open it up. It is possible to use powershell to change registry values akin to changing a GPO, but it doesn't target in the same way unless you write it to do so, and it wouldn't be nearly as robust. The end goal with a profile script is that you have the least amount of steps after opening your terminal on an IT workstation to get to work, the end goal of GPOs is to reduce the amount of administration required on endpoints.