[THIN] Re: Con2prt cannot resolve a server name

  • From: Angus Macdonald <Angus.Macdonald@xxxxxxxxxxxxxxxxxxx>
  • To: thin@xxxxxxxxxxxxx
  • Date: Wed, 17 Dec 2003 13:04:17 -0000

Sorry gents. FQDN gives the same result.
Kix gives error 1797 which I believe translates as "the printer driver is
unknown"
Does this make any sense?

-----Original Message-----
From: Gardiner Jeffrey [mailto:jeffrey.gardiner@xxxxxxxxxxx]
Sent: 17 December 2003 12:19
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: Con2prt cannot resolve a server name


Angus,
 
Does it work if you use the FQDN?
 
con2prt /c \\newservices.nww-tr.wales.nhs.uk\itlj8150 <file://\\n\itlj8150> 


-----Original Message-----
From: Angus Macdonald [mailto:Angus.Macdonald@xxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, December 17, 2003 7:04 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Con2prt cannot resolve a server name


It's the real, honest to goodness name. Here's a sample cmd output, with the
real IP address this time ;-)
 
M:\temp>con2prt /c \\newservices\itlj8150 <file://\\newservices\itlj8150> 
Failed to connect to Windows NT printer: \\newservices\itlj8150
<file://\\newservices\itlj8150> .
Please check to see that the printer exists.
 
M:\temp>ping newservices
 
Pinging newservices.nww-tr.wales.nhs.uk [134.13.17.50] with 32 bytes of
data:
 
Reply from 134.13.17.50: bytes=32 time<10ms TTL=128
Reply from 134.13.17.50: bytes=32 time<10ms TTL=128
Reply from 134.13.17.50: bytes=32 time<10ms TTL=128
Reply from 134.13.17.50: bytes=32 time<10ms TTL=128
 
M:\temp>con2prt /c \\134.13.17.50\itlj8150 <file://\\134.13.17.50\itlj8150> 
Connected to printer: \\134.13.17.50\itlj8150
<file://\\134.13.17.50\itlj8150> .
 
M:\temp>
 
Angus

-----Original Message-----
From: Braebaum, Neil [mailto:Neil.Braebaum@xxxxxxxxxxxxxxxxx]
Sent: 17 December 2003 11:58
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Con2prt cannot resolve a server name


Just so I'm fully understanding this - bear with me! servername is the true
netbios name for the machine, isn't it? It's not an alias or anything like
that?
 
Neil

-----Original Message-----
From: Angus Macdonald [mailto:Angus.Macdonald@xxxxxxxxxxxxxxxxxxx] 
Sent: 17 December 2003 11:36
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Con2prt cannot resolve a server name


PIng works fine
Net View \\servername <file://\\servername>  works fine. All of these are
from the same command-prompt session and con2prt.
It's slightly odd.

-----Original Message-----
From: Braebaum, Neil [mailto:Neil.Braebaum@xxxxxxxxxxxxxxxxx]
Sent: 17 December 2003 11:09
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Con2prt cannot resolve a server name


You can ping the servername happily, yes?
 
What happens when you do a net view \\servername <file://\\servername> ?
 
Neil

-----Original Message-----
From: Angus Macdonald [mailto:Angus.Macdonald@xxxxxxxxxxxxxxxxxxx] 
Sent: 17 December 2003 11:03
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Con2prt cannot resolve a server name


Queuename is the share name. Con2prt will happily map to
\\134.13.17.59\itlj8150$ <file://\\134.13.17.59\itlj8150$>  (not the real IP
address) but chokes on \\newservices\itlj8150$
<file://\\newservices\itlj8150$>  . Since I only have TCP/IP on the servers,
it seems odd that I can ping the servername but not connect using con2prt.

-----Original Message-----
From: Braebaum, Neil [mailto:Neil.Braebaum@xxxxxxxxxxxxxxxxx]
Sent: 17 December 2003 10:53
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Con2prt cannot resolve a server name


On the surface, sounds like a netbios name resolution issue - ie you can't
map using the name, but can explicitly with the IP address.
 
Just out of interest, is there any difference between the queuename and the
actual printername?
 
Neil

-----Original Message-----
From: Angus Macdonald [mailto:Angus.Macdonald@xxxxxxxxxxxxxxxxxxx] 
Sent: 17 December 2003 10:50
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Con2prt cannot resolve a server name


I don't remember suffering from this before and I've used con2prt since Noah
was a lad.
 
Con2prt cannot connect to \\servername\queuename
<file://\\servername\queuename>  but will happily connect to
\\ipaddress\queuename <file://\\ipaddress\queuename> . I can ping the
servername from the same command prompt with no problems. This is on NT4TSE.
Has anyone else met and conquered this? It's not a big issue but I'd like to
know why it doesn't work.
 
Regards
Angus
 
PS In case anyone was wondering, the only big change in Shelaunch 2.1a is
the facility to launch certain old 16/32 bit apps that fail to read
command-line parameters correctly when launched by the normal method with
spaces in the path. If you don't meet that particular issue, you won't need
v2.1a

*********************************************** This e-mail and its
attachments are confidential and are intended for the above named recipient
only. If this has come to you in error, please notify the sender immediately
and delete this e-mail from your system. You must take no action based on
this, nor must you copy or disclose it or any part of its contents to any
person or organisation. Statements and opinions contained in this email may
not necessarily represent those of Littlewoods. Please note that e-mail
communications may be monitored. The registered office of Littlewoods
Limited and its subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB.
Registered number of Littlewoods Limited is 262152.
************************************************ 


----------------------------------------------------------------------------
---

This message and any included attachments are from Siemens Medical Solutions


USA, Inc. and are intended only for the addressee(s).  

The information contained herein may include trade secrets or privileged or 

otherwise confidential information.  Unauthorized review, forwarding,
printing, 

copying, distributing, or using such information is strictly prohibited and
may 

be unlawful.  If you received this message in error, or have reason to
believe 

you are not authorized to receive it, please promptly delete this message
and 

notify the sender by e-mail with a copy to CSOffice@xxxxxxxxx  Thank you



Other related posts: