Time and time again the question of “I need a report of all software for all PCs” is posted to the forums / mailing list / newsgroups and every time it is going to be used for a software audit. This is an unrealistic request. Some may ask why. So let us do some math.
· 80 lines per page
· Average of 186 entries within Add/Remove Programs.
· Total site hierarchy of 10 000 clients
· 500 sheets of paper in a bundle
186/80 = 2.325 pages per PC
2.325 * 10000 PCs = 23250 pages for all software on all PCs! Or
46.5 bundles of paper!
Who will ever read this? No one! This is why this is an unrealistic request!
So why am I posting this blog post? The answer is simple; there are far too many people out there that need to know the basics of how to perform a software audit. I’m lucky enough to work with an auditor and here are our guidelines on how to review your environment to help ensure that you understand your software licensing. These are high level guidelines only.
Before you even start you need to determine a few things:
What is the purpose of the audit?
What is it you are trying to establish?
There is no point in moving forward if you don’t know what the goal is. For example:
· Are you trying to determine if you are over licensed on MS Project?
· Are you 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?
Doing an audit can be a huge project and should not be taken on without some planning.
1. Understand your data
a. Review your ConfigMgr settings
i. Hardware Inventory setting
ii. Delete Aged Data setting
iii. SW metering rules
b. Review AD
i. Are PCs removed from AD when the PCs are decommissioned?
c. Are all PCs (including servers) within ConfigMgr?
d. Do you have remote PCs?
ii. On average how often do they logon to the Network?
e. Are you proactively reviewing your PCs data and resolving issues that arise?
2. PC life cycle management
This might seem odd to talk about PC life cycle management but the answer is simple. If you install SW for a person doing a particular job and the person moves job what happened to the SW? Even worse what do you do when someone gets a new PC, do you install all the SW that existed on the old PC? Who reviews what SW is still needed by that user when they get a new PC?
a. What is the PC replacement life cycle?
i. How is SW transfer to the new PC?
b. When a person changes job do they keep their PC?
i. Is SW they don’t need removed?
3. SW life cycle management
a. Are you using old versions of SW?
b. What policies are in place to upgrade old versions of SW?
c. When a person changes job does anyone review what SW they have and why?
a. Determine if the users are Administrators on their PCs
b. Determine if there is a SW procurement process
c. How are exceptions to the SW procurement process handled
d. When did management last review the SW procurement policies
e. For Licensed Software
i. How is SW licensing controlled?
ii. Is it reviewed to ensure accuracy?
iii. Are any PCs using SW that you can’t determine whether they are licensed for?
1. Ask the user how they got the software (note that this is not the time determine blame)
iv. Is SW Metering (SWM) enabled?
v. Is someone reviewing the SWM data and is SW removed from a PC when it is no longer being used?
5. Understand ConfigMgr
a. How many sites do you have?
b. What about PCs in your DMZ?
c. Are you using IBCM or DirectConnect?
6. Reporting data
a. Print and review the “Count of Add/Remove Programs”
b. Print and review the outliers
i. PC with Maximum # of ARP
ii. PC with Minimum # of ARP
c. Based on the number of site and size of those sites, randomly select a statistically significant sample of PCs and print and compare the ARP to ConfigMgr data. About 100 PCs should be enough. If you can’t compare the ARP to ConfigMgr data for one of the 100 Random PCs, explain why not
d. Create a report that shows the last Hardware Inventory date in ranges.
e. Conclude how reliable the data is within the above reports
7. Testing reliability of the data
a. Of the 100 PCs randomly select 30 PCs and perform a full audit
i. Compare what is within the ARP to what ConfigMgr says is within the ARP.
ii. Compare the physical data about those PCs
3. Hard drive size
iii. If the data does not match, why not? Is it isolated, timing or consistent error issue in the larger population of data
iv. If errors are judge to be timing or isolated, do you need to increase the number of PCs that need to be tested?
8. Do the math
a. Compare PC numbers in AD to ConfigMgr
b. Compare PC numbers in ConfigMgr to AV console data
c. Determine what % / range of clients are missing from ConfigMgr
d. Determine what % of PC are Remote PCs
e. Determine how often software is used based on SWM data
9. Prepare report and recommendations
a. What risks are there?
b. What improvement can be made?
c. What areas are under control?
d. How can client service be improved?
10. Schedule Follow up SW audit
a. It does no good to do a one time audit; you need to compare the SW audit over time to determine are you getting better. 6-12 months is a good time frame
b. Schedule a yearly review of all relevant policies
i. SW procurement
ii. HW procurement
iii. Life Cycle Management
c. Present findings to management
Now why is the above better than “I need a list of all SW on all PCs?” Well there are many reasons.
1. This follows generally accepted audit standards
2. The amount of paper used will be significantly reduced.
a. 100 PCs * 2.325 page = 232.5 pages
b. For 10K PCs there will be about 80K unique entries within the ARP. This means about 1000 pages.
c. In either case you will need to generate a report so there should be no difference there.
d. Therefore 23,250 pages vs 1,233 pages! Or 94.7% less paper.
3. And the most important reason, this is doable.