What is WBEM?

WBEM is a set of systems management technologies developed to unify the management of distri
buted computing environments.

Key features of WBEM technology

1) remote management of applications
2) management of several instances of an application as a single unit
3) standard interface for remote application management across different applications
4) decoupling of application management from the client
5) "publishing" of key information about an application to other applications

How does WBEM "work"

A client will use the HTTP (or HTTPS) protocol to pass the request, encoding in CIM-XML, to
the WBEM server. The WBEM server will decode the incoming request, perform the necessary
authentication and authorization checks and then consult the previously-created model of the
device being managed to see how the request should be handled. For most operations, the WBEM
server determines from the model that it needs to communicate with the actual hardware or
software. This is handled by so-called "providers": small pieces of code which interface between
the WBEM server (using a standardised interface known as CMPI) and the real hardware or
software.
Note: SMI-S (Storage Management Initiative - Specification) is based on WBEM and is used for
SAN devices!

WBEM Ports
Secure port 5989
Standard port 5988
Events port 50004

WBEM Processes
/opt/wbem/lbin/cimserver
/opt/wbem/lbin/cimservera
/opt/wbem/lbin/cimserverd (restarts cimserver process if it terminated abnormally)
/opt/wbem/lbin/cimprovagt (several cimprovagt will probably be running)
cimservera (HP-UX only)- cimservera is a standalone process that provides the cimserver with
PAM Authentication services. cimservera is controlled solely by the cimserver, and as such has no
user interface.
cimserverd (HP-UX only)- HP WBEM Services’ way to automatically restart itself in case of
failure. cimserverd is not intended to be used by operators. Users can, however set the interval for
cimserverd. To see how to do that, read the cimserverd man page. Users start (and halt) CIM
Server with the cimserver command. If the CIM Server was halted by an operator with the cimser
ver command, cimserverd cannot automatically restart it.
HP-UX Directory Structure
/opt/wbem/bin --> WBEM Services utilities: cimmof, wbemexec, cimprovider, osinfo
/opt/wbem/sbin --> Executables for WBEM Services configuration commands: cimconfig,
cimauth, init_repository, cimtrust, and ssltrustmgr
/opt/wbem/lbin --> Internal executables: cimserver, cimprovagt, cimservera, cimserverd, ranseed,
and repupgrade
/opt/wbem/lib --> Shared library files for HP WBEM Services
/opt/wbem/providers/lib --> Links to Shared library files for CIM Providers
/opt/wbem/share/man --> Man pages for HP WBEM Services
/var/opt/wbem --> Sample/default configuration files. Location of trace files.
/var/opt/wbem/localauth -->Temporary directory used during Local Authentication
/var/opt/wbem/repository --> Directory containing the CIM Repository
/opt/wbem/mof --> Directory containing the initial Schema definition (A.02.05.X or higher)

1. What we need to do is collect all the basic data about the system, the repository files, and run
some simple tests to check the health of the system. This can all be achieved using the Wbem
Info.sh script. To run WbemInfo.sh, first download the tool to the /opt/wbem/bin directory:
# tar -xvf wbeminfo..tar
# cd wbeminfo
# ./WbemInfo.sh data_repos
Ask for the /tmp/WbemFiles_B.11.XX.tar.gz file.

2. The second thing we can do, is try to capture some cimserver.trc when the 'subscribe WBEM
events' is done from the Windows HP SIM CMS. This should capture the CIM-XML communi
cation between the CMS and the target node.
# rm /var/opt/wbem/trace/cim*
# cimconfig -s traceComponents=All -c
# cimconfig -s traceLevel=4 -c

'subscribe WBEM events'

# cimconfig -u traceComponents
# cimconfig -u traceLevel
Ask for the contents of the /var/opt/wbem/trace directory.

3. Finally, as Certificate Based Authentication is [allegedly] being used, we should check that the
SSL certificates have valid hostnames:
# cimtrust -l
# ssltrustmgr -l -f /etc/opt/hp/sslshare/cert.pem

4. Other things that you might want to try, as they have had success in the past, are:
1) delete and re-add the affected node in HP SIM
2) re-install WBEM Services on the target node
On the later, the following error is an indication that the WBEM Services installation has a probl
em.
Troubleshooting
What is the action plan?
1) cimsub –ls will print all the SIM and WEBES subscriptions, if there are any that is not remov
ed properly.
# cimsub -ra -n root/cimv2 -F <SIM filter name> -H <SIM handler name>
# cimsub -ra -n root/cimv2 -F <WEBES filter name> -H <WEBES handler name>

