OK. The biggest problem I have is that I have no access to these
machines, and I don't have any support personal in the LA office.
(Friday was his last day) I have access to one win 98 box from here, but
I need to come up with a "user friendly" fix that any moron...uh I mean
user... Can implement. The only success I had was in changing the
workgroup name to match the domain name, then use the same user mane and
password. This worked but I lost access to the rest of the old
"workgroup". (I was unable to browse anything) fix one thing break
another. I haven't really ever worked with win 9x in a network. Maybe
two or three machines connected together. I really do appreciate
everyone's assistance. 

Thanks all.

Mike Staines



-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Roche, Andy
Sent: Monday, July 15, 2002 6:28 PM
To: NT 2000 Discussions
Subject: RE: Win 98 and connections


No offense taken.  Just figured that he couldn't move the PC from the
group it was in.  I should know better than to make assumptions! ;)

I will also check the settings on the WinME machine at home to verify
how it is setup.

W. Andy Roche


-----Original Message-----
From: Dean Cunningham [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 15, 2002 5:02 PM
To: NT 2000 Discussions
Subject: RE: Win 98 and connections


Whilst Andy's solution will work , it is a bit of a kludge (sorry andy).
This is how I would do it, you need to set the 98 machine up to log into
the w2k domain. This is the only way to solve the password prompt
problem. This assumes you are in mixed mode w2k. You will need to put
into a LMHOSTS the location PDC and domain details for each PC so they
know where the PDC is. change the workgroup name on the PCs to match the
w2k domain name, this way they should be able to browse the network as
well

The win98 resource kit is on technet Cd, here is a snippet from it
regarding LMHOSTS

cheers
Dean

Setting Up LMHOSTS Files
  
When you use Microsoft TCP/IP on a local network with any combination of
computers running Windows 98, Windows NT, LAN Manager, or Windows for
Workgroups, server names are automatically mapped to their corresponding
IP addresses. However, to map server names across remote networks
connected by routers (or gateways), you can use the LMHOSTS file if WINS
servers are not available on the network. The LMHOSTS file is commonly
used to locate remote computers for Microsoft networking file, printer,
and remote access services, and for domain services, such as logon,
browsing, replication, and so on. 
The LMHOSTS file used by Windows 98 contains mappings of IP addresses to
Microsoft networking computer names (which are NetBIOS names). Microsoft
LAN Manager 2.x TCP/IP LMHOSTS files are compatible with Microsoft
TCP/IP. Microsoft TCP/IP loads the LMHOSTS file into memory when the
computer is started. The LMHOSTS file is a text file in the \Windows
directory that lists the IP addresses and computer names of remote
Windows networking servers that you want to communicate with. The
LMHOSTS file should list all the names and IP addresses of the servers
you regularly access. 
For example, the LMHOSTS table file entry for a computer with an address
of 192.45.36.5 and a NetBIOS computer name of Finance1 looks like this:
192.45.36.5finance1

The format for the LMHOSTS file is the same as the format for host
tables in 4.2 MSD UNIX systems, with the exception that LMHOSTS does not
allow a scoped name to be indicated. The computer name is optionally
enclosed in quotation marks (this is necessary for computer names that
contain spaces). To create an LMHOSTS file 1. Use a text editor to
create a file named LMHOSTS, or edit the default file named Lmhosts.sam
in the \Windows directory and then save this file as LMHOSTS. This
LMHOSTS file will be checked by default as the machine starts. 2. In the
LMHOSTS file, type the IP address and the host name of each computer
that you want to communicate with. Separate the items with at least one
space. Entries in the LMHOSTS file are not case-sensitive. 
You will want to use LMHOSTS for smaller networks or to find hosts on
remote networks that are not part of the WINS database (because name
query requests are not broadcast beyond the local subnetwork). If WINS
servers are in place on an internetwork, users do not have to rely on
broadcast queries for name resolution, because WINS is the preferred
method for name resolution. Therefore, with WINS servers in place,
LMHOSTS may not be necessary. 
However, the LMHOSTS file is read when WINS or broadcast name resolution
fails, and resolved entries are stored in a system cache for later
access. When the computer uses the replicator service and does not use
WINS, LMHOSTS entries are required on import and export servers for any
computers on different subnetworks participating in the replication. 
You can use Notepad or any other text editor to edit the sample
Lmhosts.sam file that is automatically installed in the \Windows
directory. The following rules apply for entries in LMHOSTS: .Each entry
should be placed on a separate line. 
.The IP address should begin in the first column, followed by the
corresponding computer name. 
.The address and the computer name should be separated by at least one
space or tab. 
.The # character is usually used to mark the start of a comment.
However, it can also designate special keywords, as described in this
section. 
The keywords listed in the following table can be used in LMHOSTS using
Microsoft TCP/IP. Notice, however, that LAN Manager 2.x treats these
keywords as comments.
  
Keyword Meaning

#PRE    Added after an entry to cause that entry to be preloaded into
the
name cache. #PRE entries in LMHOSTS are looked up and cached prior to
WINS lookup. #PRE must be appended for entries that also appear in
#INCLUDE statements; otherwise, the entry in #INCLUDE is ignored.
#DOM:domain     Added after an entry to associate that entry with the
domain
specified by domain. This keyword affects how the Browser and Logon
services behave in routed TCP/IP environments. To preload a #DOM entry,
you must also add the #PRE keyword to the line.
#INCLUDE filename       Forces the system to seek the specified filename
and
parse it as if it were local. Specifying a universal naming convention
(UNC) filename allows you to use a centralized LMHOSTS file on a server.
You must map the server before its entry in the #INCLUDE section, and
also append #PRE to ensure that it is preloaded (otherwise, the #INCLUDE
will be ignored).
#BEGIN_ALTERNATE        Used to group multiple #INCLUDE statements. Any
single successful #INCLUDE statement causes the group to succeed.
#END_ALTERNATE  Used to mark the end of an #INCLUDE grouping.
\0xnn   Support for nonprinting characters in NetBIOS names. Enclose the
NetBIOS name in quotation marks and use \0xnn hexadecimal notation to
specify a hexadecimal value for the character. This allows custom
applications that use special names to function properly in routed
topologies. However, LAN Manager TCP/IP does not recognize the
hexadecimal format, so you surrender backward compatibility if you use
this feature. Notice that the hexadecimal notation applies only to one
character in the name. The name should be padded with blanks so the
special character is last in the string (character 16). The following
example shows how all of these keywords are used:
102.54.94.98   localsrv #PRE
102.54.94.97   trey     #PRE #DOM:networking #net group's PDC
102.54.94.102  "appname        \0x14"  #special app server
102.54.94.123  popular  #PRE #source server
#BEGIN_ALTERNATE
#INCLUDE \\localsrv\public\lmhosts #adds LMHOSTS from this server
#INCLUDE \\trey\public\lmhosts     #adds LMHOSTS from this server
#END_ALTERNATE

