I run the systems nobody notices — until they break.
I’m K Shankar R Karanth — a Senior Site Reliability Engineer in Mangalore, India. I look after identity and Windows infrastructure for a living, automate anything I refuse to do twice, and write down what production teaches me. This site is the notebook.
What I do
My day job is keeping enterprise identity infrastructure healthy — Active Directory forests, the domain controllers underneath them, and the DNS, replication, and time synchronisation they quietly depend on. When authentication works, nobody thinks about it. My job is making sure nobody has to think about it.
The other half is automation. Anything I’ve had to do twice by hand becomes a PowerShell script with proper error handling and a report at the end — because the third time always arrives at the worst possible moment.
And when something does break — because something always does — the SRE half of the job takes over: reading the evidence properly, fixing the cause rather than the symptom, and making sure the same failure can never surprise us twice. Most of the troubleshooting guides on this site started life as exactly that.
How I got here
The support queue
I started on the technical support desk, where you learn the two skills no certification teaches: how to actually listen to a problem, and how to stay calm while everything around you is on fire.
Owning the servers
Local administration came next — my first Active Directory environment, my first servers that were mine to keep healthy. It’s one thing to fix a broken machine; it’s another to be the person responsible for it never breaking in the first place.
Reliability at scale
Today I work as a Senior Systems Engineer / SRE — designing for reliability instead of reacting to its absence. Automation, monitoring, secure architecture, and the unglamorous discipline of doing things the same way every time.
The thread through all three stages is the same: I have never trusted a system I couldn’t explain, and I have never met an outage that didn’t teach something worth writing down.
Rules I work by
Boring is a feature
Exciting infrastructure is infrastructure that’s about to page you. The goal is systems so predictable they’re dull — dull systems let everyone sleep.
Understand, then fix
A fix you don’t understand is a fault you’ve rescheduled. I’d rather lose ten minutes to a root cause than a weekend to a repeat.
Automate the second time
Once is an incident. Twice is a pattern. A script with error handling beats a perfect memory — especially at 3am, when nobody has one.
Write it down
If it isn’t documented, it didn’t happen — and it will happen again, to someone who wasn’t there the first time. Most of this site exists because of this rule.
The lab
Everything I publish gets tested somewhere first, and that somewhere is a Proxmox homelab built to mirror enterprise patterns without the enterprise budget. The lab is where I get to be reckless, so that at work I don’t have to be.
It runs the same things an enterprise would, just smaller: two domain controllers replicating to each other, AD-integrated DNS, a proper NTP hierarchy so Kerberos stays honest, and a small fleet of member machines to break in interesting ways. When a guide on this site says “this is what the failure looks like,” it’s because the lab produced that exact failure first — on purpose, with the event logs to prove it.
┌───────────────────────────────┐
│ PROXMOX VE — one host, many │
│ careful mistakes │
└───────────────┬───────────────┘
│ VMs
┌───────────────┬───────┴───────┬───────────────┐
│ │ │ │
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ DC01 │ │ DC02 │ │ chrony │ │ members │
│ AD DS+DNS │◀─▶│ AD DS+DNS │ │ NTP tier │ │ + clients │
└───────────┘ └───────────┘ └───────────┘ └───────────┘
▲ ▲
└───────────────┘
replication — broken on purpose, regularly
About this site
karanth.ovh is my working notebook, made public. New guides go up daily, and every one of them earns its place the same way: something broke, or something needed explaining properly, and writing it down seemed wiser than trusting my memory at the next incident.
The guides come in two shapes. Concept guides build a subject from first principles — the 13-part Active Directory series is the backbone, taking you from “what is a domain?” to replication, Kerberos, trusts, and Group Policy in the order they actually depend on each other. Troubleshooting guides start from the literal error text — KRB_AP_ERR_SKEW, Event 4012, “the trust relationship failed” — because that’s what you actually type into a search box at 2am, and each one walks the same path: symptom, cause, confirmation, fix, prevention.
If you’d rather understand a system properly than paste a fix and hope, you’re in the right place.