- Create a certificate-signed RDP shortcut via Group Policy - Fri, Aug 9 2019
- Monitor web server uptime with a PowerShell script - Tue, Aug 6 2019
- How to build a PowerShell inventory script for Windows Servers - Fri, Aug 2 2019
As an IT professional, you're familiar with how Windows represents storage volumes by using drive letters followed by a colon. C: is forever embedded in my brain. The system represents files and folders on each volume in a hierarchical fashion.
Wouldn't it be nice if you could browse other information repositories this way? For example, if you think about it, the registry is an information repository built in the same manner. You've got HKEY_LOCAL_MACHINE, HKEY_USERS and so on. Each of these keys contains subkeys and values like HKEY_LOCAL_MACHINE\Software. Why can't we navigate through the registry as we can the file system? It turns out we can, using PowerShell providers and PowerShell drives.
For example, when navigating your C:, that's the FileSystem provider, but when navigating the registry, that's the Registry provider. Each provider can contain multiple drives. Let's explain this with an example.
In a PowerShell console, you can see all of the available providers by using the Get-PSProvider command.
Listing providers with Get PSProvider
This command shows a list of all providers including all drives associated with each. You can see that out of the box, PowerShell provides more than just a FileSystem and Registry provider. The ActiveDirectory provider, as shown above, is partly a default provider but one that comes with the ActiveDirectory module. This is an excellent example of how a PowerShell drive can represent just about anything.
To drill down into the drives themselves, you'd use the Get-PSDrive command.
Viewing drives with Get PSDrive
This shows each of the drives the provider represents. To use any of these drives, we can just reference them as we can with the traditional filesystem. We'd use a drive name followed by a colon and any number of containers. For example, if I want to see all registry keys inside HKEY_LOCAL_MACHINE, I could enumerate them just like I can with files using the Get-ChildItem command.
Get-ChildItem HKCU:\ Get-ChildItem
The same applies to the all the other PowerShell drives as well. If you understand the concept of Get-ChildItem and Get-Item, you can enumerate and inspect any object in any of the PowerShell drives using these same commands.
This is why the commands have the Item noun instead of nouns like file, key, or certificate. This is why you'll also see folders and registry keys generically called containers as well. The commands and parameters are purposely generic so the same methodology of working with each PowerShell drive can be the same experience.
All the PowerShell drives can be not just read-only but read-write as well. This means you can create new items, remove items, and modify them at will using familiar syntax. PowerShell gives us the expected commands to do these things with the Remove-Item and New-Item commands.
Perhaps we need to delete a file. Remove-Item -Path C:\File.txt will do it. Maybe I need to delete a registry key. Remove-Item -Path HKLM:\Software\SomeKey will do that too. You can also create new items similarly as with New-Item -Path 'C:\' -Name 'File.txt' and New-Item -Path 'HKCU:\' -Name 'SomeKey' or even New-Item -Path Variable:\ -Name 'foo' -Value 'bar' if you'd like to create a variable the long way!
Subscribe to 4sysops newsletter!
You can create PowerShell drives that PowerShell providers represent from just about any structured information repository. Use the existing drives that come with PowerShell, and also, the next time you install a module from a vendor, check to see if they have included a PowerShell provider as well. If so, it may make working with that data much easier.