2) Remove entries from CMS.

CMS> mxwbemsub –r –n archadm.arj.archchemicals.com

3) Make sure there are no enabled entries shown for:

# cimsub -lf | grep -i webes
# cimsub -lh | grep -i webes
# cimsub -ls | grep -i webes
# cimsub -lf | grep -i sim
# cimsub -lh | grep -i sim
# cimsub -ls | grep -i sim

4) If any entries show up, use "cimsub -n root/cimv2 -rf <filter name>" for cleaning filter.
Use "cimsub -n root/cimv2 -rh <handler name>" for cleaning handler files.

5) When it is cleaned up, completely. Bounce the servers.

CMS> desta stop
archadm# cimserver -s
archadm# cimserver
CMS> desta start

6) Now to subscription again:

CMS:
• Click [Option]
• Click [Event]
• Click [Subscribe event to WBEM]
• Select archadm
• Click [Next]
• Click [Run now]
• It shows Subscribe to WBEM Events

WBEM Troubleshooting
Check as well the WTEC WBEM_SERT DIY (Do It Yourself) Triage Page
Check wether the cimserver is running
Restart the cimserver
#cimserver -s
#cimserver
Run a local osinfo
#osinfo

Run a remote osinfo

#osinfo -h <hostname>
Check that enableHttpConnection is set to true:
/opt/wbem/sbin/cimconfig -lp
sslClientVerificationMode=required
enableSubscriptionsForNonprivilegedUsers=false
shutdownTimeout=30
authorizedUserGroups=
enableRemotePrivilegedUserAccess=true
enableHttpsConnection=true
enableNamespaceAuthorization=false
enableHttpConnection=false
So change the value
#cimconfig -s enableHttpConnection=true -p
#cimserver -s
#cimserver
Info: enableHttpConnection is not a dynamic value. Therefor only the planned configuration can
be change and not the current configuration.
Check the the Provider Module is loaded and ok:
# cimprovider -ls

To load a Provider Module - check the the provider is installed using swlist - do a swverify or
reinstall the provider

Using cimserver Tracing

Ensure cimserver is running
# ps -ef |grep cimserver
Move or remove any existing trace file
# mv /var/opt/wbem/cimserver.trc /var/opt/wbem/cimserver.trc.prev
Turn on tracing Note: Tracing at level 4 for all components will generate lots of output in the trace
file; it is recommended that tracing be turned on only for the minimum time required to reproduce
the problem being investigated or exercise the function being analyzed.
# cimconfig -s traceLevel=4 -c
# cimconfig -s traceComponents=ALL -c
Send a test indication
Steps required to send a test indication depend on the specific indication provider and indication
subscription involved; e.g., using sfmconfig -t -p. Analysis of the trace file output will be simplest
if a single test indication is sent.
Turn off tracing
# cimconfig -u traceComponents -c
# cimconfig -u traceLevel -c
Alternatively, the cimserver could be stopped and restarted to turn off tracing
# cimserver -s
# cimserver
There is a script to gather the most important infos / logs for a WBEM case - this is call wbemin
fo.tar
Download wbeminfo.tar from intranet
# tar xvf wbeminfo.tar
./WbemInfo.sh data_only
collect the file /tmp/WbemFiles_*.tar.gz

Issue
On an HP-UX 11i v1 (v 11.11) server, Web-Based Enterprise Management (WBEM) Services
version A.02.05.08 is installed. After updating products and patches, the cimserver process now
consumes CPU time. There are several cimprovagt processes for the System Fault Management
(SFM) provider running, and cimprovider fails to list any providers.
# cimprovider -ls
connection timed out
# ps -ef | grep cim
root 6100 1 0 Jun 17 ? 1:10 /opt/wbem/lbin/cimserverd
root 13903 1 0 Jul 9 ? 0:02 /opt/wbem/lbin/cimprovagt 15 14 SFMProviderModule
root 24680 24679 0 Jul 11 ? 0:00 /opt/wbem/lbin/cimservera
root 19368 1 0 Jun 17 ? 0:08 /opt/wbem/lbin/cimprovagt 14 13 SFMProviderModule
root 24679 1 0 Jul 11 ? 3404:10 /opt/wbem/lbin/cimserver
root 26408 24679 0 Jul 11 ? 0:02 /opt/wbem/lbin/cimprovagt 15 14 SFMProviderModule
root 28168 24679 0 Jul 11 ? 0:00 /opt/wbem/lbin/cimprovagt 18 17 OperatingSystemModule
root 1516 1 0 Jun 24 ? 0:02 /opt/wbem/lbin/cimprovagt 15 14 SFMProviderModule

