Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 11 replies
  • Subscribers 1 subscriber
  • Views 21055 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Client not getting certificate via RMS "Caught CORBA system exception"

asester

Hey all,

I've got multiple clients that are getting this error in the router log.....and I used the same install package that some of my other clients are using and ARE reporting to the SEC via the message relay.  I am able to telnet to the message relay from the client using 8192 (which returns the IOR with a sequence of numbers) and 8194 (returns a blank screen with a cursor).  I am aware that the Auto Update and RMS services run separate, but I thought I should mention that all of the clients update just fine from the message relay.

I have been reading multiple cases but haven't really seen any concrete resolutions to this issue...and since my problem is sporatic I'm making a new thread.  The 'netstat -n' command I ran on the message relay shows the 8192 ports with the client IP's that I'm having issues with in TIME_WAIT status.

Here is an insert from the router log on the client I'm having issues with.

16.07.2013 15:29:13 050C I Successfully validated parent router's IOR
16.07.2013 15:29:13 050C I Accessing parent
16.07.2013 15:29:18 09A4 I Logged on Agent for certification
16.07.2013 15:29:18 0A30 I Routing to parent: id=03E5AD1E, origin=Router$rv20009056:27138.Agent, dest=CM, type=Certification.CertRequest
16.07.2013 15:30:58 050C E ParentLogon::RegisterParent: Caught CORBA system exception, ID 'IDL:omg.org/CORBA/TRANSIENT:1.0'
OMG minor code (2), described as '*unknown description*', completed = NO
 
16.07.2013 15:31:28 050C I Getting parent router IOR from 165.201.22.33:8192
16.07.2013 15:31:28 050C I Received parent router's IOR: (number way too long to paste...and shouldn't matter since it matches)

16.07.2013 15:31:28 050C I Successfully validated parent router's IOR
16.07.2013 15:31:28 050C I Accessing parent
16.07.2013 15:31:50 050C E ParentLogon::RegisterParent: Caught CORBA system exception, ID 'IDL:omg.org/CORBA/TRANSIENT:1.0'
OMG minor code (2), described as '*unknown description*', completed = NO

etc etc....The log repeats those steps and never obtains the certification request.

Any suggestions?

Thanks,

Adam

:41705


