Installing It: Packages, Standard Images and the One-Off

Monday, 09:20, at Ashgrove Housing. Ben has an approved ticket to put the tenancy-mapping program on three housing officers' laptops. He installs the first copy from the supplier's download page, clicking through the installer and typing the licence key from a sticky note on the monitor. The second he installs on Tuesday from a link in an old e-mail, which turns out to be a slightly older build. The third he lets the housing officer install herself, because she has local admin rights from a project two years ago. She accepts every default, including a toolbar. By Friday the three copies behave three different ways, the sticky note has been photographed by two people, and the ticket says "installed x3". Nothing is wrong yet. It is simply that nobody could now say what is on which machine, and the first person to ask will be the supplier.

Installing is the work step of a software request, the part where a program is put on a machine so that it runs. It is the step most desks do well and record badly. A package is an install prepared once so that it runs the same way every time, with the same settings and the same build. Usually a tool pushes it to machines. A standard image is the set of programs every new machine gets before anyone asks. A one-off is an install done by hand, on one machine, by a technician clicking through. This article is part of our Software Installs & Licence Requests series. It is about choosing between the three and doing the one-off properly when it is the only option. It covers answering the admin-rights question honestly and writing the record that makes the install findable in a year.

It starts with the three ways to put a program on a machine and the standard set on the image. Next come self-service installation where the tools allow it and the one-off manual install done with discipline. Then it covers the admin-rights question, testing and handing over, and the install record and why it exists. A short war story and the install record to copy finish the article.

Three Ways to Put a Program on a Machine

There are three ways to install a program. The choice between them is about how many times the install will happen and how much the desk needs each copy to be identical. The image is for programs everyone gets: the install happens once, when the image is built, and every machine inherits it. The package is for programs some people get, more than a few times a year: the install is prepared once and repeated by a tool, identically, on request. The one-off is for the program three people will ever have: the technician installs it by hand and writes down exactly what they did. Each is right for its case, and each is wrong for the others, in ways that show up months later as three copies that behave three different ways.

The table below is the three methods with when to use each, what each costs the desk, and the failure that follows from using it for the wrong case. Read the last column before deciding, because the failures are the expensive part and they are all slow to appear.

Most small desks run all three, and the proportion is the thing to watch. A desk where every install is a one-off is doing the same twenty minutes over and over and calling it support. A desk that packages everything has a technician who enjoys packaging, which is a fine quality and an expensive one. The honest rule is that a program becomes a package when its third one-off is requested. It goes on the image when the role profile says every new starter in that role gets it. That is a decision the onboarding series makes in Role Profiles and Standard Kits. This article inherits that decision.

The Standard Set on the Image

The image carries the programs that everyone in the organisation, or everyone with a given kind of machine, needs before they have asked for anything. The discipline is to keep it small. Mail, the office suite, the browser the organisation supports, the security agent, the remote support tool, the document reader, the conferencing client: the set a new starter in any role would be stuck without on their first morning. Everything that depends on the role goes in a role bundle, installed as packages after the image. An image that carries the finance system, the drawing viewer and the clinical records client for every machine is paying for seats on laptops in the warehouse. The image is a decision about what everyone gets. Make it a short one.

Treat the image as a catalogue entry in its own right, with an owner and a review date. Programs drift onto an image the way they drift onto a committee's agenda. Someone needed it once, it was easier to add than to package, and three refreshes later nobody remembers why it is there. Once or twice a year, list what is on the image beside what the last fifty new starters actually opened in their first month. The desk can tell what they opened from the tickets and the licence register. Take off anything that fewer than most of them used. The removed programs become packages, and the role bundle for the people who did use them picks them up.

Refresh the image on a calendar, not when it breaks. An image that has not been rebuilt in a long time installs old builds of everything. It spends its first hour on every new machine updating itself, which is an hour the new starter watches. Put the rebuild in the same calendar as the licence renewals, which the licence tracking article in this series keeps. Then the two reviews happen together. The image's programs are checked against the seats the organisation actually owns at the same time. An image is a decision made once and inherited by every machine after; the calendar is how the decision gets looked at again.

