Skip to Content
avatar image
Former Member

SAPCCMSR.00 Service will not start

Hi all,

I've recently installed the SAPCCMSR agent into my TREX instance, with the command line:

sapccmsr -R -j2ee pf=D:\usr\sap\DO2\SYS\profile\DO2_TRX00_<hostname>

The service has gone through, registered in my CEN (I can see the RFC destinations in SM59) and set up the Windows service to run:

"D:\usr\sap\DO2\SYS\exe\nuc\NTI386\sapccmsr.exe" -Service pf=D:\usr\sap\DO2\SYS\profile\DO2_TRX00_<hostname> -j2ee

I am running on Win x64 Enterprise, I have updated SAPOSCOL and SAPCCMSR agents (DLL's and all from the cmsagents kernel pack from SMP) and tried the suggestions from Note 883361, with no luck.

The Service user is valid, and not locked, the RFC connections are present in the CEN, so that works well, but when I press start, the service starts, takes the status "Started" and immediately terminates, with no entries in the log.

Has anyone seen this problem before?


Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • avatar image
    Former Member
    Nov 05, 2008 at 04:47 PM

    Hi Troy,

    Yes, I do recall the same problem while configuring the same! It was basically resolved after the RFC's in RZ21-> Agents for Remote systems had started to work.

    Once the RFC's start to work, this error would go away!

    Thank You,


    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Hi Antarpreet,

      Yes, you are correct, that, if the RFC's in RZ21 worked it would work ok.

      How it works is:

      1. You start the SAPCCMSR agent on the remote TREX system.

      2. It logs onto the SAP gateway, with the registered name: SAPCCMSR.<hostname>.00

      3. The RFC destination for TREX points at the registered program on the gateway with the name SAPCCMSR.<hostname>.00.

      However, if you can't get the agent to start at all, the RFC connection won't work, since it has nothing to communicate with...the program isn't registered on the gateway (Which I've verfied with the transaction SMGW...there is no entry there.)