IBM Tivoli Identity Manager Fixes

From KnowWiki
Jump to: navigation, search

Contents

[edit] How to clear ITIM message queues

  • Stop Websphere service
  • Delete \\SIMs server\c$\Program Files\ibm\WebSphere\AppServer\profiles\AppSrv01\tranlog\xxxNode01Cell\xxxNode01\server1\transaction
  • Execute the following SQL commands on the enrole DB:
delete from ITIML000.SIB000
delete from ITIML000.SIB001
  • Start Websphere service

[edit] How to check for locked services in ITIM enrole DB

Display services with their lock status

select s.erservicename, rp.recon_status, rp.lock_service, rp.resource_status from enrole.resource_providers rp, enrole.service s where s.dn = rp.resource_dn order by s.erservicename

Display services with hung resource_status

select s.erservicename, rp.recon_status, rp.lock_service, rp.resource_status from enrole.resource_providers rp, enrole.service s where s.dn = rp.resource_dn and resource_status > 0 order by s.erservicename

Display services with hung recon_status

select s.erservicename, rp.recon_status, rp.lock_service, rp.resource_status from enrole.resource_providers rp, enrole.service s where s.dn = rp.resource_dn and recon_status > 0 order by s.erservicename

Check for any type of lock in the DB:

select count(*) from enrole.resource_providers where recon_status > 0;
select count(*) from enrole.resource_providers where resource_status > 0;
select count(*) from enrole.resource_providers where lock_service > 0;

Resetting the locks

update enrole.resource_providers set recon_status=0 where recon_status > 0
update enrole.resource_providers set resource_status=0 where resource_status > 0
update enrole.resource_providers set lock_service=0 where lock_service > 0

[edit] How to resolve ITIM hunging ops due to an adapter problem

Here are some queries you could try in the db:

SELECT * FROM enrole.resource_providers
UPDATE enrole.resource_providers SET resource_status=0 WHERE resource_status=2
SELECT COUNT (*) FROM enrole.remote_services_requests
SELECT DISTINCT service_dn FROM enrole.remote_services_requests
UPDATE enrole.resource_providers SET resource_status=1 WHERE resource_dn LIKE 'erglobalid=xxxx%'
UPDATE enrole.resource_providers SET resource_status=1 WHERE resource_status=2
SELECT * FROM enrole.remote_services_requests WHERE request_id='xxxxxxxxxxx'
SELECT request_id FROM enrole.resource_providers WHERE resource_status=2
SELECT request_id FROM enrole.remote_services_requests WHERE service_dn LIKE 'erglobalid=xxxxx%'
UPDATE enrole.resource_providers SET request_id='xxxxxxxxxxxxxxxx' WHERE resource_status=2
UPDATE enrole.resource_providers SET resource_status=1 WHERE resource_status=2
SELECT TYPE FROM enrole.remote_services_requests
SELECT request_id FROM enrole.remote_services_requests WHERE TYPE=2
  1. The following query provided a list of "good" request id's, which we used in one of the above sql queries to try to set the request_id value to an ID that the system could use. This might not solve the problem
  2. Rdited Program Files\ibm\itim\data\enRoleLogging.properties and set

logger.trace.com.ibm.itim.remoteservices.level=DEBUG_MAX

  1. Find the service id's that might be involved
erglobalid=xx,ou=services,erglobalid=00000000000000000000,ou=xxx,dc=itim,dc=dom

And do do

select request_id from enrole.resource_providers where resource_status=2

[edit] Aborting pending reports synchronization AKA unlocking ITIM Data synchronization

Also known as How to kill a Data Sync request in ITIM

 SELECT STATUS, STATUS_DETAIL, STARTED_TIME FROM enrole.SYNCHRONIZATION_HISTORY WHERE REQ_TYPE ='DS'
 SELECT COUNT(STATUS) FROM enrole.SYNCHRONIZATION_HISTORY WHERE STATUS ='Started' AND req_type='DS'
 UPDATE enrole.SYNCHRONIZATION_HISTORY SET STATUS = 'Aborted' WHERE STATUS = 'Started'

