DCOM security in VB application

I am developing a client/server application in Visual Basic 6. The same instance of the server will need to communicate with multiple clients over a LAN using DCOM, although each client will create a separate object.

I have succeeded in accomplishing a DCOM connection in my test environment with one networked client by going into dcomcnfg and specifying the user the server should run as. However, this approach will obviously not work with multiple users running multiple clients.

It was suggested to make the server into an NT service, so I tried that (using the NTSVC.OCX control). However, even on the local machine, clients would not use the instance of the server that the service created.

How I can configure the server so that multiple clients (under multiple users) can access it simultaneously? Thanks.
GuiRichardAsked:
Who is Participating?
 
EDDYKTConnect With a Mentor Commented:
Without service

1. make sure your exe is binary compability
2. from dcomcfg, make it run as a specific user
0
 
EDDYKTCommented:
>>It was suggested to make the server into an NT service, so I tried that (using the NTSVC.OCX control). However, even on the local machine, clients would not use the instance of the server that the service created.

A little bit strange if this doesn't work. Have you run your server with specific user from services setup?

Does your server written in VB?

Have you set binary compatiblity on your server?
0
 
GuiRichardAuthor Commented:
"Have you run your server with specific user from services setup?"

No, I left it as running under the LocalSystem account. This was the purpose of making it a service, as I understood it. If I specify a user under which the service runs, I eliminate the possibility that the server will be able to talk to multiple clients under multiple users--right?

"Does your server written in VB?"

Yes.

"Have you set binary compatiblity on your server?"

No, but I can't see that being the problem, because I purge the registry and recompile before every test.
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
EDDYKTCommented:
>>No, I left it as running under the LocalSystem account. This was the purpose of making it a service, as I understood it.
The purpose of the service is used to run a task automatically when a machine starts-up.

>>If I specify a user under which the service runs, I eliminate the possibility that the server will be able to talk to multiple clients under multiple users--right?

That's not true, it should only starts one copy. The only reason you want to use system account is if you want to interact with desktop

I recommend that you should use a specific user.

From you original question
>>I have succeeded in accomplishing a DCOM connection in my test environment with one networked client by going into dcomcnfg and specifying the user the server should run as. However, this approach will obviously not work with multiple users running multiple clients.

If you run your task as specific account. I don't see y you have multiple copy of your task starts up. All users connect to your task should just start up one task. (may be different instance of your class, not your task, in task manager, you shoulkd only see one task)
0
 
GuiRichardAuthor Commented:
I tried specifying a user in the Services applet; specifically, I entered the user which I am currently logged in as. I started the service and then ran the client locally...two separate instances of my server EXE in the Task Manager.

Let me be clear, if there is a way to make it so that multiple clients (under multiple users) will talk to the same running instance of my server EXE *without* making my server a service, I will do that. I know the purpose of a service is to have an application run without anyone being logged in, but I don't require that functionality. The only reason I explored it is as a solution to my multiple-user problem.
0
 
EDDYKTCommented:
3. make sure your class instancing is mutliuse, not single use
0
 
GuiRichardAuthor Commented:
Setting it as a specific user in dcomcnfg did make it work with multiple clients, even ones that weren't logged in as that user. I would never have thought to try that strategy, as I thought it was naming a user name that matched the client user that might work, not just naming any user name.

Furthermore, setting the log on user in the Services applet enables it to work as a service, if we decide to go that route.

Thanks a lot for your help!
0
All Courses

From novice to tech pro — start learning today.