In the preceding example:
.The servers named localsrv and trey are preloaded so they can be used
later in an #INCLUDE statement in a centrally maintained LMHOSTS file.
.The server named "appname        \0x14" contains a special character
after
the 15 characters in its name (including blanks), so its name is
enclosed in quotation marks. .The server named popular is preloaded,
based on the #PRE keyword. Guidelines for LMHOSTS
  
When you use a host table file, be sure to keep it up to date and
organized. Follow these guidelines: .Update the LMHOSTS file whenever a
computer is changed or removed from the network. .Use #PRE statements to
preload popular entries into the local computer's name cache and to
preload servers that are included with #INCLUDE statements. .Because
LMHOSTS files are searched one line at a time from the beginning, you
can increase the speed of searches for the entries used most often by
placing frequently used servers near the top of the file. Follow these
with less frequently used servers, and then remote #INCLUDE statements.
The #PRE entries should be at the end of the file, because these are
preloaded into the cache at system startup time and are not accessed
later. Comment lines add to the parsing time, because each line is
processed individually.


-----Original Message-----
From: Michael Staines [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 16 July 2002 8:56 a.m.
To: NT 2000 Discussions
Subject: RE: Win 98 and connections



Did this, still getting the password prompt.


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Roche, Andy
Sent: Monday, July 15, 2002 4:46 PM
To: NT 2000 Discussions
Subject: RE: Win 98 and connections


This is an easy one, I have dealt with this too many times.  The Win2K
is request the authentication from the Win98 box.  Win98 will respond
with the username that the user logged into their workstation with.
Because the username will not have the Domain name from the Win2K
domain, it requests that you give it something to work with.  The
solution is to have the user log into the workstation with the same ID
as the UserID they have in the Win2K domain.  Then when it asks for a
password, they type in the password for their Win2K domainID.

Ex. 

Given a Win2K domain of WINDOMAIN and a workgroup of WRKGROUP, and a
userID of USER1 in both domains.  The passwords can be different or the
same.  Share called SHARE1 on SERVER1 in WINDOMAIN.

Solution:
User logs into the 98 workstation as USER1, and then maps 
a drive to \\SERVER1\SHARE1.  The password window pops up, and the user
puts in the password for USER1 in WINDOMAIN, because 98 has already set
the username to use as USER1.  User now has access.  

The key is that usernames have to be the same.  Should you keep the
passwords the same on the workstation and the domain, then you won't
even get the password request.

I am using this for my network at home as well. ;)

