Oct 22, 2020

Spooky SAM Stories: 7 Cautionary Tales to Avoid Compliance Risk

Editor’s note: The path to Software Asset Management often involves unexpected twists and jarring turns. Every year we try and update the original 2016 article with new scary software license management stories sure to spook even the savviest of SAM managers. Happy Halloween!

Let’s face it, Software Asset Management has its scary spots. Dreaded data, technical tangles, and chaotic challenges. Here at Aspera, our seasoned professionals have witnessed their fair share of terrifying moments. We’ve convinced our team to share six  seven of their spoooookiest SAM stories to our blog, just in time for Halloween.

Microsoft Masquerade

Rebecca Horton, SAM Evangelist, ITS manager of IT Asset Management at Ceridian

Back when I was a SAM consultant, I did a self-audit engagement, helping a company understand their infrastructure and server position across their estates, such as Microsoft and Oracle.

We did the usual work of looking at the data from all the discovery tools – SCCM, CMDB, VMware, Citrix. But as we brought all this data back in, we noticed a bunch of strange anomalies. This happened when you searched and filtered on certain keywords or naming conventions. Suddenly, you were coming up with numbers that were definitely not what we expected.

For example, the expected inventory was 50 Oracle Databases and 150 Microsoft SQL databases. Ok, that’s weird. Because our results are coming up with let’s say 100 Oracle DB and 100 Microsoft SQL. So, many more of Oracle and much fewer of Microsoft. Why is that?

Turns out, one of the administrators had renamed a bunch of Microsoft SQL databases to show up as Oracle databases. Each was called “ODP” instead of an expected “SQL”. This admin had been with the company for five years and he had control of those environments. He thought it would be funny to give things the wrong name, and it would be a joke on his coworkers.

We were like, yeah… you shouldn’t do that. If Oracle comes in to audit, and you've named something as “Oracle,” even if the discovery data shows that it's Microsoft SQL Server 2008, they will probably argue that it's an Oracle database. It’s data inaccuracy by standards around data governance and generating good quality data – that’s super important.

They're going to try to get those extra dollars from you. So why put yourself in a position where you have to even have that conversation and prove that a database is not Oracle?

As a Software Asset Management consultant, it was my job to have their back, both the company and the SAM admin. I would say the harder situation was figuring out how to tell his manager – and his manager’s manager – that all these servers need to be fixed because a bunch of their Microsoft databases were masquerading as Oracle DBs.

Ghosts in the Machines

Pat Spencer, Senior Consultant, Aspera Technologies

I consulted years ago with a high-profile global company. This company didn’t have a real software license compliance program before I came aboard. The asset managers were basically a remedy team using spreadsheets.

One day, my team is pulling in data, working to reach a software license compliance position. As the SAM manager reviews the reports, he suddenly says, “What is this?” The data showed Microsoft Access, and a lot of it.

He says: “We don’t use Access. About six years ago, we renegotiated with Microsoft and said that we no longer need Office Professional. So we started paying for Office Standard, which doesn’t include Access.”

I say: “Your raw data shows that Access is installed – and on a lot of machines. When the team renegotiated the Microsoft contract, my guess is that no one actually went through to do the uninstall. So the software has been sitting unlicensed for six years.

“No no no, that can’t be right,” says the SAM manager. Then after a few more minutes of review, he looks at me and says, “Well…can you just make it go away?”

My reply, with a straight face: “I can remove it from your compliance report. However, you still have it installed, so you need to take the right steps to fix the problem.”

I never found out if the team metered the application to discover if any employees had been using it. But they did take the initiative to go through the entire company and uninstall Access from every device. Which was probably hundreds of thousands of devices — this was a really big company!

If Microsoft had come in for a software license audit, this company would have been in deep trouble. Sadly, this kind of mistake is not uncommon. And, as we all know, vendors count everything — ghosts, ghouls, and licenses that lurk in the dark.

Audits are scary - we can help!

Zombie Account Hunter

Jochen Hagenlocher, Head SAM CH Fortune 100 Company

Once a year at Halloween, SAM managers can openly talk about our communal passion for hunting so called “Zombie Accounts”. These user accounts are unused and dead, but financially speaking, they are very much alive.

Without professional help from a software license management tool, unused software user accounts eat up 30-40% of your cloud software budget.

Experienced zombie hunters know their main hiding places. Check out your Microsoft Office 365, Salesforce, and ServiceNow Platforms; you will be surprised at what you unearth.

Feeling squeamish about zombie hunting is understandable. Look for a zombie quest guide armed with cloud software asset management solutions built to ensure complete Salesforce license management and Office 365 license management. These tools actively analyze your usage and app combinations to optimize your subscription and protect your cloud software investment from the impending zombie apocalypse.

Happy Halloween to all of you!

Spend smarter in the cloud

How will a SaaS optimization tool improve your cloud spend management?

Learn more >>


Devil in the details

Jaclynn (JC) Nicoll, Functional SAM Consultant, Aspera Technologies

Here’s a frightening fable of what can happen when your software license management tool is not capable of producing accurate results.

I was consulting for a company that was using a competitor’s software license management tool. During the discovery inventory phase, the Software Asset Management team noticed 3k installations of Adobe Photoshop across the organization. However, this SAM tool found very few purchases to cover the Adobe license requirement needed for all these Photoshop installations.

Armed with this knowledge, the SAM team set up SCCM uninstall packages to remove the unlicensed installations needed to stay compliant.

