Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

SMSMSE: Report Data is not Shown - No connection could be made because the target machine actively refused it 127.0.0.1:58081 - Symantec Mail Security Utility Service IS running

Created: 04 Jul 2012 • Updated: 30 Aug 2012 | 9 comments
Rolf Niedhorn's picture
This issue has been solved. See solution.

Hello,

I upgraded all of my clients to the latest build of SMSMSE (Build 6.5.7.279) on their SBS 2003 R2 SP2 (fully patched) Servers in May.

After the following MS Patchday in May with all the .NET-Patches I have the o.g. problem with all clients.

Although it sounds like the issue mentioned in TECH168218, it´s slightly different, cause the Symantec Mail Security Utility Service IS running.

After restarting that service, everything turns to normal till the next reboot of the machine.

At first I didn´t think it was a problem and I blamed the ngen-process after the patchdays in May and June.

Yesterday I had to reboot one client´s server without any update and run into the same issue.

The question now is: Is there a known issue with one of the latest .NET fixes or a known issue with the SMSMSE Build? Is there a depency between the Symantec Mail Security Utility Service and another service, staring in a wrong order?

Kind regards from Germany & happy Independence Day to the U.S.,

 

Rolf

 

 

 

Comments 9 CommentsJump to latest comment

benjamin_lurie's picture

See the following from the article:

1. Open a command prompt on the Exchange server with SMSMSE installed.
2. Run the following command from the command prompt:

netstat -a -n -b

3. Look for the following information:

TCP    127.0.0.1:58081        0.0.0.0:0              LISTENING
 [CmafReportSrv.exe]

 

Is the process running and listening on the port?

 

 

 

Rolf Niedhorn's picture

Thank you, Benjamin, for the reply,

I tested that, as mentioned by you and alos mentioned in the TECH-Article, I mentioned above.

Also, I used Process Explorer and TCPView für Windows to look for the CmafReportSrv.exe Process.

That Process isn´t running or listining till I restart the SMS Utility Service manually.

My only idea is to use Process Monitor for monitoring the System´s boot process next time to determine, why SMS Utily will start, but not CmafReportSrv.exe.

By the way, no other process is listining on Port 58081.

Rolf Niedhorn (Hamburg, Germany)

NIERO@net e.K.

benjamin_lurie's picture

We can work with you to collect the appropriate diagnostic data.  I don't know of any situations where the Utility service or the cmafreportsrv.exe will not start after computer reboot.

Ben

 

Rolf Niedhorn's picture

Thanks, I will open a support case and let you know here, what we find out!

I leave that thread open till I have the solution from your support.

Regards,

 

Rolf

 

Rolf Niedhorn (Hamburg, Germany)

NIERO@net e.K.

groberts's picture

Given that this happens after reboot, I suspect the utility service is starting before the TCP stack is available to actually bind to, meaning the utility service will not listen until it is restarted manually. You can delay startup of the utility service by setting a service dependency on the MSExchangeIS service.

 

This document (specifically the section titled "Startup Timing conflict") has details on how to set up a service dependency. You'll need to add the dependency for the Utility service, rather than the main service: http://www.symantec.com/docs/TECH82298

SOLUTION
Rolf Niedhorn's picture

Thanks, groberts, for that answer,

I just made your suggested changes to the registry for the Utility Service. I leaved the dependency of the Utility Service on the Remote Procedure Call Service as is.

After the next restart of those machines (perhaps next MS Patchday), I will give you a Follow Up on this.

Regards,

 

Rolf

 

 

Rolf Niedhorn (Hamburg, Germany)

NIERO@net e.K.

Rolf Niedhorn's picture

 Hello, groberts,

I´ve tested your suggestion with a few of my clients during MS August patchday and the problem is gone!

If I will get the same result with the rest of my clients this week, I can mark your reply as solution and one of two Symantec cases can be closed with minimal effort smiley.

Keep your fingers crossed!

Regards,

 

Rolf

 

Rolf Niedhorn (Hamburg, Germany)

NIERO@net e.K.

Rolf Niedhorn's picture

Issues solved, case closed!

Thank you very much for your input, groberts,

 

Rolf

 

 

Rolf Niedhorn (Hamburg, Germany)

NIERO@net e.K.