Telnet printing
Robert Bachellor
into the SCO OS5 server. He is using ICE.TCP Pro which comes with an LPD
program for Windows. My problem is how to define a printer on the server so
that his reports go to his LPD interface so he can print them.
Any help is greatly appreciated.
Thanks,
Rob
Brian K. White
I would use passthru-printing before I got entangled in defining a
bunch of lpd printers to non-static ip's. You don't have to configure
printers into the spooler for that, and you don't care the slightest
little bit about what the users IP is, if it was different 10 minutes
ago, or how they are connecting to the box (serial dialup, telnet,
ssh, facetwin, local lan, internet etc...), or how they are connecting
to the internet (direct dialup, behind a firewall, port-forwarding,
nat, etc...)
But, passthru has it's own few issues. You can't just define a virtual
printer that sends the data back to your tty because applications
typically run a print job in the background and proceed to write to
the screen as normal immediately. With passthru, you send an escape
code to the terminal and some print data and another escape code.
between the two escape codes there should be only print data, but if
the application wasn't specifically programmed to provide passthru
print functionality, it won't know that it shouldn't write to the
screen while the print data is coming through. So, some applications
have a specific feature to print with passthru, or to print using a
program of your choosing, and knows enough to wait while that program
runs.
If you can't do that, then you need to do two things:
1) anyone who has a dynamic IP and want's to print to themselves via
standard lpd protocol, needs to get a dyndns.org account. That gives
you a hostname, which stays the same, which tracks the dynamic IP, as
long as the user runs a good dyndns.org updater client. If you have a
lot of cable accounts with basic internet sharing routers, some of
them have dyndns.org updaters built right in so you don't need to run
anything on any computer to update dyndns.org, but if the IP's don't
actually change very often, then the router will not update dyndns
except after a power-cycle or when the IP actually changes, which may
be several months on end with no changes or power-cycles, and in that
case, dydndns.org times-out your account after 35 days without
activity. So $10 gets you an account that won't time out.
2) the remote users either need to be directly connected to the
internet (IE: dialu-up like aol, at&t, earthlink, etc... or their PC
is directly connected to their dsl/cable modem) or, you need to
configure port-forwarding rules in the remote users router to forward
tcp port 515 from the internet in to the PC that the printer is
attached to, and that pc needs to stay turned on even when that user
is not around if you want other people in the same remote office (or
indeed other people anywhere who connect to the system) to be able to
print to that printer.
Then you go and set up the lpd server on the remote pc's (windows 2000
and xp have lpd server built-in you know, you have to install it from
"add/remove programs, windowscomponents) but it's there and you don't
even need the windows cd usually.
Then you set up the printers in unix as remote lpd printers and use
the hostname that you gave yourself in dydns.org and the printers
"share as" name in windows (if you used the built-in lpd server)
then after all that, you will very likely have to stop & restart the
unix spooler a lot to re-enable printers that get "stuck" when the
transient remote ip goes away from being powered-off or the ip changes
and dydns takes a little while to propogate the change...
It's never going to work _well_, but that's the best you can do.
hmmm....
with some fancy scripting, you *could* make it pretty reliable and not
need dyndns.org...
install rlpr:
rftp -g -bh pcunix.com /pub/bkw rlpr.tar.bz2
bzcat rlpr.tar.bz2 |tar xvf -
(if you don't have bzip2 it's available several places
including:
rftp -g -bh pcunix.com /pub/bkw bzip2.tar.Z
zcat bzip2.tar.Z |tar xvf -
)
then, look at tony lawrences web site articles about netcat, but in
the sample printer interface script replace "|nc -h $PRTHOST -p
$PRTPORT"
with "|/usr/local/bin/rlpr -H $PRTHOST -P $PRTPORT"
and comment out the part that reads /etc/printers
create a single unix printer using /dev/null as the destination device
and this interface script as the model, and name it "myprinter"
then, in /etc/profile or in individual .profiles you:
* get users ip and put it in PRTHOST and export it
PRTHOST=`who -umx | awk '{ print $6 }'` ; export PRTHOST
* define PRTPORT as the share name of the printer in windows
(in the case of the windows built-in lpd server, otherwise
it's the lpd queue name configured in the lpd server.)
PRTPORT=HP1200 ; export PRTPORT
getting the ip using the method above can be done right in
/etc/profile one time for everyone.
setting the printer share name will have to be done seperately in
users .profiles, or, some telnet clients allow you to specify
environment variables right in the client config so when you log in
they are already set and you dont do anything in either profile except
export the already set variable, or you can tell all remote users to
use the same lpd queue name in the lpd server and you could set that
name in /etc/profile.
put something in /etc/profile or maybe in the printer interface to
detect if PRTHOST or PRTPORT is undefined and use some sane default or
in the case of the printer interface you could detect that and simply
exit immediately without trying to print instead of letting errors be
generated and eventually fill your hd with mail that no one reads.
Basically, you need to do something to deal with what happens if a
user who does not have his own remote printer tries to print to
"myprinter"
then whenever any user prints to "lp -d myprinter" it goes to "their"
printer.
this will also work for everyone else in a remote office besides the
actual person with the orinter if they are sharing a single net
connection and the pc with the printer is turned on. they will all get
the same value in PRTHOST so they can print to "myprinter" as long as
that PC is turned on in their office.
This also avoids the problem of normal lpd printers self-disabling,
since the printer is created as a "local" printer to device /dev/null.
This also keeps lpstat from hanging for long times trying to get the
status of remote printers via lpd.
Scott Burns
>"Robert Bachellor" <r...@alphaomegas.com> wrote in message news:<LNWdnfBPhso...@thebiz.net>...
>
>
>>We have a remote client using DSL with dynamic IP addressing to telnet back
>>into the SCO OS5 server. He is using ICE.TCP Pro which comes with an LPD
>>program for Windows. My problem is how to define a printer on the server so
>>that his reports go to his LPD interface so he can print them.
>>
>>Any help is greatly appreciated.
>>
>>Thanks,
>>Rob
>>
>>
>
>I would use passthru-printing before I got entangled in defining a
>bunch of lpd printers to non-static ip's. You don't have to configure
>
>
<SNIP>
>since the printer is created as a "local" printer to device /dev/null.
>This also keeps lpstat from hanging for long times trying to get the
>status of remote printers via lpd.
>
>
Bloody hell! I hope you cut and pasted that!
To bring it back ontopic, would SSH and Putty work better? SSH has the
port forwarding option. You could set it up so that anyone who
connected to port xyz on the SCO box was actually connecting over the
tunnel to the lpd server on the windows box. This also has the
advantage or getting rid of telnet and securing the original connection.
It would require some scripting to handle disconnections (auto disable
the printer on logout?).
Would a VPN work better here? It may or may not require another box
(does SCO do PPTP? ).
--
Scott Burns
Mirrabooka Systems
Tel +61 7 3857 7899
Fax +61 7 3857 1368
Jeff Liebermann
<r...@alphaomegas.com> wrote:
>We have a remote client using DSL with dynamic IP addressing to telnet back
>into the SCO OS5 server. He is using ICE.TCP Pro which comes with an LPD
>program for Windows. My problem is how to define a printer on the server so
>that his reports go to his LPD interface so he can print them.
Back in the bad old days of Unix (before VPN's), I had a similar
problem. IP addresses were assigned on the fly by a DHCP server. I
only had a maximum of 10 such dynamic IP's in the pool so I created 10
printers. I was sorta forced to use LPR/LPD because it was the most
common protocol available in a scrambled mess of operating systems and
print server boxes. There were some dialin users, so static DHCP by
MAC address was not an option. The customer did not want to deal with
a DNS server. Everyone logged into the order system with the same
login (not my idea), so I couldn't assign printers by login name.
I named the printers by appending the last part of the IP address to a
generic name. For example:
192.168.0.100 = printer100
192.168.0.101 = printer101
(...)
192.168.0.110 = printer110
On login, I extracted the DHCP assigned IP address using something
like:
IP=`who -mx | awk '{print $6}'`
I then peeled off the last 3 digits with:
NUMB=`who -mx | awk '{print $6}' | cut -c 10-`
Finally, I assigned the default printer environment variable LPDEST to
the proper printer number with something like:
LPDEST="printer"$NUMB ; export $LPDEST
About 2 years later, I discovered VPN's, disarmed this abomination,
removed the print server daemons from the client machines, simplified
my life, and lived happily ever after.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831.336.2558 voice http://www.LearnByDestroying.com
# je...@comix.santa-cruz.ca.us
# 831.421.6491 digital_pager je...@cruzio.com AE6KS
Dan Skinner
I've tried but not had luck printing through ICE.TCP.
I currently use K95 from Columbia and C-Kermit on the SCO end.
Works like a champ.
Regards...Dan.
Bob Meyers
back
> into the SCO OS5 server. He is using ICE.TCP Pro which comes with an LPD
> program for Windows. My problem is how to define a printer on the server
so
> that his reports go to his LPD interface so he can print them.
>
Actually, despite what you may hear here, I have a few of these exact setups
and they have worked very well - for years. The only time I have had to
service them is when the ISP changes all their internal IP addresses without
telling anyone. All you need to do is setup an SCO printer with device =
/dev/null, then paste in the interface script ICE.TCP gives you.
Does your email address shown work? I'll get in touch with you if you need.
Otherwise RTFM :)
Bob Meyers
"Bob Meyers" <oregon...@yahoo.com> wrote in message
news:bva0kn$putr3$1...@ID-105888.news.uni-berlin.de...
I will clarify a bit... the ICE.TCP setup provides a custom SCO printer
interface script that stores remote printjobs in a folder like
"/usr/tmp/printer_name/blah". Then the ICE.TCP runs a little background
program, called ICElp, on the remote PC. This little program will require a
static IP or hostname for the remote SCO box to get print jobs from. Then it
polls the SCO server for print jobs and prints them as needed. Since the PC
polls the server for jobs, the PC can be dynamic IP. You will have to open a
port on the SCO firewall for whatever port you use for the polling ICElp
program, the default is something like 1234, but you can change it.
The printer data is not encrypted out of the box, maybe your client don't
care. If they did want it encrypted, maybe they have one of these neat
little routers that have built-in PPTP/VPN, or VPN-to-VPN routers, or what
have you.
Bill Vermillion
Brian K. White <br...@aljex.com> wrote:
>"Robert Bachellor" <r...@alphaomegas.com> wrote in message news:<LNWdnfBPhso...@thebiz.net>...
>> We have a remote client using DSL with dynamic IP addressing to telnet back
>> into the SCO OS5 server. He is using ICE.TCP Pro which comes with an LPD
>> program for Windows. My problem is how to define a printer on the server so
>> that his reports go to his LPD interface so he can print them.
>>
>> Any help is greatly appreciated.
>I would use passthru-printing before I got entangled in defining a
>bunch of lpd printers to non-static ip's. You don't have to configure
>printers into the spooler for that, and you don't care the slightest
>little bit about what the users IP is, if it was different 10 minutes
>ago, or how they are connecting to the box (serial dialup, telnet,
>ssh, facetwin, local lan, internet etc...), or how they are connecting
>to the internet (direct dialup, behind a firewall, port-forwarding,
>nat, etc...)
>But, passthru has it's own few issues. You can't just define a virtual
>printer that sends the data back to your tty because applications
>typically run a print job in the background and proceed to write to
>the screen as normal immediately. With passthru, you send an escape
>code to the terminal and some print data and another escape code.
I'd suggest looking at anzio-lite and anzio as they handle
pass-thru printing wonderfully well. www.anzio.com
Pretty darned cheap, though it has been upped to $40 from the $25
price it had for years. And his tools perform other 'magic'
things for printing too.
My SCO clients prefered it to other and often more expensive
spreads.
Bill
--
Bill Vermillion - bv @ wjv . com
FyRE
<r...@alphaomegas.com> wrote:
Here's an idea off the top of my head: Don't let your staff TELNET
across the internet into your company server. Even though SCO OS's
don't come with any serious security measures by default, you can
still steal openSSH to build on the server if you pay SCO for the
build tools (you may be able to download it from Brian K White's warez
site full of opensource software that he's cobbled together).
--
FyRE < "War: The way Americans learn geography" >
John Boland
You dont need to steal openssh. Just download it from:
http://www.sco.com/support/update/download/openssh_osr5.html
John
Simon Hobson
(in message <LNWdnfBPhso...@thebiz.net>):
Of all the replies, I'd suggest that these days VPN is so easy to implement
that I would consider that first - then you have full control over the IPs
used and apart from the VPN tunneling itself you don't need to mess about
modifying server or client - effectively you can treat the client as being
directly connected to your network. As well as encrypting everything from
prying eyes.
Simon
Jeff Liebermann
<simon...@thehobsons.codotuk> wrote:
>Of all the replies, I'd suggest that these days VPN is so easy to implement
>that I would consider that first - then you have full control over the IPs
>used and apart from the VPN tunneling itself you don't need to mess about
>modifying server or client - effectively you can treat the client as being
>directly connected to your network. As well as encrypting everything from
>prying eyes.
>Simon
Agreed. However, there are a few things one should know before
blundering onward. Since a VPN router is essentially transparent to
all forms of traffic, I was getting clobbered by excessive broadcast
traffic propagated through the routers. However, if I turn off
broadcast propagation, the infamous Windoze browsing doesn't work.
Same with using a single central DHCP server which is a very bad idea
over a VPN. I had to hack some custom filter rules to make it all
work as my clueless customers absolutely insisted that they needed
Windoze browsing. My suggestion is to live without Windoze browsing
and just use:
\\NETBIOS_machine_name
from the "Run" box to access remote machines.
Incidentally, the most common mistake I've seen is using the same
Class-C IP block in more than one location. It's a natural to setup
the routers using the default LAN side IP block (usually
192.168.0.xxx) on every VPN router. Bad idea. That actually will
work with some routers (i.e. Sonicwall), but causes all kinds of
routing and address management problems. It's also really easy to end
up with duplicate IP's. Each office should have it's own Class-C IP
block as in:
192.168.0.xxx main office
192.168.1.xxx remote office 1
192.168.2.xxx remote office 2
and so on.
Also, most of the small routers will only handle 256 IP's. If you
have a large office, with either more than one Class-C, or a Class-B
netmask, the cheap VPN routers won't work.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com AE6KS
je...@comix.santa-cruz.ca.us je...@cruzio.com
Simon Hobson
(in message <qutn10t68bvj9kaan...@4ax.com>):
>> Of all the replies, I'd suggest that these days VPN is so easy to
>> implement
>> that I would consider that first - then you have full control over the IPs
>> used and apart from the VPN tunneling itself you don't need to mess about
>> modifying server or client - effectively you can treat the client as being
>> directly connected to your network. As well as encrypting everything from
>> prying eyes.
>> Simon
>
> Agreed. However, there are a few things one should know before
> blundering onward. Since a VPN router is essentially transparent to
> all forms of traffic, I was getting clobbered by excessive broadcast
> traffic propagated through the routers. However, if I turn off
> broadcast propagation, the infamous Windoze browsing doesn't work.
> Same with using a single central DHCP server which is a very bad idea
> over a VPN. I had to hack some custom filter rules to make it all
> work as my clueless customers absolutely insisted that they needed
> Windoze browsing. My suggestion is to live without Windoze browsing
> and just use:
> \\NETBIOS_machine_name
> from the "Run" box to access remote machines.
Getting browsing to work across subnets is allegedly possible without
broadcasts. It requires something like a master browser on each subnet which
is configured to exchange it's browse list with the other master browsers -
that way they build up a complete browse list across all subnets. Well, I
guess netbios seemed like a good idea at the time !
> Incidentally, the most common mistake I've seen is using the same
> Class-C IP block in more than one location. It's a natural to setup
> the routers using the default LAN side IP block (usually
> 192.168.0.xxx) on every VPN router. Bad idea. That actually will
> work with some routers (i.e. Sonicwall), but causes all kinds of
> routing and address management problems. It's also really easy to end
> up with duplicate IP's. Each office should have it's own Class-C IP
> block as in:
> 192.168.0.xxx main office
> 192.168.1.xxx remote office 1
> 192.168.2.xxx remote office 2
> and so on.
>
> Also, most of the small routers will only handle 256 IP's. If you
> have a large office, with either more than one Class-C, or a Class-B
> netmask, the cheap VPN routers won't work.
All good sound advice. I've come up against the duplicate address problem
twice at work, both for the same reason.
At the risk of going off-topic ...
Like most large places (we are a small part of a sizable US group), we use
private addressing internally with NAT* out to the internet - in our case we
use a LOT of the 172.16/12 range between us. At least twice to my knowledge
(one was my own company, another was another in the US) we've needed a
private connection with a third party - and guess what, they use the same
private address ranges.
The answer of course is to only ever use public addresses when talking to
third parties, but try telling some people that Private Addressing + NAT =
broken IP network.
Simon
* NAT = Network Address Translation. The router translates between your
private addresses (eg 192.168.xxx.xxx) and you public IP address(es) so that
you can have multiple machines conencting to the internet, but only a limited
number of public IP addresses. Roll on IPv6 I say.
Jeff Liebermann
<simon...@thehobsons.codotuk> wrote:
>Getting browsing to work across subnets is allegedly possible without
>broadcasts. It requires something like a master browser on each subnet which
>is configured to exchange it's browse list with the other master browsers -
>that way they build up a complete browse list across all subnets. Well, I
>guess netbios seemed like a good idea at the time !
That actually can be made to work. I ran into one of those at a local
multioffice medical group. There were 5 remote offices using
Sonicwall Soho-2 VPN routers. The local MCSE, who apparently had a
clue, made it all work without propogating broadcasts. The problem
was that it would take anywhere between zero to 12 minutes for the
complete list to appear. That's the time interval that the master
browser decides to hold an election and refresh its shopping list of
machines, shares, and printers. The local list would refresh rather
quickly, but the remotes would have a delay. Worse, if a new machine
appeared on the network at a remote site, the local master browser
would be smart enough to know that the list was out of date, but not
smart enough to bludgeon the remote master browsers into refreshing
its shopping list. In other words, it worked, but not quite in a
respectable manner. When I enabled broadcast pass-thru and disarmed
the fixed master browsers, everything worked normally, but the traffic
was exessive.
>All good sound advice. I've come up against the duplicate address problem
>twice at work, both for the same reason.
I was pleasantly suprised to see that the current crop of cheap Belkin
routers deliver a random number (actually a hash value from the MAC
address) for the 3rd number of the IP address. I guess they've
decided it's a problem worth fixing.
>Like most large places (we are a small part of a sizable US group), we use
>private addressing internally with NAT* out to the internet - in our case we
>use a LOT of the 172.16/12 range between us. At least twice to my knowledge
>(one was my own company, another was another in the US) we've needed a
>private connection with a third party - and guess what, they use the same
>private address ranges.
>
>The answer of course is to only ever use public addresses when talking to
>third parties, but try telling some people that Private Addressing + NAT =
>broken IP network.
Yep. Now, visualize my nightmare. I deal with about 15ea VPN
routers. In order to do remote admin, my management workstation needs
to have the IPSec client software (SafeNet from Sonicwall)
pre-configured for all my clients. However, the stupid software will
not allow duplicate Class-C networks in the configuration pile, even
if they are disabled. So, I have to number the LAN side of each VPN
router with a unique Class-C IP block. That works fine when I setup
the original system, but is a true pain if I inherit the customer with
an existing numbering plan. Renumbering even small networks is no
fun.
>Roll on IPv6 I say.
Need I supply a list of legacy technologies and defacto standards that
have become sufficiently ingrained in our technology as to become
unkillable? IPv6 doesn't offer sufficient benifits over IPv4 to
offset the cost of deployment, the cost of conversion, and the cost of
maintaining dual protocols for many years.
FyRE
<je...@comix.santa-cruz.ca.us> wrote:
>On Sun, 1 Feb 2004 10:37:03 +0000, Simon Hobson
><simon...@thehobsons.codotuk> wrote:
>
>>Getting browsing to work across subnets is allegedly possible without
>>broadcasts. It requires something like a master browser on each subnet which
>>is configured to exchange it's browse list with the other master browsers -
>>that way they build up a complete browse list across all subnets. Well, I
>>guess netbios seemed like a good idea at the time !
>
>That actually can be made to work. I ran into one of those at a local
>multioffice medical group. There were 5 remote offices using
>Sonicwall Soho-2 VPN routers. The local MCSE, who apparently had a
>clue, made it all work without propogating broadcasts.
This can also be achieved using a single line setting with Samba. (I
actually set this up at work to allow cross-subnet browsing). Using
this, along with Linux based DHCP, and Dynamic DNS, it's made
administering the multiple domains/subnets a doddle. Also been moving
a lot of data from the NT fileservers, as well as network print
servers over to Samba 3 (all domain authentication), with *very*
obvious performance improvements... In fact, "staggering" is not too
far off...
Jeff Liebermann
wrote:
Good to know. When I tried it again about 2 years ago, I couldn't
make it work with Samba. Google shows a note in the 1.9.17alpha
version that explains a few things.
====
The 1.9.17alpha series are known unofficially as the 'browse-fix'
releases as they contains much new and revised code to make browsing
across subnets work for the first time.
If you are setting up 1.9.17alpha series Samba servers to
test cross subnet browsing issues it is very important to
ensure that all Samba servers set up as local master browsers
or domain master browsers be 1.9.17alpha3 or 1.9.17alpha4 servers.
Previous (1.9.16p11 and before) version of nmbd will *NOT* function
correctly in this role and will prevent cross subnet browsing
from working. This also applies to the Samba machine set up
as the WINS server, if you are not using a Microsoft WINS
server.
====
I believe that I was using an earlier version at the time. Not sure.
I assume current versions work as expected. Thanks for the pointer.
That will be handy.
Incidentally, I service 7 law ofices with Samba servers. I usually
install two servers, one acting as a backup server. Most are running
RH 7.x. The current crop are SUSE 7.3 and 8.x. Some have VPN's to
various homes. I couldn't get anyone to even look at a Samba server
until I was able to demonstrate the benifits of the EXT3 journaling
filesystem. No Linux desktop users, yet. Also, I can't seem to
interest my medical office customers in Linux and Samba as they are
committed to vertical market packages where the vendor specifies the
operating system (usually SCO OpenServer).
Joe Dunning
<je...@comix.santa-cruz.ca.us> wrote:
>On Sat, 31 Jan 2004 11:44:35 +0000, Simon Hobson
><simon...@thehobsons.codotuk> wrote:
>
>
>Agreed. However, there are a few things one should know before
>blundering onward. Since a VPN router is essentially transparent to
>all forms of traffic, I was getting clobbered by excessive broadcast
>traffic propagated through the routers.
This seems a little strange. Routers, don't in general pass broadcast
traffic. The VPN tunnels I have set up don't pass broadcasts.
> However, if I turn off
>broadcast propagation, the infamous Windoze browsing doesn't work.
>Same with using a single central DHCP server which is a very bad idea
>over a VPN. I had to hack some custom filter rules to make it all
>work as my clueless customers absolutely insisted that they needed
>Windoze browsing.
This is exactly what WINS is for: to allow browsing between different
networks.
Jeff Liebermann
wrote:
>>Agreed. However, there are a few things one should know before
>>blundering onward. Since a VPN router is essentially transparent to
>>all forms of traffic, I was getting clobbered by excessive broadcast
>>traffic propagated through the routers.
>This seems a little strange. Routers, don't in general pass broadcast
>traffic. The VPN tunnels I have set up don't pass broadcasts.
Correct. I wasn't very clear. If I setup the VPN to *NOT* pass
broadcast traffic (the usual default), Windoze browsing is erratic (or
fails) and centralized DHCP does't work. If I enable propagating
broadcasts, then they work, but with excessive broadcast traffic.
>This is exactly what WINS is for: to allow browsing between different
>networks.
Yep. I guess I have to justify why I didn't use WINS (Windoze
Internet Name Service). In order of importance:
1. WINS requires a server of some sorts. It also makes little sense
with a single WINS server as it was designed as a distributed (and
dynamic) NETBIOS name service which requires a replicating WINS server
at each remote office. This did not exist. The only real file server
was SCO OpenServer, which doesn't have a WINS server. I could have
installed Samba, but this was before their WINS server was working.
2. I had a perfectly functional alternative in populating a HOSTS and
LMHOSTS file, on each client, with the latest namde->IP mapping. Only
the servers and print servers needed to be added. I didn't care about
browsing the dynamic IP clients and remote access clients. The only
downside was that stupid Windoze would check LMOSTS file *LAST* and
only after failing with WINS, DNS, and name resolution via broadcasts.
If someone had WINS enabled, then name lookups would take an extra 30
seconds. I also had a handy batch file to map drives. Something
like:
net use f: \\machine01\c_drive
net use g: \\machine02\c_drive
net use h: \\machine02\share_name
If that failed because the LMHOSTS files was out of date (as was
common on lightly used laptops), I would use:
net use f: \\192.168.0.20\c_drive
net use g: \\192.168.0.21\c_drive
net use h: \\192.168.0.21\share_name
which was guaranteed to work. As long as I didn't need to browse,
share, or map a dynamically assigned IP, the batch files would work
like a charm.
3. It wasn't my decision. The application service company declared
WINS to be a loser and would not support it.
4. The local Windoze experts all suggested that if I really wanted to
play name server, I should instead setup a DNS server. I don't recall
the exact reason they failed to appreciate WINS, but I do recall that
the feeling was universal among the experts. Since they didn't need
dynamic DNS (DDNS), and there was no need to browse any machines with
dynamic IP's, methinks the static solution made the most sense.
5. They had WINS running on an old NT4SP6 server and later a W2KSP1
server, both of which had a history of having the WINS server process
fail to start ("RPC server is unavailable"), or of corrupting its
database. When someone decided to use "Norton Ghost" to setup
cookie-cutter workstations, they forgot to change the system name.
When about 6 machines appeared with the same NETBIOS name, WINS would
promptly spend all its time adding errors to the self-compacting
(self-corrupting) database logfile. It also tended to deadlock the
files requiring a reboot to recover before restoring. Auto purging
stale objects was another problem, as even manually flushing the WINS
cache, from the WINS console, would not vaporize these old entries.
Moving servers around was hell because of the stale objects.
Restoring the previously backed up database or starting over with a
blank database was a regular event. When someone decided to setup a
BDC (Backup Domain Controller) and replicated the WINS database to it,
database corruption became even more frequent. My limited experience
with WINS was not very good.
[Bringing off topic discussions to a new low...]