transfering across lan help

[Adrian Parker]

For deployment reasons, we don't want to have to install our large app on each network client manually; we'd like to have our users
run a very small app on their clients that basically runs the main installer from a hidden share on the network. We want a server
app that we can run somewhere that will be able to send the necessary info to the client apps. Okay, so the problem is that we
don't want to have the users type in the address of the server where the listener is.. How can we query a lan to determine the
address of the machine containing the listener ? I'm going to guess it's some kind of broadcast message, but not having done
anything more complicated than simple listen / connect tcp before, I'm a bit lost.

Thanks for any help or better suggestions.

 

[Ken Tucker [MVP]]

Hi,


Maybe this will help.
http://msdn.microsoft.com/library/d...tml/vbtchno-touchdeploymentinnetframework.asp

Ken

 

[Adrian Parker]

Thanks Ken, but that won't work, the app we want to deploy isn't written in VB, we just want to write the installer mechanism in it.

-Adrian

 

[Sueffel]

For deployment reasons, we don't want to have to install our large app on

each network client manually; we'd like to have our users

run a very small app on their clients that basically runs the main

installer from a hidden share on the network. We want a server

app that we can run somewhere that will be able to send the necessary info

to the client apps. Okay, so the problem is that we

don't want to have the users type in the address of the server where the

listener is.. How can we query a lan to determine the

address of the machine containing the listener ? I'm going to guess it's

some kind of broadcast message, but not having done

anything more complicated than simple listen / connect tcp before, I'm a bit lost.

Thanks for any help or better suggestions.

Drop me an e-mail, I will sit down and write out the process, but briefly
here, I have a service on the server, it watches a directory, and writes to
a "List" file checksums for each file. Then, on the client apps, a 'lil
proggie downloads the listfile, and checks each file in there and thier
sums, if the file don't exist, or has been changed (Sums don't match ), it
copies a new one. It's difficult, but possible, to impliment the
registration of ActiveX crap, if needed.

Sueffel
BTW, (e-mail address removed) is da email

 

[Felix Wang]

Hi Adrian,

Could you elaborate more on the application? Do you mean that it is not a
.Net application and you would like a bootstrap .Net EXE to start it?

I think that the deployment idea will be much easier to implement if we run
it over a HTTP server. It may not be very efficient if the client
application need to broadcast a message everytime when it starts.

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Adrian Parker]

Ok, basically we have a customer who has a network and wants to automate the install / update of the client application software
(via msi package), and to control the database connection parameters from a central source on the network. So what I wanted to do
was have the users run an installer util from a central web page or known network share and have it seek out the server on the
network that has the configuration parameters, but we don't want to have to force the users to type in a server ip address, it
should just be able to find the srever, connect, retrieve the necessary info and disconnect.. Once it has done it once, it can
remember the ip address of the server machine and always try that first next time. When I say next time, i mean when there is a new
deployment, the client must be able to detect it and automatically execute the msi package to uninstall then re-install the client
application.

-Adrian

 

[Sueffel]

Ok, basically we have a customer who has a network and wants to automate

the install / update of the client application software

(via msi package), and to control the database connection parameters from

a central source on the network. So what I wanted to do

was have the users run an installer util from a central web page or known

network share and have it seek out the server on the

network that has the configuration parameters, but we don't want to have

to force the users to type in a server ip address, it

should just be able to find the srever, connect, retrieve the necessary

info and disconnect.. Once it has done it once, it can

remember the ip address of the server machine and always try that first

next time. When I say next time, i mean when there is a new

deployment, the client must be able to detect it and automatically execute

the msi package to uninstall then re-install the client

application.

-Adrian

Not a prob, still working on getting it written up for you. The program
I'm referring to, the way I have it set up is as follows:

In the config file for the updater, I tell it whatt he directory for
update is, ommitting the drive letter. When the updater starts, it tries to
find this directory on any driveletter, niftiness IMO. It then does the
update, which in essence is a filecoopy operation, then you can tell it to
do any custom action from there, like MyApp.msi /u or whatever is needed.

Sound like what you are needing?

Sueffel

 

[Adrian Parker]

Not a prob, still working on getting it written up for you. The program

I'm referring to, the way I have it set up is as follows:

In the config file for the updater, I tell it whatt he directory for
update is, ommitting the drive letter. When the updater starts, it tries to
find this directory on any driveletter, niftiness IMO. It then does the
update, which in essence is a filecoopy operation, then you can tell it to
do any custom action from there, like MyApp.msi /u or whatever is needed.

Sound like what you are needing?

Sueffel

From what I understand, the files will not be on a drive.. they would be on a hidden network share.. i.e.
\\machine\sharename$\filename.msi so you would not have an actual drive available.. all I need is to be able to return the
network share filename to the client for it to execute the installer..

Essentially, what do I need to look at to locate a server.. does the server just listen on a port, then a client issue a broadcast
to find it on the network?

-Adrian

 

[Sueffel]

From what I understand, the files will not be on a drive.. they would be

on a hidden network share.. i.e.

\\machine\sharename$\filename.msi so you would not have an actual drive

available.. all I need is to be able to return the

network share filename to the client for it to execute the installer..

Essentially, what do I need to look at to locate a server.. does the

server just listen on a port, then a client issue a broadcast

to find it on the network?

-Adrian

