Link to home
Start Free TrialLog in
Avatar of David Megnin
David MegninFlag for United States of America

asked on

How to install a client application on remote computers?

How can I install a .msi or .exe client application onto multiple remote computers in a domain environment where I have domain admin privileges?

The client application is currently in a network shared folder, \\server\folder\app.msi
The computers to install to are named like, \\WFO-14433 or \\

Tools I have available for scripts:
I have installed AutoIt3, PowerShell 2.0, VisualStudio 2008 (I use VB) and PowerGUI.

All computers are running Windows XP SP3
Server is Windows Server 2003

Examples really appreciated.  I'm not a "script writer" in any scripting language.  Thanks!
Avatar of Rommel Sultan
Rommel Sultan
Flag of Canada image

How big was your network.
How many workstations?
Avatar of Joseph Daly
Joseph Daly
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of David Megnin


Here on my subnet, lets call this one, there are about 50.
We have three other offices to deal with later.  I want to start with the easy one.

The other three would be like,,, and there are about 50 or so computers at each of them as well.

The client app needs to be installed on all of the computers on the local subnet right now.  I'll later want to target a special version of the client application to, like executives, as opposed to the rest of the staff, but lets start simple.  ;-)  Thank you.
Why not use GP?  Two reasons.  We don't have our AD organized by computer into the groups I need to target and I'm not the Network Analyst and I'm having a hard time squeezing into his schedule.  ;-)
Here is a step by step for the software installation.
I'm not going to use GP.
Since you cant use group policy to do this I would reccomend using PSexec to install the files remotely. You will need to have admin rights on the machine you want to install the software on. 
I was trying to use PSexec this morning and was specifying -u <my domain/login> -p <my domainAdmin password> and it kept saying login failed, so I gave up and started looking for another solution

Here is the exact syntax I was using.  Is there maybe a mistake somewhere?
psexec \\ -u domain\username -p mYSecUr3@Password  -i -d "\\storserve\common\DesktopAlerts\AlertsSetup4.msi"
It says PsExec could not start \\correct\path\tothe.msi on
Logon failure:  unknown user name or bad password

..even though they are my username and password with domain admin rights.
Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
One more article....

see this too...... Installrite step by step
"Use this tool", "Use that technology", "Look at this web page", "Try a Google search", "Read some books", "Sit next to a guru and see what he does".  

None of those suggestions are very helpful.  I tried this tool and that tool.  I don't seem to have some little detail quite right, that is just not covered in the ten thousand foot overview.

I'm not installing yet another "utility".  If it can't be done in one of the tools I listed that I have available, then I'll just install it manually.
Well, I understand your frustration, and I wouldn't blame you if you ignored my suggestion, but…  

I do have one more utility that you might wanna try.  RemotePatch is a home-grown utility that we use to remotely install patches on PCs.  You can select the list of PCs by name, OU, or IP address range.  It was developed out of the same scenario as you described... the network admin folks worked for another organization and were not responsive to our needs.

My stuff is only available as VB.Net source code, so that means you’ll have to download and compile the RemotePatch application before using it.  The source can be found here:

...again, sorry for suggesting yet another utility
graye, no, this looks promising.  I'll give it a try.  Thank you.  Are any instructions required?  Do I need to plug in our domain or is a username and admin password required?
No, there's no instructions (but it's kinda simple to use).   You just fill in the blanks, select the method to generate the list of PCs and "let her rip."  There is some fancy stuff about logging options, etc that you can safely ignore.

I typically run the application with a domain admin account (or from any account that is in the admin group on the remote PCs).
Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Sorry, busy Holidays...

Volox, you are correct, all of our machines are Windows XP and do not have PowerShell installed.  These are all machines for staff with minimal privileges. I think the Department Heads have "Power Usesr" accounts, but the rest of the staff are regular users.
We may have to set up the GP to so we can do this in the future.

Graye, sorry, still working on it.  Things should be back to normal this week.
So it sounds like you are doing the install because the users don't have enough permissions to perform the install themselves, correct?

Can you get enough of the AD admins time to have him add a startup script to the machine startup for group policy?  If so, write a script that copies a vbs script file down from a known network share location (that is secure of course) and then runs the script file.  Then you can put whatever you want in the script file to download & launch an installer.  Of course you just need to make sure you can get the installer to run in a silent mode that doesn't require a logged in user interface...

I'd provide sample code but I'm not where I can test it right now and I'm not a fan of posting broken scripts.  If you know vbs scripting I'm sure it won't take you long to figure out the pieces: connect to network share, copy a file, launch script.

Maybe this is a bit kluge, but I'm trying to think up ways you can get this done simply...  I wish I could think up a way to avoid having to change the GP at all, but frankly that is the absolute most efficient way to get something that requires privleges out to a whole group of computers.  I'll keep thinking on this one and maybe I'll come up with something else as well...
Thank you for the suggestions, Volox.  Yes, any way to get it done is fine.

It looks like we are just going to have to set up OUs for each of our three offices plus one for the corporate office where I am.  We have a single logon script for everyone right now, but I need to install four different "versions" of the .msi setup file, a different one for each office.

Our biggest problem with that is probably going to be the fact that we are moving computers around all the time.  We have about 50 staff computers at each office and then 60 to 70 customer computers at each of the three other offices, in like, "computer labs".  The .msi packages will not go to the labs, but only to staff computers.  I think it will be a nightmare to maintain the OUs.  ;-)  That's why I wanted to be able to use a script or PowerShell to install the client app. .msi package onto a list of computers listed in a text file, which would be easy to generate.
Well so if you use the domain policy to push powershell to every computer and enable remote powershell execution, then you could write a poiwershell script that run from a 'distribution' copmuter that remotely executes the msi based on the IP address or computer name.  Or would it be an issue to have PowerShell get pushed out globally?

I don't know how your network is laid out, but your other option is to push the same install script out globally but have the install script check against a list of IP addresses to determine whether to skip installing or to run the install.  If your network is like most, then you can check to say if the computer running this script has an IP in subnet 10.X then run installler A if they are in 10.Y run installer B and so on.

I would say that trying to keep computers orgainized into OUs based on physical location is definitely going to be a pain you don't want to live with.  Can you explain what the difference between the 'versions' that go to the different locations is?  For example, is it something that could be addressed by using some creative DNS entries (or maybe even hosts files on the machines)?
 If your network is like most, then you can check to say if the computer running this script has an IP in subnet 10.X then run installler A if they are in 10.Y run installer B and so on.
That would definitly work and would be how I would prefer to determine which .msi to install on each machine.

I just talked to our network guy.  He's got the OUs created for each office.  I mentioned keeping the computers orgainized into OUs to him, but he doesn't seem to mind.  That was probably the bigest hurdle, so as soon as he gets all the computers put into the various OUs I guess pushing the .msi packages will be the easy part.  It looks like we'll use GP after all.  ;-)  

I was kind of hopeing to get a good PowerShell script that could be used in the future for other similar things.

Is it okay if I just divide up the points between everyone who suggested using GP to push the packages?
Dividing the points doesn't bother me any.  I hope your implementation goes well.
Thank you for all the suggestions.  Going with GPO after all.