Solution
During troubleshooting, it was found that the /opt/sfmdb/pgsql/bin/postmaster process was runn
ing with a UID 103 instead of the sfmdb user as the owner. There was no entry in the /etc/passwd
file for this UID or the sfmdb user.

The sfmdb user was added back with its original UID to the /etc/passwd file:
# pwget -n sfmdb
sfmdb:*:103:20::/home/sfmdb:/sbin/sh

Restart cimserver and SFM:

# /sbin/init.d/sfmdb stop
# ps -ef | grep sfm
Use the kill command if any postmaster or postgres processes for user sfmdb are still running.
NOTE: Only stop postmaster processes owned by user sfmdb . Other applications, such as Syste
ms Insight Manager (SIM) will have separate postmaster (PostgreSQL ) processes running.
# cimserver -s
PGS10019: CIM server is stopped.
# ps –ef | grep cim
If any cimserver or cimprovagt processes besides cimserverd are running, use the kill command
(or kill -9 if needed).

Then restart SFM:

# /sbin/init.d/sfmdb start
# ps -ef |grep sfm
sfmdb 801 1 0 11:18:56 pts/ta 0:00 /opt/sfmdb/pgsql/bin/postmaster -I -D /var/opt/sfmdb/pgsql
sfmdb 805 804 0 11:18:56 pts/ta 0:00 postgres: stats collector process
sfmdb 804 801 0 11:18:56 pts/ta 0:00 postgres: stats buffer process

Start cimserver :
# cimserver

Test WBEM:
# osinfo
# cimprovider –ls

For HP-UX, there are 7 providers bundled with HP WBEM Services. These providers are:
• Computer System
• Operating System
• Process
• Domain Name Service
• Network Time Protocol
• Network Information Service
• IP
For HP-UX 11i v1, the Computer System, Operating System, Process, and IP providers are
registered automatically at installation.
However, you must explicitly register these three providers:
1) Domain Name Service provider
2) Network Time Protocol provider
3) Network Information Service provider

The command to register these three providers is (all on one line):

# /opt/wbem/bin/cimmof -I /etc/opt/wbem/mof -n root/PG_InterOp /etc/opt/wbem/mof/HPUX_
ManagedSystemSchemaR.mof

How to register all other providers (tested in 11.31)

These commands are used to readd the providers to the cimprovider -ls list (re-register the provid
ers).
DNS/NIS/NTP Modules:
# cimmof -w -n root/PG_InterOp /opt/wbem/mof/HPUX_ManagedSystemSchema20R.mof
IOTreeModule:
# cimmof -w -n root/PG_InterOp /opt/interconnect/wbem_providers/io/IOTreeProviderR.mof

FCProvider Module:
# cimmof -w -n root/PG_InterOp /opt/fcprovider/mof/HPUXFCIndicationR.mof
# cimmof -w -n root/PG_InterOp /opt/fcprovider/mof/HPUXFCProviderModuleRegister.mof
# cimmof -w -n root/PG_InterOp /opt/fcprovider/mof/HPUXFCCSProviderModuleRegister.mof

LANProvider Module:
# cimmof -w -n root/PG_InterOp /opt/lanprovider/mof/HPUXLANProviderModuleRegister.mof
# cimmof -w -n root/PG_InterOp /opt/lanprovider/mof/HPUXLANCSProviderModuleRegister.
mof
# cimmof -w -n root/PG_InterOp /opt/lanprovider/mof/HPUXLANIndicationProviderModuleR.
mof

VParProvider Module:
# cimmof -w -n root/PG_InterOp /opt/vparprovider/mof/VParReg.mof

NParProvider Module:
# cimmof -w -n root/PG_InterOp /opt/nparprovider/mof/NParReg0205.mof

