The Tickets That Teach You Infrastructure

Monday, 08:50, at Redbrook Engineering. Ticket 5519 has been in the queue since Thursday: "Can't see the Projects share since the department reorg. Neither can half my team." Three technicians have opened it, read it, and put it back. Everyone knows what it is. It is a permission tangle, a folder tree where somebody broke inheritance years ago and nobody has dared to touch it since. The one person who understands it, Grace, the sysadmin, is in a project meeting until Thursday. Yusuf, two years on the desk, reads it for the fourth time, and claims it. His internal note says "working this one with Grace when she is out of the meeting; starting the reading now". Nobody objects. Nobody wanted it.

A teaching ticket is a ticket whose cause sits in a shared system rather than on the user's device. The first line could hand it straight to the sysadmin. It teaches far more than it costs when a technician works it with the sysadmin instead of handing it over. There are five kinds that arrive on nearly every desk: the permission tangle, the print server, the VPN gateway, the mailbox migration and the certificate renewal. Each one crosses the line from the user's screen into the infrastructure behind it. Each one is avoided by most of the queue for exactly that reason. This article is part of our The Helpdesk-to-Sysadmin Ladder series. The skills these tickets build are inventoried in Skills to Build While You Are Still on the Desk. This article is about the tickets themselves.

It covers why some tickets teach and most do not. It covers the five tickets in turn, with what each teaches, where its dangerous step is and which article in this library owns the fix. Then come volunteering for one without being a nuisance, working it with the sysadmin rather than handing it over, and writing it up as evidence. A short war story follows. The article ends with the stretch ticket list, a template for choosing and tracking the tickets you will take this quarter.

Why Some Tickets Teach and Most Do Not

Most tickets end at the user's screen. The password is reset. The laptop is restarted, the application reinstalled, the shortcut put back. The shared systems behind them are never touched, because they did not need to be. Those tickets teach the user and the organisation, which matters. They teach nothing about infrastructure, because infrastructure is the part that stayed where it was. A technician can close four thousand of them and never once see how the directory, the print server, the gateway or the certificate store actually works.

A teaching ticket is one where the cause is on the far side of that line. The share cannot be seen because the permissions on the server are tangled, not because the user's drive mapping dropped. The printing failed for a floor because the queue on the print server is stuck, not because one laptop lost the printer. The remote user is connected and cannot reach anything because the gateway is sending their traffic the wrong way. Working such a ticket means touching the shared thing. Touching the shared thing is where every skill a sysadmin uses gets learned. There is the added advantage that a real user is waiting, so the lesson is remembered.

These tickets are avoided for good reasons, which is why they are available. They are slow. They are risky. The cause is somewhere the technician has no rights. The honest first-line move is to escalate them, which the escalation articles in this library rightly encourage. The ladder adds one word to that move. Escalate the ticket, and go with it. The queue will not mind. The queue has forty other tickets and no opinion about your career.

The Permission Tangle

A permission tangle is a folder tree where access no longer follows any rule anyone can state. Inheritance is broken part way down. Groups are nested inside groups. There is an explicit deny somebody added in a panic years ago. And a department can see the subfolder but not the folder above it. It arrives as "I can't see the share" or, worse, "I can see something I shouldn't". It is the single best directory lesson the desk ever delivers. Untangling one means reading every rule, understanding why each is there, and finding out who depends on it before you change anything.

What it teaches is inheritance, group membership and least privilege, which are three of the four ideas the directory runs on. The dangerous step is changing inheritance or group membership on a folder that a whole department uses. The change applies instantly to everyone. A mistake either locks out a team or exposes a payroll folder to it. That step is the one the sysadmin watches. Everything before it is yours: the reading, the mapping of who is in which group and which group grants what. It is most of the work. The method for the fix, including the reset-and-rebuild approach that is usually safer than patching, is in Shared Folders and the Permission Tangle. The ladder's interest is in who does the reading.

The Print Server

The print server ticket is the one where a floor, a department or a building has stopped printing, as opposed to one user. The cause is in the queue, the driver or the server rather than on anyone's laptop. It is the most frequently available teaching ticket on most desks. Printers fail with a regularity that nothing else in the building matches. The print server is usually the first shared system a technician is allowed to touch, because the blast radius, while real, is measured in paper.

What it teaches is three things at once. It teaches queues and drivers. Clearing a stuck queue and replacing a driver on the server are the two fixes, and both are done on the shared machine. It teaches networking, because a printer that has stopped answering is the four connectivity questions with toner on them. And it teaches change discipline, because a driver replaced on the server changes printing for everyone who uses that queue. That is why the driver replacement is the dangerous step and the sysadmin's step. The standard way to set queues, drivers and defaults once so that they stop generating tickets is in Drivers, Queues and Defaults Done Once. A technician who has done that work alongside the sysadmin has learned most of what a small print server has to teach.

The VPN Gateway

