Troubleshooting Cloud Pak and/or PureApplication 'Service and Support Manager' (Call Home) ( CWZIP3523E, CWZIP3509E, ...)

• Are you using a Proxy? Check that your proxy is a forward proxy and does not terminate the SSL handshake. IBM Cloud Pak System or IBM PureApplication System only supports forwarding proxies for call home and does not support reverse proxy.
• Update your firewall or proxy settings between Cloud Pak System or PureApplication System and IBM to allow connectivity to the new IP addresses.

• Check that the proxy information appears correct in the Service and Support Manager section under System -> System Settings. Then, attempt to use the Test Connection and Send Test Service Ticket features.

• Test your proxy.  Use a personal computer inside the same lab/network where your Cloud Pak System or PureApplication System is located. To correctly test the proxy, configure your personal computer to use the same external connections to IBM which will be used by Cloud Pak System or PureApplication System (same network path, same firewalls/proxies).

• Use CURL
  
  Command: curl https://129.42.56.189 -k --proxy <proxy_IP>:<proxy_port> [--proxy-user <proxy_user>:<proxy_passwod>]
  
  If this command is successful, it returns a short string: "esupport.ibm.com"
  
  curl [https://esupport.ibm.com] -k --proxy x.x.x.x:y [--proxy-user <proxy_user>:<proxy_password>]
  curl https://129.42.56.189 -k --proxy x.x.x.x:y [--proxy-user :]
  curl https://129.42.58.189 -k --proxy x.x.x.x:y [--proxy-user :]
  :

• Use HTTPS/WGET/ or other:
  
  If you cannot install curl in your environment, try other options such as wget, a web browser, or other standard method of accessing the internet from behind your proxy.
  
  If these commands are successful, attempt to download serviceProviderIBMV2.gzip from one of the addresses below:
  
  https://129.42.56.189/eccedge/gateway/services/projects/ecc/serviceProviderIBMV2.gzip
  https://129.42.58.189/eccedge/gateway/services/projects/ecc/serviceProviderIBMV2.gzip
  https://129.42.60.189/eccedge/gateway/services/projects/ecc/serviceProviderIBMV2.gzip
  
  If you are able to save or download the "serviceProviderIBMV2.gzip" file, confirm your personal computer was configured to use the lab network proxy as a middleman for the connection, thus not going directly to IBM. If both conditions are true, then the proxy settings are correct.
  
  Otherwise, check the proxy/firewall connection configuration again
  
  
  
  Try the Send Test Service Ticket feature again.

• Does the Send Test Service Ticket button spin with a blue circle of arrows?
   
  • If this spins for more than 10 minutes, then attempt to use the following REST API, which might return a useful error:
    
    https://admin/resources/callhome_send_test_trap
    For example: ""id": "CWZIP3509E",   "suggested Action": "Ensure that your Call Home configuration settings are correct and that your system is able to communicate with IBM. ...". This message will help determine whether the System Console is timing out. If you are using V2.1.0.0, then the "spinning blue circle" has been reported in APAR IT10293 and resolved in fix pack V2.1.0.1. Take corrective action based on the suggested action and retry the “Send Test Service Ticket” button. CWZIP3534E: If you are running V2.1.0.1 and received CWZIP3534E, Call Home Connection did not complete successfully,[http error = 404 this issue is resolved by APAR IT10294 in V2.1.0.2.
     

• CWZIP3509E:
   
  • CWZIP3509E: If the Error Status Code 500 with java.net.SocketTimeoutException: Socket operation timed out before it could be completed, then for V2.1.0.1 and later:
    
    To resolve this issue, open this URL in a browser to re-enable Call Home functionality:   
  • Run GET https:///admin/resources/repair_call_home?force
    
    If this REST API returns 404, the command did not work, as your Cloud Pak System or PureApplication System is not running V2.1.0.1 and would not have this problem.
    
    If this REST API returns 400, check the error message. If you see "Error occurred trying to update eccConnect.properties on the non-leader PSM. Additional steps may need to be manually run on the non-leader." , the REST API worked. This problem is resolved. Try to create a test ticket again.
     
    • If you see "CWZIP3509E The Call Home request failed while submitting a request to create a new service ticket. A duplicate CallHome problem is already Open”, then there is an existing problem open for a call home test ticket that has not been deleted.
      
      Navigate to the System->Problems page and delete any existing problems generated by the “Send Test Service Ticket” that are titled “Call home test service ticket. Test call home functionality.” Retry the “Send Test Service Ticket” button.
    • CWZIP3509E, with SSL HANDSHAKE FAILURE. Cloud Pak System or PureApplication System was updated to communicate with IBM with a simplified list of destinations with a single host and four IP addresses.
      
      Reference: Cloud Pak System or PureApplication System W* 2.3.0>Administering the system>Configuring the system>Configuring system settings>Configuring Service and Support Manager>Service and Support Manager requirements in the IBM Knowledge Center.
      
      Notes:
    • While the V2.1.0.0 and earlier table does list esupport.ibm.comand the associated IP addresses, it was added later to prepare your system for the upgrade to V2.1.0.1.
    • Recommendation: Open 129.42.0.0/18 (EI IPv4 address range) for best results.

5. Monitoring Service and Support Manager (Call Home) after you make the changes.

After firmware upgrade, the network and configuration requirements might have changed in the new firmware.    Reference our knowledge center for Enabling Service and Support Manager for the products

• Some Call Home connections work through an authenticated proxy, but others fail with 407.
  
  Call Home (ECC) only supports "basic" authentication. Some older versions of ecc might try to use "digest" or "NTLM" for the test connection, which might succeed, but cannot do so on the WebSphere requests, which will then fail.

• The connectivity tests work but the webservice requests fail and you are using a proxy.
  
  A proxy might have a feature for protocol inspection. If the communication stream has some problem, it might not be recognized as HTTP, and so there as a block on the connection. Solution is to discuss proxy settings with your network data center engineers.