Blog

Miro Consulting specializes in software license audit defense, license management, subscription management, and cloud services, for Oracle, Microsoft & IBM.

When is a Terabyte not a Terabyte?

When you’re licensing with IBM (and possibly others*).

This licensing metric used for IBM software storage products seems to be self-described by its name – Terabyte.  A Terabyte (TB) is a unit for measuring digital information.   Tera– represents the fourth power of 1000, or 1012, or one trillion bytes.

However when you read IBM’s licensing definition of the Terabyte metric, it’s not 1012A Terabyte is 2 to the 40th power bytes.  Outside of IBM, 240 is generally considered a tebibyte (TiB).

The difference between 1012 and 240 is not huge – only 99,511,627,776 bytes.   A rough ratio of 1 TiB to 1.1 TB can be used.

Where this comes into play with IBM licensing is when storage is measured in real Terabyte (TB) and then someone mistakenly buys that quantity of Terabyte licenses from IBM without verifying the underlying definition of a Terabyte, and then I see it again with software audits.

If I have 500 Terabyte licenses, it covers 500 TiB or 500 IBM TB.  Once the numbers are expanded to reflect the definition behind each measurement, it would be discovered that 500 TB licenses covers 500 TiB or 549 TB (1012 bytes).  If the conversion was done for the license purchase but not applied to an audit situation, you may be found mistakenly non-compliant for the range between 501 and 549 TB deployed.

Over time, IBM has realized this could cause confusion and has updated some products dashboards to clarify which measurement is in use:

Spectrum Control showing measurement in GiB and TiB

Best practice would be to understand the vendor’s license definition even if it seems self-explanatory, and also how the deployed product is measured.

* Google Cloud Storage uses the same Terabyte definition as IBM – a Terabyte is 240 byte.


Enabling and Disabling Oracle Database Options and Management Packs

  • Oracle Databases include extra options that are not covered by the basic license
  • Some of these options are enabled by default when creating new databases
  • Organizations that enable extra options without licensing are out of compliance

Oracle provides a number of database options and management packs for the Oracle Database, which are licensable extra cost options. Unfortunately, many of our clients are surprised to learn that they are unknowingly using unlicensed database options and management packs and are therefore out of compliance. The reason for the confusion is due to the fact that depending on the version, database options and management packs are installed and many are enabled automatically.

As a post-implementation step, an organization should evaluate which database options and management packs meet the needs of the organization and determine if additional licensing is required. Any database options and management packs that are not licensed should be disabled prior to creating and using Oracle databases to prevent accidental use. Organizations should check usage on a regular basis to highlight compliance issues early and limit financial risks.

For database options, prior to 11gR2, Oracle provided an option to select or deselect database options during the installation process of the Oracle Database. As of 11gR2, this option is not available and all of the components that are licensed under the specific database edition are installed and many are enabled automatically.

CHOPT
Oracle provides a command-line utility called CHOPT to enable or disable Oracle options depending on the version. The ‘Y’ in the following table indicates that the option can be enabled or disabled using the CHOPT utility.

Description  db_option  11gR2 12.1 12.2 18
Advanced Analytics oaa N N Y Y
Data Mining RDBMS Files dm Y Y N N
Database Vault dv Y N N N
Label Security lbac Y N N N
On-Line Analytical Processing olap Y Y Y Y
Partitioning partitioning Y Y Y Y
Real Application Testing rat Y Y Y Y
Database Extensions for .NET 1.x ode_net Y N N N
Database Extensions for .NET 2.0 ode_net_2 Y N N N

 

CHOPT will not remove database schemas and objects. This utility provides the benefit of easily enabling in the event that an option is licensed for use at a later stage. CHOPT is located in $ORACLE_HOME/bin directory. Prior to running CHOPT, verify if a database option is enabled or disabled by querying the V$OPTION view. The Oracle database should be shutdown prior to running the CHOPT utility. The syntax to enable or disable an option is as follows:

chopt [ enable | disable] db_option

After running the CHOPT utility, startup the Oracle database and verify that the option has been changed by querying the V$OPTION view.

Management Packs
For management packs, Oracle Enterprise Manager (Grid Control or Cloud Control) can be used to enable or disable management packs through the Management Pack Access page.