[edit] Audit DB2 locks and indoubt transaction keeps ITIM from starting up

clear them first. first try to roll them back. If fails try to cancel them. then clear the locks as needed (most if not all locks will be cleared by rolling back the indoubt transaction)

[edit] DB2 Tables for reporting

The ENTITY_COLUMN table is the one which contains the report status for the various report tables. It is rare that this does become out of sync but I have seen it happen. When it does it is not always that easy to determine which tables need to be adjusted in the AVAILABLE_FOR_REPORTING column and it would be best to open a pmr if you ever run into this type of situation.

[edit] GCE failst to start

copy JRE 1.4.2 from IBM into the root folder of GCE under /jre

[edit] DB2 has locks prohibiting changes

db2 get snapshot for locks on database

[edit] DB2 improperly shutdown with transaction in flight

Shutdown everything. Rollback any indoubt db2 to clear possible locks (if any are present when nothing is connecting to the db2) db2 snapshot on locks ... to see if any are presetn start half way up (not jmsserver) recreate message queues according to this page

Solution In the commands shown below - typical values for parameters are: For <server> the typical value is "server1" For <nodename> the typical value is the server host name

Examples of similar commands being used during the ITIM installation process can be seen in the $WAS_HOME\logs\createMQ.<nodename>_<server>.log file.

To Delete the Queue Manager and underlying content: Stop ITIM via the "stopServer" command in $WAS_HOME\bin

stopServer <server>

Delete the existing queue manager via the deletemq command in $WAS_HOME\bin

deletemq WAS <nodename> <server>

To create the Queue Manager: Create a new queue manager via the createmq command in $WAS_HOME\bin

createmq $WAS_HOME WAS <nodename> <server> $MQ_HOME $MQ_HOME\WEMPS

To start the Queue Manager: Start the queue manager via the "strmqm" command in $MQ_HOME\bin

strmqm WAS_<nodename>_<server>

To create the local queues within the queue manager: Start ITIM via the "startServer" command in $WAS_HOME\bin

startServer <server>

To verify that the local queues have been created: Utilize "runmqsc" found in the $MQ_HOME\bin directory against the queue manager (note: after the runmqsc command, you will enter the display qlocal command at a blank prompt.):

runmqsc WAS_<nodename>_<server>
display qlocal(*)
end
Look for the following local queues:
WQ_itim_adhocSync
WQ_itim_import_export
WQ_itim_ms
WQ_itim_policy
WQ_itim_policy_simulation
WQ_itim_ps
WQ_itim_rs
WQ_itim_rs_pending
WQ_itim_wf
WQ_itim_wf_shared

Note: If the local queues are not created after starting up ITIM, the WebSphere transaction logs might have to be deleted and ITIM restarted. To clear the WebSphere transaction logs, go to the $WAS_HOME\tranlog\<server>\transaction and delete the two directories and the two files in each of them.

start jmsserver

[edit] ITIM Generated PDFs are not opening correctly

There is an APAR at IBM (search the support site) showing that you need to remove pragma-cache and another caching variable But there is another case too: We have found two registry keys that seem to be the cause of our problems. The keys are listed below:

HKEY_USERS\ ?Users SSID ? \Software\Microsoft\Active Setup\Installed Components\{89820200-ECBD-11cf-8B85-00AA005B4383}
HKEY_USERS\ ? Users SSID ? \Software\Microsoft\Windows\CurrentVersion\Internet Settings

When we delete the two keys listed above, it fixes it (the keys are recreated after user logoff/logon)

[edit] ITIM does not work with Enterprise MQ

In addition, I was informed that the install MUST use the embedded MQ installation, as TIM does not operate correctly with the Enterprise MQ.

[edit] ITIM requests stuck in Pending Requests queue and aborts dont respond.

Problem Requests remain Pending queue with a 'Running' status and requests submitted after that remain in 'Not Started' state. Attempts to abort the Requests don't execute. The itim.log file shows no activity, browsing the application via the UI still works fine.

Cause It is possible that a request could still be processing in the ITIM server, specifically in JMS messaging.

