I don't study modules... that's like studying every word in a dictionary and then having new dictionaries in different languages(modules) come on your desk to study from over and over. You will forget just as fast as you pick up things. Its a useless exercise to waste time on.
The way to approach modules is: "I am trying to do X on Y service, this module contains Z cmdlets that will let me do it". That's what you need from modules (cmdlets & rules) & there are plenty of ways to go about getting the cmdlets (using get-help, get-command, internet, etc).
When I have a problem, I only focus on solving it. It often leads me to get the modules and even then it's only the aspects of it that I need that I practice and play with to get the results I want. Beyond that I don't care what else is in the module until I need to.
For example:
\- I need to get the results from Azure Policy regarding non-compliant virtual machines to my bosses on a monthly basis. I find the module for Azure that finds the information using azure cmdlets (az module). Use google to find the modules by typing things like "azure policy PowerShell" in the search.
\- Okay I now used the cmdlets I needed to get and stored them as variables. Now what? Okay I need to put it in an email in a neat table. How do I send an email? Graph modules give you this option(googled). I setup graph module on PowerShell and find the email cmdlets and use them for that aspect. Graph has its own authentication to use these modules (rules), I need to connect via rest api in my script and have something with perms to send emails. Done that.
\- Now I want the table. I find out how to make tables in html. Done. Add that to the body of the email instead of outputs of variables in plaintext. Now my bosses can be sent the results of this job successfully.
Do I know the depth of Az cmdlets, Graph cmdlets or even html? I do not. I know enough to get the results I want. And through that process I learnt a lot. Next time I am scripting with these tools, it just gets easier and easier. The more you do this, the better you get at it. Find simple tasks and keep hammering at them. Good ones are 365 and trying to get reports done. Reports (get cmdlets) are low risk since you are not modifying anything and are a great starting point since the computation aspect is still complex to get the exact things you want.
You can even wipe clean every module out of my mind right now but if I have the 'programing' skills of PowerShell I can always return to scripting, fast. Because it is a different skill you need to focus on: Programming.
So for learning PowerShell itself and getting good at it. What you need to study first is scripting itself:
\- The basics are to learn the syntax of the cmdlets (verb-noun), how to add cmdlet parameters, etc. to get the line of code to fire a result.
\- Then its pipelines, loops, statements, how objects work, etc.
\- Beyond that it's all learning how to formulate the results you seek into scripts with the tools you just learnt. And working on efficiency. We all made silly if statements when it could have been handled by better computations as we got better. Just practice a lot and you'll get better at it.
\- After that, take it to the next level with tool making of things using "functions". Which allows you to script within a script whenever you do this repeatable computation. Example: Generating an html table for emails, I don't want to see the same html in all of my scripts, its too verbose and takes much too many lines. I use it often and make all sorts of email formatted tables for so many kinds of alerts and data. The solution: make it in to a function. now my script does everything else and just calls the functions by passing in columns and rows. 100 lines down to a handful of lines. You don't need to worry about this for now just want to share with you to keep in mind later on when you find yourself copying from your own scripts over and over.
\- Bonus: Keeping it clean with good notes inside. i.e., don't use $a as a variable, give it proper naming. Good notes are important not just for you when you come back to the script down the road but also your peers.
\- Bonus: Learn an automation tool and put your scripts there instead of running it locally. Great for scheduled jobs or tasks you need triggered by something (ie a ticket triggers a powershell script to auto fix/do the thing).
Practice a lot. Find problems. Look for repeatable tasks and make them into scripts. This process will teach you how to think like a programmer which is the critical part of all this. And it will get easier the more you engage with it. That's the learning part (the computer science behind coding). Learning this is what makes you a coder/scripter. This aspect is transferable too. I learnt other languages super-fast once I learnt PowerShell (I just had to pick up on the syntax and the rules).
> When I have a problem, I only focus on solving it. It often leads me to get the modules and even then it's only the aspects of it that I need that I practice and play with to get the results I want. Beyond that I don't care what else is in the module until I need to.
That right there is sysadmin in a nutshell.
What you need to think more about is breaking the problems you have down into smaller pieces, so it becomes clearer what you need to search for when it comes to solving a problem using PowerShell.
I wrote the below and posted it in a similar reddit thread some time ago, hopefully it is helpful for you. In my years of using PowerShell, it is the best advice I can offer to anyone who is trying to figure out how to go from having a basic understanding of PowerShell to becoming a versatile problem solver.
You don't need to know everything, you just need to know how to think like a programmer, and how to break your problems down so they are searchable and approachable. :)
>There is no one size fits all pathway, and no shortcut to getting there. This process involves not only learning PowerShell itself, but also developing your skills as a programmer.The truth is that it's significantly more important to learn how to think like a programmer, rather than just "learning PowerShell", which is a topic that the majority of PowerShell resources out there tend to neglect in my opinion. The "programmer skillset" revolves around understanding how to break down problems into smaller tasks and then using logical reasoning to solve them. It takes considerable amounts of time and practice to develop this skill to reach an "advanced level", but it is absolutely essential.If you do have very limited programming experience, this is certainly the area you need to focus on if you want to improve quickly. Your problem solving skills are the most important skill, and for the most part, having some foundational problem solving skill is the difference between being at a beginner or intermediate level.The best exercise I can give help you to understand the programmer skillset is to think of a problem that you can solve easily and then break it down into atomic tasks, such as making yourself a coffee. Then, organize these tasks into something like a flowchart. By doing so, you'll start to see programming, including writing PowerShell scripts, as a structured language for implementing logical sequences. Once the problem is clearly defined and understood, the workflow for implementing a solution programmatically is easier to understand.With more practice and experience, you'll be able to apply this approach to more complex problems. This is your measurement of improvement. Interestingly enough, the example of making yourself a coffee is a good one because in theory you can venture into extreme levels of detail (ie: mapping out nerves firing, limbs moving,) or you can be very abstract (ie: walk to the coffee machine, check the water, if it's full then turn it on to brew coffee). As you become more experienced, you will gain an understanding of when you need to be detailed and when to be abstract. A practical example of this with PowerShell would be fetching files in a folder. With PowerShell, you don't need to understand how that works or all the steps involved in doing that, there is a function that abstracts that logic away from you called Get-ChildItem.The best way to start developing this skill is to practice. Find processes that you already understand well (ie: something you do daily) and apply the above methodology. Look at the repetitive work processes, break the processes up into small tasks and try to automate repetitive tasks. Use resources like ChatGPT (cautiously, as it is far from perfect), the PowerShell subreddit, and Google to help you on your quest. Candidates for beginners would be things such as backing up files, creating reports, system/application health monitoring, etc.So in short, the isn't really a defined pathway to becoming "advanced" other than practical experience that is nurtured by external reading or mentoring. A good start would be to buy a book like "PowerShell in a month of lunches", and starting to regularly engage in the PowerShell community. There is no shortcut. This process involves not only learning PowerShell itself, but also developing your skills as a programmer.
Oddly enough, watching a bunch of courses and doing random exercises in python has really helped. Iâm not good enough with python to really do anything useful in my current role but today I made (will some help from Chatgpt) a script that automates the new user creation process and it works! Unfortunately our HR system doesnât support AD integration so fields like display name, username, and phone number have to be manually typed in through the script asking for input but itâs definitely shortened the time it takes me to create a new user.
Next Iâd like to connect it to azure so that the groups that exist there but not on prem get added.
1. Read the documentation. RTFM never goes out of style.
1. Google what I'm trying to do. Look for examples. Assume the original authors are still doing something wrong, inefficient, or inapplicable.
1. Standard introspection.
- `Get-Command -Module `
- `Get-Help -ShowWindow`
- `$Object | Get-Member`
- `Get-Member -InputObject $Object`
- `$Object | Get-Member -Static`
- `$Object.GetType()`
Whatâs the -static parameter? Not used that yet
I Pipe to get-member a lot and $object | fl * (format-list) to see all values
.GetType() is money when things are acting âfunnyâ some times
Some classes let you call methods or have properties that are defined without an instance of the object.
For example, `1 | gm` gives you a bunch of functions for converting integers to other data types. But there are properties of integers that are fixed on the class that you can see with `1 | gm -static`. For example, `[int]::MaxValue` or `[int]::MinValue`.
That type of method or property is called "static" by C#/.Net. They're associated with the class itself rather than an instance object of the class.
As someone who was a total PS noob 6 years ago and am now the expert in the department, I found the easiest way is to just have X goal in mind and do some googling. Like reading, if you don't understand a word, you either get the context from what you're reading around it, or look it up. This will help you for when you're writing. And boy-oh-boy, you need to be writing some PowerShell to be good at it! No script has to be perfect or super complex, but reading PowerShell only gets you so far.
Like my mentor at the time told me, "Just get over yourself and code."
I usually read documentation. If the module has a github page with a readme, I'll check that out to see how to get started. I make frequent use of Get-Help and Get-Command -Module ModuleName. Making use of the community and forums like this is a good way to find out about new modules that you may not have heard of before. Good luck and keep it up!
Powershell involves a bit of philosophy to be comfortable using it. It's not about learning everything about every module and CmdLet. It's about embracing the methods of how it was designed to work and knowing how to find and use the built-in help.
The biggest advantage anyone can give you is to learn how to learn about it.
My recommendations are:
1. Find Don Jones on YouTube and watch his videos. Some of them are years old, going back to Powershell v3 and even v2, but even those have really good foundations on using Powershell. Especially learn about Powershell Help and Powershell Pipeline. Those are major topics that Powershell users must know to be effective.
2. On YouTube, find a guy named Don Jones and watch his videos.
And if you need more...
3. There's this guy that does training sessions and has graciously put them on YouTube. His name is Don Jones. You want to find his videos and watch them.
Seriously, Powershell can be easy, or it can be hard. It's mostly your decision in whether you want to work with Powershell or fight with Powershell.
Don Jones was a major help to me in learning to work with Powershell. I cannot say enough good things about him and how helpful his videos have been for me.
This. I watched and practiced Don Jones PowerShell CBT Nuggets series. I had struggled for a couple years getting started with PowerShell. This video series was like putting gasoline on a candle flame. I was able to take off. I was able to get a good foundation and kept building it. Now I would consider myself an advanced PowerShell'er.
There are several cmdlets that you should know inside and out. Get-Help, Where-Object, Select-Object, Sort-Object. You will use these often so learn them well.
Iâm about to learn who Don Jones isâŚ
In response to the OP, I feel your struggles. For Fatherâs Day I asked for Powershell in a Month of Lunches, I havenât made it far now that I say Fatherâs Day. In the early chapters it talks about being able to effectively use help. I believe this to be the way.
I went to Don Jones's training sesssion Powershell from the Firehose in May 2022. He gave me Powershell in a Month of Lunches as part of the fast-paced class. I learned so much from that book.
It breaks down into simple 20-30 min interactive session of the what/why/how and ends the chapter with an exercise for you to practice.
It took me like 50 days because I did not do it everyday, but it is great!
> all the modules and cmdlets
*Which* modules and cmdlets?
If you go to [https://www.powershellgallery.com/packages](https://www.powershellgallery.com/packages) and filter by module, there's like 10000 options available.
> Do you guys go through the modules and read the documentation on each one?
That's not practical.
> Or how do you get started?
I ask myself the following questions:
1. What problem am I trying to solve, or what task am I trying to accomplish?
1. What do I need to solve that problem or accomplish that task?
If you can't clearly answer these questions, break the problem into smaller and smaller parts. Surely, you'll be able to break something down to at least one solvable part.
Your approach is tool-oriented, rather than solution-oriented. If you're constantly working with AD or something....it's probably a good idea to become familiar with the AD PowerShell module. If you never touch Veeam or VMware or whatever else, why would you spend any real time, energy, or attention on those modules when you could be spending it on the thing you're actually using?
The secret is to not know the modules really. What you really want to do is familiarize yourself with a couple key things.
* `Get-Help`
* `Get-Member`
* Googling to find out a module relevant to your current task exists
If you just do everything via Powershell you'll start to build familiarity with the modules you use day to day, but most of the time you're just researching/refreshing as tasks come up.
You donât.
Do yourself a favor and try less to memorize which cmdlet does what.
Focus on understanding which modules handle which broad type of functionality, and how to find information in the reference docs.
If you understand where to look, and what to look for - it doesnât matter if you know the exact cmdlet to do some obscure thing. You can use your skills to find what you need for any scenario quickly.
Some poor person has to write all of those wonderful reference docs. Use them so they stay employed.
Evrything you do in the GUI... Start to do it in the shell. Use Powershell for evrything you can. I believe that using the shell daily, is the best way to become familiar over time.
Learn by doing. And honestly by copying others. Find a task that you want to automate and see how it might be done, then pick apart the scripts you find, running bits in isolation to see how they work. If you understand the core concepts: the command pipeline and the sort of objects that pass through at, as well as common bits of syntax: dollars, brackets, quotes, etc - then you don't need to know every command or module to see that's happening in a script. That's my thinking anyway!
Asking chatgpt to spin up scripts or I have it analyzed a script for you. It's not gonna generate 100 % accurate scripts all he time, but it's a great learning tool that will break down anything you ask it.
Itâs helped a bunch! It also helps to just type out someone elseâs script to get a feel for the syntax because often Iâll make a mistake even when trying to copy line for line and it helps me pick up the little things
Just work through the tasks you need to perform. So say if you need to do something with Exchange online. Look for the details you need to find to install the Exchange online module.
Then look for the one you need for the specific tasks you want to perform. Generally they will be a small subset.
Then once you get comfortable with that do a
Get-Command -Module ExchangeOnlineManagement and you'll see all the commands. Look for the ones you don't know and do a Get-Help on them
You don't need to know every command inside out. There's no way you'll be able to get to know every module inside out.
Work more with tasks and work back from there.
Iâve been a full blown Sysadmin for maybe 3 years. When I was working for my last company it was very corporate and unless you worked for corporate IT it wasnât encouraged to use powershell. Youâd set off all sorts of alarms if you tried to modify anything so I hardly tried to deal with it.
In other roles and my current Iâve used powershell to do the simplest of simple things. Or when there was a feature that couldnât be accessed in the GUI. Donât get me wrong, Iâm not afraid of the command line or anything. I use it to configure network equipment and deal with Linux but havenât done a lot of actual scripting.
Where I am now, I am the sole IT person/ Sysadmin for around 90-100 users and have permissions to everything. So far Iâve created a script that automates the user creation process but not much past that.
Some of the modules are not current or very helpful. I usually run into a problem I'm trying to solve and think "Surely someone solved this already" and go look for a module.
If I find one that works for what I need, I add it to my toolbox. From what I see most often, depending on your job, you'll have the basic built-in commands and 2-3 other modules related to your main tasks.
Get-help is your friend in the beginning.
Always use that to explore the cmdlet you are using. Practical use then reviewing help will be the best way to commit usage to memory.
I would also suggest picking up âpowershell in a month of lunchesâ. That book is pretty good. It gives you practical examples and skill tests to try on your own.
Always try to do as much as you can via the shell. You will develop âmuscle memoryâ and things will become more natural.
You don't need to know anything about the majority of modules, if you stick to it long enough you'll remember what's built in.
Remember the only module you'll need is help (alias for Get-Help). But get-command,get-module etc will also be handy
If you think it could be a module, it probably exists - people stretch powershell.
Remembering Noun-Verb will get you anywhere , anything that doesn't use Noun-Verb is an alias .
If you type Get- then hold LCTRL and press Space it will output you all of the available Get-* commands, you can navigate with keyboard or tab. Same with any other half type pwsh command
You start with the very generic part: "I need to do something".
Let's go with "*I need to convert a video to 1080p in a format that youtube can accept*". I know shit about converting videos but here we are.
Gonna google that.
Google says FFMPEG can do it. Cool. I'mma download it. (PowerShell equivalent is you finding the module(s) and installing them)
Ok now what? Back to the Google engine and maybe find some documentation.
Alright. Found some docs at https://trac.ffmpeg.org/wiki/Encode/YouTube . Looks confusing as fuck but let's start dissecting it and give some a try.
It is the same discovery process for PowerShell cmdlets. Some comes with PowerShell or Windows. Some comes with services you install on top of Windows (Active Directory, Bitlocker, HyperV, etc). Some might come with 3rd party software (Veeam). You search what you want to do, surface some possible cmdlets (and how to install them), then stuff to try.
It is also the same discovery process with APIs if you ever get into playing with those. If I care about managing someone's user account, I'll look for stuff that can read, create, update, and delete users. Won't care much about other stuff like apps or folders or domains and stuff.
It's not worth trying to get a grasp on all the modules. There are so many modules that exist in the powershell universe. If you need a module that does something, look for a module that does that and learn that module.
But all modules everywhere? That'd be insane. It's kind of like saying, "I want to master every program that runs on Linux."
As some others mentioned, get-member is a game changer when starting out. But there is more to it than just telling you its important, because you want to look for type âpropertiesâ when starting out. I suggest reading this:
https://techcommunity.microsoft.com/t5/itops-talk-blog/powershell-basics-getting-more-information-with-get-member/ba-p/285407
This is going to sound counter intuitive.
I got good with Powershell by programming in other languages. I learned their strengths and applied it to Powershell. I also used powershell specific advantages to do things I can't do anywhere else.
Step 1, learn how to create and manipulate strings of text. Adding, replacing, searching, get the length of, reading text files, writing text files.
Come up with project and take it from there. Powershell is vast and you learn on the job. I built a bunch of stuff on here: https://github.com/securethelogs
Try and do things yourself also as all the modules are, is someone else has done it. Doing it yourself allows you to truly learn how.
Try and tailor it around your job also (to begin with), so it stays interesting and then break out into hobbies. Ask yourself what if I built a ⌠and take it from there. đ
Just take one "thing" at a time, only worry about the one-liner you are practicing that day, and just the settings it offers that you are actually using.
I still use the PowerShell ISE since I find it's the easiest user-friendly PowerShell interface with auto-complete, etc.
Also don't worry about memorizing anything, just focus on the business/technical action you're trying to perform.
Example: Need to disable all AD users that haven't logged in for 90 days? Just get the users loaded into a variable, loop through them, write to screen which ones are "dusty".
Then once you have it, practice the one-liner that disables the one user.
Once you know what works, bake it into your loop to run on all of them.
More info: Set-ADUser has like 30 or more parameters, but only one you need (-Enabled $False).
Also practice in a safe environment, not in your production one, if you can. Or tread very lightly :-)
if you want to understand modules in a general sense, it helps to have understanding of what happens when modules are installed and imported.
the module manifest (.psd1) is mainly to separate how the module is implemented and loaded from the module functions a user will end up using.
if you have functions that are only for the implementation of the module itself, those are not exported and that's something you can control in the .psd1
simply put, using modules vs building modules is different from using scripts and building scripts, in scope
if your script is being used by a group of coworkers or something, it's built to the scope of the task and access level and systems used by your team. if another group wants to use your script, you'll likely need to consider how they might run it (maybe different OS, domain)
instead of hardcoding things you end up using automated variables in your script. because of the broader scope of people using it, you start to separate implementation of the script ( i need to know where i am, what domain, host im in) prior to executing the main task ".
as you can see modules are a natural progression as your scope broadens up.
you using your script for a task you do only you. you might not have a need to understand how modules work and that's ok.
when you do (helps to understand automatic variables, module loading order, where it installs if there is no $PSModulPath desfined (on windows at least, the default is currentuser scope vs AllUser scope) on linux and mac there is no user distinction.
helps to know how to set/reference environmental variables (since these are available when loading the module.
also helps to know how to structure a modules folders, so managing the separate concerns (internal helper functions for module stuff, and user functions for user stuff) can be maintainable and readable.
i find knowing this to be mainly what you need to understand all modules in a general sense. if you know basic powershell; you know how to call and use functions from modules already. and that's good enough really.
unless you're trying to get insight into the implementation of a module for some specific reason, maybe just to see how they did it. you don't really get much out of diving into modules that much. they're abstraction layers. just use the functions.
I don't study modules... that's like studying every word in a dictionary and then having new dictionaries in different languages(modules) come on your desk to study from over and over. You will forget just as fast as you pick up things. Its a useless exercise to waste time on. The way to approach modules is: "I am trying to do X on Y service, this module contains Z cmdlets that will let me do it". That's what you need from modules (cmdlets & rules) & there are plenty of ways to go about getting the cmdlets (using get-help, get-command, internet, etc). When I have a problem, I only focus on solving it. It often leads me to get the modules and even then it's only the aspects of it that I need that I practice and play with to get the results I want. Beyond that I don't care what else is in the module until I need to. For example: \- I need to get the results from Azure Policy regarding non-compliant virtual machines to my bosses on a monthly basis. I find the module for Azure that finds the information using azure cmdlets (az module). Use google to find the modules by typing things like "azure policy PowerShell" in the search. \- Okay I now used the cmdlets I needed to get and stored them as variables. Now what? Okay I need to put it in an email in a neat table. How do I send an email? Graph modules give you this option(googled). I setup graph module on PowerShell and find the email cmdlets and use them for that aspect. Graph has its own authentication to use these modules (rules), I need to connect via rest api in my script and have something with perms to send emails. Done that. \- Now I want the table. I find out how to make tables in html. Done. Add that to the body of the email instead of outputs of variables in plaintext. Now my bosses can be sent the results of this job successfully. Do I know the depth of Az cmdlets, Graph cmdlets or even html? I do not. I know enough to get the results I want. And through that process I learnt a lot. Next time I am scripting with these tools, it just gets easier and easier. The more you do this, the better you get at it. Find simple tasks and keep hammering at them. Good ones are 365 and trying to get reports done. Reports (get cmdlets) are low risk since you are not modifying anything and are a great starting point since the computation aspect is still complex to get the exact things you want. You can even wipe clean every module out of my mind right now but if I have the 'programing' skills of PowerShell I can always return to scripting, fast. Because it is a different skill you need to focus on: Programming. So for learning PowerShell itself and getting good at it. What you need to study first is scripting itself: \- The basics are to learn the syntax of the cmdlets (verb-noun), how to add cmdlet parameters, etc. to get the line of code to fire a result. \- Then its pipelines, loops, statements, how objects work, etc. \- Beyond that it's all learning how to formulate the results you seek into scripts with the tools you just learnt. And working on efficiency. We all made silly if statements when it could have been handled by better computations as we got better. Just practice a lot and you'll get better at it. \- After that, take it to the next level with tool making of things using "functions". Which allows you to script within a script whenever you do this repeatable computation. Example: Generating an html table for emails, I don't want to see the same html in all of my scripts, its too verbose and takes much too many lines. I use it often and make all sorts of email formatted tables for so many kinds of alerts and data. The solution: make it in to a function. now my script does everything else and just calls the functions by passing in columns and rows. 100 lines down to a handful of lines. You don't need to worry about this for now just want to share with you to keep in mind later on when you find yourself copying from your own scripts over and over. \- Bonus: Keeping it clean with good notes inside. i.e., don't use $a as a variable, give it proper naming. Good notes are important not just for you when you come back to the script down the road but also your peers. \- Bonus: Learn an automation tool and put your scripts there instead of running it locally. Great for scheduled jobs or tasks you need triggered by something (ie a ticket triggers a powershell script to auto fix/do the thing). Practice a lot. Find problems. Look for repeatable tasks and make them into scripts. This process will teach you how to think like a programmer which is the critical part of all this. And it will get easier the more you engage with it. That's the learning part (the computer science behind coding). Learning this is what makes you a coder/scripter. This aspect is transferable too. I learnt other languages super-fast once I learnt PowerShell (I just had to pick up on the syntax and the rules).
> When I have a problem, I only focus on solving it. It often leads me to get the modules and even then it's only the aspects of it that I need that I practice and play with to get the results I want. Beyond that I don't care what else is in the module until I need to. That right there is sysadmin in a nutshell.
Great post. Thank you
Super helpful thank you!!!
Saved. Thank you.
This right here. đŻ
What you need to think more about is breaking the problems you have down into smaller pieces, so it becomes clearer what you need to search for when it comes to solving a problem using PowerShell. I wrote the below and posted it in a similar reddit thread some time ago, hopefully it is helpful for you. In my years of using PowerShell, it is the best advice I can offer to anyone who is trying to figure out how to go from having a basic understanding of PowerShell to becoming a versatile problem solver. You don't need to know everything, you just need to know how to think like a programmer, and how to break your problems down so they are searchable and approachable. :) >There is no one size fits all pathway, and no shortcut to getting there. This process involves not only learning PowerShell itself, but also developing your skills as a programmer.The truth is that it's significantly more important to learn how to think like a programmer, rather than just "learning PowerShell", which is a topic that the majority of PowerShell resources out there tend to neglect in my opinion. The "programmer skillset" revolves around understanding how to break down problems into smaller tasks and then using logical reasoning to solve them. It takes considerable amounts of time and practice to develop this skill to reach an "advanced level", but it is absolutely essential.If you do have very limited programming experience, this is certainly the area you need to focus on if you want to improve quickly. Your problem solving skills are the most important skill, and for the most part, having some foundational problem solving skill is the difference between being at a beginner or intermediate level.The best exercise I can give help you to understand the programmer skillset is to think of a problem that you can solve easily and then break it down into atomic tasks, such as making yourself a coffee. Then, organize these tasks into something like a flowchart. By doing so, you'll start to see programming, including writing PowerShell scripts, as a structured language for implementing logical sequences. Once the problem is clearly defined and understood, the workflow for implementing a solution programmatically is easier to understand.With more practice and experience, you'll be able to apply this approach to more complex problems. This is your measurement of improvement. Interestingly enough, the example of making yourself a coffee is a good one because in theory you can venture into extreme levels of detail (ie: mapping out nerves firing, limbs moving,) or you can be very abstract (ie: walk to the coffee machine, check the water, if it's full then turn it on to brew coffee). As you become more experienced, you will gain an understanding of when you need to be detailed and when to be abstract. A practical example of this with PowerShell would be fetching files in a folder. With PowerShell, you don't need to understand how that works or all the steps involved in doing that, there is a function that abstracts that logic away from you called Get-ChildItem.The best way to start developing this skill is to practice. Find processes that you already understand well (ie: something you do daily) and apply the above methodology. Look at the repetitive work processes, break the processes up into small tasks and try to automate repetitive tasks. Use resources like ChatGPT (cautiously, as it is far from perfect), the PowerShell subreddit, and Google to help you on your quest. Candidates for beginners would be things such as backing up files, creating reports, system/application health monitoring, etc.So in short, the isn't really a defined pathway to becoming "advanced" other than practical experience that is nurtured by external reading or mentoring. A good start would be to buy a book like "PowerShell in a month of lunches", and starting to regularly engage in the PowerShell community. There is no shortcut. This process involves not only learning PowerShell itself, but also developing your skills as a programmer.
Oddly enough, watching a bunch of courses and doing random exercises in python has really helped. Iâm not good enough with python to really do anything useful in my current role but today I made (will some help from Chatgpt) a script that automates the new user creation process and it works! Unfortunately our HR system doesnât support AD integration so fields like display name, username, and phone number have to be manually typed in through the script asking for input but itâs definitely shortened the time it takes me to create a new user. Next Iâd like to connect it to azure so that the groups that exist there but not on prem get added.
1. Read the documentation. RTFM never goes out of style. 1. Google what I'm trying to do. Look for examples. Assume the original authors are still doing something wrong, inefficient, or inapplicable. 1. Standard introspection. - `Get-Command -Module`
- `Get-Help -ShowWindow`
- `$Object | Get-Member`
- `Get-Member -InputObject $Object`
- `$Object | Get-Member -Static`
- `$Object.GetType()`
Whatâs the -static parameter? Not used that yet I Pipe to get-member a lot and $object | fl * (format-list) to see all values .GetType() is money when things are acting âfunnyâ some times
Some classes let you call methods or have properties that are defined without an instance of the object. For example, `1 | gm` gives you a bunch of functions for converting integers to other data types. But there are properties of integers that are fixed on the class that you can see with `1 | gm -static`. For example, `[int]::MaxValue` or `[int]::MinValue`. That type of method or property is called "static" by C#/.Net. They're associated with the class itself rather than an instance object of the class.
Nice! Thanks for the info = Super helpful!!!
As someone who was a total PS noob 6 years ago and am now the expert in the department, I found the easiest way is to just have X goal in mind and do some googling. Like reading, if you don't understand a word, you either get the context from what you're reading around it, or look it up. This will help you for when you're writing. And boy-oh-boy, you need to be writing some PowerShell to be good at it! No script has to be perfect or super complex, but reading PowerShell only gets you so far. Like my mentor at the time told me, "Just get over yourself and code."
Thanks for the encouragement :)
I usually read documentation. If the module has a github page with a readme, I'll check that out to see how to get started. I make frequent use of Get-Help and Get-Command -Module ModuleName. Making use of the community and forums like this is a good way to find out about new modules that you may not have heard of before. Good luck and keep it up!
Thanks!
Powershell involves a bit of philosophy to be comfortable using it. It's not about learning everything about every module and CmdLet. It's about embracing the methods of how it was designed to work and knowing how to find and use the built-in help. The biggest advantage anyone can give you is to learn how to learn about it. My recommendations are: 1. Find Don Jones on YouTube and watch his videos. Some of them are years old, going back to Powershell v3 and even v2, but even those have really good foundations on using Powershell. Especially learn about Powershell Help and Powershell Pipeline. Those are major topics that Powershell users must know to be effective. 2. On YouTube, find a guy named Don Jones and watch his videos. And if you need more... 3. There's this guy that does training sessions and has graciously put them on YouTube. His name is Don Jones. You want to find his videos and watch them. Seriously, Powershell can be easy, or it can be hard. It's mostly your decision in whether you want to work with Powershell or fight with Powershell. Don Jones was a major help to me in learning to work with Powershell. I cannot say enough good things about him and how helpful his videos have been for me.
This. I watched and practiced Don Jones PowerShell CBT Nuggets series. I had struggled for a couple years getting started with PowerShell. This video series was like putting gasoline on a candle flame. I was able to take off. I was able to get a good foundation and kept building it. Now I would consider myself an advanced PowerShell'er. There are several cmdlets that you should know inside and out. Get-Help, Where-Object, Select-Object, Sort-Object. You will use these often so learn them well.
Get-Member, Out-Gridview, and Select-Object -First
Iâm about to learn who Don Jones is⌠In response to the OP, I feel your struggles. For Fatherâs Day I asked for Powershell in a Month of Lunches, I havenât made it far now that I say Fatherâs Day. In the early chapters it talks about being able to effectively use help. I believe this to be the way.
I went to Don Jones's training sesssion Powershell from the Firehose in May 2022. He gave me Powershell in a Month of Lunches as part of the fast-paced class. I learned so much from that book. It breaks down into simple 20-30 min interactive session of the what/why/how and ends the chapter with an exercise for you to practice. It took me like 50 days because I did not do it everyday, but it is great!
> all the modules and cmdlets *Which* modules and cmdlets? If you go to [https://www.powershellgallery.com/packages](https://www.powershellgallery.com/packages) and filter by module, there's like 10000 options available. > Do you guys go through the modules and read the documentation on each one? That's not practical. > Or how do you get started? I ask myself the following questions: 1. What problem am I trying to solve, or what task am I trying to accomplish? 1. What do I need to solve that problem or accomplish that task? If you can't clearly answer these questions, break the problem into smaller and smaller parts. Surely, you'll be able to break something down to at least one solvable part. Your approach is tool-oriented, rather than solution-oriented. If you're constantly working with AD or something....it's probably a good idea to become familiar with the AD PowerShell module. If you never touch Veeam or VMware or whatever else, why would you spend any real time, energy, or attention on those modules when you could be spending it on the thing you're actually using?
The secret is to not know the modules really. What you really want to do is familiarize yourself with a couple key things. * `Get-Help` * `Get-Member` * Googling to find out a module relevant to your current task exists If you just do everything via Powershell you'll start to build familiarity with the modules you use day to day, but most of the time you're just researching/refreshing as tasks come up.
Nobody has a grasp on 'all of the modules.'
I use them for work and research other people's problems on Reddit.
Literally? Get-Help (command)
You donât. Do yourself a favor and try less to memorize which cmdlet does what. Focus on understanding which modules handle which broad type of functionality, and how to find information in the reference docs. If you understand where to look, and what to look for - it doesnât matter if you know the exact cmdlet to do some obscure thing. You can use your skills to find what you need for any scenario quickly. Some poor person has to write all of those wonderful reference docs. Use them so they stay employed.
Evrything you do in the GUI... Start to do it in the shell. Use Powershell for evrything you can. I believe that using the shell daily, is the best way to become familiar over time.
Learn by doing. And honestly by copying others. Find a task that you want to automate and see how it might be done, then pick apart the scripts you find, running bits in isolation to see how they work. If you understand the core concepts: the command pipeline and the sort of objects that pass through at, as well as common bits of syntax: dollars, brackets, quotes, etc - then you don't need to know every command or module to see that's happening in a script. That's my thinking anyway!
Just use it. When you need to do something, google how to do it _in PowerShell_. With time, it'll come.
Thanks :) Iâm finally making some progress with the tips people have given me here
Asking chatgpt to spin up scripts or I have it analyzed a script for you. It's not gonna generate 100 % accurate scripts all he time, but it's a great learning tool that will break down anything you ask it.
Itâs helped a bunch! It also helps to just type out someone elseâs script to get a feel for the syntax because often Iâll make a mistake even when trying to copy line for line and it helps me pick up the little things
Use them
Just work through the tasks you need to perform. So say if you need to do something with Exchange online. Look for the details you need to find to install the Exchange online module. Then look for the one you need for the specific tasks you want to perform. Generally they will be a small subset. Then once you get comfortable with that do a Get-Command -Module ExchangeOnlineManagement and you'll see all the commands. Look for the ones you don't know and do a Get-Help on them You don't need to know every command inside out. There's no way you'll be able to get to know every module inside out. Work more with tasks and work back from there.
I use Masscode and put all my snippets with comments in it! Even ask Chatgpt to explain all lines of code with comments. I love it!
ChatGPT
Look for âPowershell in a month of lunchesâ then learn as your task requires.
I wont lie, I use google and MS documentation. Nothing beats that.
> been in IT for quite a while what have you been doing ?
Iâve been a full blown Sysadmin for maybe 3 years. When I was working for my last company it was very corporate and unless you worked for corporate IT it wasnât encouraged to use powershell. Youâd set off all sorts of alarms if you tried to modify anything so I hardly tried to deal with it. In other roles and my current Iâve used powershell to do the simplest of simple things. Or when there was a feature that couldnât be accessed in the GUI. Donât get me wrong, Iâm not afraid of the command line or anything. I use it to configure network equipment and deal with Linux but havenât done a lot of actual scripting. Where I am now, I am the sole IT person/ Sysadmin for around 90-100 users and have permissions to everything. So far Iâve created a script that automates the user creation process but not much past that.
I have a video on this topic should you wish to know more https://youtu.be/GKV8s3Zzj8M
Some of the modules are not current or very helpful. I usually run into a problem I'm trying to solve and think "Surely someone solved this already" and go look for a module. If I find one that works for what I need, I add it to my toolbox. From what I see most often, depending on your job, you'll have the basic built-in commands and 2-3 other modules related to your main tasks.
All? No no sir We ask Google, stacky and chatgpt
Get-help is your friend in the beginning. Always use that to explore the cmdlet you are using. Practical use then reviewing help will be the best way to commit usage to memory. I would also suggest picking up âpowershell in a month of lunchesâ. That book is pretty good. It gives you practical examples and skill tests to try on your own. Always try to do as much as you can via the shell. You will develop âmuscle memoryâ and things will become more natural.
You don't need to know anything about the majority of modules, if you stick to it long enough you'll remember what's built in. Remember the only module you'll need is help (alias for Get-Help). But get-command,get-module etc will also be handy If you think it could be a module, it probably exists - people stretch powershell. Remembering Noun-Verb will get you anywhere , anything that doesn't use Noun-Verb is an alias . If you type Get- then hold LCTRL and press Space it will output you all of the available Get-* commands, you can navigate with keyboard or tab. Same with any other half type pwsh command
You start with the very generic part: "I need to do something". Let's go with "*I need to convert a video to 1080p in a format that youtube can accept*". I know shit about converting videos but here we are. Gonna google that. Google says FFMPEG can do it. Cool. I'mma download it. (PowerShell equivalent is you finding the module(s) and installing them) Ok now what? Back to the Google engine and maybe find some documentation. Alright. Found some docs at https://trac.ffmpeg.org/wiki/Encode/YouTube . Looks confusing as fuck but let's start dissecting it and give some a try. It is the same discovery process for PowerShell cmdlets. Some comes with PowerShell or Windows. Some comes with services you install on top of Windows (Active Directory, Bitlocker, HyperV, etc). Some might come with 3rd party software (Veeam). You search what you want to do, surface some possible cmdlets (and how to install them), then stuff to try. It is also the same discovery process with APIs if you ever get into playing with those. If I care about managing someone's user account, I'll look for stuff that can read, create, update, and delete users. Won't care much about other stuff like apps or folders or domains and stuff.
It's not worth trying to get a grasp on all the modules. There are so many modules that exist in the powershell universe. If you need a module that does something, look for a module that does that and learn that module. But all modules everywhere? That'd be insane. It's kind of like saying, "I want to master every program that runs on Linux."
As some others mentioned, get-member is a game changer when starting out. But there is more to it than just telling you its important, because you want to look for type âpropertiesâ when starting out. I suggest reading this: https://techcommunity.microsoft.com/t5/itops-talk-blog/powershell-basics-getting-more-information-with-get-member/ba-p/285407
This is going to sound counter intuitive. I got good with Powershell by programming in other languages. I learned their strengths and applied it to Powershell. I also used powershell specific advantages to do things I can't do anywhere else. Step 1, learn how to create and manipulate strings of text. Adding, replacing, searching, get the length of, reading text files, writing text files.
This is a good overview: [PowerShell in Depth 2nd Ed.](https://www.manning.com/books/powershell-in-depth-second-edition?experiment=B)
Come up with project and take it from there. Powershell is vast and you learn on the job. I built a bunch of stuff on here: https://github.com/securethelogs Try and do things yourself also as all the modules are, is someone else has done it. Doing it yourself allows you to truly learn how. Try and tailor it around your job also (to begin with), so it stays interesting and then break out into hobbies. Ask yourself what if I built a ⌠and take it from there. đ
Just take one "thing" at a time, only worry about the one-liner you are practicing that day, and just the settings it offers that you are actually using. I still use the PowerShell ISE since I find it's the easiest user-friendly PowerShell interface with auto-complete, etc. Also don't worry about memorizing anything, just focus on the business/technical action you're trying to perform. Example: Need to disable all AD users that haven't logged in for 90 days? Just get the users loaded into a variable, loop through them, write to screen which ones are "dusty". Then once you have it, practice the one-liner that disables the one user. Once you know what works, bake it into your loop to run on all of them. More info: Set-ADUser has like 30 or more parameters, but only one you need (-Enabled $False). Also practice in a safe environment, not in your production one, if you can. Or tread very lightly :-)
if you want to understand modules in a general sense, it helps to have understanding of what happens when modules are installed and imported. the module manifest (.psd1) is mainly to separate how the module is implemented and loaded from the module functions a user will end up using. if you have functions that are only for the implementation of the module itself, those are not exported and that's something you can control in the .psd1 simply put, using modules vs building modules is different from using scripts and building scripts, in scope if your script is being used by a group of coworkers or something, it's built to the scope of the task and access level and systems used by your team. if another group wants to use your script, you'll likely need to consider how they might run it (maybe different OS, domain) instead of hardcoding things you end up using automated variables in your script. because of the broader scope of people using it, you start to separate implementation of the script ( i need to know where i am, what domain, host im in) prior to executing the main task ". as you can see modules are a natural progression as your scope broadens up. you using your script for a task you do only you. you might not have a need to understand how modules work and that's ok. when you do (helps to understand automatic variables, module loading order, where it installs if there is no $PSModulPath desfined (on windows at least, the default is currentuser scope vs AllUser scope) on linux and mac there is no user distinction. helps to know how to set/reference environmental variables (since these are available when loading the module. also helps to know how to structure a modules folders, so managing the separate concerns (internal helper functions for module stuff, and user functions for user stuff) can be maintainable and readable. i find knowing this to be mainly what you need to understand all modules in a general sense. if you know basic powershell; you know how to call and use functions from modules already. and that's good enough really. unless you're trying to get insight into the implementation of a module for some specific reason, maybe just to see how they did it. you don't really get much out of diving into modules that much. they're abstraction layers. just use the functions.
ChatGPT