Okay, I see where you're going. Do a google on enumerating all machines on
a network. I'm not sure how to do it, then, you can check for the existance
of your directory structure, and execute the file if it's there. Not too
complicated, but not too awfule bad.

HTH
Sueffel

 

[Felix Wang]

Hi Adrian,

Thanks for your update.

You mentioned that you would like "the users run an installer util from a
central web page or known network share and have it seek out the server on
the network that has the configuration parameters".

So why don't we store the configuration parameters on the cerntral web site
or the known network share? We can update the contents of it from time to
time.

If we need to search for a server, we need to define a scope for the search
(e.g. IP address span) and the characteristic of the server. Since the
NetBios ports (UDP 137, UDP 183, TCP 139) are opened by default on most of
the machines, I don't think that we can rely on these ports to locate the
server. If we check the file shares using
System.IO.File.Exists(@"\\192.168.1.1\sharename$\filename.msi"), there may
also be a security problem, since we cannot prevent malicious users from
creating their own "\sharename$\filename.msi" and cheating our application.

If I were you, I would rather store all the information on a well-known
central point. It is quick and simple. I hope this makes sense to you.

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Adrian Parker]

Felix,

The thing is we don't have a "known" website or network share.. it could be anywhere on the network (we sell to lots of different
customers, so networks differ). I'm begining to think that the easiest way of doing this is to have the user dynamically build a
distribution exe with the info server address stored in a companion file to the util exe. the util exe can then just connect
directly and retrieve the necessary info.

-Adrian

 

[Jarod_24]

So wat you need is some kind of Scanning-system that will scan all or a
range of IP's
How will you know what range to scan in?
Scanning in just the current computers subnet isn't gonna cut is since
many/most company networks span over multiple subnets.
And starting to scan over networks for multiple computers like that can
cause the Network Firewalls to react (maybe).

Then when you find the Server you need to verify that it IS the server
(username/password or something)

If the customer puts the Installation package on a central network drive or
for example a CD, to let the users install it from, why not put a
ini/xml file in the same directory that holds the adress of the Server.

That way your .msi will be general, and the ini/xml-file can be customized
by the administrator/company.

Another thing could be to fake the DNS adress
Your .msi would allways look for the server named "myserverformyapp.com",
and then each Company configures their DNS server-to return the IP of their
server when asked for that adress.

There is nothing that is more annoying having to _manually_ install a App on
100+ Computers, so including a way of automating the whole install process
is a Must if the app is ment for a network enviroment.

Anyways; i would reccomend that you had a fallback-strategy where the user
can if everything else fails, type inn serveradress username and password.

Ok, basically we have a customer who has a network and wants to automate

the install / update of the client application software

(via msi package), and to control the database connection parameters from

a central source on the network. So what I wanted to do

was have the users run an installer util from a central web page or known

network share and have it seek out the server on the

network that has the configuration parameters, but we don't want to have

to force the users to type in a server ip address, it

should just be able to find the srever, connect, retrieve the necessary

info and disconnect.. Once it has done it once, it can

remember the ip address of the server machine and always try that first

next time. When I say next time, i mean when there is a new

deployment, the client must be able to detect it and automatically execute

the msi package to uninstall then re-install the client

 

[Felix Wang]

Hi Adrian,

Have you read "Jarod_24"'s reply? I agree with him/her. We can deploy the
App.config (an XML file) along with the client side application. In the
App.config, we can set one or two server addresses for probing (one for
primary use and the other one for fallback). The point is that we should
define a range for probing. I don't think it is a good idea enumerate all
the machines on the subnet.

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Adrian Parker]

Did you read the actual msg you replied to ?

"I'm begining to think that the easiest way of doing this is to have the user dynamically build a
distribution exe with the info server address stored in a companion file to the util exe. the util exe can then just connect
directly and retrieve the necessary info."

my brain got there just before Jarod_24 suggested it.

 

[Sueffel]

Did you read the actual msg you replied to ?

"I'm begining to think that the easiest way of doing this is to have the user dynamically build a
distribution exe with the info server address stored in a companion file

to the util exe. the util exe can then just connect

directly and retrieve the necessary info."

my brain got there just before Jarod_24 suggested it.

I think you're making this a little more complex than it is. Here's what
you need to consider, are the drives going to be mapped? If not, then you
have to find a way ( I have yet to find one ) to dynamically seek every
network share and sheck for the existance of the file, or put a listing into
a file such as the App.config. The easiest way is to tell the customer they
will have to map the server share to the local users system, anything they
want, that way you can enumerate through the drive letters, and search for
the file. You would also, in the config file, set it so that the customer
can define thier directory tree that the file is sitting in, minus the drive
letter. For instance, I have a COTS (Commercial Off The Shelf ) software
directory on one of my servers, \\MyServer\COTS, and I have that mapped to
T:\ drive, my starter app searches for the directory tree of
\Tiberiansun\Installer\Setup.msi on all drives. This way, if they stick a
CDROM in the drive, it will use that, first come first serve scenerio.
You are just simply specifing a location of a file to execute, then execute
it. There's only soo much dynamics that can be programmed in, and I don't
think it's unreasonable at all to request those 2 things from a customer so
they can use your software without any problems.

HTH
Sueffel

 

[Felix Wang]

Hi Adrian,

I had read the message before I replied it. I just wanted to say that
Jarod_24's reply was worth reading.

If you need any assistance on authoring the App.config, please feel free to
post here.

Have a nice day!

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.