Solution This solution applies to Websphere Application Server 5.0.x with MQ Series 5.3 embedded. Check the MQ queues for existing messages, specifically the CURDEPTH attribute. This can be done via a command line prompt on either Windows or Unix server installs:

  1. For single server environments, type "runmqsc WAS_<hostname>_<server instance name>" at the command line prompt to access MQ's Script Command functionality. For example, enter 'runmqsc WAS_alpha_server1' to connect to the 'server1' instance with the Script Command utility on the "alpha" server.

For cluster environments, type "runmqsc WAS_<hostname>_jmsserver" at the command line prompt to access MQ's Script Command functionality. For example, enter 'runmqsc WAS_alpha_jmsserver' to connect to the Script Command utility on the "alpha" server.

Once connected you will see this response:

"Starting MQSC for queue manager WAS_alpha_jmsserver."

Unfortunately there really isn't a prompt symbol to indicate you've arrived at the Script Command utility, it's just a blank line so be sure you see the aforementioned response.

  1. Enter "dis ql('WQ_itim_*') CURDEPTH" to display the CURDEPTH value for all of the ITIM queues. This should display a value of zero for all queues (see sample output below) if there are no messages currently pending, processing:
dis ql('WQ_itim_*') CURDEPTH
dis ql('WQ_itim_*') CURDEPTH
AMQ8409: Display Queue details.
QUEUE(WQ_itim_adhocSync) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(WQ_itim_ms) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(WQ_itim_rs) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(WQ_itim_rs_pending) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(WQ_itim_wf) CURDEPTH(99)
AMQ8409: Display Queue details.
QUEUE(WQ_itim_wf_abort) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(WQ_itim_wf_pending) CURDEPTH(0)


  1. If any of these returns a CURDEPTH value greater than zero then there are still messages being processed. This would most likely occur if a large request or large volume of requests were submitted in ITIM. If there is a CURDEPTH value/s greater than zero, continue running the "dis ql('WQ_itim_*') CURDEPTH" command and watch to see if the numbers/values are changing. The numbers should change (at least every few minutes) and eventually return to zero.

If after a long period of time (scenario dependent, > 20 minutes maybe . . . ?) the CURDEPTH values are not changing then it may be necessary to purge messages from the appropriate queues. If the values/numbers are changing then let ITIM continue processing until it is finished.

  1. If it is necessary to purge a queue/s of current messages you must stop WAS first. If you don't you will likely see a response like "AMQ8148: WebSphere MQ object in use." when you attempt clear the queue/s.
  2. *** NOTE ****

The process of clearing the queues of existing messages will remove activities that have been generated by ITIM, so it is possible that complete requests may be removed and will need to be resubmitted. To clear a queue of existing messages type "clear ql('WQ_itim_wf')" at the mqsc prompt (where the "WQ_itim_wf" queue was the queue with message content in our example above). Use the "dis ql('WQ_itim_*') CURDEPTH" command again to confirm the messages in the queue have been purged.

  1. When all queues have a CURDEPTH value of zero restart ITIM/WAS and confirm the previously hung process is again processing. This should allow ITIM to continue processing normally again and allow all Pending requests to process through.

It is possible however that this will not resolve the problem and allow Pending requests to continue through to completion. The requests may need to be aborted and resubmitted as a new request. The restart of ITIM/WAS should restart the MQ Queue Manager and allow it to receive and process requests/messages, but there could be something more to the problem that would prevent this from being sufficient action. If the problem persists at this point, that is following these steps has not resolved the problem, contact support for further assistance.

[1]

[edit] ITIM server wont process any new requests, all remain in the Pending Requests queue and a Request abort doesnt seem to respond

Connect to the mq you can run dspmq to see the list of queue servers to use with runmqsc. The server must have Running next to it

runmqsc WAS_<hostname>_<server instance name> (i.e runmqsc WAS_alpha_server1)

you will get NO prompt. Dont worry - just start inputing the lines. run to see if tim mq is not empty

dis ql('WQ_itim_*') CURDEPTH
clear qlocal('WQ_itim_ms'). If it says
"AMQ8143 MQSeries queue not empty"