These management packs include:

  • Diagnostics Pack
  • Tuning Pack
  • Data Masking and Subsetting Pack
  • Cloud Management Pack
    • Database Lifecycle Management Pack
    • Change Management Pack
    • Configuration Management Pack
    • Provisioning
    • Patch Automation Pack

Diagnostics Pack
The Diagnostic and Tuning Pack functionality can be accessed through Enterprise Manager and database server APIs and command-line interfaces. As of 11g, Oracle provides a dynamic initialization parameter called control_management_pack_access to control access to the Diagnostic and Tuning Pack with one of the following values:

  • NONE – Diagnostic and Tuning Packs are disabled.
  • DIAGNOSTIC – Diagnostic Pack is enabled.
  • DIAGNOSTIC + TUNING – Diagnostic and Tuning Pack are enabled. This is the default parameter.

Prior to changing, verify which initialization parameter value is in use by typing the following at the SQL prompt:

SQL> show parameter control_management_pack_access;

If unlicensed, the control_management_pack_access should be disabled by changing the initialization parameter value to NONE. The control_management_pack_access initialization parameter can be changed by typing the following at the SQL prompt:

SQL> ALTER SYSTEM SET control_management_pack_access = <value>;

After changing, verify that the initialization parameter value has been successfully changed.

Database option and management pack usage can be checked by querying the SYS.DBA_FEATURE_USAGE_STATISTICS view, which provides usage information such as the feature name, version number, whether a feature is currently in use, detected usages, first usage date, and last usage date. The DBA_FEATURE_USAGE_STATISTICS view is automatically updated once a week; however, the view can be manually updated by executing the following procedure:

SQL> EXEC SYS.DBMS_FEATURE_USAGE_INTERNAL.exec_db_usage_sampling(SYSDATE);

Conclusion
Many of our clients are surprised to learn that they have usage for unlicensed database options and management packs. Non-compliance may result in the organization paying significant penalties and purchasing licenses at a higher cost. Organizations should disable unlicensed database options and management packs to prevent accidental use and should regularly check usage to highlight compliance issues early and limit financial risks. Please contact your trusted Miro Analyst or Miro Account Manager for questions or assistance with preventing accidental usage and determining database options and management packs usage (including options, packs, and features not mentioned in this document) to ensure a fully compliant environment.


10 Oracle Data Recovery Mistakes That Put You Out of Compliance

10 Oracle Data Recovery Mistakes That Put You Out of Compliance
Having a data recovery strategy in place is critical to ensuring business continuity in the event of an outage or disaster. When developing a data recovery strategy, it is essential to take into consideration the different licensing rules when deploying backups, failover (active/passive), and high-availability (active/active) scenarios.

Many of our customers remain confused regarding the licensing requirements for Oracle data recovery environments. As a result, this could cause the organization to be out-of-compliance and fail an audit. Therefore, it is important to understand these differences as there are specific occasions when Oracle licensed customers do not have to purchase licenses for every server/node.

The following are common misconceptions our customers have encountered in regard to licensing Oracle data recovery environments:

1. Nightly Backup

Oracle customer copies/stores a nightly backup copy of the production database data to the test/development server not knowing that from an Oracle licensing perspective, this would be interpreted as a standby configuration and therefore the licensing metric (including options and management packs) for this server must match the associated production server.

2. Unlimited Testing and Validation

Oracle customer believes that the testing and validation of database backups is unlimited and has no restrictions; however, from an Oracle licensing perspective, customers are allowed to restore the database to an unlicensed server (for the purpose of testing the physical copies of the backups) up to four times, not exceeding two days per test, in a given calendar year.

3. Monthly Maintenance

Oracle customer has an accepted failover configuration and brings down the production server once a month for maintenance not knowing that from an Oracle licensing perspective, downtime for maintenance purposes counts towards the ten-day policy for failover and therefore must be fully licensed.

4. Standby vs. Production Licensing Metrics

Oracle customer has different licensing metrics applied to their standby server than their corresponding production server; however, in terms of licensing, Oracle requires that customers apply the same metric to both production and standby servers (including options and management packs).

5. Data and Binaries on a Single Array

