Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: Win32 MFC VC++
Hey Guys,
I am developing a Dialog based Win32 application (I know that's ancient - Client's requirement).
 
In my program, I need to send a file to different remote machines connected via LAN (without client). The application is supposed to run on domain server - so credentials should not be an issue.
 
I am already performing some WMI tasks on remote machines. So I wondered whether it is possible to send file through WMI. How reliable would it be? Could you direct me to some sample too...
 
Full points to anybody who helps...
Thanks in advance...
 
--
Varun
Posted 16-Jan-13 18:16pm
Comments
Sergey Alexandrovich Kryukov at 16-Jan-13 23:23pm
   
I don't think WMI is related to sending files at all. How? All your remote operations are not done via files...
 
The whole idea looks just weird. You can use FTP, HTTP, some custom service you can develop.
—SA
Varun Pandey at 16-Jan-13 23:34pm
   
I am trying to develop an enterprise software that will manage many (lets say 100+) machines at a time. Running 100+ client receivers isn't a great idea.
WMI is used for enterprise management. Agreed that all remote operations are not done by WMI, but I am already using it for some operation. So was thinking of reusability of code.
Sergey Alexandrovich Kryukov at 16-Jan-13 23:39pm
   
No, what reusability. Whatever you do, you need some software on both sides. And 100+ is not a serious number at all... It all depends on what can you install on every host.
—SA
Varun Pandey at 16-Jan-13 23:48pm
   
I have work arounds... SHFileOperation can be used on server to copy file on remote machine - It works. Another way to do this by WMI is by creating a process in remote machine that runs copy command. But that will require Server login credentials. The First method will obviously need impersonation. Re-usability is this, I am already using WMI for some operation. For that I have impersonated the remote machine. So if I use SHFileOperation, I will have to impersonate the machine again. This is what I don't want. I am 101% sure...
Sergey Alexandrovich Kryukov at 16-Jan-13 23:56pm
   
Agree. Don't you think you are trying things more complex than they have to be? If you need send files, solve just this problem...
—SA
Varun Pandey at 17-Jan-13 0:05am
   
It isn't complex... I am just looking for a better solution... I don't trust SHFileOperation, it's parameter passing(double null terminated string) and result codes are weird. That's why I am here asking you guru(s). :-|
Sergey Alexandrovich Kryukov at 17-Jan-13 0:37am
   
:-)

1 solution

Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

Instead of "sending" the file, make it available on the LAN to the clients. The file may or may not appear 'local' to those clients, but will always be available to them. This can be done with various technologies: shared file system (Windows share, samba, nfs, ...), http, ftp/ftps, ...
 
Doing it this way, the file will be created and managed locally on the server (with full local credentials, and readonly/readwrite at your choice) and you can control access to the clients, who should see it 'readonly' from their point of view.
 
tl;dr: In other words, change "push" from the server to "pull" from the clients.
  Permalink  
v2
Comments
Espen Harlinn at 17-Jan-13 14:47pm
   
Good idea :-D
Varun Pandey at 17-Jan-13 22:35pm
   
Thanks for the response. The purpose of this utility is to do the remote installation. Agreed, I can create a remote process (also through WMI) and pass the shared path to the remote machine. Then the remote machine will be responsible for installation. What about the network over-head. Will it be more than sending a file and installing?
H.Brydon at 17-Jan-13 23:36pm
   
If you are on a LAN, there is no conceivable file size that will cause problems with network overhead. I would estimate the LAN activity to be within the same order of magnitude whether you use the pull vs push strategies.
 
... having said that, installing software is a different problem from transferring files (which was your original question). Perhaps clarify your problem description a little...
Varun Pandey at 17-Jan-13 23:55pm
   
Initially my plan was to send the file over LAN, and "MSEXEC" it. So the installation part wasn't that important. Now, as you suggested, I am attempting to "MSEXEC" the same installer from the shared folder by creating a process on Remote machine. In such a case, is the file copied to the remote and then executed or is it extracted first. In the later, as I recollect, SMB may add latency issues, will it?
H.Brydon at 18-Jan-13 0:35am
   
The details you are adding are changing the type and complexity of the original problem you stated.
 
It now seems that you want to install software (multiple installs?) remotely on multiple machines (but on a LAN) from a dialog based app (by button click) on a master server while sitting at your desk.
 
This is a much different problem from pushing a file to a bunch of client machines on a LAN.
 
Installing software is a much different problem from pushing a file somewhere. Maybe start over with a better problem description.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 OriginalGriff 335
1 Peter Leow 135
2 Zoltán Zörgő 130
3 Afzaal Ahmad Zeeshan 115
4 DamithSL 100
0 Sergey Alexandrovich Kryukov 7,442
1 OriginalGriff 5,996
2 Peter Leow 4,292
3 CHill60 2,858
4 Mika Wendelius 2,850


Advertise | Privacy | Mobile
Web01 | 2.8.150224.1 | Last Updated 17 Jan 2013
Copyright © CodeProject, 1999-2015
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100