Self-Service Where the Tools Allow It

Self-service installation is the user picking a pre-approved program from a list and the machine installing it without a technician. Where the organisation's management tools can offer it, it is the fastest lane there is. The user opens the tool's catalogue on their own machine and chooses the program. The package installs in the background, with the desk's settings and the security look's conditions already baked in. No ticket, no wait, no technician's twenty minutes. The list the catalogue offers is the pre-approved list from the approvals article, and the two must be kept the same. A program on the pre-approved list that is not in the self-service catalogue is a ticket. A program in the catalogue that is not on the pre-approved list is a decision nobody made.

Paid software in self-service needs the seat check somewhere, and most small-desk tools cannot do it. So the honest shape is that free pre-approved programs are self-service. Paid ones go through a ticket for the seat count and then a package push. This is slower by a day and it is the difference between a licence register that is right and one that is a guess. If the tool can count seats and refuse the install when they are out, use it; if it cannot, do not pretend. A self-service catalogue that hands out the eleventh copy of a ten-seat licence has moved the audit letter from unlikely to scheduled.

Where the tools allow nothing of the kind, which is the case on many small desks, self-service is a knowledge base article. "Software you can have, and how to ask" lists the pre-approved programs, says which are already on the image, and links the request form with the entry pre-selected. It is not self-service in the sense of no technician. But it is self-service in the sense that matters to the requester, which is knowing the answer is yes before they ask. If you run QuerySolv, that article sits in the knowledge base as one visible to everyone rather than agents only. That puts the list where a requester looks before they raise a ticket. The ticket they raise is the one that says "from the list" at the top. The desk's twenty minutes is still spent. The requester's three days of wondering are not.

The One-Off, Done With Discipline

The one-off install is the technician putting a program on a machine by hand, and it is not a lesser method. It is the method whose quality depends entirely on the technician writing down what they did. Ben's three copies at Ashgrove went wrong because the second came from a different source than the first. The third was installed by someone else with different choices. None of those facts was recorded. The one-off done properly is the same install three times, from the same source, with the same choices. The record is how the second and third technician know what the same means.

Get the installer from the supplier's own site, every time, and write down where. Consider a link in an old e-mail, a copy on a shared drive from a previous install, or a download found by searching the program's name. Each is a way of installing something other than what was approved. The third is a way of installing something nobody would have approved at all. Download it from the source the approval named and note the build identifier the supplier shows. Keep that installer in the desk's own software store with a name that says what it is and when it was fetched. Install the next copy from the store rather than fetching it again. The store is a folder. It needs no tool. It needs a naming convention and a technician who uses it.

Make the same choices every time, and write them down the first time. Installers ask questions: where to put the program, whether to add a toolbar, whether to send usage data, whether to start with the machine, whether to install the extras. The security look's conditions answer some of them ("data sharing off"), and the desk's preferences answer the rest. The install record for the first copy lists each choice so that the second copy makes the same ones. A one-off installed with "accept every default" is a one-off installed with whatever the supplier wanted that month, which is sometimes a toolbar and occasionally worse.

The licence key never goes on a sticky note, in the ticket note, in the e-mail to the requester, or in the knowledge base. It goes in the team's secret store, the same place the desk keeps every other credential, with the entry named for the program and the licence. The install record says "key: in the secret store under the drawing-office licence" and nothing more. A ticket's internal note is read by every technician and kept forever; a key in it is a key shared with everyone who will ever work on the desk. The internal note never carries a secret, in any tool. The key on Ben's monitor had been photographed twice by Friday, which is two more copies of the licence than the organisation had bought.

Do the one-off over a remote session or at the machine, with the requester reachable at the end, and never by sending the requester an installer and a key. The requester installing it themselves is the third copy at Ashgrove: every default accepted, a toolbar, and a licence key now in the requester's inbox. Where the desk's remote tool allows an unattended session, the install can happen while the requester is at lunch, with a note when it is done. The handover test, below, happens when they are back. The twenty minutes are the desk's, by design. They are what the record is bought with.