First try to restart the jmsservers. No need to exit runmqsc, just stopserver jmsserver then startserver jmsserver. You might first have to start the channel by running start channel(WAS.JMS.SVRCONN) (same for all itim installs). If you are trying to clear up WQ_itim_wf and it is not clearing up try restarting server1, dmgs,nodeagent and jmsserver. Try to clean it again. Also try

alter ql('WQ_itim_wf') FORCE

Try starting ITIM and check again (?) More information

[edit] Logging

C:\Program Files\IBM\itim\data\enRoleLogging.properties

Set

logger.trace.level=DEBUG_MIN, MID or MAX

[edit] Provisioning policy enforcement fails with Object Class violation

CTGIMO017E The following directory server schema violation occurred. Error: [LDAP: error code 65 - Object Class Violation] Another symptom is it happens when empty values are being enforced to non-empty ones. May be only e-mail related. Fix: Restart the ITIM server. If not possible or a small number of error - try to localize the field(s) that is getting enforced and is causing the object class violation. Now open the LDAP browser for the ITIM LDAP, search for the failed entry and change the field(s) causing problems from null to anything else. Then re-run the policy enfrocement. TIM FP21 fixes (or was supposed to) the error. [2]

[edit] Purging Tivoli Identity Manager database content

For more info about ITIM DB2 usage see the problem determination guide. [3]

Cause The data in the ITIM database tables is not maintained automatically by ITIM, and therefore it must be managed manually. Solution The database tables used to store processes information are the following (with a brief explanation taken from the ITIM Problem Determination Guide): PROCESS: stores all the pending, running, and historical requests submitted to the Tivoli Identity Manager workflow. Each request is represented as a process. PROCESSLOG: maintains a record of audit events associated with a process. PROCESSDATA: stores the runtime process data of a process. After the process is completed, the record is removed. ACTIVITY: contains records of each workflow process's execution flow. WORKITEM: maintains a record of workitems associated with manual workflow activies for running processes. The records associated with the process are removed after the process is completed. PASSWORD_TRANSACTION: is used during secure password delivery to store information. After the password is retrieved, the record is deleted from the table. If the password is never picked up, this record is deleted upon password pickup expiration. PENDING: stores all the provisioning requests that are being processed, but not completed yet.

The audit information regarding completed/terminated processes can be purged by following these steps below, regardless the kind of DBMS being used (important note: once this archived data is removed there will no longer be archive/audit data for ITIM to reference; for this reason it is highly recommended that a backup of the database be done before the purge is executed): Start a SQL command processor and connect to the ITIM database (authenticating as the "enrole" user). Execute the following statements:

delete from ENROLE.PROCESSLOG where PROCESS_ID in (select ID from ENROLE.PROCESS where COMPLETED IS NOT NULL)
delete from ENROLE.PROCESSDATA where PROCESS_ID in (select ID from ENROLE.PROCESS where COMPLETED IS NOT NULL)
delete from ENROLE.WORKITEM where PROCESS_ID in (select ID from ENROLE.PROCESS where COMPLETED IS NOT NULL)
delete from ENROLE.PENDING where PROCESS_ID in (select ID from ENROLE.PROCESS where COMPLETED IS NOT NULL)
delete from ENROLE.PASSWORD_TRANSACTION where PROCESS_ID in (select ID from ENROLE.PROCESS where COMPLETED IS NOT NULL)
delete from ENROLE.ACTIVITY where PROCESS_ID in (select ID from ENROLE.PROCESS where COMPLETED IS NOT NULL)
delete from ENROLE.PROCESS where COMPLETED IS NOT NULL.

Close the connection to ITIM database and exit from the SQL command processor. The statements execution order is relevant because of the presence of foreign key constraints.

[edit] Reconciliation does not pull the values of attributes from the IDI search AL

Reconciliation does not pull the values of attributes from the IDI search assembly line. Check all attributes to match the ITIM config. especially if the could or could not be multivalued. In my example office code was multivalued in the ldap and it made none of the rest of the ldap attributes come accross back to ITIM. No errors were reported on the IDI or ITIM gui side (did not check the log).

