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.
