Counting Computers
Summary: 250,000 clients is not the same as 250,000 computers, and 250,000 clients over a 30 day cycle is not the same as 250,000 clients over a 14 day cycle. So let's define our terms before talking computer counts.
In this business we’ve got plenty of challenges. One of the least obvious (at least to those not intimately involved) would be counting clients. Your boss comes to you and asks “how many computers do we have?” “323”. “Thanks.” If your organization is a bit larger, you’re talking thousands. Some of us are going to have tens or hundreds of thousands. On those scales, the first problem we have is that you can’t personally run around and sanity check the answer. You can’t even call up 5 guys who can run around and do the sanity check for you. But the bigger problem is, what is a “computer”? “Come, on Paul”, you say, “see that keyboard you’re typing on? Follow its cable to the end – that’s a computer.” End of discussion. Fair enough. But what if it dual boots? Sure, it’s still one computer, but if I’m doing security patches (aren’t we all?), then I want to patch both instances. So that’s 2 things. We’ll call them clients. If I patch one but not the other, then when the other client comes online it will have the potential to infect my other computers. Or mount a denial-of-service attack on the network. Or send confidential data to outsiders. Or cause the disk to be reformatted and thus serious data loss. So when I’m counting computers I really care about the one computer, but when I’m patching I really care about the two clients. What about if there are virtual PC’s on it? Same problem. Eventually the computer is old and the user gets rid of it. Then it’s not a computer or client from my point of view. Will the user tell me they got rid of it? Surely not – that’s a tough problem. But a discarded computer doesn’t report any data onto the network (such as SMS data or Active Directory computer password resets or DHCP requests). So if I have the computer recorded in one of those databases and none of the data has been updated recently, then the computer is gone. Problem solved. Except that a computer that is offline also doesn’t update its data in those databases. A computer can be offline because it’s on the road (maybe it’s on someone else’s network, but not mine). Or the user temporarily doesn’t need it and so it’s powered off. Or the user is on vacation. Or the computer is broken just enough that it doesn’t update the relevant database. All valid scenarios. That certainly complicates things, but vacations or road trips only last so long. Eventually the user needs the secondary machine. Eventually the broken machine gets fixed, somehow. So let’s give it a time-limit. If the computer reports within the time-limit, then it was gone temporarily. If it doesn’t report in that time, it’s gone permanently, and so we don’t count it any more. What’s the right time-limit? That will vary from organization to organization. Within Microsoft, it’s painful to take vacations longer than 1 week, so 2 weeks might be good. But we also have a lot of testers (almost every employee does some kind of testing, and almost all have more than one machine). Road trips can easily last a week or two. So we’ve long ago settled on 30 days. But if you don’t have many secondary machines or testers, then 2 weeks (plus maybe a few days) might be right, allowing for 2 week vacations. Fair enough? If so, we learned some things:
- Computers (physical machines) are not the same as clients (computer-like things that I want to patch)
- So the right answer to the boss’s question depends on whether he’s interested in doing asset management or patch management
- There are plenty of sources of answers to the questions of how many clients we have (SMS, AD, DHCP, physical counting, etc.)
- Off-line computers/clients are indistinguishable from decommissioned computers/clients
- Setting a time-limit allows us to make a reasonable guess to divide the off-line from the decommissioned
I suggest that as computer management specialists, we mostly deal with problems that relate to clients rather than computers. In other words, we want to know how many computer instances we should patch, or upgrade the software on. Sometimes we want to count the computers, for accounting purposes, but that’s a less common problem. So when we’re quoting counts, we should quote client counts unless someone asks us for computer counts. Even if they use the word “computer” we should ask whether they really want to know the count of physical machines. I also suggest that when we’re quoting client counts, we should specify our time-frame. So at Microsoft we currently have 250,000 30-day clients. Someone that has 250,000 14-day clients is more aggressive than we are in their client counting. If their user behavior is more predictable, allowing them to use that smaller time-limit, then they’re probably more accurate than we are. So I’d be more impressed by an organization that has 250,000 14-day clients than another that has 250,000 30-day clients.