DASProvider Module:
# cimmof -w -n root/PG_InterOp /opt/dasprovider/mof/HPUXStorageIndicationR.mof
# cimmof -w -n root/PG_InterOp /opt/dasprovider/mof/HPUXStorageInstanceR.mof

Kernel Module:
# cimmof -w -n root/PG_InterOp /opt/uxprov/mof/HPUX_ProviderModuleR.mof
# cimmof -w -n root/PG_InterOp /opt/uxprov/mof/HPUX_SwapR.mof
# cimmof -w -n root/PG_InterOp /opt/uxprov/mof/HPUX_CrashDumpR.mof
# cimmof -w -n root/PG_InterOp /opt/uxprov/mof/HPUX_BootR.mof

OLOSProvider Module:
# cimmof -w -n root/PG_InterOp /opt/olosprovider/mof/OLOSPReg.mof

RAIDSAProvider Module:
# cimmof -w -n root/PG_InterOp /opt/raidsaprovider/mof/HPUXRAIDSACSProviderModuleR.
mof
# cimmof -w -n root/PG_InterOp /opt/raidsaprovider/mof/HPUXRAIDSAIndicationR.mof

SASProvider Module:
# cimmof -w -n root/PG_InterOp /opt/sas/sasprovider/mof/HPUXSASCSProviderModuleRegister.
mof
UtilizationProvider Module:
# cimmof -w -n root/PG_InterOp /opt/util/mof/Reg.mof

VMProvider Module:
# cimmof -w -n root/PG_InterOp /opt/hpvmprovider/mof/HPVMReg.mof

iCOD Modules:
# cimmof -n root/PG_InterOP /opt/icod/mof/HP_iCODProviderReg.mof
# cimmof -n root/PG_InterOP /opt/icod/mof/HP_iCAPProviderReg.mof
# cimmof -n root/PG_InterOP /opt/icod/mof/HP_GiCAPProviderReg.mof

LVMProvider Module:
# cimmof -w -n root/PG_InterOp /opt/lvmprovider/mof/LVMProviderR.mof

ResParProvider Module (PRM):

# cimmof -w -n root/PG_InterOp /opt/prm/lib/hpux32/HP_ResParReg.mof
# cimmof -w -n root/PG_InterOp /opt/prm/lib/hpux32/HP_ResParReg5.mof

AmgrAgentProvider Module:
# cimmof -w -n root/PG_InterOp /opt/amgr/wbem/AmgrAgentProvider.mof
# cimmof -w -n root/PG_InterOp /opt/amgr/wbem/AmgrAgentProviderMeta.mof
# cimmof -w -n root/PG_InterOp /opt/amgr/wbem/AmgrAgentProviderMeta2.mof

EMSHAProvider Module:
# cimmof -w -n root/PG_InterOp /etc/opt/resmon/mof/EMSHAProviderR.mof

SGProvidersModule
# cimmof -w -n root/PG_InterOp /opt/sgproviders/mof/HP_SGClusterR.mof

FSProviderModule
# cimmof -w -n root/PG_InterOp /opt/fsprovider/mof/PG_FileSystem20R.mof

The repository files located in /var/opt/wbem/repository/ for HP-UX and /var/cache/pegasus/rep

ository/ for Linux are created as a by-product of the HP WBEM Services installation. They should
never be deleted or moved.

Four namespaces install with HP WBEM Services. Others may be added by clients and providers.
The four that are automatically installed are:
root: The root namespace exists to conforms to the DMTF specifications.
root/cimv2: The standard CIM schemas go here. Also, the schemas for the bundled providers.
root/PG_Interop: This is for provider registration. This space is reserved exclusively for providers,
and all providers must register here. (See cimprovider man page.)
root/PG_Internal: This space is reserved for use by HP WBEM Services only.
It is important to schedule frequent backups of the repository directories and files. If the repository
is moved or lost or it becomes corrupted, restore the files you backed up.

If you cannot restore the files, the init_repository script will restore the files to the way they were
when you first installed HP WBEM Services. The three providers that installed with HP WBEM
Services will be intact. However, any managed objects, providers, or namespaces that you added
since you first installed HP WBEM Services will be gone. You will need to re-register (perhaps
reinstall) all the added providers.

To run the script, enter the following commands:

Shut down the CIM Server.
# cimserver -s
Move the repository directory.
# mv /var/opt/wbem/repository /var/opt/wbem/repository.bak
Start the CIM Server.
# cimserver
Run the init_repository script.
# /opt/wbem/sbin/init_repository

