IBM BigFix Inventory V9.5 and Licence Metric Tool V9.2 Administration Exam Guide
The IBM Certified Administrator—BigFix Inventory V9.5 and Licence Metric Tool V9.2 credential validated an intermediate administrator’s ability to plan, install, configure, maintain, troubleshoot, and support an inventory and licensing environment. IBM’s certification page states that the certification was withdrawn on September 30, 2019 and expired on March 31, 2020. This guide therefore helps you make an important decision first: use the material for historical study or role preparation, but verify IBM’s current certification catalogue before trying to schedule an exam.
Is this certification still available?
No. IBM states that the IBM Certified Administrator—BigFix Inventory V9.5 and Licence Metric Tool V9.2 certification was withdrawn on September 30, 2019 and expired on March 31, 2020. Treat the published objectives as a skills reference rather than evidence that a current test appointment can be booked.
The page also says candidates for the certification had to pass one test, but the supplied IBM material does not establish a current exam number, registration route, delivery format, duration, fee, language list, passing score, or question count. Do not rely on third-party listings that present those details as current.
Before spending time on registration, search IBM’s current certification catalogue and confirm whether a successor credential covers the administration skills you need. If no replacement is listed, use this guide to structure practical BigFix and License Metric Tool learning rather than to prepare for an active V9.5/V9.2 examination.
What did the administrator role cover?
The credential targeted administrators with extensive hands-on experience in BigFix Inventory V9.5 and License Metric Tool V9.2. Its role definition covered planning, installation, configuration, deployment, maintenance, troubleshooting, and support, so preparation needed to connect architecture decisions with operational work.
This was not a narrow reporting or user-interface credential. An administrator had to understand how the BigFix platform supplied data, how the inventory and licensing components were arranged, how databases and clients participated, and how to investigate failures after deployment.
Use the role description to test your readiness. You should be able to explain why a component is needed, identify dependencies before installation, choose a workable design for a stated environment, validate collected data, and form a troubleshooting plan from symptoms rather than guessing at settings.
What does License Metric Tool actually do?
IBM describes License Metric Tool as helping organizations inventory core-based software in full-capacity or virtualization sub-capacity environments and measure the licenses required by software products. It is intended to help manage IBM software licensing requirements and maintain an audit-ready posture.
That purpose creates two related study tracks. The first is technical collection: discovering computers, gathering software and hardware information, importing data, and keeping the environment operational. The second is licensing interpretation: understanding how the collected evidence supports capacity and license calculations for the relevant IBM software.
Do not reduce the product to a list of reports. For each study topic, ask what evidence enters the system, which component processes it, where an administrator verifies it, and how an incomplete or stale result could affect a licensing decision. That chain is more useful than memorizing isolated menu names.
Which architecture must you be able to draw?
A complete License Metric Tool deployment with BigFix consists of the License Metric Tool server and database, the BigFix server and database, and a BigFix console. IBM’s architecture documentation also states that a BigFix client must be installed on each computer from which software inventory data is collected.
Start your architecture notes with those components and add the direction of data flow in your own words. Mark the collection endpoint, the BigFix infrastructure, the License Metric Tool application and database, and the administrator’s console access. Then annotate the points at which connectivity, credentials, database health, or configuration can interrupt processing.
IBM states that IBM i uses disconnected scans instead of the BigFix client. This is a useful boundary condition for design exercises: do not apply a standard client-based collection assumption to every platform. A good design explanation identifies the collection method for each computer group and explains how the resulting data reaches the inventory process.
How should you study BigFix architecture and the console?
The certification objectives included describing BigFix architecture and the BigFix console. Study the console as an administration surface, not as a sequence of clicks: identify where deployment actions originate, how computer groups are represented, how client status is checked, and how an administrator distinguishes an infrastructure problem from an inventory application problem.
Build a small diagram and a fault table. For each symptom, record the likely layer: client, network, BigFix server, database, License Metric Tool server, License Metric Tool database, or user configuration. This habit prepares you for scenario reasoning and prevents you from treating every missing record as an application defect.
How should you approach solution design questions?
The objectives included designing BigFix Inventory V9.5 and License Metric Tool V9.2 solutions based on customer environments and requirements. The strongest preparation method is to translate each requirement into a design constraint: monitored computers, platform mix, database choice, network boundaries, virtualization, security controls, growth, and operational ownership.
Practice writing a short design decision for each constraint. Explain which component is deployed, where it is hosted, what it must communicate with, how data is collected, and how the administrator will verify the result. Include a reason for rejecting an unsuitable design instead of listing several options without choosing one.
A design is incomplete if it works only in a diagram. Add maintenance, backup, upgrade, support, and troubleshooting considerations. The administrator role included deployment and support, so an operationally sustainable design is more relevant than a visually simple one.
What changes when BigFix Inventory and License Metric Tool coexist?
IBM documents that BigFix Inventory and License Metric Tool can share a BigFix server while monitoring different computer sets, but the two applications must be installed on separate computers. Keep those conditions together when studying coexistence; sharing the platform does not mean placing both applications on one computer or treating their monitored populations as identical.
Create a coexistence checklist with four questions: which application monitors each computer set, which BigFix server supports the deployment, where each application is installed, and how administrators prevent overlap or unintended collection. Then consider how a change to the shared BigFix infrastructure could affect both applications.
When answering a design scenario, state the separation explicitly and explain the computer-set boundary. Avoid the common mistake of assuming that a shared BigFix server removes the need to plan application placement, data ownership, or operational impact.
What installation and configuration knowledge matters most?
The published objectives included installing and configuring the software and its components. Prepare by learning the order and dependencies of a deployment rather than memorizing an installer screen. You should know what must exist before installation, which database and network decisions matter, how clients or scans are introduced, and how to validate each stage.
Use a staged laboratory plan if you have access to an approved environment. First document the target topology and prerequisites. Next install the platform components in dependency order. Then connect a deliberately small computer set, collect inventory, and verify that the data reaches the expected application. Record every validation point and any corrective action.
The lab does not need to reproduce a production estate to be useful. Its purpose is to make component relationships concrete and to expose gaps in your reasoning. Do not use live licensing data or production infrastructure as a substitute for a controlled learning plan.
How can you study deployment without memorizing procedures?
For each installation task, write three notes: prerequisite, action, and verification. For example, a database prerequisite should be paired with the configuration that uses it and a check showing that the application can communicate with it. This structure helps you reason when documentation, versions, or environments differ.
Repeat the exercise for client deployment, disconnected scans, user access, data imports, and routine maintenance. If you cannot state what success looks like after a step, you have memorized a procedure without understanding it.
Which troubleshooting skills should you build?
Problem determination was an explicit objective, and it should be practiced as evidence-led isolation. Begin with the symptom and its scope: one computer, one platform, one computer group, one import, or the entire environment. Then identify the last known successful stage and test the next dependency.
A useful sequence is to confirm the affected inventory source, check client or scan participation, verify network reachability, inspect BigFix activity, confirm application processing, and review database or server health. The exact checks depend on the environment, but the method remains consistent: narrow the fault domain before changing configuration.
Keep a troubleshooting journal containing symptom, evidence, hypothesis, test, result, and resolution. Include false leads. This develops the discipline to distinguish a collection failure from a processing delay, a connectivity fault from a permission problem, and a product configuration issue from an unsupported platform condition.
How should performance tuning be prepared?
Performance tuning was also named in the objectives. Study it as a relationship between workload and resources: the number and type of computers, scan activity, data volume, database behavior, server capacity, and the timing of imports or reports. Avoid treating a single slow screen as proof that the user interface is the root cause.
For every performance scenario, ask what measurement would confirm the suspected bottleneck. Compare the scope and timing of the problem, inspect the relevant processing stage, and change one controlled factor at a time. Document the expected effect and the rollback plan.
A frequent mistake is tuning before establishing correctness. First determine whether data is missing, duplicated, delayed, or merely slow to display. Performance work on an incorrectly configured collection process can hide the real defect and make later diagnosis harder.
What does customization mean in this context?
The objectives included customizing components for customer requirements. Interpret that broadly but cautiously: configuration should help an organization collect, organize, report, or administer the environment according to an identified requirement. It should not be a collection of arbitrary changes made because an option exists.
Practice mapping a request to its impact. A request for separate computer populations may affect BigFix targeting and application reporting. A request for restricted administration may affect access design. A request for different collection behavior may affect data completeness, processing load, and licensing evidence. Explain both the benefit and the operational trade-off.
Record the original state, the requested outcome, the change, and the verification method. This creates a maintainable configuration record and gives you a practical answer to the support question, “What changed, and how do we know it worked?”
Which supporting technologies should you revise?
IBM listed LDAP, TCP/IP, network troubleshooting, Microsoft SQL, IBM Db2, unattended software installation, Linux and Windows, and virtualization technologies among the recommended skills. These are supporting capabilities for administration, not separate subjects to study in isolation.
Prioritize the technologies that match your intended environment. Review directory integration and access concepts, name resolution and connectivity, database fundamentals, silent deployment patterns, operating-system administration, and virtualization terminology. For each topic, connect the skill to a BigFix or License Metric Tool task.
Do not claim expertise because you can define a term. A better check is practical: can you identify which evidence would show a network path is failing, explain why database configuration matters, deploy a component unattended in a controlled test, or describe how virtualization changes the licensing context?
How do licensing and compliance considerations affect preparation?
IBM states that License Metric Tool use is recommended for full-capacity licensing and mandatory for sub-capacity licensing. IBM also explains that the tool helps maintain inventory and measure required licenses, so study must include the relationship between technical evidence, capacity classification, and compliance records.
The IBM Passport Advantage information states that customers have 90 days from the first eligible Virtualization (Sub)-capacity product deployment to install and begin using License Metric Tool for supported virtualization technologies. It also states that customers must maintain documentation for at least two years to demonstrate ongoing compliance with sub-capacity licensing terms.
These are official licensing requirements and should not be confused with exam logistics. Use the current IBM licensing information for policy decisions, because eligibility, supported technologies, and contractual terms can change. In a study scenario, identify the deployment date, the eligible technology, the collection status, and the records that must be retained rather than assuming that an inventory report alone resolves every licensing obligation.
IBM’s information also says that, starting January 1, 2024, prior exceptions were no longer applicable. This matters when reading older training material: a historical procedure may describe an exception that no longer applies. Mark old notes with their policy context and verify current terms before using them in production.
What should you verify about supported technologies?
IBM directs readers to the list of technologies supported by License Metric Tool and to the relevant administrative-server and agent requirements. Do not build a study assumption that every operating system, hypervisor, or hardware configuration is covered. Check the current support information for the exact technology involved.
For practice, create a support matrix with platform, collection method, required component, licensing relevance, and source date. Leave uncertain cells marked for verification. This is safer than filling gaps from memory, especially when preparing for a historical product version while administering a newer environment.
How does the BigFix 9.5 status change the practical value of this guide?
IBM announced that License Metric Tool would withdraw support for BigFix 9.5 starting in the fourth quarter of 2024. IBM’s notice states that, if BigFix 9.5 continued in use, imports of data to License Metric Tool would stop working in the second quarter of 2025 and BigFix components would need to be upgraded to resume imports.
The same notice says that the required action was to upgrade the BigFix server and clients to the latest patch of version 10.0. It also explains that continued use after support withdrawal could leave the environment working without IBM support for problems related to BigFix. These statements are operational guidance, not evidence of an active certification exam.
This creates a clear study decision. If your goal is historical certification research, learn the V9.5/V9.2 objectives as documented. If your goal is administering a live environment, use the current IBM and HCL product guidance, validate supported versions, and plan an upgrade rather than treating the old exam title as a deployment target.
How should upgrade topics be studied?
IBM’s current 9.2 documentation states that License Metric Tool can be upgraded to version 9.2.44 from all 9.x versions. Read that statement together with the relevant upgrade instructions, prerequisites, backup planning, compatibility checks, and validation steps; do not infer that every surrounding component can be upgraded by the same path.
Build an upgrade runbook with inventory of current versions, dependency checks, backups, maintenance communication, ordered changes, verification, and rollback considerations. The exact runbook must follow the current documentation for the environment. A historical exam objective can test upgrade reasoning, but production execution requires current support information.
What study sequence is most efficient?
Study in dependency order: purpose and licensing context, architecture, collection, installation, configuration, reporting and evidence, troubleshooting, performance, customization, and lifecycle maintenance. This sequence follows the way an administrator makes decisions and prevents advanced troubleshooting exercises from resting on an unclear topology.
Begin with the official certification page to capture the role and objectives. Read the architecture and coexistence documentation next. Then use the current product and upgrade information to identify which historical assumptions require verification. Finish each topic with a written scenario or lab check rather than another passive reading session.
Allocate more time to topics you cannot demonstrate. A candidate who can explain architecture but cannot verify collection needs practical work; a candidate who can deploy components but cannot interpret licensing obligations needs policy and evidence review. Let observed gaps determine the next study block.
A practical four-stage roadmap
Stage one is orientation. Confirm that you are studying a withdrawn and expired credential, collect the official objectives, and decide whether your outcome is historical knowledge, job preparation, or research into a current replacement. Make a version-and-source register so older material is visibly separated from current guidance.
Stage two is architecture and deployment. Draw the complete deployment, include the BigFix server and database, License Metric Tool server and database, console, clients, and IBM i disconnected scans, and explain the data path. In a controlled environment, install or inspect components and write a verification result for each dependency.
Stage three is operations. Practice computer targeting, inventory collection, data validation, access administration, problem isolation, performance investigation, and a customer-specific customization. For each exercise, save the evidence you would give to another administrator: topology, configuration record, symptom analysis, and validation result.
Stage four is lifecycle and decision review. Rehearse an upgrade assessment, a coexistence design, a sub-capacity evidence review, and a supportability check. Revisit every note containing a version, date, policy condition, or platform assumption and verify it against current IBM documentation before applying it.
Which mistakes waste the most preparation time?
The largest mistake is preparing for an active exam without checking its status. IBM’s page says this certification expired on March 31, 2020, so registration claims from unofficial sources require particular caution. A second mistake is studying only interface actions while ignoring architecture, databases, networks, operating systems, and support responsibilities.
Another error is mixing historical and current product guidance without labels. BigFix Inventory is now an HCL product, while IBM continues to publish License Metric Tool information and validated-version guidance. Keep source, product owner, release, and publication context in your notes.
Do not memorize unsupported claims about scores, timing, question counts, prices, or delivery. The supplied official research does not provide those details. Do not use leaked questions or dumps as a substitute for understanding; they cannot establish current requirements and do not demonstrate that you can administer a licensing environment safely.
Finally, do not treat a successful installation as proof of readiness. A capable administrator must also explain collection boundaries, investigate missing or delayed data, maintain evidence, evaluate upgrades, and communicate the operational consequences of a design choice.
What should you do before relying on older notes?
Separate facts into three labels: official historical certification information, current product or licensing guidance, and personal study assumptions. This simple classification prevents a V9.5 exam objective from being mistaken for a current support requirement or a remembered lab result from being treated as IBM policy.
Check every time-sensitive statement against IBM’s current pages. The Passport Advantage information says all IBM License Metric Tool customers should be using the latest IBM License Metric Tool version and directs readers to current supported-technology information and notifications. Use those sources when making deployment or compliance decisions.
If you are seeking a current credential, contact IBM through its current certification resources rather than assuming that the old title has a direct successor. If you are preparing for a role, ask the employer which BigFix, License Metric Tool, HCL, database, operating-system, and virtualization versions are actually in scope, then adapt the roadmap.
Final readiness check
You are ready to move from reading to practical validation when you can draw the deployment without notes, explain client-based and IBM i disconnected collection, design a coexistence arrangement with separate application computers, and identify the evidence needed to confirm successful imports.
You should also be able to describe the administrator’s work across planning, installation, configuration, deployment, maintenance, troubleshooting, performance tuning, customization, and support. Add licensing awareness: distinguish full-capacity from sub-capacity context, check current eligibility and support information, and preserve the documentation required by the applicable terms.
For a historical exam study project, finish by matching your notes to the published objectives and recording any objective you cannot demonstrate. For current operational work, finish by checking version support and upgrade guidance. The next action is not to purchase an unverified exam attempt; it is to confirm the current IBM path or build a controlled, source-grounded administration plan.
Conclusion
This certification is a historical credential, not a current scheduling target according to IBM’s published page. Its objectives remain useful for understanding the administrator responsibilities around BigFix Inventory and License Metric Tool: design the environment, collect reliable data, maintain the platform, troubleshoot methodically, and connect technical evidence to licensing obligations. Use the official objectives for scope, current IBM and HCL documentation for live-version decisions, and a small controlled lab or documented workplace exercises to turn each topic into demonstrable skill.
