Service using Winsock works on Workstation but not server

[BigMickeyD]

I have developed a "mailing address quality" application that runs as a Service and uses Winsock to communicate. Basically you send it a US address as a delimited string and it returns a USPS validated address as a delimited string.

When the service is installed on my Windows 2000 workstation it works great - multiple clients can connect and send addresses and get responses. I log new connections and address correction requests in the event log.

I install the same executable as a service on a Windows 2003 server and the communications fail. The server accepts the client connection request and the test client believes it is connected. The new connection is logged in the event log.

However, when the address to correct is sent, the service behaves as if it did not receive the address. Nothing is logged in the event log. I'm not seeing any connection errors.

I've checked to see if port filtering is set up on the server and it is not. Could this be a security or policy issue? From a programming standpoint, I don't understand why it would work on a Workstation and not on the Server. Both are running the same framework versions and service packs. Any suggestions?

 

[chiph]

Who's account is it running under on the server?

By default, services run as LocalService, which means no network access.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[BigMickeyD]

Thanks for the reply. That might be the cause.

The service is running under the local system account on both the Workstation and the Server. The Workstation works fine.

I have a catch 22. The service needs to interact with the desktop while it starts up (A "feature" of a 3rd party App) to clear a splash screen. That option is only avalable to the local account.

Would there be more restriction on the Local system account on a server as opposed to a workstation? I wouldn't think there would be a difference.

Mike

 

[chiph]

Local System again, has no access to the network. You could grant it this privilege, but there might be side effects (other apps not running correctly, security holes, etc).

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[BigMickeyD]

Thanks Chip, I'll do some experimenting.

There's lots of services running under the Local System account that talk TCP/IP without any special privleges.
Automatic updates, Background intelligent transfer service,
Computer Browser and many more.

I think the restriction for the local system account is that it can't access resources like files and printers, not that it can't talk TCP/IP on the network.

I've tested SQL Server running under the local system account. People could connect to it and query it without problem. DTS packages failed if they tried to access files on the network. The files had to be on local drives.

This is a strange problem. The application works fine running under the system account on my workstation. It's just that a workstation is limited in the number of inbound connections.

Mike