The Admin-Rights Question

Sooner or later a requester asks for administrator rights on their own machine "so I can install things myself and stop bothering you". The honest answer is that the organisation gives rights for the work a person does, not for the convenience of the desk. That is the principle in Least Privilege Under Pressure, applied to the one permission requesters ask for most. Administrator rights on a machine let the holder install anything, change anything, and disable the things the organisation put there to protect the machine. They do all of that for malicious software too, which runs with whatever rights the person who opened it had. A machine whose user has admin rights is a machine whose every mistake is a full one.

The need behind the request is real, and it is nearly always one of three. The requester installs software often, in which case the fix is self-service for the pre-approved programs and a fast lane for the rest, not a permanent key to the machine. The requester runs a program that demands admin rights to work at all. In that case the program is the problem, and the security look should have caught it. The desk works with the supplier or finds a way for the program to run as an ordinary user. Or the requester is a developer, a tester or an engineer whose daily work genuinely needs elevated rights on their own machine. In that case the answer can be yes, with conditions written in the ticket. These include a separate administrative account used only when elevating, not for mail or browsing, and a review date. They include the understanding that the desk does not support what the holder installs with it.

Where the tools allow it, a time-boxed elevation is the answer that serves everyone. The user is granted administrator rights for an hour, for a stated purpose, with the grant logged. The rights expire on their own. Some management tools can do this. Many small desks have nothing of the kind, and the honest alternative is the desk installing, promptly. That is cheaper than it sounds once self-service has taken the routine requests away. What a desk must never do is grant permanent admin rights to save itself the twenty minutes. It saves twenty minutes once and spends them, with interest, on the day the machine opens the wrong attachment.

Record the admin-rights decision in the ticket whichever way it went, with the reason and, for a yes, the conditions and the review date. The leaver audit in the offboarding series finds the admin accounts nobody disabled. The access review in the access series asks whether each one is still needed. Both read the ticket that granted it, and both find nothing if the grant was a quiet favour. An admin right with no ticket is an exception nobody can review, which makes it permanent by default.

Testing and Handing Over

An install is finished when the requester has done the thing the one-line business case said they needed, not when the installer's last screen says it is. "Open it, and open the drawing you needed to compare" is the test. A program may install cleanly but be unable to open the organisation's files, reach the licence server from the home network, or print to the line printers. In that case, it is not installed in any sense the requester cares about. The ticket closed at the installer's last screen is a ticket reopened on Monday. The test takes the requester two minutes and is the only test that counts.

Close with a reply that says what was installed, where, and how to tell the desk if it misbehaves, and ask the requester to confirm. The silent close, where the status changes and nobody is told, is the subject of Avoiding the Silent Close, and it is the commonest way a good install becomes a bad ticket. The requester who replies "works, thanks" has given the desk its confirmation. The one who replies "it opens but the toolbar is in the way" has reopened the ticket. A requester's reply to a resolved ticket does that in most tools. That install is not done until the toolbar is gone. Most installs are done in one pass. The reply is how the desk finds the ones that were not.

Where the program is new to the organisation, put a line in the knowledge base at the same time: what it is for, who may have it, who to ask. The next requester finds the line before they raise a ticket, and the next technician finds the install record linked from it. A knowledge base that knows what the organisation runs is the cheapest software catalogue there is, and it is written one line at a time, at close, by whoever did the install.

The Install Record and Why It Exists

The install record is the closing note on the install ticket. It holds what the organisation will need to know about this copy for as long as the copy exists. It says what was installed, as the supplier names it and with the build identifier. It gives the machine's asset name, the source, the method and the licence seat it used. It records which choices were made and which conditions applied, which ticket held the approval, and who tested it. Nine facts, two minutes to write, and the answer to every question anyone will ask about the copy later. "Installed x3" answers none of them.