Suddenly, IT was flooded with tickets from users asking why their Photoshop had disappeared(!). It turned out that the SAM tool they were using didn’t include the latest version in their software catalog. So, it missed the critical data that showed that these installations were actually part of their licensed suite because the tool wasn't capable of reliable adobe creative cloud license management.

Luckily, they had SCCM packages available to quickly reinstall Adobe Photoshop, and get the users back up and running.

Lesson learned: validate, validate, validate.

The curse of sharing too much

Jaclynn (JC) Nicoll, Functional SAM Consultant, Aspera Technologies

Years ago, I was working with a customer to finalize a new Adobe agreement. Adobe asked the procurement team to run an innocent little script. They wanted the company to then provide the output to Adobe so that they would know how many licenses they wanted for the new agreement.

Ever efficient, the Procurement lead quickly sent Adobe’s request over to the IT team so they could run the script. Once the data results were generated, the output was promptly sent to Adobe. But here’s the kicker, those results were never cross-referenced against how many licenses the customer already had.

One week to the day: they were hit with audit letter. It was like the wicked witch of the west had swooped down and dumped her bucket of gloom on us.

Audit result: Adobe strong armed the company into an expensive ETLA to get out of the mess.

Lesson learned: Always maintain a strong communication protocol for data being sent externally. A corporate officer should review and authorize the release of any usage data before results are ever sent to a software vendor.

Adobe Creative Cloud SaaS Management

Control your subscription costs to release creative potential with Adobe License Management.

Get started >>

The Case of the Invisible Inventory

Lawrence Dempsey, Manager of Services, Aspera Technologies

What’s your current process for dealing with ‘aging’ or old inventory data on your organization’s devices?

I was consulting at a global security company which had recently been forced to pay fines during a software compliance audit. They decided to take a Software Asset Management program seriously and rolled out a tool built for software license management. The SAM tool tracked both hardware and software assets, and utilized deployed SAM agents to each device. My job was to ascertain the ‘current state’ of Software Asset Management compliance for the company’s key strategic vendors.

The agents were configured to scan weekly, and the policy was to ensure we had a frequent scan on every device no older than 30 days. Any device with a last-scan date older than 30 days raised a red flag. That indicated either an issue with the agent, or a device that had not been on the network for awhile and could be a security risk.

I noticed there was a significant percentage of devices with aging scans, which were owned and used by the development team. But why the data was old — that’s the big question, and that was my job to find out.

If you’re familiar with managing software and hardware assets, you know that developers are fun people to deal with. They may have 3-5 devices they use, 1 for production and the rest for development, and sometimes those boundaries can be crossed. Additionally, developers can be a little bit cavalier when it comes to what they are deploying for testing and development, and what they are licensed to deploy for testing and development.

I told the developers there was a problem with their scanning agents and we needed to reinstall them. They gave a significant amount of push-back for what should be a straightforward and ‘background running’ process.

Three days later, the developers told me they had “fixed the problem” and we wouldn’t have an agent issue anymore. I said, “That’s great, thank you, how did you fix it?” Turns out they completely reformatted their computers. “Why did you do that? We could have just reinstalled the agent,” I asked. They told me: “Oh, we disabled the agent after you installed it the first time.”

Here’s the challenge: How do you manage and track assets when users have control over what you can and can’t see? The developers had full admin rights and could install what they wanted on their machines. Turns out they shouldn’t have been so trusted. This situation wasn’t about ‘accidental’ non-compliance. It was ‘intentional’ non-compliance, that is, an intentional disabling of software license management capabilities.

Here’s the lesson. Don’t always assume that aging scan data could mean a device is inactive or decommissioned. Your process should analyze the status of each device when looking at the age of discovery inventory data. Is the device still active and deployed? If so, that’s a trigger to get updated data inventory, not to ignore the inventory completely.

Everyone enjoys a little scare on Halloween, but in software asset management, I prefer to keep the real horror to a minimum.

Own your next software license audit, from start to finish.

Looking for a comprehensive guide for proven Software Audit Defense strategies?

Get the eBook >>

The Walking Dead Project

Olaf Diehl, Managing Director, Aspera GmbH

I knew a very large logistics company with an IT project team that was full of ideas. They had a bunch of targets and goals for starting up their SAM service. As the organization was huge and complex, their initial plan was to go for the client devices and to count deployed software only.

This was hard work and a valid approach at the time, perhaps 10 years ago.

After that process was in place, they integrated SAM into their request management and customized the hell out of their system. The customization took many years and probably hundreds of thousands of Euros for internal resources and external support.

Several years later, the company was ready to update their system to the most recent version of their SAM solution. But guess what? This was no longer possible. Years of customizing the system had killed all versioning compatibility. Data quality issues were also poisoning the service results.

So they tried in a test environment to update. It crashed. The expected effort to fix the problems was massive. What does a clever organization do? They reverted back to a new standard system, especially since the SAM solution’s vendor promises that customization is not necessary anymore.

Do you see the light at the end of the tunnel? Ok: Go! The regression to a standard system worked quite well — at least for some months. Four years later, they were spending a huge budget and still on the hunt, like a drug addict, for a reliable result. Yet as far as I know, they still had the compatibility problem, no good data, and no significant server coverage.

And no hope, maybe. The team knew their needs and what could cure it. But their bottom line was that “we already invested so much” and political reasons inside the company prevented any helpful movement. In the end, this company was left with a very expensive trick, and never got to enjoy any treats.

Topics: SAM 101, SAM Insights