Want to pass on domain admin privileage to a VB program from another VB program

I have a VB application deployed on a Windows 2000 Domain Server. This application is launched each a client logs on to the domain. Client machines are either 2000 or NT. I do not have any problem with 2000 clients.

I have a VB program, deployed on server, lets say A.EXE, which will call another VB program B.EXE. B.EXE has to perform administrative functions on the client machine. A.EXE is launched when a normal user logs
in. So I need a way to pass on administrative privileage to B.EXE. I can not use LogonUser() function since I can not grant 'Act as part of the
operating system' privileage to the user.

can anyone help???
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

why doesnt a.exe take all the load and just allow a.exe to have the privalages that you want b.exe to have?
never mind, trouble understanding it at first.

i take it A.exe resides on the server and B.exe resides on the client correct?

what exactly do you need B.exe to do for the client?
sprasad15Author Commented:

Thanks for the response. My requirement is as follows

1) The application is relating to enforcing IT security within our Win network

2) Application is going to be deployed on Windows 2000 Domain Server

3) Each domain user's profile contains a batch file to execute this application on login

4) A.exe is the first vb program which is called by the batch file. If A.exe can assume admin privileage, it is fine with me

5)On launching A.exe, A.exe will check for the installation of all application files in the client machine. If not found, it copies all files to client machine (including B.exe. But A.exe executed from server only and not copied to client machine)

6) A.exe calls B.EXE (b.exe is now in the client)

7) B.exe will check for the installation of latest service packs, security updates etc. in the client machine, and installs them if not found. This process needs admin privileage in the client machine.

8) Since the login user is a normal user and has no admin privileage on both local machine as well as server, A.exe will not have admin privileage.  So I need a way to passon admin privileage to b.exe
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

from what i can find right now before i hit the sack is this


that changes security attributes to a specified path to allow writing, if this isnt the and you dont have windows privelages then thats a whole nother really long story.  Ill look more in the morning if someone else hasnt allready answered your question
sprasad15Author Commented:

Since B.EXE will be calling certain installables for security updates, service packs etc., this process will require admin privileage on the client machine, I think not just file permissions


I think SSPI is an option for me, but I am yet to come across any VB code samples using SSPI to impersonate a user

A.exe would need local admin privileges in order to install anything on the local machines. I don't think you can do that when a.exe exists only on the server.

Here are a couple of alternatives that would seem to give you the outcome your looking for.

1 - Get in a commercial package that does pretty much exactly what you're asking for here. (SMS for example). You will need to install an agent app locally on each machine and give it admin priveleges, though the docuementation pretty much talks you through how to do it. The downside is that it's costly.

2 - Write your own agent applcation (like your b.exe) which runs as a service on each workstation and checks a file (central or copied locally) of required updates. You can use "srvany.exe" from MSDN to make your app into a service. The file could be CSV with a format like Code, Description, Path as below

IE6SP2, Internet Explorer 6 update, \\server\share\ie6update.exe

When the update is installed, the application creates a file (in the above case called IE6SP2.tag) which is stored in a local (shared) directory on each PC. Before installing the update, the program checks whether it has the tag (and so already has the update) before installing again.

By making the folder shared, it allows you as an admin, to go in and delete tags, to force re-installs of updates should you ever need to.

The service is started as part of the login script using net start.

I have used this approach myself, and sucessfully managed 7000 machines on around 20 sites this way.


Thanks for the comments.

I think the solution you suggested will call for manual installation of the service on each NT client. I have 1000+ NT client machines. Is there anyway, this (installing the service on client machines) can be done by the domain when a normal (non-admin) user logs in??

There is no way round this. The agent is providing you with a back door to get round the problem that non admin users can't install their own software. Before you have this installed, there is no way for a non admin user to do it.
This of course is the standard MS security working exactly as it's supposed to.

It will be a significant effort getting round 1000 machines, but of course it would be the last time you needed to do it as once the agent is there any other updates (including updates to the agent itself) could be done automatically.

An alternative to a big rollout is to only install the service on fresh builds, or when support staff visit the machines for another reason. Old machines that are giving you no trouble just get treated on the "if it ain't broke, don't fix it" principle, as sooner or later they'll get replaced anyway.

If you needed to do global rollouts then presumably you have to go round machines manually at the moment anyway if you don't have this kind of system in place.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
You can use dcomcnfg to set B.exe to run as admin user on client machine

One thing is B.exe must be activex exe

Can you elaborate more on this solution?

A.exe starts on server and B.exe initiated by A.exe from server using createobject

If B.exe is activex exe then you can use dcomcnfg.exe to run b.exe on client with admin user
Maybe I'm missing something here, but haven't you still got to set up the dcom permissons for b.exe on each workstation individually?

Is that better than making b.exe into a serivice and giving it system privileges?


I am trying to work around this issue using an ActiveX EXE as sugegsted by EDDYKT.

In my A.EXE i have added this code

Dim LaunchObj
Set LaunchObj = CreateObject("LaunchX.LaunchCls") 'I use LaunchObj for B.EXE
Call LaunchObj.callingLogin

'This code is from ActiveX EXE - Project LaunchX, Class LaunchCls. I have replaced B with this
Public Sub callingLogin()
    MsgBox ("Calling Login")
End Sub

I get an error meaage running this in the Win 2000 server
Run-time error '429'
ActiveX component can't create object

I can get this code work on my local (development) machine

Also I wanted to know, if B.EXE has admin rights, rest of the programs called by B.EXE will also carry admin rights???



I have tried out the ActiveX EXE option, but it is not feasible because of two reasons

1) ActiveX EXE needs to be registered on each client machine, which reqiures admin privileage, because registry needs to be updated
2) Even if ActiveX EXE is registered once using an admin account, when the application has to do a job it is meant to do, like installing a service pack, it stops there saying that user does not have admin privileage

Pls comment

>>Also I wanted to know, if B.EXE has admin rights, rest of the programs called by B.EXE will also carry admin rights???

Yes it will only on Windows 2000 or higher not on NT.

sprasad15 and siva_manikoth are both same person?
Do you know you cannot have two account for the same person?
>>Even if ActiveX EXE is registered once using an admin account,

You use admin account to register doesn't do anything on using

dcomcnfg.exe to set B.exe to run as admin account.
Am i missing something here?
Moderator, my recommended disposition is:

    Accept EDDYKT's comment(s) as an answer.

Dan Rollins -- EE database cleanup volunteer
EDDYKTs solution is really just a rehash of the answer I had previously given.  His (Her?) answer certainly doesn't come up with a solution for the issue that the questioner had with my answer (ie that my solution would call for manual installation of the service on each NT client).

I also think that my answer is rather more clearly expressed.

Points to me please.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.