Oracle customer copies/stores a backup copy of the database data on a disk array that also includes Oracle binaries, which has access to the same data; however, from an Oracle licensing perspective, this would be interpreted as a standby configuration and therefore must be fully licensed. Additionally, the licensing metric (including options and management packs) for this server must match the associated production server.

6. Failover Definition

Oracle customer configures what they believe is a “failover” environment based on the vendor’s technical whitepaper; however, the term “failover” is a general industry term that is often used to describe a solution that is considered a standby configuration according to Oracle Data Recovery Methods.

7. Real Application Clusters (RAC) Configuration

Oracle customer believes that one of the servers/nodes in a Real Application Clusters (RAC) configuration can be considered as failover (active/passive) server/node; however, from an Oracle licensing perspective, an Oracle RAC environment is considered high-availability (active/active) and therefore all servers/nodes must be licensed.

8. Failover Limitations per Cluster

Oracle customer has a failover configuration with multiple failover servers accessing a single storage array; however, from an Oracle licensing perspective, only one failover server in the cluster can be unlicensed.

9. Multiple Storage Arrays

Oracle customer has a failover configuration with two servers accessing different storage arrays; however, from an Oracle licensing perspective, this would be considered a remote mirroring configuration and therefore both servers must be fully licensed. Additionally, the same licensing metric (including options and management packs) must be applied to both servers.

10. Data Guard

Oracle customer believes that since Data Guard is included with Oracle Database Enterprise Edition, the standby server does not need to be licensed; however, from an Oracle licensing perspective, any Data Guard scenario would be interpreted as a standby configuration and therefore must be fully licensed. Additionally, the licensing metric (including options and management packs) for this server must match the associated production server.

Summary

The following is a recap of Oracle’s licensing rules when deploying backups, failover (active/passive), and high-availability (active/active) scenarios:

Backups/Testing
In this type of data recovery, Oracle permits customers to store a backup copy of the database data on storage devices (tape, disk, cloud) without the purchase of additional licenses. In the event of a failure, the backup files can be used to reconstruct the Oracle database.
Oracle permits a licensed customer, for the purpose of testing physical copies of backups, to restore the database to an unlicensed server up to four times, not exceeding two days per test, in a given calendar year. When testing is complete, the restored database must be removed from the unlicensed server; otherwise, the server must be licensed.

Failover (Active/Passive)
In this type of data recovery, servers/nodes are configured in a cluster and are connected to a single disk array. The production server/node acts as a primary node. The Oracle database software is installed on both the production and failover server(s)/node(s); however, the database is installed on the shared disk array. In the event of a failure, the clustering software will switch control from the primary server/node disk subsystem to the secondary (failover) server/node.

From an Oracle licensing perspective, failover applies to an active/passive clustered environment where only the primary (production) server/node is actively running Oracle software and the failover server/node is effectively idle (not running) and will only be used in the event that a failure occurs or maintenance is required. Therefore, Oracle permits a licensed customer to run a failover server/node without any additional licenses on the condition that the failover period does not exceed a maximum of ten days in a given calendar year.

This failover period also includes downtime for maintenance. Once the failover/maintenance period has exceeded ten days, the failover server/node must be licensed. Oracle only permits one failover server/node per cluster. Therefore, if additional servers/nodes are configured as failover, those servers/nodes must be licensed. When licensing this type of scenario, the same license metric must be applied to both production and failover servers/nodes.

High-Availability (Active/Active)
In this type of data recovery, the Oracle database software and the database are installed on both the production and standby/data recovery servers, which are usually located in different geographic locations. The data at the standby/data recovery server is kept in sync with production through some form of data replication, mirroring, or copying. In the event of a failure or disaster, the standby/data recovery server can be activated as the primary with little or no disruption or data loss.

From an Oracle licensing perspective, both the production and standby/data recovery servers must be fully licensed. This rule also applies when Oracle software can access the data that is located on separate servers, sites, or storage devices. With a high-availability (Active/Active) configuration, the ten-day policy does not apply. When licensing this type of scenario, the same license metric must be applied to both production and standby/data recovery servers.

Conclusion

In general, all Oracle installations must be licensed; however, there are a few exceptions. It is important to understand these licensing rules and exceptions to avoid costly non-compliance penalties. Please contact your trusted Miro Analyst or Miro Account Manager if you are considering or have a data recovery strategy in place. Miro can assist your organization with assessing all of the risks and opportunities to maximize your software investment while ensuring a fully compliant environment.