[edit] SPNEGO error message

"Browser Configuration Error The application you are trying to access requires a change to your security settings." To resolve the problem yourself, click "Tools", "Internet Options", "Security", and select {zone you are in}. Click on "Custom Level", scroll to the bottom under "User Authentication", "Logon". Select "Anonymous logon", click "Ok" to close the window, and "Ok" to close the previous window. Shut down your browser and attempt to logon again.

[edit] Some attributes can not be created or deleted

Attributes and class names can not contain underscores for IDS. This is an incompatibility known to IBM. It seems to be due to the DB2 running under IDS

[edit] Workflows are not getting completed in a clustered TIM environment

Make sure the other half of the cluster is up. Stop the servers, delete WAS/translog/transactions folder and clear the mq queues. Start them back up. If still stuck check the DB2 indoubt transactions and the locks

[edit] Agent fails to start

If you have multiple agents check the ADK version required by an agent (use agentCfg) sometimes it is different with different agents and they dont work with the one installed

[edit] fixing hung data synchronization for reports

To check if the data sync lock is held issue the following DB2 commands: 1) Start a DB command line as the ITIM DB2 instance owner. 2) CONNECT TO the ITIM DB. 3) Execute the following from the DB command line

EXPORT TO "C:\Scheduled_Message.wsf" OF WSF MODIFIED BY 1 MESSAGES "C:\Scheduled_Message.txt" SELECT * FROM ENROLE.SCHEDULED_MESSAGE;
EXPORT TO "C:\Synchronization_History.wsf" OF WSF MODIFIED BY 1 MESSAGES "C:\Synchronization_History.txt" SELECT * FROM ENROLE.SYNCHRONIZATION_HISTORY;

Then send the .wsf files. This are binary files. Or text files can be generated from the commands:

SELECT * FROM ENROLE.SCHEDULED_MESSAGE;
SELECT * FROM ENROLE.SYNCHRONIZATION_HISTORY;

To Clear out the "In Progress" state: Delete the row in the SYNCHRONIZATION_HISTORY table. Using the following command.

DELETE  FROM ENROLE.SYNCHRONIZATION_HISTORY WHERE STATUS='Started';  COMMIT;

You can determine that the lock is held in the SYNCHRONIZATION_HISTORY table then removing it from the table will clear the lock. If you continue to have problems the following entries in the ITIM enroleLogging.properties file will provide more information:

logger.trace.com.ibm.itim.report.level=DEBUG_MAX
logger.trace.com.ibm.itim.dataservices.model.level=DEBUG_MAX
logger.trace.com.ibm.itim.adhocreport.level=DEBUG_MAX
logger.trace.com.ibm.itim.apps.ejb.adhocreport.level=DEBUG_MAX

[edit] Providing correct timezone offset from TAM to TIM

Configuring the Time Zone Offset: After you logon to the Tivoli Identity Manager console, the Effective Date field displays the server time in GMT (Greenwich Mean Time) instead of the local browser time. The administrator can provide a workaround to have the desired time displayed.

  • Embed the time zone offset value in the URL provided (publish) to users in the following format:

http://WebSEAL-system-address/junction-name/enrole/logon?timezoneOffset=calculated-offset

The URL link passes the offset value as an HTTP parameter when submitting the post. For example, if the server is in California (United States) and the users (client browsers) are in Tokyo (Japan), publish the following URL to the users in Japan:

http://WebSEAL-system-address/junction-name/enrole/logon?timezoneOffset=9

  • Alternatively, you can publish the URL of a Web page on the Web server used by WebSEAL, or a Web page that is part of your corporate portal. The Web page presents the link to the WebSEAL SSO. The page should contain a JavaScript function that calculates the time zone offset between the client browser and GMT. Once clicked, the link should submit an HTTP request (with the auto-calculated time zone offset value passed as an HTTP parameter) to the Tivoli Identity Manager Server. When using this approach, the offset value is automatically calculated.

[4]

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox