07-12-2000 07:27 AM
i've recently installed an Omniback client on an Windows NT4, SP5 and everything was working fine. Yesterday i installed the HP VP Internet Services 2.0 on the same system and if i try to add components or upgrade the omniback client e get a timeout, the same timeout i've mentioned in a previous post.
No change if i stop the service "HP Internet Services", have to disable it and restart the system, after that omniback installation works again.
Ok, i think the problem must be conflicting ports...i could get no information in wich ports are used in Omniback installation or in Internet Services
so does it mean that we can not have VP Internet Services and an Omniback client on the same machine?!
somebody knows the ports used during the OB client installation?
07-12-2000 11:09 AM
It looks like one of the things VP IIS does is scan known ports (or perhaps even all ports.)
Omniback on port 5555 will look a little bit like a telnet server. Try it yourself...
telnet 5555 servername.domain.com
Also, Some applications other than Omniback have been known to use port 5555 - like Netscape Fasttrack.
I am guessing that VP IIS is finding the port in use, and either...
...Repeatedly requesting status from it, say at 1 second intervals...
...attempting to query it to determine which application it is - blocking the port from other use...
This is just a guess - as I have not been able to look at any VP documentation.
07-14-2000 05:42 AM
thanks for the quick reply...
no much information yet available about Internet Services, i'll wait for that to come out.
But, i think port 5555 isn't the only one used in the installation, it is used with comunication between agent and manager, but some other ports must be used during the install, i think...
07-14-2000 12:41 PM
The relate to communications between the NT installation server and the target server.
Your firewall administrator may be able to read logs and determine which ports will need to be opened up.
The ports we use implicitly (by using standard windows function calls) will probably relate to RPC, SMB, and Netbios.
Again, here is what we (more or less) try to do...
1. connect to a disk drive from the depot server, to the target server
net use q: \targetserverc$ password /user:domainomnibackntaccount
if this fails - Omniback install would fail...
2. We copy some files
3. We remotely execute one of the files - this is probably an RPC (Remote Procedure Call)
After that we are not quite so dependent on NT to NT mechanisms...
Look for some documentation from Microsoft...
I found a list (buried in an article) of several likely places to look (i.e. netbios...)
Here is some bad news from that article...
NetBIOS (137, 138, and 139 TCP)
NetBIOS is the protocol used by Microsoft Windows networking to connect LAN clients to file and print servers. NetBIOS will run over IPX, NetBEUI, and TCP.
You should definitely not allow NetBIOS traffic to pass your firewall in either direction. NetBIOS is easily hacked and many exploits exist on hacker Web sites. If you want to link your LANs over the Internet, you should use an encrypted IP tunnel to convey the NetBIOS IP packets through the Internet.
So - Microsoft says DON'T DO IT.
Just for the record - the only function we support through the firewall is the Omniback GUI talking to (controlling) the cell server.
Beyond that you are assuming all of the risks.