8 Secrets Microsoft Won’t Tell You

Microsoft keeps a lot of secrets from its clients. They can cost companies hundreds of thousands of dollars in compliance penalties and wasted expenditures. They can also cost you your job.

1. You’re Paying for Cloud Whether You Use It or Not

Microsoft Enterprise Agreements typically include an “Azure Monetary Commitment” fee. This is Microsoft charging you for using their cloud, even if you didn’t want it or ever use it. Not only do Microsoft reps usually not explain what this fee is, they use it to make your discount seem larger than it really is. Miro can help you calculate what your real discount, and help you understand how to actually get use out of the fees you’ve already paid.

2. Your Microsoft Partner is Contractually Obligated to Report You to Microsoft

To be a Microsoft Partner, you have to sign a contract saying you’ll report all out-of-compliance issues about your clients back to Microsoft. This is why it’s critically important to get independent advice on your Microsoft situation, and not rely on your Microsoft partner to evaluate your compliance position.

3. To Settle an Audit, You Might Pay Far More than You Think

Many Microsoft clients are shocked to find out that if you’re more than 5% out of compliance, Microsoft can charge you the retail price for the products included in the settlement. Depending on your current pricing – perhaps Level “D” under an Enterprise Agreement – this could amount to a serious outlay of cash.

4. You’re Going to Need a Lot More Network Bandwidth

If you’re moving your Windows Server, Desktop or Office to the cloud, your networking bandwidth needs may increase substantially, often negating or, at least, seriously reducing any cost savings. Miro has seen Clients whose bandwidth needs have risen nearly a million dollars just from the incremental extra data going back and forth to the cloud for simple every-day operations that were formerly local connections. And, depending on how critical this hosted service is deemed, redundant bandwidth might also be necessary.

5. You Can’t Use the Desktop Version after the Online Subscription Ends

Office 365 comes with the option of installing a copy of the Office Suite on your local computer. While this local version will still function for a while after the online subscription is terminated, your organization won’t actually be licensed to use it. If you do, it’s just like using pirated software. Of course, Microsoft’s products won’t give you any warning of it happening.

6. You’re Still Going to Need Your Database Administrators in the Cloud

If you’re planned cost savings when moving to the cloud include the salaries of your database administrators, you’ll probably be disappointed. Database administrators will still be needed for the planning, migration and long-term management. Microsoft may promise to handle those needs for you, but they have little incentive to provide the highest level of service, and they won’t be familiar with your systems and data like your current team. You may need more network administrators as well, to deal with the extra bandwidth the cloud requires. You’ll definitely still need someone to manage your vendor relationship with Microsoft, preferably someone who understands the technical details of every day usage.

7. Having Software Assurance Can Hurt You

You really should, or should not have Software Assurance, depending on the product. For some products, you need Software Assurance to be on the “Long-Term Service Branch”. With other products, you can NOT be on the “Long-Term Service Branch” if you have Software Assurance. Miro can help you understand when you want it, when you don’t, and why.

8. Some Microsoft Audit Information Requests Are a Scam by Third-Party Companies

You may get an email from Microsoft demanding information on your licensing, with warnings that you are not legally allowed to ignore the request. Even though they come from a @microsoft.com email address, they are not actually from Microsoft, and you should probably ignore them.

There are unscrupulous Microsoft partners who will mass spam emails to company IT and Executive teams, demanding licensing info. They will almost always find that you are out of compliance, and need to purchase additional licensing from them. The good news is that you can probably safely ignore them, but if you send the information, it’s too late. Check out our recent blog post to see what the scam emails look like, and how to tell a real Microsoft LLC audit from a scam partner audit.

Want to learn more about Microsoft licensing and how to prevent and deal with a real Microsoft Audit? Download our Microsoft Licensing Guide or our Microsoft Audit Guide, both free, to get all the information you’ll need.

Contact Miro to speak with an analyst about your specific situation. Miro is fully independent of Microsoft and does not share any information with them.


Oracle Virtualization Compliance

Oracle Virtualization Compliance & VMware

Any mention of virtualization causes many people to immediately think of VMware, as they remain to be a main player among virtualization technologies. The challenge of keeping up with Oracle’s evolving licensing requirements of virtualization platforms can be a daunting endeavor for many IT departments and Oracle database administrators.