The VPN gateway is the device or service that remote users connect to in order to reach the office network. The teaching ticket is "connected, but I can't reach anything", which is a different and better ticket than "can't connect". A user who cannot connect at all usually has a client, a password or a second-factor problem on their own device. A user who is connected and cannot reach the file server has a problem in the middle. It is in how the gateway routes their traffic, which names it lets them resolve, or which networks it allows them to see. Working that ticket means reading the gateway's view of the session. Reading it is how a technician learns what the gateway does.

What it teaches is routing, name resolution and the idea of a tunnel. A remote device is on two networks at once, and the gateway decides which traffic goes where. The dangerous step is changing the gateway's configuration, because every remote user shares it. A wrong change disconnects all of them at once, typically at the busiest hour of the day. That step is the sysadmin's. The reading of the session logs, the four questions asked from the remote device, and the comparison of a working user with a broken one are yours. The diagnostic path is in Connected but Can't Reach It. Following it once, in full, with the gateway's logs open beside you, is worth a chapter of any networking course.

The Mailbox Migration

A mailbox migration is moving a mailbox, or a shared mailbox, from one place to another. The move can be between storage on the same mail service, from an old service to a new one, or from one person's ownership to a team's. It arrives as a project rather than a fault, often tied to a leaver, a reorganisation or a department that has outgrown a single inbox. It is the teaching ticket for the mail service, which most first-line technicians know only through "can't send" and "mailbox full".

It teaches the difference between the account and the mailbox, which are separate objects that share a name. It teaches delegation, meaning who may read, send and manage on whose behalf. And it teaches the communication that a cutover needs. A mailbox moved at the wrong moment loses the user a morning and the desk a week of trust. The dangerous step is the cutover itself, the moment the old mailbox stops receiving and the new one starts. The cutover is the sysadmin's step because an error there loses mail rather than delaying it. The preparation, which is most of the work, is yours. That includes the inventory of who uses the mailbox and how, the delegation list, and the rules and forwards that will need rebuilding. It includes the message to the users saying what will happen and when. The delegation model that the migration has to preserve is in Shared Mailboxes and Delegation.

The Certificate Renewal

A certificate is the file a service presents to prove it is what it says it is. That lets a device trust it. Every certificate has an expiry date. The certificate renewal is the job of replacing one before it expires. The teaching ticket arrives in two forms. The calm one is a calendar reminder saying the VPN gateway's certificate expires in thirty days. The loud one is the morning every remote user fails at once and nobody can say why. The calm one is the ticket to volunteer for. The loud one is what happens when nobody did.

It teaches the calendar, which is the heart of sysadmin work. It teaches the chain of trust, meaning which certificate vouches for which. And it teaches the dependency map, because one certificate on one gateway can be what the whole remote workforce signs in through. The dangerous step is installing the new certificate on the service and restarting it. A wrong file or a wrong restart takes the service down for everyone. That step is the sysadmin's. The first time you do it the sysadmin's hand should be near the keyboard. The reading of the expiry dates, the list of what depends on each certificate, the request for the new one and the test plan are yours. Certificates and the Morning Everyone Fails owns the incident. The ladder's interest is in making sure two people know the renewal, not one.

Volunteering Without Being a Nuisance

The sentence that works is short and makes an offer rather than a request: "I'd like to work the Projects share ticket with you rather than hand it over; I'll do the reading and the write-up, and I'll come to you before I touch anything." It tells the sysadmin three things they want to hear. The ticket stays with you, so it is not more work for them. The dangerous step will not happen without them. And a document will exist afterwards, which it would not if they did the job alone at speed. A sysadmin who hears that sentence from a technician who has already read the ticket properly says yes far more often than the technician expects.

Claim the ticket visibly, with a note saying what you are doing and who with. That way, the queue knows it is being worked. The sysadmin can see the state when they come out of their meeting. On a desk with claim-based ownership, as in QuerySolv, the claim and the internal note do that in one move. The rest of the desk stops reopening it to check. Do not claim what you cannot start. If the sysadmin is away for a fortnight and the users are waiting, the honest move is to escalate normally and ask to shadow the next one. The requester's problem outranks your education, every time.

Agree it with your own manager too, in one sentence. A teaching ticket takes longer than an escalated one, and your closed count will show it that week. "I'm working 5519 with Grace instead of escalating it; it will take me most of two afternoons and I'll have a runbook at the end." A manager who has read the ladder card will protect those afternoons. A manager who has not will ask why your numbers dipped, and the answer is on the card.

Working It With the Sysadmin, Not Handing It Over

Three rules make the arrangement work, and they are the same for all five tickets. First, you keep the ticket. It stays claimed by you. You write every note and update the requester. The sysadmin is a consultant on it rather than its owner. Second, the sysadmin watches the dangerous step. The one change that touches the shared thing is made with them beside you, or by them with you watching the first time. It is never made by you alone until they say so. Third, you write it up, all before the ticket is closed. Write the ticket note a stranger could act on, the runbook if the job will recur, and the change record if a shared thing was changed. The table below gives the five tickets against those rules.

