I try to automate everything I can with PowerShell. Whether we’re talking SQL Server, WSUS, Active Directory, or any other product with active support in PowerShell, I try to write scripts to do everything. I believe in the old proviso that good engineers are lazy engineers (thank you, Andy Leonard). And lazy engineers try not to do the same type of work more than once. That’s why automation is key.
What have I automated recently?
- Restarting WSUS app pools in IIS along with the main WSUS service because, well, there are known performance issues that keep cropping back up.
- Checking Active Directory Federated Services services and making sure they are started (which they sometimes fail to do after patching).
- Exporting users and key security groups out of AD and into SQL Server, which makes that information more accessible for developers writing apps that need that information.
I’ve been asked recently how to get started using PowerShell. Essentially, it’s no different than learning anything else in IT.
- Have a problem you want to solve.
- Have a location to test (this is NOT production).
- Find some resources that give you insight into solving the problem.
- Try to build a solution.
- Test!
With respect to PowerShell, there’s a ton of resources. Of course, there’s the Microsoft documentation. And if you want that documented help locally, there’s a great cmdlet update-help. From there you can use get-help and the cmdlet to find out what the syntax is. If you use the -ex flag, you’ll get the examples. There’s also a large number of scripts and blog posts on just about everything you can think to do. Just do a search with your first keyword being PowerShell and then the rest of the search being what you’re trying to do. For instance, if you’re trying to figure out how to export data out of SQL Server using PowerShell, a good search to run would be: PowerShell SQL Server export data.
There’s no shame in starting with someone else’s script. Most folks do. I often do as well, even though I’ve been writing scripts for a long time now. It’s known as time savings. It’s also known as being a lazy engineer (see above). But don’t just grab a script and run it. Walk through it using the documentation. Try to understand what each line is doing. Figure out what you have to modify for your own environment. And most importantly, don’t be afraid to ask for help.
I can’t emphasize that last statement enough. You’re not going to suddenly be a PowerShell master because your Google-fu is sharp. And learning anything new takes time and effort and, sometimes, a helping hand. If you’ve tried and you aren’t getting it, ask. There’s no point holding on to your pride if you aren’t getting the job done, right?
On a closing note, yes, you can learn PowerShell if you don’t have a problem to solve. However, my experience is that I learn better when I have a goal. If that goal is solving a problem that’s causing me discomfort, I have greater motivation to get the job done. Therefore, try to think of what manual processes you’d like to get automated so you don’t have to deal with them any longer.
Want to learn more about PowerShell and SQL Server? Go here to the original hosting post. You should see links / trackbacks in the comments.