Some times is necessary to recreate a namespace under repository directory for wbem. Editing this
directory manually is not recommended but sometimes is necessary. You can follow the steps to
recreate the repository, to recreate the regular namespaces, that are created when you install WBE
M Services, but there are other namespaces that are created when you install other Providers, for
example, NparProvider, VparProvider, HPVM Provider, etc.

Here are the steps:

1. Make a backup of your current repository by copying it to another directory:
# cp /var/opt/wbem/repository /var/opt/wbem/repository.bak

2. Move the namespace of the problematic provider, example npar:

# mv /var/opt/wbem/repository/root#cimv2#npar /var/tmp/root#cimv2#npar.bak

3. Re-install the Provider associated to the namespace:

# swinstall -x reinstall=true -x reinstall_files=true -s <fullpathtodepot> \*

This should recreate the namespace correctly and fix the repository.

What is WBEM?
WBEM is a set of systems management technologies developed to unify the management of distri
buted computing environments.
Key features of WBEM technology
remote management of applications
management of several instances of an application as a single unit
standard interface for remote application management across different applications
decoupling of application management from the client
"publishing" of key information about an application to other applications

How does WBEM "work"

A client will use the HTTP (or HTTPS) protocol to pass the request, encoding in CIM-XML, to
the WBEM server. The WBEM server will decode the incoming request, perform the necessary
authentication and authorization checks and then consult the previously-created model of the
device being managed to see how the request should be handled. For most operations, the WBEM
server determines from the model that it needs to communicate with the actual hardware or
software. This is handled by so-called "providers": small pieces of code which interface between
the WBEM server (using a standardised interface known as CMPI) and the real hardware or
software.

Note: SMI-S (Storage Management Initiative - Specification) is based on WBEM and is used for
SAN devices!
WBEM Ports
Secure port 5989
Standard port 5988
Events port 50004
WBEM Processes

/opt/wbem/lbin/cimserver
/opt/wbem/lbin/cimservera
/opt/wbem/lbin/cimserverd (restarts cimserver process if it terminated abnormally)
/opt/wbem/lbin/cimprovagt (several cimprovagt will probably be running)
cimservera (HP-UX only)- cimservera is a standalone process that provides the cimserver with
PAM Authentication services. cimservera is controlled solely by the cimserver, and as such has no
user interface.

cimserverd (HP-UX only)- HP WBEM Services’ way to automatically restart itself in case of
failure. cimserverd is not intended to be used by operators. Users can, however set the interval for
cimserverd. To see how to do that, read the cimserverd man page. Users start (and halt) CIM
Server with the cimserver command. If the CIM Server was halted by an operator with the
cimserver command, cimserverd cannot automatically restart it.

HP-UX Directory Structure

/opt/wbem/bin --> WBEM Services utilities: cimmof, wbemexec, cimprovider, osinfo
/opt/wbem/sbin --> Executables for WBEM Services configuration commands: cimconfig,
cimauth, init_repository, cimtrust, and ssltrustmgr
/opt/wbem/lbin --> Internal executables: cimserver, cimprovagt, cimservera, cimserverd, ranseed,
and repupgrade
/opt/wbem/lib --> Shared library files for HP WBEM Services
/opt/wbem/providers/lib --> Links to Shared library files for CIM Providers
/opt/wbem/share/man --> Man pages for HP WBEM Services
/var/opt/wbem --> Sample/default configuration files. Location of trace files.
/var/opt/wbem/localauth -->Temporary directory used during Local Authentication
/var/opt/wbem/repository --> Directory containing the CIM Repository
/opt/wbem/mof --> Directory containing the initial Schema definition (A.02.05.X or higher)
1. What we need to do is collect all the basic data about the system, the repository files, and run
some simple tests to check the health of the system. This can all be achieved using the
WbemInfo.sh script:

To run WbemInfo.sh, first download the tool to the /opt/wbem/bin directory:

# tar -xvf wbeminfo..tar
# cd wbeminfo
# ./WbemInfo.sh data_repos
Ask for the /tmp/WbemFiles_B.11.XX.tar.gz file.

2. The second thing we can do, is try to capture some cimserver.trc when the 'subscribe WBEM
events' is done from the Windows HP SIM CMS. This should capture the CIM-XML
communication between the CMS and the target node.
# rm /var/opt/wbem/trace/cim*
# cimconfig -s traceComponents=All -c
# cimconfig -s traceLevel=4 -c

