Endpoint Insights
How to Perform a Basic Software Audit
Topics: Endpoint Insights
I originally wrote this blog post about how to perform a basic software audit back in 2009. It’s still one of my most popular blog posts ever! Why? Many people still want to know the basics about how to perform a software audit.
The second reason why this post has become one of my most popular posts is because a lot of folks need to know how to explain to someone why it’s a bad idea to create a report about all of the software installed on every computer.
I’m not simply talking about a count of software titles, I’m talking about a list of each software title on each computer. What could that encompass? In my small lab of 37 computers (see the screenshot below) there are over 4000 rows of data! Imagine the amount of data in a far bigger environment.
Together with my wife, who is an auditor, we’ve developed a list of high-level guidelines about how to review your environment to help with software licensing. Do you want to ensure that your software installs are compliant? Do you want to know whether you’re over-licensed or under-licensed? Then make sure to follow the guidelines listed below on how to perform a basic software audit.
Background
Sometimes ConfigMgr Admins are asked to put together a report that lists all of the software installed on each computer. This is a bad idea because of data overload, not to mention the amount of paper needed to print such a report.
I’m going to prove why this is a bad idea by showing you the average number of software titles per computer, and the number of pages this would amount to in a report. By the way, since my original post was published, Windows 8, 8.1, and 10 were released, so the average number of software titles per computer has dropped, but it is still a lot as you will see below.
To help me illustrate, check out the screenshot below of a report within Endpoint Insights titled ‘Basic Software Statistics’. It answers the following questions:
- How many computers are there?
- How many distinct software titles are there?
- What is the total number of software titles?
- What is the maximum, average and minimum software titles per computer?
- How many pages, reams, or trees would this report amount to if it was printed?
- What are the top 10 computers with the most software titles?
- What are the top 10 most installed software titles?
Quickly reviewing this report, you can see that for 37 computers, it would take 57 pages to print off a report about all of the software installed on each computer! By the way, the average number of software titles has indeed dropped from what I documented in my previous 2009 blog post; it’s down from 186 to 121 titles. That’s almost a full page!
At this point, you might be wondering how I determined the amount of pages needed to print such a report. The answer depends on the type of font, font size, page size, etc. Do you remember the old dot matrix printers? They used Courier New, 9pt font with no margins. You would end up getting 77 lines per page using 8.5” x 11” letter-sized paper. In my example, however, I’m going to say that 80 lines will fit on each page.
How many pages per computer would you get?
121/80 = 1.5125 pages per computer.
How many pages would be needed for a report about 10,000 computers?
1.5125 * 10000 computers = 15,125 pages!
That’s about 15.125 reams of paper, double-sided!
A tree will produce 16.67 reams, therefore you would kill over 90% of one tree!
Now you can see why this is an unrealistic request. A report of this size will overwhelm anyone who would even try to read it!
What is a Software Audit?
The purpose of software audits are often straight-forward: to determine whether the software installed on company-owned computers was obtained legally and was authorized for use by the appropriate staff.
Sometimes software audits are conducted for legal reasons (e.g. to verify that there are sufficient licenses to cover software use, as in a software copyright audit), or to make sure staff are using the same software versions, or to ensure that there are no surplus licenses.
Getting Started with an Audit
Before you even start you need to determine a few things:
- What is the purpose of the audit?
- Are you trying to determine if you are over-licensed or under-licensed?
- What software titles do you care about? “Everything” is NOT an option.
In the Basic Software Statistics report (above screenshot), do you really care about Service Pack 1 for Microsoft Office 2013 (KB2850036) 64-Bit Edition or Microsoft Silverlight? In a software audit you won’t care about either of those software titles because neither of them are licensed. You need to ask yourself, “What exactly do I need to know?” Only licensed software? What specific software? CorelDraw, Microsoft Office 365, Oracle database, etc.?
- What level of risk are you willing to live with?
There is no point in moving forward if you don’t know the goal. For example:
- Are you trying to determine if you are over-licensed on Microsoft Project?
- Are you trying to determine if you are under-licensed on SAP?
- Are you trying to determine how well your purchasing controls are working?
- Are you trying to get an idea as to your licensing status and this is the first phase of the project?
- How to Perform a Basic Software Audit
Doing an audit can be a huge project and should not be taken on without some planning.
1. Understand your environment and the data.
a) Review your ConfigMgr settings:
- Is your hardware inventory schedule set to daily, weekly or monthly?
- What are your delete aged data settings?
- Are computers removed from AD when they are decommissioned?
b) Are all computers (including servers) within ConfigMgr?
- What about computers within the DMZ?
c) How do you manage remote computers?
- Notebooks/laptops?
- On average how often do these computers logon to the network? Or return inventory to ConfigMgr?
d) Are you proactively resolving client health issues?
2. Do you have a computer lifecycle plan?
a) How often are computers replaced?
b) How do you determine what software should be migrated from one computer to another?
c) What happens when someone moves jobs? Is the list of software on their computer reviewed to see if anything should be removed or added? Does the computer go with them or stay in the old office?
d) Are computers re-imaged between users that use them?
3. Software lifecycle management.
a) Are you using old versions of software?
b) What policies are in place to upgrade older versions of software?
c) Who pays to upgrade old software?
4. Policies.
a) Do you audit who is an Administrator on each computer?
b) Do you review the software procurement process on a yearly basis?
c) Do you review how software is installed on each computer? Is it automated (ConfigMgr), is it done by a technician, or both?
d) How are exceptions to the software procurement process handled?
e) When did management last review and approve the software procurement policies?
f) How is software licensing controlled?
g) Is software licensing reviewed to ensure accuracy?
h) Is software removed when it is no longer being used?
5. Reporting data.
a) Print and review the, “Count of Add/Remove Programs (ARP).” In newer operating systems, ARP is also known as, “Program and Feature,” however, in the backend it will still be seen as ARP. To complicate things even more, within ConfigMgr, ARP is now called, “Installed Applications.”
- Make a list of the software titles that you want to audit based on the, “Count of Add/Remove Programs.”
- Print and review the outliers.
6. Software audit.
a) What computer has the maximum number of ARPs?
b) What computer has the minimum number of ARPs?
c) Based on the number of sites and size of those sites, randomly select a statistically significant sample of computers. Print and compare the ARPs on the computer itself to ConfigMgr data. About 100 computers should be enough. If you can’t compare the ARPs to ConfigMgr data for one of the 100 randomly selected computers, explain why not.
d) Create a report that shows the last hardware inventory dates.
e) Conclude how reliable the data is within the above reports.
7. Testing the reliability of the data.
a) Of the 100 sample computers, randomly select 30 of those computers and perform a full audit.
- Compare the physical data about those computers: CPU, RAM, and hard drive size.
b) If the data does not match, why not? Is it an isolated, timing or a consistent error issue in the larger population of data?
c) If errors are judged to be based on timing or an isolated issue, do you need to increase the number of computers that need to be tested?
8. Calculations.
a) Compare the number of computers in AD to ConfigMgr.
b) Compare the number of computers in ConfigMgr to AV console data.
c) What is an acceptable number of computers missing from the AD/AV console?
d) Determine when the software was last executed by employing recent application dates.
9. Prepare the report and recommendations.
a) What risks are there?
b) What improvements can be made?
c) What areas are under control?
d) How can end-user services be improved? Or, answer the question, “Why do end-users by-pass IT and install software themselves?”
10. Schedule a follow-up software audit.
a) It does no good to do a one-time audit; you need to compare the software audit over time to determine if you are getting better. A six to 12-month timeframe is good.
b) Schedule a yearly review of all relevant policies.
11. Present findings to management.
Conclusion
1. By using these guidelines you will be following generally accepted audit standards.
2. The amount of paper used for software audit reports will be significantly reduced.
3. Following audit standards to perform an informal software audit is something that anyone can do without too much trouble. Compared to a request for a report listing all software installed on every computer, there will certainly be no information overload!
I hope that you find these guidelines on how to perform a basic software audit useful and if you have any questions, please feel free to contact me @GarthMJ.
