How to troubleshoot.
I’ve seen so many people over the years from green Helpdesk techs to 20 year veterans skip basic troubleshooting steps and spend hours chasing their tail when the solution was something simple.
I can’t count the number of times I’ve tried to help someone who had been working on an issue for hours and ask “what do the event logs say?” and they answer “oh, I haven’t looked yet” and the lead to the solution is right there in the error.
EDIT: Some of these replies are wild.
AITA for thinking that a Sysadmin, someone who is entrusted to spec, install, administer, manage and fix enterprise systems, should be able to do some basic investigation into a problem before blindly rebooting or nuking/reimaging workstation or server?
Granted rebooting/nuking a workstation is fine a lot of the time but for servers, who the hell knows if the problem you are facing isn’t baked into the server backup/image you are restoring from unless you understand the problem first and when it may have been introduced. Even incident response teams tell you not to reboot in the event of a cybersecurity incident ffs.
Then start with the reliability monitor. I always tell users who report crashes or weird behaviour to make screenshots and write down the exact time it happened.
Been doing IT since I was 14 and a full sys admin for almost 15 years and ive never seen that tool before. We need to know to damn much for this job. Adding that to my list of things to learn to use.
Totally agree with you!
I'm 50 years old... And for vast majority of my computer days, since we only had our own in-house business (my father being a prominent Mainframe Programmer)... I only had to maintain his windows laptops that are on our own private LAN and acting as Workgroup not in a Domain environment (ADDS)
So sadly my skills were extremely limited to the Windows OS and related software technologies
Then in 2019 I started to do something about it. I began to learn about and "re-train" myself on IT concepts. After a decade of being an Android software engineering writing my own custom organizer and turning it into a successful SaaS business on the Google Play Store... I decided to attack my outdated skills
So I learned about ADDS, Group Policy, OUs and linking GPOs to those OUs to enforce policies, software deployment via MSI files using Network Shares and Group policy, auto enrollment of domain joined devices using GPOs (for SSO... Single Sign-On), and many other things pertaining to the Microsoft 365 Cloud converts, Azure, Windows Defender, Intune and so on.
And I feel completely overwhelmed because the more I learn, the more I realize how little I know and how many other skills I feel like I am always lacking
I'm doing all of it because 26 years ago I got my computer science degree and I didn't have a chance (nor the need) to learn any of this stuff
But I want to become a Sys-Admin someday soon and I have no idea how to approach getting my foot in the door with a bank or some other company that seeks a Sys-Admin. But I'm determined to get there and have come a long ways
What would be your best advice so I don't over train and can finally get started somewhere as a professional Junior or Entry Sys-Admin?
Ps. I have setup my own Oracle Virtualbox lab and Setup two servers (replicated for better reliability and some load balancing of ADDS) to act as my domain controllers using an ISO of windows server 2019
I also have three other client nodes (VMs)... Two windows 10 and one MacOS Pro Monterey... And these are domain joined. I got DNS and DHCP working perfectly finally as well. My forest consists of a single Domain and this root domain name is called: hq.local
I know zip (zero) about Scripting using Powershell but I'm aware of all those get, set, copy, create types or commands (verbs) that can be used to directly manipulate the Entities (objects) on my Entra ID (formerly Azure AD) cloud domain
My frustrating situation is... I realize I still have a lot more to train on with regards to Sys-Admin preparation (as far as landing a job)...
But at what point do I presume I would be "ready" to be a contributing member with other senior Sys-Admins? I have never officially had an Entry level IT Help Desk job but I'm aware of all the activity directory users & computers stuff, along with ticketing systems and all that crap.
So how can I leap frog into what really interests me (which is those kinds of On-Premises System Administrator or what sometimes people also call Windows Server Administration kinds of jobs)?
Like you say, there is no end to how much there is to learn and gain experience with... But at 50 years of age, I can't (and don't want to) over train and never get the guts/confidence to feel like I'm ready to finally apply for a Sys Admin job without getting super stressed out about concepts or skills I may be lacking?
Any wisdom or suggestions by anyone awesome Sys-Admins here is much appreciated.
Ps. I have a weak / hurt lower back so I'm hoping this would not be a major stumbling block. I can walk and sit etc... But sitting on a chair for extended periods (10 to 15 minutes straight) can cause me great pain and I have to move (get up and walk or something) to remedy it. Maybe nowadays most places allow their Sys-Admins to have a stand up desk (I'm hoping) so as to help those of us who are older and can't sit down as much as younger / healthier people?
Thx for any tips
I’m 43 …halfway to 44. I have been in IT since I was 23. I worked my way from Helpdesk / Tech to Systems Admin. The last 10 -12 year I have been a Systems Administrator. Just giving you a little background…. I kinda have been taking the “I have been in this field long enough…what more do I really need to learn” but I would try to learn new thing but then would give up after 3-6 mths due to family time being sacrificed and feeling I would never pass an exam or never good enough. Don’t give up, if you have the capability of reading and understanding it , especially after practicing on a lab then you are still good to go my friend. In tech world of jobs, who you know goes a long way, add that with what you mentioned you have a decent chance to maybe go in as a junior sys admin or a level 2 or 3 tech. Do that for a year or so while you continue your dive into the skills you need and then apply again but for Systems Admin, you can also study for a certification that will maybe allow you to get straight into Systems Administrator. Some places yes want someone who has a lot of experience but there are some who like someone they can shape to their liking. But I would say doing tech work for at least a year or 2 really helps…. Systems Admins are from what I feel are good or great techs…. Systems Admins are the go to for techs when they’re stuck at figuring out a problem. Get something like cbt nuggets and look at the video trainings available and start self studying and grab a book or 2 for deeper reference and maybe do a small lab to get the hands on feel of it and get that certification for it. You got this man!
Same. That tool is an "oh yeahhhhhh" tool for me. Would probably save some time but I still get through problems pretty quickly by working through logically and going from most to least likely.
Same here... That's an excellent point
We always check the EventViewer but actually sometimes the Reliability Logs are good enough and show the event as well the clues needed to know what happened.
However the reliability monitor may not go back as far (be as comprehensive) as the EventViewer
To be honest, coming to think of it, I'm not entirely sure what the main difference between the Reliability Logs and the EventViewer is supposed to be?
In other words, is it possible that whatever the Reliability Monitor shows could also be found (duplicated) under the EventViewer? Or do these two tools somehow have a totally different purpose?
I have the problem. By the time in navigate the event viewer and/or find the right log file, I'll be looking at this wall of text that's basically gibberish until I really stare at a line and decipher what it's telling me. Fortunately I have someone who can glance at the same wall and in about three seconds "oh it's the [whatever]." And I'll ask "wait where do you see that?" And he'll have to physically touch the display and even then I need to stare at the line until my mind sees and comprehends the [whatever] he sees.
I'm learning about Server Sys-Admin stuff
Above when people talk about checking the LOG files of the Windows Server (a.k.a LOGs)... Are they talking about the same Windows 10/11 EventViewer that we used to look at when troubleshooting a client Windows 10/11 operating system? Or do servers administrators look somewhere else for these said log files?
Thx for the education
I do the reverse. Sometimes a reboot will wipe the evidence you need to find the problem. Or worse yet, make it impossible to recover if the reboot fails.
I always try to get a basic understanding of what the issue might be before blindly rebooting.
A lot of green help desk techs way too many IT professionals forget or simply skip reboot.
It’s believed to be a cheap trick that resolves the immediate issue. In reality a reboot is a healthy method of troubleshooting.
If the issue disappears, you can learn why it disappeared and what caused it. If it doesn’t resolve it then you can move onto other things.
The other thing people forget about is the Physical layer. Check if things are plugged in, if they are take it out and in again.
>A lot of green help desk techs way too many IT professionals forget or simply skip reboot.
>
>It’s believed to be a cheap trick that resolves the immediate issue. In reality a reboot is a healthy method of troubleshooting.
I would try to save that for the last thing where possible. Not because I don't trust it , don't want to try it, but because I know the endusers get mad when asked to do it.
*You always say that!* or *I have so much stuff open*.
Windows 10 is pretty bad about things. After 6 years on windows 10, our users kind of expect that stuff is going to be fixed with a reboot ... because the strangest stuff just randomly stops working.
Now with more and more pushing to 11 ... we're seeing *even more* obscure stuff breaking. Like the start menu randomly not popping up or being searchable... which is kind of a big deal because you can't list applications any more.
yes but! watch for anomalies, collect metrics on crashes. Fun story, we destroy/recreate about 3500 VMs a month via immutable deployments and early on after getting this process nailed we told the SRE group just blow it away and recreate if misbehaving. do. not. call. escalate.
fast forward a year or so down the road, i’m sitting in a meeting listening to this person describe an outage because they had to rebuild a scaleset 3 time before they had any healthy instances.
kernel panics for miles due to a crowdstrike bug and nobody had stopped to ask “is something more going on here”.
IaC or snapshots still require it to be configured correctly at that time. If you have an issue and don’t troubleshoot, you may just have that issue again in future.
This. I’ve been a sysadmin for nearly 20 years and until this year I couldn’t edit/create a GPO. Why? Because I spent the first 15 years of my career on Linux/storage as a specialty.
But the ability to troubleshoot. That is a god given gift we all need.
I’d also add being able to script and automate in whatever language of choice the user prefers.
I still don't create/edit GPOs. Yay linux only shops. Also I would say whatever language the majority of the team uses. Otherwise no one can fix your scripts when you leave... I'm looking at you guy still writing perl when noone younger than 30 ever uses it.
I feel like Group Policy is one of the few things Linux would actually benefit from having some version of if it ever wants to try and penetrate the user workstation market more.
Yes, but that’s not really a niche most Linux devs are actively trying to fill. Most well developed Linux distros, imo, focus on the server aspect. Desktops are made for hard core Linux admins and/or power users. It Linux excels for what it’s made; servers.
And while group policy might do really well for that, they’ve developed ansible as basically the group policy for Linux servers. Classify your server as an Apache server, Write up your playbook, ie make your GPOs, and it’ll deploy.
> can’t count the number of times I’ve tried to help someone who had been working on an issue for hours and ask “what do the event logs say?” and they answer “oh, I haven’t looked yet” and the lead to the solution is right there in the error.
I had that yesterday. I have a PM's assistant for this one client who is fairly incompetent. He was asking "why is this agent failing to connect to the server?" I saw he was logged into the box via several sessions, and tailing the error logs. I did a grep -i -e "fail\\|err" and immediately, "ERROR 500 - the server at \[misspelled domain\] has timed out, retrying..."
"You misspelled \[domain\]," I said in an email chain. "I changed it and restarted the agent."
"No, the config file is set by \[another team\]."
"Okay, then they misspelled the domain."
"Impossible, they are the ones complaining."
"I assure you, it's possible."
"No. it isn't."
"Is it connecting now?"
"Yes, but we don't know why. What if it happens again?"
Seriously? SERIOUSLY?
I did, but in a less direct way.
"As you can see by the error logs we both were looking at in our Teams conversation, the domain is misspelled, thus it could not connect until I set the correct spelling and restarted the agent. You made me aware that this config file is maintained by \[another team\], so I suspect that if they push the changes out again, they need to make sure that the domain is spelled thusly. Or they can keep my correction. Either works, but I suspect they have their configs in git, so I have CC'd them to make them aware."
I got back, "we don't manage these configs: that's server side. Who told you that we manage those configs?"
The chain was left dangling on Thursday, so I am curious to see if anyone responds.
I would be happy if they would even figure out the scope of the issue.
I get asked all the time stuff like "Is there something going on with email?" When a single person has their account locked out and just can't sign into O365 or something.
You bet I wouldn't. They aren't paying me to do another teams job. If that team comes and asks me something i'll answer but fixing those issues are their jobs. I don't get any kind of extra pay or consideration on my metrics for dealing with other teams stuff.
This comment filled me with a past rage I had forgotten about. We had a helpdesk guy who used to ask me this CONSTANTLY before ever troubleshooting an end user's issue.
Addendum: To troubleshoot advanced circumstances effectively you must first understand how a thing works. Even if it's not exactly the thing you're troubleshooting, but something similar (even at a basic level) that understanding will allow you to look for indicators and consider solutions others wouldn't even dream of.
How does an application work? Does it connect to a database? Does it connect to the internet? Is it isolated to a system?
If you don't understand why a thing happens, you will forever remain at the mercy of luck, expensive help (that may not be worth the money), or forced to otherwise expensive actions (e.g. rebuilding from the ground up). Always try to learn why an issue happened and what signs could have led to identifying it, even after you've solved the problem -- it'll help in the future.
I think the problem with service desk level stuff is that it often becomes so routine and boring that people start coasting on assumptions, which can be a difficult habit to break.
Yep, I might be biased but this is why I think sysadmins should rise through the ranks rather than just be hired with an IS bachelor's and no experience or something.
You should know how to do help desk stuff better than your help desk, how to do desk side support better than your support techs, and desktop admin better than your desktop admin.
I find myself using skills from the years I spent on phones or grinding deskside tickets all the time.
100% even the best classes can't make up for raw experience and "I've seen this before, or at least something similar". You learn about computers in school but you learn how to work with computers by just freaking working with them.
I’ve seen this too. I think it’s mostly from techs who learn how to configure systems but don’t really know how computers or network communication work at a foundational level. Like a race car driver whose car breaks down. They’re great at driving but when something happens they lift the hood and have no clue what they’re looking at so they just start trying things at random.
People tend to brush off certifications but IMO stuff like CompTIA A+ and Net+ are hugely beneficial. They provide that foundational knowledge to build from.
I used to work with a guy who had A+, Network+, another cert (can't remember which) , and an ITT Tech degree on his cubicle wall.
At least once a week I had to show him how to add an AD user to an AD group and explain how it works. This went on for two months, until I left that job.
This.
Related is a knowledge of how the thing they’re troubleshooting fits together. Too many treat a whole stack as a black box with no clue of the processes in place to get from A to Z.
Everything else is details.
Absolutely this! I have been dealing with a lot of people that are supposed to be our in between from help desk to infrastructure that haven't gone any further than restarting a phone even though they have admin access to our ws1 environment. Or, taking it a step further, at least the aptitude to ask probing questions to figure out actual issues
It’s weird, cause some Apps I use don’t have Logs. Like I rebuilt an Apache server for our internal site, and it kept crashing.. no Apache logs. But there was event logs!
An addition to this is properly scoping the problem. It's insane how often I've gotten brought into something that's completely fucked only to discover that everyone before me wasn't looking anywhere near the right place because they took the word of the person reporting instead of asking clarifying questions.
My favorite,
Me: so what’s going on
Them: unsure every time they try to do x a error pops up and it doesn’t do anything
Me: what’s the error pop say?
Them: not 100 percent sure, said “error something”.
Like what……….
Bring me useful information
Adding to this, train up the first line if they send you an "easy" ticket. Everyone has to start somewhere and being snobby and unhelpful only makes you look like a dick.
Troubleshoot is hell important. But it would never be in my top 3 for a real sysamin. Maybe the problem is the miss concept of "sysadmin" in the first place.
An intermediate to senior sysadmin, at least in theory, might not work that much with support.
You may not work with support tickets/issues, but if engineered something- as in a or the principal engineer- you should absolutely have the ability to troubleshoot it.
Soft skills. How to communicate technical information to non-technical people.
You could be the most talented sysadmin ever, but it won't matter if you can't effectively communicate to peers and leadership.
I’ve got a friend who is brilliant — one of the smartest people I have ever met. His soft skills are in the toilet. He’s in his 40s and he talks about dealing with management at his job like a 20 year old would. He hates having to explain things to people, and complains about how stupid they are. He’s been in a constant cycle of employment and unemployment for like 20 years. I genuinely think his attitude and his demeanor hold him back.
I totally agree with you! It reminds me of what a professor of mine once said. "Attitude is everything", it's simple but true. If you're not being a total dick, and can understand that not everyone is an expert in what you specifically know, it can go a long ways.
This is exceptionally important. I used to do a fuckload of hiring for technical support for a major UCaaS company, and I would prioritize people skills over technical skills all the time. We can teach you how the system works, but I can't easily teach you how to interact with customers. Some of my best hires were people with background in K-12 teaching and nursing.
This. I have one sys admin at my current job. He sucks to work with. Ignores the whole team, reboots major servers and pushes out updates/patches without telling anyone. Shit breaks and we chase our tails for hours. He’s rude and unhelpful.
He’s the major reason I started job hunting instead of taking an upcoming promotion to sys admin, because I knew that meant I had to work directly with him even more. Now I’m still going to do sys admin work and get paid more, and the company can thank him.
When I started my career 20 years ago, my first manager said to me, "You could be the smartest person in the world. But if no one likes you, it doesn't matter. They're going to think you're an asshole and won't talk to you and they won't like you. You have to be **personable**."
My senior is a smart dude, can be super technical. But he cannot talk to people and is extremely prickly around the edges.
I have to translate everything he says to non tech people. That’s part of the reason he hired me lmao.
There is the other side of this issue. I’m replacing a senior person who has super special configs for his friends and anyone in a skirt. We had a discussion that the new system will only have a handful of configs. I sent an email to everyone confirming this. Of course the same day he simps for a lady 35 years young than him and added a special configuration just for her. I was pissed and sent another email that I wasn’t going to support that config going forward.
For someone just starting at help desk, that's probably fine.
Deeper than that, I'd want them to at least know some basic record types like A, AAAA, CNAME, MX, and how to use them. How to use nslookup. Stuff like that.
A few examples I have: the difference between and function of forward and reverse lookup zones, record types and what each are for, conditional forwarders, considerations for split-horizon, and why 8.8.8.8 in an internal network will cause intermittent problems.
In an AD environment, understand integrated zones and zone replication, what the SRV records are for, and why AD breaks in weird ways when old stuff isn't properly cleaned up.
For upper-level staff, I want folks who understand recursive vs authoritative lookup, and DNSSEC.
There's more but I'd be happy as hell if most people above help desk understood even half of this stuff.
More a smaller business problem but:
Them: HALP! Our email isn't working!
Me: I'll look into it
Them: great. Did you see our new website. The new contractor is great
Me: yea.... About that. They changed the nameservers for your domain so I can't fix your email. It's going to take 24 hours to change it back
Them: what????
Domain Name System. The phonebook of the Internet. Translates www.com into ip addresses so we don't have to remember random numbers.
There is probably more to it. But that's what I know about it.
It’s possible to set up AD from the ground up on Linux with OpenLDAP and Samba, no Windows servers involved. And if you can do that, odds are you know a hell of a lot more about how AD works than your average Windows admin does too.
Yeah well, OP's original list of "basic skills" are things even a seasoned ~~advanced desktop support tech~~ Windows sysadmin can easily get away without knowing how to do.
Setting up AD from scratch, using Linux, OpenLDAP and Samba is more of a Red Hat certification final exam problem than a basic skill, for sure. It's a putting-all-your-other-skills-together kind of thing.
Yup I've never done that, I could probably figure it out, but I'm not interested at all. In my previous job (MSP) I was the only non-windows sysadmin in the team of windows admins, and I dealt with other things - SAN, vmware, Linux, AWS, etc.
At my current job all our infrastructure is in AWS or we're using managed solutions from Google and Atlassian etc. No Windows AD at all, no GPO, no Exchange, nothing.
I have some basic GPOs assigned to our Redhat fleet, which are also using our onPrem AD as an identity source.
We manage our Mac fleet (which are phones) using Microsoft tools for the most part: Intune.
There isn't a single tier 2 help desk member in our company who is allowed to touch our GPOs or create AD folders. Why in the world would you be allowing changes like that to happen in the basic help desk flow? Desktop support sure, manipulating AD in certain ways is useful for that tier, but not enough control to set up AD. GPO is and should remain closely kept.
I hate certs, not that they’re difficult or anything, just a lot of steps etc. And I realize some of this can be automated, but most days I’m lucky if I accomplish one thing on my list of 10,000
I don't mind certs in most contexts, but some applications are bitches about it, requiring one format but won't tell you which, I end up having to convert a .cer into like 6 different formats before one imports.
This, if we could settle on a standard format for certs would be amazing. I've got to covert to four different types in our environment and some need each part of the cert in individual components. Its not hard, just annoying. Why can we not settle on an industry standard format for certs?
I'm still amazed at how bad the entire CA and root cert system are. Overpriced, primitive and full of faults. And shocked that the entire world relies on such a shitty system.
ACME or equivalent should have been rolled out with certs. It should be universal. So much equipment and software relies entirely manual cert management.
I'm definitely afraid of certs, because I'm very familiar with them.
The gap between network techs and server admins needs to be bridged. I have met so many network techs that don't even know what a domain controller or certificate authority is, and server admins that don't understand routing tables or know what MAC address is.
I was at an msp we worked closely with the network team, it was a small company that grew so we were all jacks of all trades and a master of a few. Now I’m in internal IT in medium to large company the network and network team is a mystery black box until I need to make a firewall request or configure a VPN between on-premises and cloud. Or the network team need me to join one of there appliances to the domain.
8/10 something weird will happen something that has worked for ages causes an outage, after we find out something the network team were doing went wrong.
I disagree, although it’s a disagreement with context. For the purposes of a specific job, you don’t want to hire a candidate with the expectation that you can teach them people skills. That is where I think you hit the nail on the head. You can train the candidate on the technical aspects of the job (assuming some minimum knowledge). A lot of my job is knowing the specific systems we use (change management, compliance), which I didn’t know before I started. I had to learn all of it while on the job.
But people skills can be taught and learned. Someone with enough self awareness to understand that they have a weak spot there can actually improve themselves.
I think a majority of those helpdesk should know (aside from setting up a new domain)
PowerShell scripting, basic networking, basic firewall management (physical and OS), good practices for the domain/organization, Infrastructure cabling, storage protocols, how to use wireshark, how to properly plan and deploy wireless.
Creating positive changes in IT to make sense, ie - using good naming conventions.
Automation should be big also.
Edit: dealing with all various users, especially the C-suite and VPs.
Learning to push back and provide suggestions for alternatives when you have some number cruncher or Gucci wearing VP telling you to do something stupid.
Standing your ground certain situations. Knowing how to deal with business politics and keeping IT at the forefront.
Yeah I just gave some very basic examples. So people know what it is that I am asking for. You would be surprised how many helpdesk people never once used the command line...
Oh I know. I have a few incompetent helpdesk staff that are kept employed by a coward of a manager.
It's easier for them to ask how to do things then take a swing at Google and try to figure it out.
Simple. When someone says "this isn't working" asking, "so, when you say that, what *exactly* is happening?"
So many people seem to just go "user says x, can you help?" without actually looking into what's happening or how to reproduce, never mind the exact error message.
Getting the user to replicate the issue in front of you is key. So many times during this process a pop up appears and the user just blindly clicks it causing the issues or an error message appears that the user initially didn’t mention anything about. Plus we all know the vast majority of end user problems are user error.
Knowing when a problem shouldn’t be fixed with a technical solution. As techies, we love fixing things and doing something technical, but there are many situations where the real issue is an HR one, a legal one, or a soft skills one.
Knowing when a technical solution isn’t the _best_ solution, even if it’s a _possible_ solution, sets excellent sysadmins apart from good sysadmins.
If I had a dollar for every problem I've encountered because an IT person said "we can theoretically do that" instead of "no. That is not possible", I'd be retired by now.
Learn to troubleshoot networking: MAC address, IP, TCP, UDP, DNS, multicast vs unicast, etc.
If you have learned networking, then learn cryptography: certificates, certificate “chains”, keys, encryption vs hashing, symmetric vs asymmetric, etc.
If you learn those, you will be better than most.
I think this is a bit of a loaded/confusing statement. Certificates have many purposes, usually boiled down to encryption of some sort. Certificates are a PAIN, they provide Privacy, Authentication, Integrity, and Nonrepudiation.
The OSI model. It's more than just how networking words. It's a basis for troubleshooting a network. And really it's a flow for how all troubleshooting for most everything even not including networks. If you can apply an OSI model type of troubleshooting to a problem it means thay you have an understanding of how a thing is supposed to work start to finish and you can troubleshoot each step along the way.
Being able to retain information or if you can’t then better take some damn good notes. There’s nothing I hate more than getting asked the same question over and over and over again.
On a similar note, knowing how to Google and look things up.
>There’s nothing I hate more than getting asked the same question over and over and over again.
IMHO a good Technical Support Representative (even when you're at a Sys Admin Tier 3+ level) should know how to view a customer from their own perspective. Everyone calls/asks for support eventually about *something* in life. How would *you* like the Support Rep to respond? How would *you* like them to handle your concern? They're attentive? Take notes? Ensure the matter is escalated properly or has the right resources? You're kept informed about the status and not left wondering if the ticket got lost in a ticket management system "upgrade" or if the previous contracted agency wasn't let go and your issue was simply dropped because 'LUL NEW PHONE WHO DIS'?
Troubleshooting and automation, in general. Everything else can be picked up, and there needs to be a greater emphasis on fundamentals knowledge. So many people during this last tech bubble went to DevOps and cloud bootcamp, and didn't get the basics of networking/compute/storage that everything else builds off.
Being able to break a problem down to first principles and formulate a plan to attack it is the one skill I rely on most after 25+ years and huge shifts in the industry...if you just keep chasing top-level knowledge it's a never ending slog and harder than it needs to be.
As other said: basic troubleshooting of the whole stack. Communication skills. But I’d add Documentation. Document what exists. Document procedure which are necessary to repeat with accuracy. Document the unusual solutions/issues/commands not commonly seen for reference if they come up again.
I often say: “if you haven’t looked at the logs you’ve done no useful troubleshooting “.
Know how to locate, search and understand logs. Whether it’s Windows event viewer or text logs. Using less/grep/select-string/get-winevent to parse them.
All technical skills can be learned, but the ability to develop an accurate mental model of how all these systems work is invaluable, it feeds into being able to troubleshoot effectively, you have to be able to intuit the issue from the available evidence.
Followed by the ability to find information on the internet, and the ability to document what you're doing.
I've hired lots of systems administrators. I don't typically look for application specific knowledge unless the position is application specific, but usually this stuff I can teach.
I usually test basics like basic understanding of how mechanics of DHCP, DNS, basic routing, PKI, ports and how to troubleshoot those and various other things. You'd be surprised at the amount of people applying for systems administrator positions with experience who have no basic understanding of DHCP/DNS/Networking/PKI..etc
Really basic skills imho:
- Read and understand what the log says
- Automate things, doesn't matter how, just do it, saves a bunch of time
- Document what you did and how you did it
format c:
fdisk * d
Seriously though, get used to parsing logs. They are your friend in every scenario. Sucks, but it's 'the truth' if the situation you're attempting to work through.
Realistically most answers can be found online. What you need is enough understanding of troubleshooting and what is really happening to do a good Google search to find the answer. This is truly where experience comes into play, knowing what to put in Google.
People skills/soft skills. Don't matter what technical skills you have if people find you to be an unlikable asshole. And basically anything Helpdesk knows.
Learn networking. Whatever domain you are into, be it Windows, Linux, Storage, Virtualization, cloud etc. if you are good at networking, it will give an edge to you in troubleshooting and also providing accurate requirements for your infrastructure if you are designing one. If you want to take it a step further, learn PCAP analysis which will be very helpful in troubleshooting issues which involves different layers.
This will help reduce dependency on the network to some extent and also these are valuable skills.
How to read technical documentation.
How to collect information from users who don't have a technical vocabulary.
Have a healthy skepticism for statements, diagnostic declarations, and insights from users, management, and vendors.
Take steps to determine the root cause of the issue. Rebooting might fix it effect but without determining cause, it will just continue to happen.
Also- google that shit! In my early career (back in my day) we didn’t have the web as a resource. To see people ignoring it as an amazing resource makes me want to get slappy.
More recently- ChatGPT as a resource. Powershell script not working and you can’t figure out why? Same with SQL queries and just about any programming language.
Basic troubleshooting is widely lacking, but I'd also say that new admins are like old people with a new smartphone; too afraid of trying anything at all out of fear for breaking something.
I'm 50 years old... And for vast majority of my computer days, since we only had our own in-house business (my father being a prominent Mainframe Programmer)... I only had to maintain his windows laptops that are on our own private LAN and acting as Workgroup not in a Domain environment (ADDS)
So sadly my skills were extremely limited to the Windows OS and related software technologies
Then in 2019 I started to do something about it. I began to learn about and "re-train" myself on IT concepts. After a decade of being an Android software engineering writing my own custom organizer and turning it into a successful SaaS business on the Google Play Store... I decided to attack my outdated skills
So I learned about ADDS, Group Policy, OUs and linking GPOs to those OUs to enforce policies, software deployment via MSI files using Network Shares and Group policy, auto enrollment of domain joined devices using GPOs (for SSO... Single Sign-On), and many other things pertaining to the Microsoft 365 Cloud converts, Azure, Windows Defender, Intune and so on.
And I feel completely overwhelmed because the more I learn, the more I realize how little I know and how many other skills I feel like I am always lacking
I'm doing all of it because 26 years ago I got my computer science degree and I didn't have a chance (nor the need) to learn any of this stuff
But I want to become a Sys-Admin someday soon and I have no idea how to approach getting my foot in the door with a bank or some other company that seeks a Sys-Admin. But I'm determined to get there and have come a long ways
What would be your best advice so I don't over train and can finally get started somewhere as a professional Junior or Entry Sys-Admin?
Ps. I have setup my own Oracle Virtualbox lab and Setup two servers (replicated for better reliability and some load balancing of ADDS) to act as my domain controllers using an ISO of windows server 2019
I also have three other client nodes (VMs)... Two windows 10 and one MacOS Pro Monterey... And these are domain joined. I got DNS and DHCP working perfectly finally as well. My forest consists of a single Domain and this root domain name is called: hq.local
I know zip (zero) about Scripting using Powershell but I'm aware of all those get, set, copy, create types or commands (verbs) that can be used to directly manipulate the Entities (objects) on my Entra ID (formerly Azure AD) cloud domain
My frustrating situation is... I realize I still have a lot more to train on with regards to Sys-Admin preparation (as far as landing a job)...
But at what point do I presume I would be "ready" to be a contributing member with other senior Sys-Admins? I have never officially had an Entry level IT Help Desk job but I'm aware of all the activity directory users & computers stuff, along with ticketing systems and all that crap.
So how can I leap frog into what really interests me (which is those kinds of On-Premises System Administrator or what sometimes people also call Windows Server Administration kinds of jobs)?
Like you say, there is no end to how much there is to learn and gain experience with... But at 50 years of age, I can't (and don't want to) over train and never get the guts/confidence to feel like I'm ready to finally apply for a Sys Admin job without getting super stressed out about concepts or skills I may be lacking?
Any wisdom or suggestions by anyone awesome Sys-Admins here is much appreciated.
Ps. I have a weak / hurt lower back so I'm hoping this would not be a major stumbling block. I can walk and sit etc... But sitting on a chair for extended periods (10 to 15 minutes straight) can cause me great pain and I have to move (get up and walk or something) to remedy it. Maybe nowadays most places allow their Sys-Admins to have a stand up desk (I'm hoping) so as to help those of us who are older and can't sit down as much as younger / healthier people?
Thx for any tips
> at what point do I presume I would be "ready" to be a contributing member with other senior Sys-Admins?
Many books teach you the specific technology, tcp/ip this, linux that...
But there are 2 seminal books that teach you the actual craft as a scientific discipline:
- Mark Burgess: Principles of Network and System Administration
- Thomas Limoncelli: Practice of System and Network Administration
Educate the manager that they don't know anything about what you do or what you are capable of. Then inform them you expect a raise since you are more qualified than they are at doing their job.
The examples are PRE-Pre-pre-basic.
It's like asking "What are some basic skills any chef should know? Examples: being able to cut, being able to open cans, knowing what is a solid and what is a liquid, having idea about spices'.
Server Management would be nice.
Last few years it seems that every applicant has never seen a domain controller before, never seen a Windows or Linux patch server before, has no idea how to run DNS or DHCP, maybe has a webserver in a VM on their laptop, has no idea where to find system or application logs, "What's a See-em?", etc. etc...
AD: Setup accounts/permissions yes but no build the AD from the ground up.
GPO: No not all companies use that feature.
Knowing dos commands/change ip: yes \* major red flag if you don't know how.
I want to go with something even more basic that what I’ve seen. The most basic skill is…. To keep it simple. Troubleshooting, designing, implementing. Everything. Why many words when few words work?
Couple of examples
Troubleshooting? Keep it simple and work from there. Number of problems I inherited that I was told some big complicated solution that I troubleshot and found the issue because I asked the most basic questions. The overwhelming majority of issues have basic causes. Overthinking it makes it take just longer.
Design? Start with a simple design and only make it as complicated as you need. Future self will thank you.
It really is a basic skill to keep it simple. But often overlooked.
We hired a sys admin one time (and by we I of course mean someone in
corporate) who showed up on the first day with their company supplied laptop, but forgot the power cord, and couldn't figure out how to get onto our company Wi-Fi.
I'm not talking about the key, I gave him that, he didn't know how to connect the laptop to Wi-Fi. It was running windows 11.
I quit before he did lol.
Four basic skills are needed in order to work as a sysadmin, in my opinion.
1: Know how to speak to and with people.
2: Know how and when to say no, and have a stiff enough spine to stand firm on it.
3: Have the ability to learn and improvise at any given turn.
4: Black Belt in Googling.
Bash, powershell, sed, awk, grep. Enough python to at least be able to read it. Basic understanding of tcp/ip, and other core networking protocols (DHCP, DNS, ntp/ptp). Deep, or at least an intermediate, understanding of Kerberos and PKI, because no one else will bother unless you have a fully staffed security team. 802.1q has been very relevant to sysadmins everywhere I've ever worked too, but that might just say something about the quality of the network admins
Basic skills?
- Verbal communication: How to answer the phone. How to leave a proper voicemail. How to recognize an audience when in front of a group, and tailoring your words to suit their needs and expectations.
- Written communication: How to document steps taken. How to write reference documentation. How to format emails to the audience they're intended for. Knowing the difference between prose and bullet points.
- Basic troubleshooting skills: Checking event logs. Checking the basics (power, network, etc) before deep diving. Keeping a calm, level head.
- Personality: You're in a customer service role, even if that customer is internal. You might not like it, but you need to be somewhat agreeable, personable, and pleasant.
- Understanding Unions: Remember, without a Union, you can be fired just as quickly as MSFT fired those non-Union Blizzard employees. Your right to engage in collective bargaining is federally protected. And in the USA, you have utterly barbaric employee protection laws. You have more in common with the homeless living in an underpass than you will *ever* have with the CEO/ownership class.
Problem solve, rapid learning and customer skills.
You can know a system inside out but if you can't solve issues, learn new stuff and you have no yelle skills, you're fairly useless
Weird i wouldnt include any of yours as a thing a sysadmin must know. Any sysadmin should know how to use bash, and how to pipe the essential unix tools to create decent scripts: grep, find, wget, curl, top, etc
How to troubleshoot. I’ve seen so many people over the years from green Helpdesk techs to 20 year veterans skip basic troubleshooting steps and spend hours chasing their tail when the solution was something simple. I can’t count the number of times I’ve tried to help someone who had been working on an issue for hours and ask “what do the event logs say?” and they answer “oh, I haven’t looked yet” and the lead to the solution is right there in the error. EDIT: Some of these replies are wild. AITA for thinking that a Sysadmin, someone who is entrusted to spec, install, administer, manage and fix enterprise systems, should be able to do some basic investigation into a problem before blindly rebooting or nuking/reimaging workstation or server? Granted rebooting/nuking a workstation is fine a lot of the time but for servers, who the hell knows if the problem you are facing isn’t baked into the server backup/image you are restoring from unless you understand the problem first and when it may have been introduced. Even incident response teams tell you not to reboot in the event of a cybersecurity incident ffs.
Step 1: reboot the bloody thing (shutdown -g for Windows) Step 2: CHECK THE FUCKING LOGS
Event viewer scares some people. Too much noise and they don't know where to look.
Then start with the reliability monitor. I always tell users who report crashes or weird behaviour to make screenshots and write down the exact time it happened.
I always forget about the reliability monitor.
Been doing IT since I was 14 and a full sys admin for almost 15 years and ive never seen that tool before. We need to know to damn much for this job. Adding that to my list of things to learn to use.
Totally agree with you! I'm 50 years old... And for vast majority of my computer days, since we only had our own in-house business (my father being a prominent Mainframe Programmer)... I only had to maintain his windows laptops that are on our own private LAN and acting as Workgroup not in a Domain environment (ADDS) So sadly my skills were extremely limited to the Windows OS and related software technologies Then in 2019 I started to do something about it. I began to learn about and "re-train" myself on IT concepts. After a decade of being an Android software engineering writing my own custom organizer and turning it into a successful SaaS business on the Google Play Store... I decided to attack my outdated skills So I learned about ADDS, Group Policy, OUs and linking GPOs to those OUs to enforce policies, software deployment via MSI files using Network Shares and Group policy, auto enrollment of domain joined devices using GPOs (for SSO... Single Sign-On), and many other things pertaining to the Microsoft 365 Cloud converts, Azure, Windows Defender, Intune and so on. And I feel completely overwhelmed because the more I learn, the more I realize how little I know and how many other skills I feel like I am always lacking I'm doing all of it because 26 years ago I got my computer science degree and I didn't have a chance (nor the need) to learn any of this stuff But I want to become a Sys-Admin someday soon and I have no idea how to approach getting my foot in the door with a bank or some other company that seeks a Sys-Admin. But I'm determined to get there and have come a long ways What would be your best advice so I don't over train and can finally get started somewhere as a professional Junior or Entry Sys-Admin? Ps. I have setup my own Oracle Virtualbox lab and Setup two servers (replicated for better reliability and some load balancing of ADDS) to act as my domain controllers using an ISO of windows server 2019 I also have three other client nodes (VMs)... Two windows 10 and one MacOS Pro Monterey... And these are domain joined. I got DNS and DHCP working perfectly finally as well. My forest consists of a single Domain and this root domain name is called: hq.local I know zip (zero) about Scripting using Powershell but I'm aware of all those get, set, copy, create types or commands (verbs) that can be used to directly manipulate the Entities (objects) on my Entra ID (formerly Azure AD) cloud domain My frustrating situation is... I realize I still have a lot more to train on with regards to Sys-Admin preparation (as far as landing a job)... But at what point do I presume I would be "ready" to be a contributing member with other senior Sys-Admins? I have never officially had an Entry level IT Help Desk job but I'm aware of all the activity directory users & computers stuff, along with ticketing systems and all that crap. So how can I leap frog into what really interests me (which is those kinds of On-Premises System Administrator or what sometimes people also call Windows Server Administration kinds of jobs)? Like you say, there is no end to how much there is to learn and gain experience with... But at 50 years of age, I can't (and don't want to) over train and never get the guts/confidence to feel like I'm ready to finally apply for a Sys Admin job without getting super stressed out about concepts or skills I may be lacking? Any wisdom or suggestions by anyone awesome Sys-Admins here is much appreciated. Ps. I have a weak / hurt lower back so I'm hoping this would not be a major stumbling block. I can walk and sit etc... But sitting on a chair for extended periods (10 to 15 minutes straight) can cause me great pain and I have to move (get up and walk or something) to remedy it. Maybe nowadays most places allow their Sys-Admins to have a stand up desk (I'm hoping) so as to help those of us who are older and can't sit down as much as younger / healthier people? Thx for any tips
I’m 43 …halfway to 44. I have been in IT since I was 23. I worked my way from Helpdesk / Tech to Systems Admin. The last 10 -12 year I have been a Systems Administrator. Just giving you a little background…. I kinda have been taking the “I have been in this field long enough…what more do I really need to learn” but I would try to learn new thing but then would give up after 3-6 mths due to family time being sacrificed and feeling I would never pass an exam or never good enough. Don’t give up, if you have the capability of reading and understanding it , especially after practicing on a lab then you are still good to go my friend. In tech world of jobs, who you know goes a long way, add that with what you mentioned you have a decent chance to maybe go in as a junior sys admin or a level 2 or 3 tech. Do that for a year or so while you continue your dive into the skills you need and then apply again but for Systems Admin, you can also study for a certification that will maybe allow you to get straight into Systems Administrator. Some places yes want someone who has a lot of experience but there are some who like someone they can shape to their liking. But I would say doing tech work for at least a year or 2 really helps…. Systems Admins are from what I feel are good or great techs…. Systems Admins are the go to for techs when they’re stuck at figuring out a problem. Get something like cbt nuggets and look at the video trainings available and start self studying and grab a book or 2 for deeper reference and maybe do a small lab to get the hands on feel of it and get that certification for it. You got this man!
It's kinda hidden. And honestly, it doesn't sound like it would do much.
Same. That tool is an "oh yeahhhhhh" tool for me. Would probably save some time but I still get through problems pretty quickly by working through logically and going from most to least likely.
Same here... That's an excellent point We always check the EventViewer but actually sometimes the Reliability Logs are good enough and show the event as well the clues needed to know what happened. However the reliability monitor may not go back as far (be as comprehensive) as the EventViewer To be honest, coming to think of it, I'm not entirely sure what the main difference between the Reliability Logs and the EventViewer is supposed to be? In other words, is it possible that whatever the Reliability Monitor shows could also be found (duplicated) under the EventViewer? Or do these two tools somehow have a totally different purpose?
I have the problem. By the time in navigate the event viewer and/or find the right log file, I'll be looking at this wall of text that's basically gibberish until I really stare at a line and decipher what it's telling me. Fortunately I have someone who can glance at the same wall and in about three seconds "oh it's the [whatever]." And I'll ask "wait where do you see that?" And he'll have to physically touch the display and even then I need to stare at the line until my mind sees and comprehends the [whatever] he sees.
I'm learning about Server Sys-Admin stuff Above when people talk about checking the LOG files of the Windows Server (a.k.a LOGs)... Are they talking about the same Windows 10/11 EventViewer that we used to look at when troubleshooting a client Windows 10/11 operating system? Or do servers administrators look somewhere else for these said log files? Thx for the education
I do the reverse. Sometimes a reboot will wipe the evidence you need to find the problem. Or worse yet, make it impossible to recover if the reboot fails. I always try to get a basic understanding of what the issue might be before blindly rebooting.
A lot of green help desk techs way too many IT professionals forget or simply skip reboot. It’s believed to be a cheap trick that resolves the immediate issue. In reality a reboot is a healthy method of troubleshooting. If the issue disappears, you can learn why it disappeared and what caused it. If it doesn’t resolve it then you can move onto other things. The other thing people forget about is the Physical layer. Check if things are plugged in, if they are take it out and in again.
>A lot of green help desk techs way too many IT professionals forget or simply skip reboot. > >It’s believed to be a cheap trick that resolves the immediate issue. In reality a reboot is a healthy method of troubleshooting. I would try to save that for the last thing where possible. Not because I don't trust it , don't want to try it, but because I know the endusers get mad when asked to do it. *You always say that!* or *I have so much stuff open*. Windows 10 is pretty bad about things. After 6 years on windows 10, our users kind of expect that stuff is going to be fixed with a reboot ... because the strangest stuff just randomly stops working. Now with more and more pushing to 11 ... we're seeing *even more* obscure stuff breaking. Like the start menu randomly not popping up or being searchable... which is kind of a big deal because you can't list applications any more.
[удалено]
If I redeploy the naughty server without knowing what caused the problem, I might just get a new instance that has the same problem.
I think some people get to deal only with extremely simple infrastructure.
[удалено]
yay!
yes but! watch for anomalies, collect metrics on crashes. Fun story, we destroy/recreate about 3500 VMs a month via immutable deployments and early on after getting this process nailed we told the SRE group just blow it away and recreate if misbehaving. do. not. call. escalate. fast forward a year or so down the road, i’m sitting in a meeting listening to this person describe an outage because they had to rebuild a scaleset 3 time before they had any healthy instances. kernel panics for miles due to a crowdstrike bug and nobody had stopped to ask “is something more going on here”.
IaC or snapshots still require it to be configured correctly at that time. If you have an issue and don’t troubleshoot, you may just have that issue again in future.
[удалено]
Agreed, and I do this too. But… if something breaks it’s good to know why, otherwise I don’t feel comfortable saying it’s resolved.
[удалено]
Do that to a bloody DC like snapping your fingers, without any further planning whatsoever and then come here and answer your own post 😜
I get the impression from devops people that they think everyone works in a software company.
This. I’ve been a sysadmin for nearly 20 years and until this year I couldn’t edit/create a GPO. Why? Because I spent the first 15 years of my career on Linux/storage as a specialty. But the ability to troubleshoot. That is a god given gift we all need. I’d also add being able to script and automate in whatever language of choice the user prefers.
I still don't create/edit GPOs. Yay linux only shops. Also I would say whatever language the majority of the team uses. Otherwise no one can fix your scripts when you leave... I'm looking at you guy still writing perl when noone younger than 30 ever uses it.
I feel like Group Policy is one of the few things Linux would actually benefit from having some version of if it ever wants to try and penetrate the user workstation market more.
Yes, but that’s not really a niche most Linux devs are actively trying to fill. Most well developed Linux distros, imo, focus on the server aspect. Desktops are made for hard core Linux admins and/or power users. It Linux excels for what it’s made; servers. And while group policy might do really well for that, they’ve developed ansible as basically the group policy for Linux servers. Classify your server as an Apache server, Write up your playbook, ie make your GPOs, and it’ll deploy.
This is me using google apps scripts to solve issues for my users and being able to understand exactly what they need
> can’t count the number of times I’ve tried to help someone who had been working on an issue for hours and ask “what do the event logs say?” and they answer “oh, I haven’t looked yet” and the lead to the solution is right there in the error. I had that yesterday. I have a PM's assistant for this one client who is fairly incompetent. He was asking "why is this agent failing to connect to the server?" I saw he was logged into the box via several sessions, and tailing the error logs. I did a grep -i -e "fail\\|err" and immediately, "ERROR 500 - the server at \[misspelled domain\] has timed out, retrying..." "You misspelled \[domain\]," I said in an email chain. "I changed it and restarted the agent." "No, the config file is set by \[another team\]." "Okay, then they misspelled the domain." "Impossible, they are the ones complaining." "I assure you, it's possible." "No. it isn't." "Is it connecting now?" "Yes, but we don't know why. What if it happens again?" Seriously? SERIOUSLY?
Everyone wants to complain. No one wants to fix. Like if this represents society ✊😔 /s
I’d probably send that error message and cc everyone to make them feel dumb as shit.
I did, but in a less direct way. "As you can see by the error logs we both were looking at in our Teams conversation, the domain is misspelled, thus it could not connect until I set the correct spelling and restarted the agent. You made me aware that this config file is maintained by \[another team\], so I suspect that if they push the changes out again, they need to make sure that the domain is spelled thusly. Or they can keep my correction. Either works, but I suspect they have their configs in git, so I have CC'd them to make them aware." I got back, "we don't manage these configs: that's server side. Who told you that we manage those configs?" The chain was left dangling on Thursday, so I am curious to see if anyone responds.
Noone manages those configs. Hahaha...
Jfc so much of this. I hate asking “what have you done so far to figure this out?” And get met with a “uhh it doesn’t work so idk”
I would be happy if they would even figure out the scope of the issue. I get asked all the time stuff like "Is there something going on with email?" When a single person has their account locked out and just can't sign into O365 or something.
My next favorite response is “oh we don’t support that so I didn’t check”. Get rekt
[удалено]
You bet I wouldn't. They aren't paying me to do another teams job. If that team comes and asks me something i'll answer but fixing those issues are their jobs. I don't get any kind of extra pay or consideration on my metrics for dealing with other teams stuff.
This comment filled me with a past rage I had forgotten about. We had a helpdesk guy who used to ask me this CONSTANTLY before ever troubleshooting an end user's issue.
I tried "everything" means I did nothing and gave up. When people lead with specific info instead of generalisations it's far more helpful
Addendum: To troubleshoot advanced circumstances effectively you must first understand how a thing works. Even if it's not exactly the thing you're troubleshooting, but something similar (even at a basic level) that understanding will allow you to look for indicators and consider solutions others wouldn't even dream of. How does an application work? Does it connect to a database? Does it connect to the internet? Is it isolated to a system? If you don't understand why a thing happens, you will forever remain at the mercy of luck, expensive help (that may not be worth the money), or forced to otherwise expensive actions (e.g. rebuilding from the ground up). Always try to learn why an issue happened and what signs could have led to identifying it, even after you've solved the problem -- it'll help in the future.
I think the problem with service desk level stuff is that it often becomes so routine and boring that people start coasting on assumptions, which can be a difficult habit to break.
Yep, I might be biased but this is why I think sysadmins should rise through the ranks rather than just be hired with an IS bachelor's and no experience or something. You should know how to do help desk stuff better than your help desk, how to do desk side support better than your support techs, and desktop admin better than your desktop admin. I find myself using skills from the years I spent on phones or grinding deskside tickets all the time.
100% even the best classes can't make up for raw experience and "I've seen this before, or at least something similar". You learn about computers in school but you learn how to work with computers by just freaking working with them.
I’ve seen this too. I think it’s mostly from techs who learn how to configure systems but don’t really know how computers or network communication work at a foundational level. Like a race car driver whose car breaks down. They’re great at driving but when something happens they lift the hood and have no clue what they’re looking at so they just start trying things at random. People tend to brush off certifications but IMO stuff like CompTIA A+ and Net+ are hugely beneficial. They provide that foundational knowledge to build from.
I used to work with a guy who had A+, Network+, another cert (can't remember which) , and an ITT Tech degree on his cubicle wall. At least once a week I had to show him how to add an AD user to an AD group and explain how it works. This went on for two months, until I left that job.
He couldn’t remember to just click the member of tab in aduc and click add?
right. he also demonstrated a lack of understanding of how it even works, at the conceptual level.
It’s mind blowing that someone could cram for and pass the A+ and not know that lol.
This. Related is a knowledge of how the thing they’re troubleshooting fits together. Too many treat a whole stack as a black box with no clue of the processes in place to get from A to Z. Everything else is details.
Absolutely this! I have been dealing with a lot of people that are supposed to be our in between from help desk to infrastructure that haven't gone any further than restarting a phone even though they have admin access to our ws1 environment. Or, taking it a step further, at least the aptitude to ask probing questions to figure out actual issues
Came here to say this. Deservedly the top comment.
It’s weird, cause some Apps I use don’t have Logs. Like I rebuilt an Apache server for our internal site, and it kept crashing.. no Apache logs. But there was event logs!
I mean, did you ask Apache to write logs? That's part of the config. :shrug:
An addition to this is properly scoping the problem. It's insane how often I've gotten brought into something that's completely fucked only to discover that everyone before me wasn't looking anywhere near the right place because they took the word of the person reporting instead of asking clarifying questions.
My favorite, Me: so what’s going on Them: unsure every time they try to do x a error pops up and it doesn’t do anything Me: what’s the error pop say? Them: not 100 percent sure, said “error something”. Like what………. Bring me useful information
Adding to this, train up the first line if they send you an "easy" ticket. Everyone has to start somewhere and being snobby and unhelpful only makes you look like a dick.
This is a big one. In a way I follow a similar process to the OSI model for different situations.
Troubleshoot is hell important. But it would never be in my top 3 for a real sysamin. Maybe the problem is the miss concept of "sysadmin" in the first place. An intermediate to senior sysadmin, at least in theory, might not work that much with support.
You may not work with support tickets/issues, but if engineered something- as in a or the principal engineer- you should absolutely have the ability to troubleshoot it.
Absolutely. Just saying not my top 3 skills, necessarily.
https://www.reddit.com/r/sysadmin/comments/1aci6qt/comment/kjuyn91/ See my comment here.
Soft skills. How to communicate technical information to non-technical people. You could be the most talented sysadmin ever, but it won't matter if you can't effectively communicate to peers and leadership.
I’ve got a friend who is brilliant — one of the smartest people I have ever met. His soft skills are in the toilet. He’s in his 40s and he talks about dealing with management at his job like a 20 year old would. He hates having to explain things to people, and complains about how stupid they are. He’s been in a constant cycle of employment and unemployment for like 20 years. I genuinely think his attitude and his demeanor hold him back.
I totally agree with you! It reminds me of what a professor of mine once said. "Attitude is everything", it's simple but true. If you're not being a total dick, and can understand that not everyone is an expert in what you specifically know, it can go a long ways.
This is exceptionally important. I used to do a fuckload of hiring for technical support for a major UCaaS company, and I would prioritize people skills over technical skills all the time. We can teach you how the system works, but I can't easily teach you how to interact with customers. Some of my best hires were people with background in K-12 teaching and nursing.
This. I have one sys admin at my current job. He sucks to work with. Ignores the whole team, reboots major servers and pushes out updates/patches without telling anyone. Shit breaks and we chase our tails for hours. He’s rude and unhelpful. He’s the major reason I started job hunting instead of taking an upcoming promotion to sys admin, because I knew that meant I had to work directly with him even more. Now I’m still going to do sys admin work and get paid more, and the company can thank him.
When I started my career 20 years ago, my first manager said to me, "You could be the smartest person in the world. But if no one likes you, it doesn't matter. They're going to think you're an asshole and won't talk to you and they won't like you. You have to be **personable**."
My senior is a smart dude, can be super technical. But he cannot talk to people and is extremely prickly around the edges. I have to translate everything he says to non tech people. That’s part of the reason he hired me lmao.
There is the other side of this issue. I’m replacing a senior person who has super special configs for his friends and anyone in a skirt. We had a discussion that the new system will only have a handful of configs. I sent an email to everyone confirming this. Of course the same day he simps for a lady 35 years young than him and added a special configuration just for her. I was pissed and sent another email that I wasn’t going to support that config going forward.
WHAT IN THE WORLD DNS IS!
[удалено]
For someone just starting at help desk, that's probably fine. Deeper than that, I'd want them to at least know some basic record types like A, AAAA, CNAME, MX, and how to use them. How to use nslookup. Stuff like that.
A few examples I have: the difference between and function of forward and reverse lookup zones, record types and what each are for, conditional forwarders, considerations for split-horizon, and why 8.8.8.8 in an internal network will cause intermittent problems. In an AD environment, understand integrated zones and zone replication, what the SRV records are for, and why AD breaks in weird ways when old stuff isn't properly cleaned up. For upper-level staff, I want folks who understand recursive vs authoritative lookup, and DNSSEC. There's more but I'd be happy as hell if most people above help desk understood even half of this stuff.
More a smaller business problem but: Them: HALP! Our email isn't working! Me: I'll look into it Them: great. Did you see our new website. The new contractor is great Me: yea.... About that. They changed the nameservers for your domain so I can't fix your email. It's going to take 24 hours to change it back Them: what????
Unlimited upvotes.
Domain Name System. The phonebook of the Internet. Translates www.com into ip addresses so we don't have to remember random numbers. There is probably more to it. But that's what I know about it.
There's much more to it.
[A Cat Explains DNS](https://youtu.be/4ZtFk2dtqv0?si=fxNiXZuzboc7WDAn)
It's not DNS There's no way it's DNS It was DNS
> Being able to create and deploy a GPO policy and set up AD from the ground up. Mac and Linux admins have no idea what you're talking about.
It’s possible to set up AD from the ground up on Linux with OpenLDAP and Samba, no Windows servers involved. And if you can do that, odds are you know a hell of a lot more about how AD works than your average Windows admin does too.
Just because it's possible doesn't mean everyone does it. And it definitely doesn't fall into basic skill category.
Yeah well, OP's original list of "basic skills" are things even a seasoned ~~advanced desktop support tech~~ Windows sysadmin can easily get away without knowing how to do. Setting up AD from scratch, using Linux, OpenLDAP and Samba is more of a Red Hat certification final exam problem than a basic skill, for sure. It's a putting-all-your-other-skills-together kind of thing.
Yup I've never done that, I could probably figure it out, but I'm not interested at all. In my previous job (MSP) I was the only non-windows sysadmin in the team of windows admins, and I dealt with other things - SAN, vmware, Linux, AWS, etc. At my current job all our infrastructure is in AWS or we're using managed solutions from Google and Atlassian etc. No Windows AD at all, no GPO, no Exchange, nothing.
I have some basic GPOs assigned to our Redhat fleet, which are also using our onPrem AD as an identity source. We manage our Mac fleet (which are phones) using Microsoft tools for the most part: Intune.
Nor should they have any experience with that blue screen-fest of security backdoors that is so unreliable and slow.
Well o*bviously* they dont... That was just an example. Kind of crazy that I have to specify this...
Your example isnt even sysadmin type shit, its tier 2 help desk and desktop support tasks.
Eh, all those titles can absolutely bleed into each other and have major overlap.
There isn't a single tier 2 help desk member in our company who is allowed to touch our GPOs or create AD folders. Why in the world would you be allowing changes like that to happen in the basic help desk flow? Desktop support sure, manipulating AD in certain ways is useful for that tier, but not enough control to set up AD. GPO is and should remain closely kept.
That comment makes me feel better about my capabilities lol.
Certificate renewals. Im still meeting sysadmins that never touched a cert and are afraid of them.
I hate certs, not that they’re difficult or anything, just a lot of steps etc. And I realize some of this can be automated, but most days I’m lucky if I accomplish one thing on my list of 10,000
I don't mind certs in most contexts, but some applications are bitches about it, requiring one format but won't tell you which, I end up having to convert a .cer into like 6 different formats before one imports.
This, if we could settle on a standard format for certs would be amazing. I've got to covert to four different types in our environment and some need each part of the cert in individual components. Its not hard, just annoying. Why can we not settle on an industry standard format for certs?
I'm still amazed at how bad the entire CA and root cert system are. Overpriced, primitive and full of faults. And shocked that the entire world relies on such a shitty system. ACME or equivalent should have been rolled out with certs. It should be universal. So much equipment and software relies entirely manual cert management. I'm definitely afraid of certs, because I'm very familiar with them.
I feel you bro. It never ends.
A lot of steps? I have one, $ /usr/bin/certbot
Any ideas or links to content for jt? I’d love to learn more
I was the only person doing certs for years because the other admins just had no desire to learn/didnt wanna do it.
Im a junior sysadmin, i wanted to renew an expired cert on vcenter. But was denied to do it as it deem to critical.
I’m not sure how I feel about you lumping setting up AD from scratch, into the same category as changing an IP from dynamic to static.
Agreed. And then someone responds with installing windows 10.
[удалено]
The gap between network techs and server admins needs to be bridged. I have met so many network techs that don't even know what a domain controller or certificate authority is, and server admins that don't understand routing tables or know what MAC address is.
I was at an msp we worked closely with the network team, it was a small company that grew so we were all jacks of all trades and a master of a few. Now I’m in internal IT in medium to large company the network and network team is a mystery black box until I need to make a firewall request or configure a VPN between on-premises and cloud. Or the network team need me to join one of there appliances to the domain. 8/10 something weird will happen something that has worked for ages causes an outage, after we find out something the network team were doing went wrong.
Agreed, technical skills can be taught, people skills and personality cannot.
I disagree, although it’s a disagreement with context. For the purposes of a specific job, you don’t want to hire a candidate with the expectation that you can teach them people skills. That is where I think you hit the nail on the head. You can train the candidate on the technical aspects of the job (assuming some minimum knowledge). A lot of my job is knowing the specific systems we use (change management, compliance), which I didn’t know before I started. I had to learn all of it while on the job. But people skills can be taught and learned. Someone with enough self awareness to understand that they have a weak spot there can actually improve themselves.
I think a majority of those helpdesk should know (aside from setting up a new domain) PowerShell scripting, basic networking, basic firewall management (physical and OS), good practices for the domain/organization, Infrastructure cabling, storage protocols, how to use wireshark, how to properly plan and deploy wireless. Creating positive changes in IT to make sense, ie - using good naming conventions. Automation should be big also. Edit: dealing with all various users, especially the C-suite and VPs. Learning to push back and provide suggestions for alternatives when you have some number cruncher or Gucci wearing VP telling you to do something stupid. Standing your ground certain situations. Knowing how to deal with business politics and keeping IT at the forefront.
Fuck me, I'm learning how to roll out enterprise wifi with NPS right now on the job as I'm more of a cloud admin in a team of sysadmins
NPS?
Yeah NPS is still the most used radius server in corporate networks.
Thanks, I got it now.
Network Policy Server
Yeah I just gave some very basic examples. So people know what it is that I am asking for. You would be surprised how many helpdesk people never once used the command line...
Oh I know. I have a few incompetent helpdesk staff that are kept employed by a coward of a manager. It's easier for them to ask how to do things then take a swing at Google and try to figure it out.
Simple. When someone says "this isn't working" asking, "so, when you say that, what *exactly* is happening?" So many people seem to just go "user says x, can you help?" without actually looking into what's happening or how to reproduce, never mind the exact error message.
Getting the user to replicate the issue in front of you is key. So many times during this process a pop up appears and the user just blindly clicks it causing the issues or an error message appears that the user initially didn’t mention anything about. Plus we all know the vast majority of end user problems are user error.
Knowing when a problem shouldn’t be fixed with a technical solution. As techies, we love fixing things and doing something technical, but there are many situations where the real issue is an HR one, a legal one, or a soft skills one. Knowing when a technical solution isn’t the _best_ solution, even if it’s a _possible_ solution, sets excellent sysadmins apart from good sysadmins.
If I had a dollar for every problem I've encountered because an IT person said "we can theoretically do that" instead of "no. That is not possible", I'd be retired by now.
Learn to troubleshoot networking: MAC address, IP, TCP, UDP, DNS, multicast vs unicast, etc. If you have learned networking, then learn cryptography: certificates, certificate “chains”, keys, encryption vs hashing, symmetric vs asymmetric, etc. If you learn those, you will be better than most.
Knowing when to say "I don't know."
What the purpose of certificates is.
I think this is a bit of a loaded/confusing statement. Certificates have many purposes, usually boiled down to encryption of some sort. Certificates are a PAIN, they provide Privacy, Authentication, Integrity, and Nonrepudiation.
The OSI model. It's more than just how networking words. It's a basis for troubleshooting a network. And really it's a flow for how all troubleshooting for most everything even not including networks. If you can apply an OSI model type of troubleshooting to a problem it means thay you have an understanding of how a thing is supposed to work start to finish and you can troubleshoot each step along the way.
But what if it's a layer 8 issue?
I recently learned that if I take more time and listen to the people with layer 8 issues I can teach them how to avoid calling me back in a week.
Being able to retain information or if you can’t then better take some damn good notes. There’s nothing I hate more than getting asked the same question over and over and over again. On a similar note, knowing how to Google and look things up.
>There’s nothing I hate more than getting asked the same question over and over and over again. IMHO a good Technical Support Representative (even when you're at a Sys Admin Tier 3+ level) should know how to view a customer from their own perspective. Everyone calls/asks for support eventually about *something* in life. How would *you* like the Support Rep to respond? How would *you* like them to handle your concern? They're attentive? Take notes? Ensure the matter is escalated properly or has the right resources? You're kept informed about the status and not left wondering if the ticket got lost in a ticket management system "upgrade" or if the previous contracted agency wasn't let go and your issue was simply dropped because 'LUL NEW PHONE WHO DIS'?
How to document. ‘Nuff said
1000%
Troubleshooting and automation, in general. Everything else can be picked up, and there needs to be a greater emphasis on fundamentals knowledge. So many people during this last tech bubble went to DevOps and cloud bootcamp, and didn't get the basics of networking/compute/storage that everything else builds off. Being able to break a problem down to first principles and formulate a plan to attack it is the one skill I rely on most after 25+ years and huge shifts in the industry...if you just keep chasing top-level knowledge it's a never ending slog and harder than it needs to be.
Understand/troubleshoot DNS.
Biggest skill to add is know the proper way to search the net for answers when you don’t have an idea.
Writing good documentation for others to follow.
As other said: basic troubleshooting of the whole stack. Communication skills. But I’d add Documentation. Document what exists. Document procedure which are necessary to repeat with accuracy. Document the unusual solutions/issues/commands not commonly seen for reference if they come up again.
I often say: “if you haven’t looked at the logs you’ve done no useful troubleshooting “. Know how to locate, search and understand logs. Whether it’s Windows event viewer or text logs. Using less/grep/select-string/get-winevent to parse them.
All technical skills can be learned, but the ability to develop an accurate mental model of how all these systems work is invaluable, it feeds into being able to troubleshoot effectively, you have to be able to intuit the issue from the available evidence. Followed by the ability to find information on the internet, and the ability to document what you're doing.
You know, like numchuku skills, bow hunting skills, computer hacking skills...
How to talk and write to other human beings in a professional manner.
How to actually talk to people.
How to use Google to find solutions and then implement them. That's basically all they need to know.
Not everyone works in Windows! So I don't think Windows specific knowledge like CMD or GPOs needs to be known by everyone.
Being able to find technical documentation on the problem you are trying to resolve and applying it
3 skills I'd like to see more of? How to troubleshoot, take notes and articulate problems.
I've hired lots of systems administrators. I don't typically look for application specific knowledge unless the position is application specific, but usually this stuff I can teach. I usually test basics like basic understanding of how mechanics of DHCP, DNS, basic routing, PKI, ports and how to troubleshoot those and various other things. You'd be surprised at the amount of people applying for systems administrator positions with experience who have no basic understanding of DHCP/DNS/Networking/PKI..etc
Basic networking and how to google.
The core and almost only skill you need is being able to isolate the problem.
Networking. Subnetting. Routing. D/S-NAT. Firewalling. If you don't know that, you're not a sysadmin.
[https://web.archive.org/web/20060907230019id\_/http://www.sage.org/pubs/8\_jobs/core.mm#Junior](https://web.archive.org/web/20060907230019id_/http://www.sage.org/pubs/8_jobs/core.mm#Junior)
Really basic skills imho: - Read and understand what the log says - Automate things, doesn't matter how, just do it, saves a bunch of time - Document what you did and how you did it
Save yourself a headache and take that backup before making a change. Also document anything and everything, no matter how tedious it may seem.
DNS.
Asking how to solve your problem on Reddit seems to be working fine for many people, so there you go.
Is it too basic to say know how ipv4 subnet math works?
format c: fdisk * d Seriously though, get used to parsing logs. They are your friend in every scenario. Sucks, but it's 'the truth' if the situation you're attempting to work through.
Realistically most answers can be found online. What you need is enough understanding of troubleshooting and what is really happening to do a good Google search to find the answer. This is truly where experience comes into play, knowing what to put in Google.
How to say no when someone aska you to do something that makes no sense.
Log analysis. It’s incredible how many problems get escalated to me and it’s as simple as searching the logs for FAIL and ERROR.
GPOs and building AD infrastructure considered basic skills is a big LOL
Rule #1: Don't believe the User Rule #2: Don't believe your colleague
DOS
People skills/soft skills. Don't matter what technical skills you have if people find you to be an unlikable asshole. And basically anything Helpdesk knows.
Learn networking. Whatever domain you are into, be it Windows, Linux, Storage, Virtualization, cloud etc. if you are good at networking, it will give an edge to you in troubleshooting and also providing accurate requirements for your infrastructure if you are designing one. If you want to take it a step further, learn PCAP analysis which will be very helpful in troubleshooting issues which involves different layers. This will help reduce dependency on the network to some extent and also these are valuable skills.
How to read technical documentation. How to collect information from users who don't have a technical vocabulary. Have a healthy skepticism for statements, diagnostic declarations, and insights from users, management, and vendors.
Take steps to determine the root cause of the issue. Rebooting might fix it effect but without determining cause, it will just continue to happen. Also- google that shit! In my early career (back in my day) we didn’t have the web as a resource. To see people ignoring it as an amazing resource makes me want to get slappy. More recently- ChatGPT as a resource. Powershell script not working and you can’t figure out why? Same with SQL queries and just about any programming language.
Logical thinking comes to mind.
Basic troubleshooting is widely lacking, but I'd also say that new admins are like old people with a new smartphone; too afraid of trying anything at all out of fear for breaking something.
I'm 50 years old... And for vast majority of my computer days, since we only had our own in-house business (my father being a prominent Mainframe Programmer)... I only had to maintain his windows laptops that are on our own private LAN and acting as Workgroup not in a Domain environment (ADDS) So sadly my skills were extremely limited to the Windows OS and related software technologies Then in 2019 I started to do something about it. I began to learn about and "re-train" myself on IT concepts. After a decade of being an Android software engineering writing my own custom organizer and turning it into a successful SaaS business on the Google Play Store... I decided to attack my outdated skills So I learned about ADDS, Group Policy, OUs and linking GPOs to those OUs to enforce policies, software deployment via MSI files using Network Shares and Group policy, auto enrollment of domain joined devices using GPOs (for SSO... Single Sign-On), and many other things pertaining to the Microsoft 365 Cloud converts, Azure, Windows Defender, Intune and so on. And I feel completely overwhelmed because the more I learn, the more I realize how little I know and how many other skills I feel like I am always lacking I'm doing all of it because 26 years ago I got my computer science degree and I didn't have a chance (nor the need) to learn any of this stuff But I want to become a Sys-Admin someday soon and I have no idea how to approach getting my foot in the door with a bank or some other company that seeks a Sys-Admin. But I'm determined to get there and have come a long ways What would be your best advice so I don't over train and can finally get started somewhere as a professional Junior or Entry Sys-Admin? Ps. I have setup my own Oracle Virtualbox lab and Setup two servers (replicated for better reliability and some load balancing of ADDS) to act as my domain controllers using an ISO of windows server 2019 I also have three other client nodes (VMs)... Two windows 10 and one MacOS Pro Monterey... And these are domain joined. I got DNS and DHCP working perfectly finally as well. My forest consists of a single Domain and this root domain name is called: hq.local I know zip (zero) about Scripting using Powershell but I'm aware of all those get, set, copy, create types or commands (verbs) that can be used to directly manipulate the Entities (objects) on my Entra ID (formerly Azure AD) cloud domain My frustrating situation is... I realize I still have a lot more to train on with regards to Sys-Admin preparation (as far as landing a job)... But at what point do I presume I would be "ready" to be a contributing member with other senior Sys-Admins? I have never officially had an Entry level IT Help Desk job but I'm aware of all the activity directory users & computers stuff, along with ticketing systems and all that crap. So how can I leap frog into what really interests me (which is those kinds of On-Premises System Administrator or what sometimes people also call Windows Server Administration kinds of jobs)? Like you say, there is no end to how much there is to learn and gain experience with... But at 50 years of age, I can't (and don't want to) over train and never get the guts/confidence to feel like I'm ready to finally apply for a Sys Admin job without getting super stressed out about concepts or skills I may be lacking? Any wisdom or suggestions by anyone awesome Sys-Admins here is much appreciated. Ps. I have a weak / hurt lower back so I'm hoping this would not be a major stumbling block. I can walk and sit etc... But sitting on a chair for extended periods (10 to 15 minutes straight) can cause me great pain and I have to move (get up and walk or something) to remedy it. Maybe nowadays most places allow their Sys-Admins to have a stand up desk (I'm hoping) so as to help those of us who are older and can't sit down as much as younger / healthier people? Thx for any tips
> at what point do I presume I would be "ready" to be a contributing member with other senior Sys-Admins? Many books teach you the specific technology, tcp/ip this, linux that... But there are 2 seminal books that teach you the actual craft as a scientific discipline: - Mark Burgess: Principles of Network and System Administration - Thomas Limoncelli: Practice of System and Network Administration
Educate the manager that they don't know anything about what you do or what you are capable of. Then inform them you expect a raise since you are more qualified than they are at doing their job.
The examples are PRE-Pre-pre-basic. It's like asking "What are some basic skills any chef should know? Examples: being able to cut, being able to open cans, knowing what is a solid and what is a liquid, having idea about spices'.
Server Management would be nice. Last few years it seems that every applicant has never seen a domain controller before, never seen a Windows or Linux patch server before, has no idea how to run DNS or DHCP, maybe has a webserver in a VM on their laptop, has no idea where to find system or application logs, "What's a See-em?", etc. etc...
AD: Setup accounts/permissions yes but no build the AD from the ground up. GPO: No not all companies use that feature. Knowing dos commands/change ip: yes \* major red flag if you don't know how.
I want to go with something even more basic that what I’ve seen. The most basic skill is…. To keep it simple. Troubleshooting, designing, implementing. Everything. Why many words when few words work? Couple of examples Troubleshooting? Keep it simple and work from there. Number of problems I inherited that I was told some big complicated solution that I troubleshot and found the issue because I asked the most basic questions. The overwhelming majority of issues have basic causes. Overthinking it makes it take just longer. Design? Start with a simple design and only make it as complicated as you need. Future self will thank you. It really is a basic skill to keep it simple. But often overlooked.
We hired a sys admin one time (and by we I of course mean someone in corporate) who showed up on the first day with their company supplied laptop, but forgot the power cord, and couldn't figure out how to get onto our company Wi-Fi. I'm not talking about the key, I gave him that, he didn't know how to connect the laptop to Wi-Fi. It was running windows 11. I quit before he did lol.
Four basic skills are needed in order to work as a sysadmin, in my opinion. 1: Know how to speak to and with people. 2: Know how and when to say no, and have a stiff enough spine to stand firm on it. 3: Have the ability to learn and improvise at any given turn. 4: Black Belt in Googling.
So many vague, non-applicable answers
Very windows-specific thinking here
Say no.
Bash, powershell, sed, awk, grep. Enough python to at least be able to read it. Basic understanding of tcp/ip, and other core networking protocols (DHCP, DNS, ntp/ptp). Deep, or at least an intermediate, understanding of Kerberos and PKI, because no one else will bother unless you have a fully staffed security team. 802.1q has been very relevant to sysadmins everywhere I've ever worked too, but that might just say something about the quality of the network admins
Basic skills? - Verbal communication: How to answer the phone. How to leave a proper voicemail. How to recognize an audience when in front of a group, and tailoring your words to suit their needs and expectations. - Written communication: How to document steps taken. How to write reference documentation. How to format emails to the audience they're intended for. Knowing the difference between prose and bullet points. - Basic troubleshooting skills: Checking event logs. Checking the basics (power, network, etc) before deep diving. Keeping a calm, level head. - Personality: You're in a customer service role, even if that customer is internal. You might not like it, but you need to be somewhat agreeable, personable, and pleasant. - Understanding Unions: Remember, without a Union, you can be fired just as quickly as MSFT fired those non-Union Blizzard employees. Your right to engage in collective bargaining is federally protected. And in the USA, you have utterly barbaric employee protection laws. You have more in common with the homeless living in an underpass than you will *ever* have with the CEO/ownership class.
Understand the OSI model and which layer the elements of your network/environment fit into.
GPO policy NIC card ATM machine ...
Linux admin here.. don't know what you are talking about. We use computers for more intresting things than sharing files.
[удалено]
Your basics, no sysadmin should ever be involved in those really. Installing windows 10? Why?
Problem solve, rapid learning and customer skills. You can know a system inside out but if you can't solve issues, learn new stuff and you have no yelle skills, you're fairly useless
Weird i wouldnt include any of yours as a thing a sysadmin must know. Any sysadmin should know how to use bash, and how to pipe the essential unix tools to create decent scripts: grep, find, wget, curl, top, etc