Handing the ticket over completely is the failure the three rules prevent. It is faster for everyone that week. The sysadmin does the job in twenty minutes from memory. The requester is happy, and nothing has been learned or written down. So the next time the same ticket arrives it goes to the same person for the same twenty minutes, until the day that person is not there. The arrangement in the table is slower once. It is faster every time after that, for the desk as well as for the technician.

Writing It Up So It Counts

The write-up is what turns a ticket into evidence, and evidence is what the ladder runs on. The ticket note comes first, written for the stranger who opens it in a year. It records what the user reported, what you read and found, and what was changed and by whom. It records how to undo it, and what the user was told. Then write the runbook, if the job will happen again, which for all five of these tickets it will. Write the change record, if a shared thing was changed, which for all five it was. Link the related tickets together: the four "can't see the share" incidents to the one tangle they came from. That way, the record shows the cause and not just the cases. Linking tickets is ordinary in most tools, and it is the single habit that makes a problem record visible later.

Then put the ticket number on the ladder card and the skills inventory, in the evidence column. Add one line saying what you did and what the sysadmin did. "5519: permission tangle on the Projects share; mapped eleven groups and found the broken inheritance; Grace made the rebuild with me watching; runbook written." That line, read by a manager or by a sysadmin at another employer, says more than any adjective. Five such lines, one per ticket type, over a year, are most of a case for the next rung. They are also, not by coincidence, the desk's documentation for five jobs it used to do from one person's memory.

A Short War Story: The Renewal Nobody Watched at Redbrook Engineering

Grace had renewed the VPN gateway's certificate herself every year at Redbrook Engineering. It took her twenty minutes, and explaining it would have taken an hour. When Yusuf asked to watch she said, kindly, next year. Grace left in the spring for a larger firm. The calendar reminder for the renewal lived in her personal calendar and left with her. On a Monday morning in the autumn the certificate expired, and seventy engineers at client sites could not connect to anything until early afternoon. The contractor who covered the sysadmin role took five hours to establish which certificate, on which device, had expired, because nothing was written down. It took another hour to find out how the previous one had been requested. The cost was a morning of seventy engineers, a contractor's day, and a client who noticed. Yusuf by then knew the gateway from the connected-but-can't-reach-it tickets. That week, he wrote the renewal runbook from what the contractor had worked out. The calendar entry was in the desk's shared calendar rather than anyone's own. The twenty-minute job that was quicker to do than to teach had cost the company a day. The lesson was the one the ladder always teaches: the second person is the cheap part.

The Stretch Ticket List

The stretch ticket list is the quarter's plan for which teaching tickets you will take. It is agreed with the sysadmin and your manager at the start and reviewed at the end. It names the ticket type, what it will teach, who will watch the dangerous step, and what you will write afterwards. It has a status column so that at the review nobody has to remember. The standing rules at the bottom are the three from this article, written down so that the arrangement survives a busy month. Keep it to three to five tickets a quarter. With more than that, the desk's work suffers. With fewer, the quarter passes. The queue decides which arrive, so the list says "the next one of these", not a ticket number, until one does.

THE STRETCH TICKET LIST — ONE QUARTER
Technician: ______________   Sysadmin: ______________   Manager: ______________
Quarter from: ________  to: ________        Reviewed on: ________

STANDING RULES
   1. I keep the ticket: I claim it, write every note and update the requester.
   2. The sysadmin watches the dangerous step; I do not touch the shared thing alone.
   3. I write it up before I close it: note, runbook if it recurs, change record if a shared thing changed.
   4. The requester's problem outranks my education; if I cannot start it this week, I escalate it normally.

THE LIST (the next one of each that arrives)
   Ticket type                    What it teaches              Watcher        Dangerous step            Status     Written up
   [ ] Permission tangle          inheritance, groups          __________     inheritance / membership  ________   note [ ] runbook [ ] change [ ]
   [ ] Print server               queues, drivers, network     __________     driver / queue on server  ________   note [ ] runbook [ ] change [ ]
   [ ] VPN gateway                routing, names, the tunnel   __________     gateway configuration     ________   note [ ] runbook [ ] change [ ]
   [ ] Mailbox migration          account vs mailbox, cutover  __________     the cutover               ________   note [ ] runbook [ ] change [ ]
   [ ] Certificate renewal        calendar, chain, dependencies __________    install and restart       ________   note [ ] runbook [ ] change [ ]
   [ ] Other: ___________________ ___________________________  __________     ______________________    ________   note [ ] runbook [ ] change [ ]

AT THE REVIEW
   Tickets taken: ____   Runbooks written: ____   Change records written: ____
   What I can now do alone (the sysadmin agrees): ____________________________________
   What still needs a watcher: ____________________________________________________
   Next quarter's list starts with: ______________________________________________

Yusuf's list for that first quarter had the permission tangle on it with Grace's name as the watcher and "5519" written in by the second week. The rebuild took two afternoons, as he had told his manager it would, and the runbook was used by another technician inside a month. The desk had worked that share from Grace's memory for six years. It took one person refusing to hand a ticket over to change that.

Frequently Asked Questions