At my company, we have 9x clients that recently started dropping mapped share sessions to a particular NT4 file server. They get "Access Denied" on reconnect attempts. This is SIMILAR to the reported problems w/98 to Win2K shares (Q278558 on TechNet). They don't drop from any other server - just this one, and NT clients don't drop from the affected server (so far as I have seen). And it seems to be a recent phenomenon, which leads me to believe *something* changed or broke.
This one has been tough, so follow me if you can... We have three domains in question: An old single domain structure for both users and machines (we'll call it BLOB), and two newer domains for user accounts and resources (called PEOPLE and THINGS). NT clients tend to have user accounts in PEOPLE and machine accounts in THINGS. Win9x clients tend to have user accounts in the BLOB domain. The server has been around a while, and is still has a machine account in the BLOB domain. Connections to other servers in BLOB (or in THINGS) do not seem to be affected.
Recent noteworthy events have been a failed power test that brought all the servers down, and a change-over to new WINS servers. The old WINS servers are still up until we find the remaining seats with statically mapped WINS addresses and change them to get this from DHCP. The power outage is a good candidate for database corruption somewhere in the mix.
I am curious to know what differences there may be between 9x clients and NT clients in creating a mapped drive session and in re-establishing a session that has been disconnected. Our server is set to 15 minutes autodisconnect (default). If a 9x client session disconnects, the users get access denied when it tries to re-establish the connection on next attempted use. But if I do a disconnect and re-map with NET USE, that share (and any others with the server) come back to life just fine.
I'm still not sure if this is just a problem with 9x boxes, or if it is BLOB domain users. I have not seen an incident (yet) with a BLOB account on an NT box or a PEOPLE account on a 98 box failing. So for now we've concentrated on differences with Win9x.
Here are questions I have:
Is it possible for LSA table corruption on the server to affect the entries for one domain (BLOB) and not affect entries for the other(s) (PEOPLE and THINGS)?
Are there differences in how connections are established and re-established with 98 clients vs. NT clients? I know that for NT, the server will initially challenge the LSA on the workstation, and then send the challenge response up to the PDC. Then the server will get tokens back from the PDC, and on subsequent (reconnect) attempts from the workstation, it can authenticate against the tokens it has in it's LSA. Is this pretty much identical for Win9x, or are there important differences here?
Does a server keep tokens in it's LSA for members of any domain, or just for members of it's own domain??? If it is only it's own domain (BLOB), then a courrupt LSA would explain why BLOB users fail on reconnects but PEOPLE users do not.
Is there anything specific in the event logs of the server I can look for that might give me some clues? How about the Domain Controllers?
It's been real hard digging up some of this info, so I want to say THANKS! up front to any and all for help/insight you can offer!!! - Tim
This one has been tough, so follow me if you can... We have three domains in question: An old single domain structure for both users and machines (we'll call it BLOB), and two newer domains for user accounts and resources (called PEOPLE and THINGS). NT clients tend to have user accounts in PEOPLE and machine accounts in THINGS. Win9x clients tend to have user accounts in the BLOB domain. The server has been around a while, and is still has a machine account in the BLOB domain. Connections to other servers in BLOB (or in THINGS) do not seem to be affected.
Recent noteworthy events have been a failed power test that brought all the servers down, and a change-over to new WINS servers. The old WINS servers are still up until we find the remaining seats with statically mapped WINS addresses and change them to get this from DHCP. The power outage is a good candidate for database corruption somewhere in the mix.
I am curious to know what differences there may be between 9x clients and NT clients in creating a mapped drive session and in re-establishing a session that has been disconnected. Our server is set to 15 minutes autodisconnect (default). If a 9x client session disconnects, the users get access denied when it tries to re-establish the connection on next attempted use. But if I do a disconnect and re-map with NET USE, that share (and any others with the server) come back to life just fine.
I'm still not sure if this is just a problem with 9x boxes, or if it is BLOB domain users. I have not seen an incident (yet) with a BLOB account on an NT box or a PEOPLE account on a 98 box failing. So for now we've concentrated on differences with Win9x.
Here are questions I have:
Is it possible for LSA table corruption on the server to affect the entries for one domain (BLOB) and not affect entries for the other(s) (PEOPLE and THINGS)?
Are there differences in how connections are established and re-established with 98 clients vs. NT clients? I know that for NT, the server will initially challenge the LSA on the workstation, and then send the challenge response up to the PDC. Then the server will get tokens back from the PDC, and on subsequent (reconnect) attempts from the workstation, it can authenticate against the tokens it has in it's LSA. Is this pretty much identical for Win9x, or are there important differences here?
Does a server keep tokens in it's LSA for members of any domain, or just for members of it's own domain??? If it is only it's own domain (BLOB), then a courrupt LSA would explain why BLOB users fail on reconnects but PEOPLE users do not.
Is there anything specific in the event logs of the server I can look for that might give me some clues? How about the Domain Controllers?
It's been real hard digging up some of this info, so I want to say THANKS! up front to any and all for help/insight you can offer!!! - Tim