01. Repository don't exists
Solution: Administration > Attachments Library > Repositories
Know more: How to Set Up the Attachments Library - CA Service Management - 14.1 - CA Technologies Documentation
02. Is it everything OK with tomcat ?
Try: http://localhost:8080/CAisd/UploadServlet
See more on troubleshooting section
03. DNS Errors
CA SDM custom changes can be turn to different names, sometimes or somewhere can be access deny or don't answer for named server.
example: Workstation without domain
See more on troubleshooting section
04. Restart Services/Windows
Experience: Could solved this problem just only restart Windows.
Troubleshooting Guidelines - from: Attachments - Best Practice Recommendations from Support |
---|
Trouble-shooting in Attachments typically involves double-checking installation settings.The following guidelines have been developed by CA Support based on many issues received. - Define the problem and be very specific, for example:
- Did Attachments ever work? What changed?
- What users and which browsers are affected?
- If this does not impact all users, what is the location of the users that are not impacted?
- Are all Service Desk Access Types/Roles impacted? eg Customer, Employee, Analyst
- Do all Document repositories fail, or do attachments only fail on specific Document Repositories?
- Is Tomcat running? Better yet, is Tomcat Running on the same host specified in the Document Repository Detail Window/s?
Try to backup the file /log/pdm_tomcat.log before recycling Tomcat, as it is overwritten on a recycle.
- Review the networking basics:
- Ping
- netstat /a
- netstat /b (If on Windows 2003)
- nslookup
- hostname
- Obtain a screen shot of the problematic Document Repository and also of one that does not show problems if possible. Compare the settings.
- Does the "Server Name" field in the Document Repository Detail use a Fully qualified domain name?
It should be set to the same as the value for NX_SERVER or NX_LOCAL_HOST (If a secondary).
- Case sensitivity of these names is an important matter and can be the sole cause of failure. For example, setting up the Repository to use 'myservr' rather than 'MyServ.'
- For trouble-shooting, always gather the following. If they do not reveal the problem on first analysis, they will be of use to the engineers who come after.
Note that the 'Service Desk and CMDB Support Diagnostic Tool' can gather most of this information, with the exception of the pdm_extracts mentioned. See TEC469212.
NX_ROOT/log NX_ROOT/<servername>.his file NX_ROOT/bopcfg/www/CATALINA_BASE/logs NX_ROOT/bopcfg/www/CATALINA_BASE/webapps/CAisd/WEB-INF/web.xml NX_ROOT/bopcfg/www/CATALINA_BASE/conf/server.xml NX_ROOT/pdmconf slstat > slstat.txt pdm_status > pdm_status.txt pdm_extracts of the following two tables:
pdm_extract attmnt_folder >> attmnt.txt pdm_extract Document_Repository >> Document_Repository.txt
- If a recycle is possible and nothing else is revealed elsewhere, enable debug logging in log4j.properties under:
NX_ROOT/bopcfg/www/CATALINA_BASE/webapps/CAisd/WEB-INF/log4j.properties
Change this: log4j.rootCategory=info, jsrvrlog to: log4j.rootCategory=debug, jsrvrlog
and recycle Service Desk. Then attempt to replicate the problem if possible.
Note: Reading debug files correctly can be a time consuming process. Try more direct, obvious approaches first.
- Enabling pdm_trace or bop_logging on the appropriate webengine may be helpful as well.
First identify the webengine, the user is connected to. Next, run slstat to find the slump process name for that webengine. Last, run one of the following:
pdm_trace web:local ON
or
bop_logging web:local ON
Reproduce the problem, then turn off the trace:
pdm_trace web:local OFF
or
bop_logging web:local OFF
The traces will be written to NX_ROOT/log.
You may wish to engage CA Support if the problem has not yielded to regular trouble-shooting at this point.
|
Attachments - Best Practice Recommendations from Support
AHD05949 Search Results
TEC484107