'subscribe WBEM events'

# cimconfig -u traceComponents
# cimconfig -u traceLevel
Ask for the contents of the /var/opt/wbem/trace directory.

3. Finally, as Certificate Based Authentication is [allegedly] being used, we should check that the
SSL certificates have valid hostnames:
# cimtrust -l
# ssltrustmgr -l -f /etc/opt/hp/sslshare/cert.pem

4. Other things that you might want to try, as they have had success in the past, are:
delete and re-add the affected node in HP SIM
re-install WBEM Services on the target node
On the latter, the following error is an indication that the WBEM Services installation has a
problem:
Troubleshooting
What is the action plan?
1) cimsub –ls will print all the SIM and WEBES subscriptions, if there are any that is not
removed properly.

# cimsub -ra -n root/cimv2 -F <SIM filter name> -H <SIM handler name>

# cimsub -ra -n root/cimv2 -F <WEBES filter name> -H <WEBES handler name>

2) Remove entries from CMS.

CMS> mxwbemsub –r –n archadm.arj.archchemicals.com

3) Make sure there are no enabled entries shown for:

# cimsub -lf | grep -i webes
# cimsub -lh | grep -i webes
# cimsub -ls | grep -i webes
# cimsub -lf | grep -i sim
# cimsub -lh | grep -i sim
# cimsub -ls | grep -i sim

4) If any entries show up, use "cimsub -n root/cimv2 -rf <filter name>" for cleaning filter.
Use "cimsub -n root/cimv2 -rh <handler name>" for cleaning handler files.

5) When it is cleaned up, completely. Bounce the servers.

CMS> desta stop
archadm# cimserver -s
archadm# cimserver
CMS> desta start

6) Now to subscription again:

CMS:
• Click [Option]
• Click [Event]
• Click [Subscribe event to WBEM]
• Select archadm
• Click [Next]
• Click [Run now]
• It shows Subscribe to WBEM Events

WBEM Troubleshooting
Check as well the WTEC WBEM_SERT DIY (Do It Yourself) Triage Page
Check wether the cimserver is running
Restart the cimserver
#cimserver -s
#cimserver

Run a local osinfo

#osinfo

Run a remote osinfo

#osinfo -h <hostname>
Check that enableHttpConnection is set to true:

/opt/wbem/sbin/cimconfig -lp
sslClientVerificationMode=required
enableSubscriptionsForNonprivilegedUsers=false
shutdownTimeout=30
authorizedUserGroups=
enableRemotePrivilegedUserAccess=true
enableHttpsConnection=true
enableNamespaceAuthorization=false
enableHttpConnection=false
So change the value

#cimconfig -s enableHttpConnection=true -p
#cimserver -s
#cimserver
Info: enableHttpConnection is not a dynamic value. Therefor only the planned configuration can
be change and not the current configuration.

Check the the Provider Module is loaded and ok:

# cimprovider -ls

To load a Provider Module - check the the provider is installed using swlist - do a swverify or
reinstall the provider

Using cimserver Tracing

Ensure cimserver is running

# ps -ef |grep cimserver

Move or remove any existing trace file

# mv /var/opt/wbem/cimserver.trc /var/opt/wbem/cimserver.trc.prev
Turn on tracing Note: Tracing at level 4 for all components will generate lots of output in the trace
file; it is recommended that tracing be turned on only for the minimum time required to reproduce
the problem being investigated or exercise the function being analyzed.
# cimconfig -s traceLevel=4 -c
# cimconfig -s traceComponents=ALL -c
Send a test indication
Steps required to send a test indication depend on the specific indication provider and indication
subscription involved; e.g., using sfmconfig -t -p. Analysis of the trace file output will be simplest
if a single test indication is sent.

Turn off tracing

# cimconfig -u traceComponents -c
# cimconfig -u traceLevel -c
Alternatively, the cimserver could be stopped and restarted to turn off tracing

# cimserver -s
# cimserver
There is a script to gather the most important infos / logs for a WBEM case - this is call wbem
info.tar Download wbeminfo.tar from intranet

# tar xvf wbeminfo.tar

./WbemInfo.sh data_only
collect the file /tmp/WbemFiles_*.tar.gz