W. Andy Roche



-----Original Message-----
From: Ed Esgro [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 15, 2002 3:22 PM
To: NT 2000 Discussions
Subject: RE: Win 98 and connections


This pc is representing itself as workgroup/computername.
It is not trusted on your domain I am sure. I don't know of a way to
trust a workgroup. I think the only thing you can do is give explicit
rights at the share level to the workgroup/computername or
workgroup/username. Is the box you are sharing a 2000 server? Does it
have IIS installed? If so why not do a web share of this folder? Just
some thoughts.

Ed

-----Original Message-----
From: Michael Staines [mailto:[EMAIL PROTECTED]] 
Sent: Monday, July 15, 2002 3:56 PM
To: NT 2000 Discussions
Subject: Win 98 and connections



Please someone out there has to be able to help me. 

I have a mixed 4.0 and 2000 domain. My company just recently purchased
another company that runs on a win 98 workgroup. (I know I know it hurt
me too) I have installed a firewall and created a VPN between the new
company (in LA) and myself (in NY). I need the users to see some docs I
have on a shared folder on one of my 2000 boxes. When I try to map the
drive, I get prompted for a password. Not a username AND password. Just
a password. I have tried every password I know of in my 2000 domain, but
none work. What user is this win 98 box representing itself as? What
password is it looking for? One person suggested making a duplicate
domain user that matches the workgroup users. I tried this and it still
didn't work. 


Any suggestions would be appreciated.

Mike Staines
 


------
You are subscribed as [EMAIL PROTECTED]
Archives: http://www.swynk.com/sitesearch/search.asp
To unsubscribe send a blank email to %%email.unsub%%

------
You are subscribed as [EMAIL PROTECTED]
Archives: http://www.swynk.com/sitesearch/search.asp
To unsubscribe send a blank email to %%email.unsub%%

------
You are subscribed as [EMAIL PROTECTED]
Archives: http://www.swynk.com/sitesearch/search.asp
To unsubscribe send a blank email to %%email.unsub%%


------
You are subscribed as [EMAIL PROTECTED]
Archives: http://www.swynk.com/sitesearch/search.asp
To unsubscribe send a blank email to %%email.unsub%%


**********************************************************************
This email is not an official statement of the Waikato
Regional Council unless otherwise stated.
Visit our website http://www.ew.govt.nz
**********************************************************************


------
You are subscribed as [EMAIL PROTECTED]
Archives: http://www.swynk.com/sitesearch/search.asp
To unsubscribe send a blank email to %%email.unsub%%

------
You are subscribed as [EMAIL PROTECTED]
Archives: http://www.swynk.com/sitesearch/search.asp
To unsubscribe send a blank email to %%email.unsub%%


------
You are subscribed as [email protected]
Archives: http://www.swynk.com/sitesearch/search.asp
To unsubscribe send a blank email to [EMAIL PROTECTED]

Reply via email to