Powershell today can be used for almost any purpose in a Windows IT Infrastructure, so far I have met only one limitation, which is creating useful GPO’s. There are plenty of ways to manage policies, import, export, finding conflicts etc. but creating a useful GPO is yet to come in Powershell.
But we are not looking for limitations here, we are looking for possibilities. Because Powershell makes you powerful ! No shit .. managing your infrastructure with scripted solutions and automated routines, which also is very useful for standardization and documentation .. it almost makes you want to just put your feet up, and hit Run.
In my experience, setting up a good working environment is worth the while production-wise, and what I have been missing in various learning books and on the internet looking for a fast solution, it is much more educational and rewarding to find the solution yourself, by setting up a working environment and a lab for developing and testing.
I like to use Visual Studio Code, a very powerful Editor for creating Powershell scripts and tools, which also ties all ends together developing new scripts, and seamlessly exporting your scripts to your projects in GitHub. Surely VSC takes some time getting to know and getting used to, it is, after all, a lightweight programming tool compared to Visual Studio, but worth the while to learn, and there are plenty of Tips & Tricks for it to be found on the internet.
For current Profile path: $profile
By default, you have 6 different Powershell profile locations, which is I think very confusing. Let us focus on just one, whether you put it on a share sharing it with your co-workers or in my case in a OneDrive location shared and updated by my devices, so whether i work on my desktop or laptop, it is the same paths.
|Current User, Current Host – console||$Home\[My ]Documents\WindowsPowerShell\Profile.ps1|
|Current User, All Hosts||$Home\[My ]Documents\Profile.ps1|
|All Users, Current Host – console||$PsHome\Microsoft.PowerShell_profile.ps1|
|All Users, All Hosts||$PsHome\Profile.ps1|
|Current user, Current Host – ISE||$Home\[My ]Documents\WindowsPowerShell\Microsoft.P owerShellISE_profile.ps1|
|All users, Current Host – ISE||$PsHome\Microsoft.PowerShellISE_profile.ps1|
Setting your working profile is an essential part of creating a productive working environment. I use this script to set my environment.
# Create Work folder New-Item "V:\OneDrive - Virak.eu\Powershell\Scripts" -ItemType Directory -Force # Create basic profile and populate $profile = "V:\OneDrive - Virak.eu\Powershell\profile.ps1" . $profile New-Item –Path $Profile –Type File –Force # New-Item $profile -Force -ErrorAction SilentlyContinue ‘# Profile file created’ | OUT-File $profile ‘# Profile for $(hostname)’ | OUT-File $profile -Append '' | OUT-File $profile -Append '# Set location' | OUT-File $profile -Append 'Set-Location -Path "V:\OneDrive - Virak.eu\Powershell\Scripts"' | OUT-File $profile -Append '' | OUT-File $profile -Append '# Set an alias' | Out-File $Profile -Append 'Set-Alias gh get-help’ | Out-File $Profile -Append ‘### End of profile’ | Out-File $Profile -Append
The location where new modules are installed and imported from, and as with profiles there are also several PS module locations, and from PS ver. 3 modules are auto-imported when called upon in commands, but where exactly are the modules stored that you install? Again it would be nice just having one repository to focus on.
Get-module -listavailable will show all currently imported modules and those installed in the different module locations.
For current module paths: $env:PSmodulepath -split ‘;’
Set new Module path:
$env:PSModulePath = $env:PSModulePath + “$([System.IO.Path]::PathSeparator)V:\OneDrive – Virak.eu\Powershell\Modules”
Module path is also set in the Registry
“PSModulePath”=”V:\\\\OneDrive – Virak.eu\\Powershell\\Modules
I changed mine to just using one, but usually several locations shown separated by ;
You might get an “error” setting execution policy, saying: “set-executionpolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of RemoteSigned. Type “Get-ExecutionPolicy -List” to view your execution policy settings. For more information please see “Get-Help Set-ExecutionPolicy”.
In a domain environment, this is set in a Group Policy. On a standalone Windows client, it is done in the local policy editor (gpedit.msc), navigating to Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell. Double-click “Turn on Script Execution” on the right pane. I have set mine to allow local and remote signed scripts. Get-executionpolicy will now say RemoteSigned.
|Heads up: Don’t be tempted to run the command from within the profile settings script. It won’t run before setting the executionpolicy prior to running scripts.|
Let us set up the PSGallery repository. After a repository is registered, you can reference it from the Find-Module, Install-Module, and Publish-Module cmdlets. The registered repository becomes the default repository in Find-Module and Install-Module.
There are other repositories, such as NuGet which we will use later on.
Set-PSRepository -Name “PSGallery” -InstallationPolicy Trusted
Do not use more repositories than needed, if both PSGallery and PowershellModules are registered, you will have to specify which repository you want the module installed from.
Having the PSGallery repository set up, it is easy to use the many modules online and seamlessly integrate them in your work.
Update Windows, using the Windows Update Powershell Modules from PSGallery?
Install-Module PSWindowsUpdate Get-Module
A simple Update routine
Get-WUInstall -AcceptAll -Verbose -Install -AutoReboot
Install a specific KB with Get-WUInstall -KBArticleID KB4534307 -AcceptAll -ForceInstall
Get-WUHistory to get a list of installed updates.