Over the years many of us have built up a collection of handy tools to help with
system administration and troubleshooting. I thought some of you might find it helpful if
I gave you a peek inside my toolkit so I decided to write down a few... I wrote down close to 50!
We don't have time for that so here's what I'll do: I'm going to share a few of them in this video,
you're going to watch this video, and then you're going to tell me if you want more.
If you want more I'll give you more!
Welcome back to The Pro Tech Show. All of the tools in this video are free,
so you can integrate them into your toolkit without having to worry about licensing.
Depending on how you choose to count I'll either be showing you 7 tools, 8 tools, or well over 100 tools.
That's because the last tool is actually a helpful service that will itself give you
access to loads of other tools. A tool gateway so to speak. Make sure you stick around for that one.
Let's ease into this gently. The first tool I think everyone should have in their bag is 7-Zip.
Now i realise that basically any operating system these days can zip and unzip files, but IT pros
tend to deal with more complicated archives than just your standard zip
file. For one, the formats used in Linux and Windows tend to be different so you'll often
find yourself with say a Gzip file that Windows can't extract natively. That's why back in the
day when most people had dodgy copies of WinZIP the techies had dodgy copies of WinRAR instead.
I mean seriously, has anyone ever actually seen a licensed copy of one of those?
Comment if you bought it! Another reason is that as an IT Pro you'll often want to extract
individual files from self-extracting archives like installers without actually installing the
full program. 7-Zip can help you do that; and it can help you do it legally. WinRAR and WinZIP may have
become internet memes and given us all a laugh due to their never-ending trials, but we all know
that just because you can use an expired trial doesn't mean you should. If you install unlicensed
software on a company's devices or servers then you're putting them in a really dodgy position.
There could be legal ramifications or one day an auditor does a scan, finds it, and they fail to pass
a certification. Suddenly the tool you thought was harmless could end up costing you your job.
I find this all the time when working with new customers and there is no need for it. 7-Zip
is free, it's fast, it does everything you need. Just use 7-Zip and avoid any licensing problems.
The next tool I want to mention is the Windows SSH command. Hear me out on this one. Haven't you
heard of Putty or the Windows Terminal? Yes, and did a video on the latter. They're both
better than the built-in SSH command. Assuming you're on Windows Server 2016, Windows 10, or
later: the SSH command is built-in. It is amazing how many people don't actually know this. I'll
hear people grumbling about needing to access a switch or Linux server from a Windows box but they
don't have internet access to download putty... guess what? You don't need it! The SSH command is built-in
and enabled by default. If you're working on your own admin workstation use whatever SSH
client you prefer, but if you're connecting to other people's servers as a consultant or an MSP
then I think it's good practice to leave as little trace as possible. By that i don't mean cleaning
the logs behind you. Don't do that. That is dodgy A.F. What I mean is don't go installing your favorite
tools on somebody else's system just because you like them. It's their system, not your virtual
living room. Get your feet off the sofa! With servers less is more. The more software you put
on it, the bigger the attack surface. Anything you install, someone has to patch... assuming they know
about it, which they probably don't. The SSH command might not be the most fully-featured SSH client,
but it's always there for a quick connection and you don't need to download any extra files; so
don't forget about it. While we're talking about remote terminals let's talk about the
Telnet client. The Telnet protocol is old, outdated, horribly insecure, and you should basically never
use it. The Telnet client on the other hand is a troubleshooting Swiss Army Knife. On most Windows
and Linux systems it isn't enabled or installed out of the box but if this system has been around
for more than... I don't know... a week?There's a fair chance someone has already enabled it. The reason
the Telnet protocol sucks is it's just sending characters back and forth. There's no encryption.
Because it's so simple, though; the client can basically talk to anything that uses plain text,
and that is actually quite a few protocols - many of which has been with us for a very long time.
If i'm having an email problem I can point the Telnet client at the email server on port 25 and
strike up a conversation. This is how email started out and it hasn't really changed under the covers;
so I can type my commands and see what the server says in return.
Often the fastest way to see what is going wrong is just to ask the server directly. You can Google
the syntax if you've never done this before. It's actually pretty simple and will quickly teach you
why you should never trust the sender address on an email just by itself.
"Can I send you an email, please?"
"No, because I'm low on resources."
OK. Cool. Somebody go check disk space on the server and find out why we didn't get alerted to it.
The same thing works for POP, IMAP, FTP, etc., etc.
but probably the second most common use I have for it is HTTP. Yes you can just point this thing at
a website and talk to Google on port 80. Here's the HTML source for Google.com. Admittedly it's not
the most useful way to browse a website, but you can quickly see if it's responding or not and if
it's throwing an error. The one downside of using Telnet is that it's pretty useless if the other
end relies on encryption, and if the data you're transmitting is sensitive it really should do.
Although you can use the Telnet client to log into an IMAP server, if you did that you'd be sending your
password in plain text and that's a really bad idea! That doesn't mean it's useless, though.
The Telnet client is great for basic connectivity tests to a TCP port. If you can Telnet to the
port and the console goes black you know the port was open and listening. If the command hangs, though,
and times out; then... well... either the service isn't running, or you couldn't reach it. This is a great
way to check for network problems. If a local Telnet test works but a remote one doesn't,
then you knew the service was listening but something's blocking you from getting to it
at the network level. Probably a firewall, or maybe a routing issue. But what if you've got a connection
and you want to have a conversation with the server for further troubleshooting, but the service
requires encryption (as it probably should)? At this point unless you can type in encryption you're
pretty stuck with the Telnet client. Which brings me on to the next tool that you should learn to love:
OpenSSL. The OpenSSL library is responsible for a fair chunk of the internet's communications,
which is why the Heartbleed vulnerability was such a big deal. On Iinux, it's probably installed anyway;
and for Windows it's just a free download. There are two things i find myself using OpenSSL for
quite often. The first is related to the Telnet example. What if you need to send and receive
commands with an encrypted service? Just use OpenSSL's s_client. Google the syntax to open the
connection, and from there you can just type away as before in plain text. All of the encryption is
just handled for you. You can let it figure out what encryption to use if you want an easy life
or you can specify exactly what encryption to use - which can be handy if you want to
diagnose problems where two different sides are supporting mismatched standards. It's also a great
way to diagnose certificate problems because you can view the encryption certificates being used.
On a website this is no big deal because your browser will show it to you, but when you're having
problems connecting to something less visible (like maybe a phone system or an email server) then
there's often no way to simply see the certificate in the user interface. OpenSSL will show you.
Speaking of certificates... that's the second reason I tend to find myself cracking OpenSSL... um...
open. It seems like everything uses certificates these days, because encryption is a good thing;
but what they can't agree on is which format to use! Windows likes PFX files, Linux tends to like
separate certs and keys, and applications installed on top? They can use any old mixture imaginable.
With OpenSSL you can type a command and convert between them, so whichever formats you have your
certificate in you can always change it to whatever your application requires.
I know there are websites that will let you point and take your way through this, but
don't. Google the syntax and use OpenSSL. Certificates consist of public keys and private
keys. The whole point of it, the entire method by which we can trust encryption, is that you never
ever let anyone else see your private key. Share the public key with anyone you want - that's fine.
Never, ever give your private key to anyone. If you use a website to do the conversion you have to
give them your private key. That defeats the entire point of having a signed certificate in the first
place. If someone running that website is malicious, or they've been breached by someone malicious,
they can now impersonate you or decrypt your communications. The likelihood might not be
very high but there is no justification for taking that risk when a single command with a free tool
will just do the job for you instead. We're leaving the command line behind now and going
back to our Windows comfort zone. The next tool I'd like to share is WinMerge. WinMerge does a simple
but powerful thing: it compares files and folders and shows you the differences.
This is a great way to answer the perennial question of "What's changed?" or to reconcile
differences if two things get out of sync with each other. Let's start with the "what's
changed" scenario. If you have two different config files and want to quickly see how they differ,
load them into WinMerge and it will highlight all of the differences for you. This is helpful in
so many ways... Compare a live copy against a backup copy, or a working system against a broken system.
If I'm making a change, say I'm scripting something across a large estate; I will dump
the current state into a text file, make my change, and dump the new state into a new text file. Then
I'll take those two text files and compare them using WinMerge to verify the change I expected
is the change that happened ,or that there were no operational changes if that was the particular worry.
Consider the power of this. In Linux most of your configuration is done in text files,
and you tend to work in Bash which outputs text. In Windows most things have gone PowerShell which is
also outputting text, and everything in PowerShell can be exported to XML which is a text file.
The results of virtually anything you might need to do or check on a server
can be compared using WinMerge. The other way I'll tend to use it is to compare two sets of folders
that are supposed to be in sync, but aren't. The classic example here is Active Directory.
If people start reporting weird and unpredictable Group Policy effects
then it's usually a sign that DFS is broken and your SYSVOLs have gotten out of sync.
Simply point WinMerge at your domain controllers, let it compare them, and you can see which are in
sync, which aren't, and where the latest versions of each policy are. Staying within the Windows world,
let's talk Sysinternals. If you've never used one of the Sysinternal tools, do you really work in IT?
Sysinternals is a collection of tools and utilities for managing and troubleshooting Windows.
Originally they were produced by a company called Winternals, but in 2006 Microsoft decided "Hey,
those tools are pretty good and everyone seems to use them. We should probably just buy the company."
There are loads of tools in this collection and you've probably seen or used some of them
without even realising it. Ever worked somewhere and noticed the desktop had a readout of some useful
information about the computer, like its name and its IP address? That's BgInfo and its a
Sysinternals tool. Seen an admin with remote desktop connections all organised into a hierarchical
dashboard type of thing? That's probably RDCMan, another Sysinternals tool. As I said, there are
lots of tools here, but the two i wanted to bring to your attention in particular are PsExec
and Process Explorer. Process Explorer is like Task Manager meets Chuck Norris. It lets you dig much
deeper into processes running on your system and if you ever find yourself struggling with a locked
file but no idea which process is actually using it, Process Explorer can help you find the answer.
I don't find myself reaching for this much these days, but back when I worked on a service desk
I'd use it a lot. Sometimes turning it off and on again isn't the best answer -especially for
a production system. If you can track down that pesky file lock without resorting to a reboot
you can get that ticket closed pronto without the need to wait for a maintenance window.
The other tool I've used quite a bit is PsExec.
This lets you run commands on another system, which has all sorts of really useful applications.
You can make changes remotely without bothering users. You can apply them at scale by scripting
them - even if there is no native remote management for whatever system you're trying to access,
because PsExec takes the commands and runs them locally on the target system for you.
These days you can achieve a lot of the same thing using PowerShell's Invoke-Command or
its PSSessions. PsExec predates that but it hasn't quite been replaced by it yet. There are
two scenarios where PsExec is still really useful. The first is to avoid Berberos double-hop problems.
When you connect to another system using PowerShell, you authenticate to it and you send your command.
What if that command needs to run an authenticated execution against something else? That is a double-hop;
where you authenticate to one thing, which then authenticates to another. The problem with
that is Kerberos will not allow you to do it without some very specific configuration.
This can cause PowerShell scripts that ran perfectly well locally to fail if you try and run them remotely,
because you've added a second authentication hop. PsExec sidesteps this problem by launching
your command locally on the target system; so when the command authenticates to something else that's
only its first hop, not the second. The second thing about PsExec that is really useful is
its ability to run as the local system account. Forget your administrator account. The system
account is the one with the real power. This is helpful to fix "unfixable" permissions problems,
or to get into that part of the registry that Windows didn't really want you to get into,
or if you need to authenticate on the network as the computer account itself. That last part can be
really handy to troubleshoot permissions problems, or to test things like Group Policies or startup
and shutdown scripts that ordinarily run in the context of the computer system account before
any user actually logs in. Those are the two Sys internal tools that I've used more than any others;
but before I go I want to show you something else. It's called Sysinternals Live, and it's less of
a tool and more of a service; but still free. If you type live.sysinternals.com into a web browser
you get this rather basic directory listing of all the tools. It's a handy no-fills way
to access them. You can pull any of them down quite easily from a script as the latest version
is always available at live.sysinternals.com/TheNameOfTheTool; but it's
more than just a website. It's also available over the internet as a plain old SMB file share.
You can enter \\live.sysinternals.com\tools and they're all right there.
You can copy-paste them. You can even run them directly from that file share.
That works from the command prompt, too. Look how easily I can get my command prompt to run
as the Windows system account. Not only is this a handy way to get hold of the latest version, but you
can incorporate it directly into your scripts. As long as you've got internet access you don't need
to distribute copies of the tools along with your script. Your script could simply pull them
down, or even run them straight from the file share. Of course you might not want to do that.
In the wake of ever-increasing supply chain attacks maybe pulling down and running code from a
file share on the internet isn't the ideal way to run privileged scripts - especially ones that you're
going to leave running unattended for the long term; but there's no denying that it's pretty handy.
Now it's your turn to give me some feedback. I've mentioned a few tools here, but as I said at the
start I have quite a list of them. Let me know if you found this video useful and if it does
well I'll post more. You can of course improve those chances by liking, sharing, and subscribing;
and why don't you use the comment section to share your own favorite tools as well?
I'm quite interested to see how many of the ones you suggest already on my list. Maybe
you'll suggest enough new ones that I've never used that'll end up doing a "Viewers' Suggestions"
episode as well. That could be quite fun I think! Anyway, that's the end of this for today.
Thanks for stopping by and thanks for watching to the end. See you next time!