Four people will read it. The next technician, when the program misbehaves, needs the build and the choices, because "it was fine on the other two" is only useful if the other two were installed the same way. The licence register, which is the subject of Licence Tracking Without a Tool, is built from the seat line. Without that line the register is a count of installers downloaded rather than copies in use. The offboarding checklist, when the housing officer leaves, needs the machine and the seat so that the seat comes back. And the supplier, when the audit letter arrives, needs the count. A desk that can answer from its closed tickets answers in an afternoon. A desk that cannot answers in a week of walking round.

Most small-team help desks have no asset module, QuerySolv included. The device name in the install record is a field on the ticket or a line in the note, which is enough. The link between a program and the machine it lives on is a sentence, not a database, and the asset series shows how far a sentence goes in Linking Devices Without an Asset System. Write the device name the way the desk names devices everywhere else. That way, a search for the machine finds every install on it, and a search for the program finds every machine it is on. Those two searches are the audit, and the register, and the offboarding check, and they only work if the note was written the same way every time.

A Short War Story: Fourteen Stock-Count Installs at Northgate Retail

Northgate Retail bought a stock-counting program for fourteen stores. A technician called Jamal installed it on each store's back-office computer over three weeks. He drove round with a download link from the supplier's welcome e-mail. The download changed build twice during the three weeks without the link changing. He typed the one licence key into each installer from a text message he had sent himself, accepted the defaults, and closed the parent ticket with "all 14 stores done". Four months later the supplier's audit letter asked how many copies were installed and on which machines. Northgate's answer took three working days and two technicians. The stores had since swapped two computers. One store had reinstalled after a fault using an installer found by search. Nobody could say which build was where or whether the key had been used more than fourteen times. The honest count turned out to be sixteen, and the supplier invoiced for two. The desk lead, Fatima, costed the reconciliation at about forty hours, against the fourteen two-minute records Jamal had not written. She put the install record on every install ticket from then on as a required close. The lesson she wrote on the whiteboard was shorter than this paragraph: an install you cannot find is an install you will pay for twice.

The Install Record

The record below is the closing note on every install ticket at Ashgrove now. It is filled in by the technician who did the install, at the machine, before the ticket closes. An install record written on Friday from memory is a guess with a date on it. The first block identifies the copy; the second says how it was done; the third is the handover. Where several machines get the same program from one approval, each machine gets its own linked ticket and its own record. In that case, the parent ticket holds the approval and the seat allocation. Keep the "choices made" line honest and specific; it is the line the next technician reads first.

INSTALL RECORD — ONE PER MACHINE, WRITTEN AT INSTALL TIME
Ticket: ________   Parent / approval ticket: ________   Date: ________

THE COPY
  Program (as the supplier names it): ______________________
  Build / release identifier shown by the installer: ______________
  Machine (asset name): ______________   User: ______________
  Licence: ______________   seat ____ of ____   key: in the secret store, entry ______________

HOW IT WAS DONE
  Method:  [ ] standard image   [ ] package, pushed   [ ] self-service   [ ] by hand
  Source:  [ ] supplier's site, fetched ________   [ ] desk software store, file ______________
  Choices made in the installer: ______________________________________________
  Conditions from the security look applied: ______________________________________
  Settings changed after install: _______________________________________________
  Admin rights involved:  [ ] none   [ ] desk elevated for the install   [ ] user holds admin: ticket ________

HANDOVER
  Tested by the requester doing: ______________________   result: ______________
  Closing reply sent:  [ ]     Requester confirmed:  [ ]  on ________
  Knowledge base line added or updated:  [ ]   Register updated:  [ ]
  Installed by: ______________

Ben re-did the three tenancy-mapping installs the following week from one installer in the desk's store. He used the same choices on each, moved the key into the secret store, and wrote three records in six minutes. The toolbar came off the third laptop. The sticky note went in the shredder, and the two photographs of it were deleted by their owners after a conversation that was shorter than this sentence. The three housing officers noticed nothing except that the program now behaved the same way on all three machines, which is the whole of what a good install looks like from the outside.

Frequently Asked Questions