Solving the hardest problems with powershell. Where to go next?

Sometimes you run into a problem and you don’t know where to go next. When I run into an issue, it often becomes an obsession for me to solve it. It is easy to say google it, but sometimes you need to be able to look at your problem from different points of view for google to actually help you. I have been wiring Powershell for a long time and this is how I tackle those hard to solve problems.

First use get-help, get-command, show-command, get-member, and Format-List * to try and discover a command and get information about object. The more advanced you get with Powershell, the more you will use these commands. So build that habit. (Run update-help to get the most recent updates).

Then turn to google. Something like “Powershell thing I am trying to do”. There are a lot of good samples and old samples out there. The old samples will still work but you may miss the new way to solve that problem if you are on server 2012/windows 8. This is why those first commands are important. If you want examples, get-help command –examples.

Then search for a command line way to do it. If a command or a tool exists, then that’s the easiest way. Depending on what I find, I may look at other solutions and come back to this one.

If this is a standalone application, figure out how it stores its settings. Registry, text file or database. Knowing this will give you a direction. I’ll mention how to flesh these out later if you are unsure at this point.

Then search for a WMI solution. Powershell and WMI play really well together. Windows is an API based OS and a lot of those APIs are exposed in WMI or CIM. People have been working with WMI for a long time and lots of examples exists. I solve a lot of problems with WMI. One I know the object to look at, get-member and format-list * help me explore it. There is also a show-object script floating around that may also help here.

Then google for how to solve your problem with the registry. The registry really controls a lot of things and I would bet a lot of the Powershell script for system configuration are just setting a value in the registry if it is not using WMI.

From here, I look for a VBScript or C#/.Net solution. If it feels like something an admin should be able to do, I will search harder for VBscript. Odds are that someone has solved this issue before. VBScript is easy to translate into simpler Powershell once you have done it a few times. C# and .Net offer a lot of power but you may be diving into some serious code at this point. You can take this to an extreme and look for Win32 API or system calls (rundll32 type stuff). This is never fun but sometimes that is where the solution is.

Another approach is using sysinternals to figure out how the system does what it is doing. Procmon is great. It watches every file change and registry change that your system does. So fire that up, and make your change. Then start hunting for what the system did when you make that change. If SQL is involved, then SQL profiler is also a must have tool.

Look for a GPO solution. If you can find one, remember that most of group policy is just setting registry keys. If there is an ADM file, you can dig into that for the actual key.

While you are doing your hunting, there are a few complications to be aware of. Is it a per user setting or a per machine setting. User profiles can easily be adjusted by the user, but if you are remote or running with different creds, there are often other roadblocks to deal with.

Also, there is nothing wrong with asking for help either. I just wanted to give you a direction. Even if this is all gibberish today. The more advanced you get at this, the deeper down the rabbit hole you can go. I have used every one of these techniques at some point to solve a problem.