The import that never ends
We have watched more than one inventory project start with a grand import. Every server from the virtualization platform, every device from the network scanner, every user from the directory. Twelve thousand records on day one. Then the team looks at twelve thousand unconnected rows, feels tired, and goes back to the spreadsheet.
The rows were never the point. The point is the connections between them, and connections are drawn by people who understand the service. So the advice in this guide is deliberately small: describe one service, properly, before you touch anything else.
Pick the right one
Choose a service that matters enough that people would notice it failing within an hour, and is small enough that one person understands it end to end. Payroll, the internal wiki, printing, the VPN people use from home. Not the big accounting system. That one comes in month three, after the first few services have taught you how you like to describe things.
If you look after other companies’ IT, pick one client and one of their services. If you are the only administrator, pick the thing that would ruin your holiday.
Write down the chain, top to bottom
Start at the top with what the business sees: a product called “Payroll”, not “the SQL server in rack 4”. Under the product, create the service. Under the service, one or more running copies (instances): production, test, maybe a second region. Under each instance, the servers it runs on.
Then the things around it. The physical hardware if the server is not virtual. Its network addresses and the network segment they belong to (the subnet). The software and the licence that covers it. The room and building. The accounts the service uses. The monitoring checks that watch it. The backup rule, so the question “is this backed up, and how often?” has an answer on the record instead of in someone’s memory.
At every step, link instead of retyping. The server’s location should come from the rack, the rack’s from the room, the room’s from the building. AverDesk passes these details down the chain and shows you when two parents disagree, so you choose. This is usually the moment people discover their spreadsheet had three different spellings of the same data centre.
Let the record become the documentation
Here is where a connected inventory stops being a list and becomes documentation. On the service, record the ports it listens on. Record the outside things it depends on: a payment provider, a mail relay, a licence server you do not own. Record where the backup site is and what it would take to switch over to it.
You will be tempted to put this in a wiki page. Don’t. When this lives on the service record, replacing a server or changing a port changes the documentation itself, with a history that says who did it and when. A wiki page about a server is out of date the day after someone touches the server. A service model is the server.
Decide who may see what
Before you invite anyone, think about who needs access to what. In AverDesk this has two halves, kept apart on purpose. Teams decide which assets a person can reach. Roles decide what that person can do with them. An invitation can carry rights to specific objects, so a contractor can be given one service and nothing else.
Anything a person may not see is hidden, not greyed out, so the model looks complete to everyone at their own level. When something is refused, the refusal says why. A person who works in several organizations is counted once for billing, which matters for service providers and for holding structures.
For one service, this is a five-minute decision: the owner, the team that operates it, and perhaps the manager who wants to look. Get that right once and it becomes the template for every service after.
Live with it for two weeks
Now stop describing and start using. Send the problems and requests for that service through the service desk. Announce the next planned maintenance against it and watch the list of affected things fill in. Install the agent on one of its servers and look at the status bar. Reboot something and check the server page first.
Two weeks is enough to find out which fields you actually look at and which kinds of connections you wish existed. Adjust the dictionaries. Then pick the second service. By the fifth you will have a shape you trust, and the big import, when you finally do it, will land in a model that knows where everything goes.
If you do not have an organization yet, start with the Free plan. It includes a demo organization, which is a good place to describe your first service twice: once to learn, once for real.
Read next
What AverDesk is and who it is for
A plain description of the product: a list of everything your company runs, a map of what depends on what, and a help desk, all in one place.
· 6 min read
Nothing comes in: how AverDesk gets your data
To see your servers, an inventory tool usually asks you to open a door into the network. AverDesk does not. Here is how the data gets out without anything getting in.
· 5 min read