This thread was automatically locked due to age.
  • 0

    HI,

    Something is going wrong when accessing the parent on 8194.  A couple of things I would be interested in seeing would be:

    1. If the certificate can be obtained reliably from 8194 from the client.  

    I would try conecting up to 10 times to see the responsiveness of the data coming back with an SSL client such as:

    http://slproweb.com/products/Win32OpenSSL.html

    Win32 OpenSSL v1.0.1e Light and Visual C++ 2008 Redistributables should be all you need.

    The in a command prompt switch to:

    C:\OpenSSL-Win32\bin\

    and run:

    openssl.exe s_client -connect parentaddress:8194

    Does it error or show the certificate?

    2. Trace logging on the client router might help to see what error message is returned after accessing parent.

    Under:

    HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Sophos\Messaging System\Router

    create a DWORD value called LogLevel and set it to 2.

    Under:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sophos Message Router

    Edit the image path from:

    "C:\Program Files (x86)\Sophos\Enterprise Console\Remote Management System\RouterNT.exe" -service -name Router -ORBListenEndpoints iiop://:8193/ssl_port=8194

    to read:

    "C:\Program Files (x86)\Sophos\Enterprise Console\Remote Management System\RouterNT.exe" -service -name Router -ORBListenEndpoints iiop://:8193/ssl_port=8194 -ORBDebug -ORBDebugLevel 10 -ORBVerboseLogging 2

    More details here:

    http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/TAO/docs/Options.html

    Restart the router, wait a few seconds to give it a chance to start, what does it say in the logs after "Accessing parent".  Next 25 lines for example?

    3. A Wireshark capture of the router starting and communicating with the parent router.

    4. Consider the MTU along the path, it may be that the client is not receiving back from the path a request to fragment the data.

    Regards,

    Jak

    :41707
  • 0

    Thanks for the speedy reply Jak.  I ran the SSL command and it did return the certificate without any issues.  I also added the registry entries for changing the client router log file and here are the results:

    17.07.2013 10:05:00 0E68 T C:\Program Files\Sophos\Remote Management System\RouterNT.exe|MessageRouter::validateIOR called
    17.07.2013 10:05:00 0E68 T C:\Program Files\Sophos\Remote Management System\RouterNT.exe|Endpoint found: rvhalo3.kdor.ks.gov:8193
    17.07.2013 10:05:00 0E68 T C:\Program Files\Sophos\Remote Management System\RouterNT.exe|>>> StatusReporting::StatusReporter::Done
    17.07.2013 10:05:00 0E68 T C:\Program Files\Sophos\Remote Management System\RouterNT.exe|DNS            : problem 0, changed 0, already reported 0
    17.07.2013 10:05:00 0E68 T C:\Program Files\Sophos\Remote Management System\RouterNT.exe|Certification  : problem 0, changed 0, already reported 0
    17.07.2013 10:05:00 0E68 T C:\Program Files\Sophos\Remote Management System\RouterNT.exe|Incoming       : problem 0, changed 0, already reported 0
    17.07.2013 10:05:00 0E68 T C:\Program Files\Sophos\Remote Management System\RouterNT.exe|Outgoing       : problem 0, changed 0, already reported 0
    17.07.2013 10:05:00 0E68 T C:\Program Files\Sophos\Remote Management System\RouterNT.exe|<<< StatusReporting::StatusReporter::Done
    17.07.2013 10:05:00 0E68 I C:\Program Files\Sophos\Remote Management System\RouterNT.exe|Successfully validated parent router's IOR
    17.07.2013 10:05:00 0E68 I C:\Program Files\Sophos\Remote Management System\RouterNT.exe|Accessing parent
    17.07.2013 10:05:00 0E68 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|3688) - Connector::connect, looking for SSLIOP connection.
    17.07.2013 10:05:00 0E68 E C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|3688) Initializing SSLIOP_Endpoint
    17.07.2013 10:05:00 0E68 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO_LF_Event::state_changed to 2. No follower.
    17.07.2013 10:05:00 0E68 E C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|3688) - Transport_Cache_Manager::find_i, unable to locate a free connection
    17.07.2013 10:05:00 0E68 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|3688) - SSLIOP_Connector::ssliop_connect, making a new connection
    17.07.2013 10:05:00 0E68 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|3688) - Transport_Cache_Manager::fill_set_i, current_size = 1, cache_maximum = 10
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - Connection_Handler[548]::handle_input, handle = 548/548
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - Transport[548]::handle_input
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - Transport[548]::process_queue_head
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - Transport[548]::handle_input, read 104 bytes
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - GIOP_Message_State::parse_message_header_i
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - GIOP_Message_State::get_version_info
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - GIOP_Message_State::get_byte_order_info
    17.07.2013 10:05:00 07A4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|1956) - ORB_Core::run, handle_events() returns 0
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - GIOP_Message_Base::dump_msg, recv GIOP v1.2 msg, 92 data bytes, my endian, Type Request[249]
    17.07.2013 10:05:00 07A4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|1956) - ORB_Core::run, calling handle_events()
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|GIOP message - HEXDUMP 104 bytes
    47 49 4f 50 01 02 01 00  5c 00 00 00 f9 00 00 00   GIOP....\...ù...
    03 00 00 00 00 00 08 28  23 00 00 00 14 01 0f 00   .......(#.......
    4e 53 54 a0 b1 e6 51 99  0d 04 00 02 00 00 00 01   NST ±æQ.........
    00 00 00 00 00 00 00 01  00 00 00 01 00 00 00 72   ...............r
    0c 00 00 00 47 65 74 45  6e 76 65 6c 6f 70 65 00   ....GetEnvelope.
    01 00 00 00 01 00 00 00  0c 00 00 00 01 8b 54 02   .............‹T.
    01 00 01 00 09 01 01 00                            .... ...       
    17.07.2013 10:05:00 0BB4 T C:\Program Files\Sophos\Remote Management System\RouterNT.exe|CertEnvelopeSupplier::GetEnvelope() called
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - GIOP_Message_Base::dump_msg, send GIOP v1.2 msg, 51 data bytes, my endian, Type Reply[249]
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|GIOP message - HEXDUMP 63 bytes
    47 49 4f 50 01 02 01 01  33 00 00 00 f9 00 00 00   GIOP....3...ù...
    01 00 00 00 00 00 00 00  23 00 00 00 49 44 4c 3a   ........#...IDL:
    53 6f 70 68 6f 73 4d 65  73 73 61 67 69 6e 67 2f   SophosMessaging/
    4e 6f 45 6e 76 65 6c 6f  70 65 3a 31 2e 30 00      NoEnvelope:1.0.
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - Transport[548]::cleanup_queue, byte_count = 63
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO_LF_Event::state_changed to 3. No follower.
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - Transport[548]::cleanup_queue, after transfer, bc = 0, all_sent = 1, ml = 0
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - Transport[548]::drain_queue_helper, byte_count = 63, head_is_empty = 1
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - Transport[548]::drain_queue_i, helper retval = 1
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - Connection_Handler[548]::handle_input, handle = 548/548, retval = 0
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - ORB_Core::run, handle_events() returns 1
    17.07.2013 10:05:00 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - ORB_Core::run, calling handle_events()
    17.07.2013 10:05:01 08E0 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2272) - Connection_Handler[548]::handle_input, handle = 548/548
    17.07.2013 10:05:01 08E0 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2272) - Transport[548]::handle_input
    17.07.2013 10:05:01 08E0 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2272) - Transport[548]::process_queue_head
    17.07.2013 10:05:01 08E0 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2272) - Transport[548]::handle_input, read 104 bytes
    17.07.2013 10:05:01 08E0 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2272) - GIOP_Message_State::parse_message_header_i
    17.07.2013 10:05:01 08E0 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2272) - GIOP_Message_State::get_version_info
    17.07.2013 10:05:01 08E0 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2272) - GIOP_Message_State::get_byte_order_info
    17.07.2013 10:05:01 0BB4 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2996) - ORB_Core::run, handle_events() returns 0
    17.07.2013 10:05:01 08E0 D C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|2272) - GIOP_Message_Base::dump_msg, recv GIOP v1.2 msg, 92 data bytes, my endian, Type Request[250]

    And then it begins to repeat itself. 

    Below is the wireshark log.  I applied a filter that only captured the message relay IP for the destination.

    "No.","Time","Source","Destination","Protocol","Length","Info"
    "30","21.822977000","165.201.184.232","165.201.22.33","TCP","54","vpjp > blp1 [ACK] Seq=1 Ack=1778 Win=65535 Len=0"
    "31","21.852834000","165.201.184.232","165.201.22.33","TCP","1514","vpjp > blp1 [ACK] Seq=1 Ack=1778 Win=65535 Len=1460"
    "32","21.852849000","165.201.184.232","165.201.22.33","TCP","882","vpjp > blp1 [PSH, ACK] Seq=1461 Ack=1778 Win=65535 Len=828"
    "34","24.493959000","165.201.184.232","165.201.22.33","TCP","1514","[TCP Retransmission] vpjp > blp1 [ACK] Seq=1 Ack=1778 Win=65535 Len=1460"
    "35","29.923646000","165.201.184.232","165.201.22.33","TCP","1514","[TCP Retransmission] vpjp > blp1 [ACK] Seq=1 Ack=1778 Win=65535 Len=1460"
    "40","31.811169000","165.201.184.232","165.201.22.33","TCP","1514","[TCP Retransmission] vpjp > blp1 [ACK] Seq=1 Ack=1778 Win=65535 Len=1460"
    "42","32.123402000","165.201.184.232","165.201.22.33","TCP","54","vpjp > blp1 [ACK] Seq=1461 Ack=1779 Win=65535 Len=0"
    "43","32.123521000","165.201.184.232","165.201.22.33","TCP","882","[TCP Retransmission] vpjp > blp1 [FIN, PSH, ACK] Seq=1461 Ack=1779 Win=65535 Len=828"
    "44","32.124359000","165.201.184.232","165.201.22.33","TCP","62","equationbuilder > blp1 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1"
    "47","32.148996000","165.201.184.232","165.201.22.33","TCP","54","equationbuilder > blp1 [ACK] Seq=1 Ack=1 Win=65535 Len=0"
    "48","32.149147000","165.201.184.232","165.201.22.33","TCP","114","equationbuilder > blp1 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=60"
    "52","42.600399000","165.201.184.232","165.201.22.33","TCP","590","[TCP Retransmission] vpjp > blp1 [ACK] Seq=1 Ack=1779 Win=65535 Len=536"
    "57","56.807234000","165.201.184.232","165.201.22.33","TCP","54","equationbuilder > blp1 [ACK] Seq=61 Ack=1778 Win=65535 Len=0"
    "58","56.836163000","165.201.184.232","165.201.22.33","TCP","1514","equationbuilder > blp1 [ACK] Seq=61 Ack=1778 Win=65535 Len=1460"
    "59","56.836177000","165.201.184.232","165.201.22.33","TCP","882","equationbuilder > blp1 [PSH, ACK] Seq=1521 Ack=1778 Win=65535 Len=828"
    "67","59.392390000","165.201.184.232","165.201.22.33","TCP","1514","[TCP Retransmission] equationbuilder > blp1 [ACK] Seq=61 Ack=1778 Win=65535 Len=1460"
    "69","64.622850000","165.201.184.232","165.201.22.33","TCP","1514","[TCP Retransmission] equationbuilder > blp1 [ACK] Seq=61 Ack=1778 Win=65535 Len=1460"
    "71","66.796413000","165.201.184.232","165.201.22.33","TCP","1514","[TCP Retransmission] equationbuilder > blp1 [ACK] Seq=61 Ack=1778 Win=65535 Len=1460"
    "73","67.092851000","165.201.184.232","165.201.22.33","TCP","54","equationbuilder > blp1 [ACK] Seq=1521 Ack=1779 Win=65535 Len=0"
    "74","67.092958000","165.201.184.232","165.201.22.33","TCP","882","[TCP Retransmission] equationbuilder > blp1 [FIN, PSH, ACK] Seq=1521 Ack=1779 Win=65535 Len=828"
    "79","77.196087000","165.201.184.232","165.201.22.33","TCP","590","[TCP Retransmission] equationbuilder > blp1 [ACK] Seq=61 Ack=1779 Win=65535 Len=536"
    "85","97.093179000","165.201.184.232","165.201.22.33","TCP","62","lotusnote > spytechphone [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1"
    "87","97.114093000","165.201.184.232","165.201.22.33","TCP","54","lotusnote > spytechphone [ACK] Seq=1 Ack=1 Win=65535 Len=0"
    "90","97.137420000","165.201.184.232","165.201.22.33","TCP","54","lotusnote > spytechphone [ACK] Seq=1 Ack=462 Win=65075 Len=0"
    "91","97.137502000","165.201.184.232","165.201.22.33","TCP","54","lotusnote > spytechphone [FIN, ACK] Seq=1 Ack=462 Win=65075 Len=0"
    "92","97.139862000","165.201.184.232","165.201.22.33","TCP","62","relief > blp1 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1"
    "95","97.163107000","165.201.184.232","165.201.22.33","TCP","54","relief > blp1 [ACK] Seq=1 Ack=1 Win=65535 Len=0"
    "96","97.163366000","165.201.184.232","165.201.22.33","TCP","114","relief > blp1 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=60"

    Thanks again for looking into this.

    Adam

    :41725
  • 0

    HI,

    Could you make the entire router log available from startup, for say 5 minutes after a restart of the router?

    Regards,

    Jak

    :41749
  • 0

    Hi,

    Thank you for the.  I think this is the important line(s):

    Line 1109: 17.07.2013 10:05:15 0E68 E C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|3688) - SSL connection to <rvhalo3.kdor.ks.gov:8194:8194> failed (errno: No error)
    Line 2000: 17.07.2013 10:05:41 0E68 E C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|3688) - SSL connection to <rvhalo3.kdor.ks.gov:8194:8194> failed (errno: No error)
    Line 4115: 17.07.2013 10:06:43 0E68 E C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|3688) - SSL connection to <rvhalo3.kdor.ks.gov:8194:8194> failed (errno: No error)
    Line 4801: 17.07.2013 10:07:03 0E68 E C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|3688) - SSL connection to <rvhalo3.kdor.ks.gov:8194:8194> failed (errno: No error)
    Line 6412: 17.07.2013 10:07:49 0E68 E C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|3688) - SSL connection to <rvhalo3.kdor.ks.gov:8194:8194> failed (errno: No error)
    Line 7098: 17.07.2013 10:08:09 0E68 E C:\Program Files\Sophos\Remote Management System\RouterNT.exe|TAO (3284|3688) - SSL connection to <rvhalo3.kdor.ks.gov:8194:8194> failed (errno: No error)

    On the client computer that is failing, could you try creating under

    [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\[Adapter ID]]


    Where: the adapter id is for the adapater bening used to connect to the management server.

    a new DWORD called MTU (DWORD Value) and set it to 576 (dec).

    Restart the computer. How does the router log look then?

    Regards,

    Jak

    :41797
  • 0

    Jak - you are the man.  This resolved the issue.  I would have never guessed what MTU value to change the NIC's to....any insight on where you came up with that?  I scoured multiple Sophos how-to's and troubleshooting guides and never came across this.

    Adam

    :41825
  • 0

    Hi,

    There are potentially a few ways to fix it and 576 isn't the only value that would work.  It's probably not optimum for you I just wasn't sure what the "path" was like between the client and server so went for the lowest just to ensure that was the problem.

    To work out a more sensible MTU for your path (client to relay) I would suggest pinging the server from the client, setting the Don't Fragment (DF) bit and changing the packet length as you go  If you get a reply you're good, if you get packet needs to be fragmented you need to reduce the packet size to squeeze it through the path available.

    So I would start with:

    ping rvhalo3.kdor.ks.gov -f -l 1472

    if you get a packet needs to be fragmented messages then decrease it to say 1460 and try again.

    ping rvhalo3.kdor.ks.gov -f -l 1460

    If you get a reply, then increase it to 1465 for example.  You're essentially trying to figure out the max value that doesn't require the packets to be fragmented, it may take 6 of 7 tries with different values

    Say you find 1460 responds ok 1461 tells you the packet needs to be fragmented then 1460 is the maximum packet size along the path.  In which case I'd probably just set the MTU to 1400.  

    If the value is too low, e.g. 567, you're going to be sending data in smaller chunks than really needed which is quite an overhead and slower and almost 3 times as many packets as you would typically need on a LAN.

    This article is worth a look:

    http://support.microsoft.com/kb/900926

    as is something like:

    http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

    There are a few ways to fix this, maybe a firewall just needs to allow ICMP traffic for example but hardcoding the MTU is certianly one but may not be the best option for you.  If you don't have control over the full path, i.e. if the traffic is going over the internet setting at source may be your best bet.

    Regards,

    Jak

    :41833
  • 0

    Hey Jak,

    Thanks for the info.  I have a new issue now....heh.  None of my PC's that connect to the RMS are reporting now - they all stopped communicating at the same time: 9:51 AM on 7/23.  I didn't make any changes to the RMS, but I noticed that morning the Sophos Update Manager software applied an update at roughly 8 AM.  That's really the only change that I can see that would have caused this issue.  I've tried all the same troubleshooting steps from before and nothing seems to be working.  Do you think re-installing the SUM software could resolve this issue?

    :42099
  • 0

    Another interesting note:  In the SEC it shows that the version for the SUM's for both the servers are the same (version 1.4.2.186).  However, when I look at the Programs and Features list on the RMS server, it shows a different version - 1.3.1.168.  I tried to push it again from the SEC by implementing "Update Now", but it didn't seem to change.  I'm still thinking a re-install from the SUM location on the SEC will be the best fix, but I'll wait to hear if anyone has had the same issue.

    Adam

    :42101
  • 0

    Heh, well I resolved my own issue.  All in all - I had to uninstall the SUM on the RMS and re-install it to get the version to match.  Once I did that the end points still were not communicating to the SEC.  I then went through and changed the ServiceArgs and ImagePath registry entries which was the solution. 

    It appears that if you run the ClientMRInit.exe file on the RMS server it changes the ServiceArgs registry entry back to the default value and dropped the -ORBDottedDecimalAddresses 0 and the &hostname_in_ior=xyz.com additions...and I ran that test on my RMS on the 16th when I was initially having communication issues.  Apparently the update for the SUM software didn't like the default values and decided to stop talking to the SEC.  Anywho - hope this helps anyone else in the future.

    :42111