Any technological advancement made by VMware, specifically relating to any abilities to easily move server sessions around the virtualized environment, prompts a new possible interpretation of licensing requirements by Oracle on the popular platform.

We refer to the requirement updates as “changes of interpretation” since Oracle’s documented policy guidelines have never actually changed. Oracle’s “Hard Partitioning Policy” simply indicates that VMware is considered by Oracle to be soft-partitioning and does not consider any of its features capable of satisfactorily limiting software licensing through resource partitioning.  Oracle’s concerns stem from any possibility for a client to inadvertently and rapidly expand the use of Oracle software without proper licensing.

As VMware’s features have developed into enabling greater flexibility in redistributing computing resources, Oracle’s continually evolving licensing requirements have adapted. IT departments should carefully plan the use of Oracle software within their VMware environments. Oracle can be just as harsh in licensing their software within other virtualized environments, including their own virtualization products.

Oracle VM Server for x86 is based-on and incorporates the open-source Xen hypervisor technology. Oracle recognizes the feature of the virtualization platform which enables the pinning of CPU’s to virtual machines. This enables OVM to be used to partition the processing resources of a server, which Oracle considers to be hard-partitioning. However, should you activate live migration capabilities within a pool of these servers then the accepted hard-partitioning scenario described above is invalidated, and all physical processors are required to be licensed. This would give it the same challenge as experienced with VMware.

IBM Power servers that have LPAR technology, which is recognized by Oracle for the hard-partitioning of server resources, will face the same dilemma. Once those servers are tied together through the use of IBM Live Partition Mobility features, the use of LPAR technology for hard-partitioning is invalidated.

Just because you utilize virtualization technology that Oracle does recognize as having hard-partitioning capabilities, you could be invalidating those features due to the way you are implementing the technology.

Please contact Miro Consulting should you have any license compliance concerns regarding the way you are implementing your virtualization technology.


Oracle Software Licensing and EU General Data Protection Regulation (GDPR) Compliance

The European Union (EU) General Data Protection Regulation (GDPR) is a new regulation that will go into effect on May 25, 2018. The GDPR introduces a legal accountability obligation for organizations and will require organizations to reassess current policies, procedures, and systems and increase the level of controls, processes, and protection around the personal data of EU individuals. Organizations must have a complete understanding of their data and have the ability to implement appropriate technical and organizational measures that ensure and demonstrate that data processing activities are in compliance with the requirements of the GDPR.

As a result, organizations may be required to license additional software to comply with the data protection requirements of the GDPR. Under GDPR, data protection requirements can be broken down to three main categories that include assessment, preventive, and detective controls. Many software vendors such as Oracle offer security products to help address the GDPR’s assessment, preventive, and detective compliance requirements.

Assessment Controls – Article 35 of the GDPR mandates that organizations are to perform risk assessments to help identify vulnerabilities and lessen the possibility of security breaches. Organizations are also required to indicate how data privacy will be addressed. Organizations need to know where the personal data exists, who has access and what privileges, identify possible vulnerabilities, and determine the likelihood of potential threats and the impact to the organization.

Software vendors such as Oracle offer tools to assess the current state of data security. For example, Oracle Application Data Modeling can be used to discover personal data, Oracle Enterprise Manager’s Database Lifecycle Management Pack can be used to scan database configurations, and Oracle Database Vault Privilege Analysis can be used to analyze roles and privileges.

Preventive Controls – Article 32 of the GDPR mandates that organizations implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. Therefore, once the risks are identified, policies, procedures, and controls must be put into place to prevent and deter unauthorized access and misuse of personal data. Unauthorized access can occur internally and externally; therefore, appropriate controls such as encryption, pseudonymization, and anonymization should put in place.

Software vendors such as Oracle offer tools to protect sensitive data at the source. For example, Transparent Data Encryption can be used to encrypt data in production applications, Data Redaction can be used to pseudonymize data in production applications, and Oracle Data Masking and Subsetting can be used to mask or anonymize the data in non-production applications and be used to subset the data either by deleting or extracting the data to a different location.

Detective Controls – Article 30 of the GDPR mandates that organizations maintain an audit record of processing activities on the personal data. The audit data can then be used to help detect potential security breaches, unauthorized activity, and misuse of personal data and be used to timely notify authorities in case of a breach. Article 33 of the GDPR mandates that organizations report personal data security breaches within 72 hours of becoming aware of a breach to the designated GDPR supervisory authority. If the security breach is likely to result in a high risk of adversely affecting the rights and freedoms of individuals, organizations must also inform those individuals affected by the breach.

Software vendors such as Oracle offer tools to monitor suspicious activity. For example, Oracle Database Auditing can be used to enable and maintain audit records of processing and Oracle Fine-Grained Auditing can be used to record and audit specific activities of users.

About the GDPR

The GDPR was approved by the European Parliament on April 14, 2016 and replaces the 1995 Data Protection Directive (95/46/EC). The aim of the GDPR is to give EU individuals more control over their personal data and to simplify the regulatory environment for organizations by unifying the data protection law across all 28 European Union (EU) member states. The GDPR defines personal data as any information, either directly or indirectly, that can be used to identify an individual. An identifier can be name, identification number, location data, online identifier, or one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that individual.

Extended Jurisdiction

The GDPR will apply to any organization that creates, stores, or processes personal data of EU individuals, regardless of whether the organization is located in the EU and regardless of where the data is created, stored, or processed. The GDPR will apply to data controllers and data processors and holds both liable for breaches or non-compliance; therefore, if personal data is hosted in the cloud or shared with vendors or contractors, the organization (data controller) and the third-party (data processor) are liable for penalties.

Penalties

Organizations in breach of the GDPR may be liable for penalties. The GDPR has a tiered approach to penalties depending on the nature of the violation. For example, organizations may be fined up to 2% of total global annual turnover or €10 million (whichever is greater) for not having their records in order, or not conducting a risk assessment, or not notifying supervisory authorities when a security breach occurs, or not notifying individuals affected by the breach. Organizations with more serious consequences may be fined up to 4% of total global annual turnover or €20 million (whichever is greater).

Individual Rights and Control

The GDPR will give back control to EU individuals over their personal data, which includes the right to access, right to be forgotten, and right to portability.

Right to Access – Organizations will be required to request consent from individuals and consent must be provided in an intelligible and easily accessible form. The GDPR will give individuals the right to obtain confirmation from the data controller as to whether or not their personal data is being processed, where the data is being processed, and for what purpose. Individuals will be entitled to a copy of their personal data, free of charge, in an electronic format.

Right to be Forgotten – The GDPR will give individuals the right to withdraw. Once consent is withdrawn, individuals also have the right to direct the data controller to erase and not use their personal data for data processing.

Right to Portability – The GDPR will give individuals the right to portability, which means that individuals may transfer their personal data between organizations more easily.

Data Protection Officer

Organizations that process large amounts of personal data will be required to designate a data protection officer. This position may be performed by either an employee of the data controller or processor or can be outsourced to a third party. Data protection officers will be required to have knowledge and expertise in data protection law and practices. Data protection officers will be responsible for overseeing the GDRP data protection strategy, implementation, and compliance. Responsibilities also include training and conducting internal audits and address potential vulnerabilities. The data protection officer also serves as the point of contact between the organization and the designated GDPR supervisory authority. The data protector officer is also available for inquires and requests by individuals pertaining to their data privacy.

Conclusion

The GDPR introduces a legal obligation for organizations that promotes accountability, transparency, and trust. The GDPR will require organizations to increase the level of controls, processes, and protection around the personal data of EU individuals. As a result, organizations may be required to license additional software to address the assessment, preventive, and detective compliance requirements of the GDPR. Organizations face strict penalties for not complying with the new standards set by the GDPR once the regulation goes into effect on May 25, 2018. For questions and further assistance, please contact your trusted Miro Analyst or Miro Account Manager to provide guidance on GDPR governance, risk, and compliance.


10 Signs of a Fake Microsoft Audit

Do you know how to spot a fake Microsoft Audit?  Learn the 10 Signs of a Fake Microsoft audit, and avoid a trap that could cost your organizations hundreds of thousands of dollars.

  1. You are contacted by a person using a “V-“ microsoft address, formatted like
    v-john.doe@microsoft.com”. These are not real Microsoft employees, but temporary employees or partners.  They do not have the authority of Microsoft to initiate a mandatory Microsoft audit.
  2. It’s not your Microsoft licensed partner. You don’t know the company or the person sending the email, and have not done business with them in the past.
  3. They ask for an email address where they can send some forms to be filled out.
  4. The person’s linkedin says they work at microsoft, but also says they work for another company (their real employer, the Microsoft partner).
  5. The email address the person uses may not match their name because multiple people use it to spam these requests. In fact, the person may not even exist, and the senders use a continually changing fake name, in order to stymie internet searches for the person.
  6. Possible File Names:
    1. Updated Copy of Deployment Summary SAMC.XLSX
    2. SAM+C Engagement.pdf
  7. The company is located in Atlanta GA, Fargo ND, Australia, or New Zealand.
  8. The audit letter is only delivered by email, not by paper mail.
  9. The audit email talks about penalties for refusing a Microsoft audit, not the voluntary partner audit, which is what the sender is proposing.
  10. Possible audit letter appearance:10 Signs of a Fake Microsoft Audit

You can research the issue to verify its veracity, but will likely find misleading results as such rogue partners will evolve their approach.  The truth is that they function as revenue generators and that those partners neither have the authority nor intention of actually conducting an audit.  Their goal is to get the organization to incriminate itself by sending the information.

These partners engage in a fishing expedition – or a phishing expedition –  looking for organizations and IT workers who are unaware of this practice and want to stay in compliance with their vendors. They will attempt to contact multiple people at the organization to solicit information.  If the organization ignores or refuses the information request, they will threaten to subject the organization to a full audit, and to disable any active Microsoft software.

But by completing and submitting these requests for information, the organization can give the partner the information it needs to share with the vendor who will then declare the organization out-of-compliance. In every scenario, the partner will strongly push the organization to purchase the additionally needed licenses from the partner themselves.

Audits initiated by Microsoft SAM partners are ALWAYS voluntary, and declining the offer will not always, or even often, lead to a formal audit by Microsoft, known as a Microsoft LLC audit.  An official Microsoft LLC audit will be initiated by a major accounting firm.  You will get an audit letter via snail mail from KPMG, Deloitte, or similar.

Download

The Definitive Guide to Microsoft Audits

by Miro Consulting

While this particular type of audit notice isn’t a real Microsoft audit, your organization may receive a real Microsoft LLC audit request that it cannot legally ignore.  To learn more about Microsoft Licensing, download The Definitive Guide to Microsoft Audits, or contact us at info@miroconsulting.com.  Miro is NOT a Microsoft Partner, and shares no information with Microsoft or it’s partners.

 


Oracle License Compliance Issues Related to API Usage

Users who have no direct access may still need licenses, if they use a system that connects via an API

APIs (Application Programming Interfaces) are utilized in all applications to allow programmers to interface with other applications or devices. It is common for us to find organizations that have underestimated the software licensing impact of leveraging the APIs of their Oracle applications and products. Oracle applications typically utilize an “application user” metric. It is logical for organizations to only consider the user IDs in their system for calculating software licensing requirements. Unfortunately, they may overlook the fact that an API utilizes a user ID itself.

It may also be thought that licensing that single API user ID is sufficient. However, that is not the case. Oracle considers such use as a form of multiplexing, which obscures the true count of users accessing the application. This also has the potential of falling under Oracle’s concept of batching if an external home-built application compiles all incoming data from users and delivers it at once through an API. This is why Oracle counts users at the front end of usage.

All users that are utilizing the external application or interface that feed data into the Oracle application through the API must be licensed for the Oracle application. It is common for users of Oracle E-Business to incorporate the use of APIs to pull data from external sources, and this is a typical source of software compliance issues. However, this situation can impact any Oracle program that utilizes a user licensing metric and receives data from external sources into an API, which includes Oracle Database.

Examples of API Connected Systems:

  • CRMs
  • ERPs
  • Mobile Apps
  • Point-of-Sale
  • Scanners
  • Business Analytics

Identifying software compliance issues in these situations can be very confusing as there are many different usage scenarios, licensing metrics, and differing license rules across all Oracle products. If you have any usage situation that you feel could fall into the situation described above please contact Miro Consulting.