Can't Connect to Shared Drives

Any help with this will be GREATLY appreciated. This is quite the crisis until I can figure it out (oh how I love Monday mornings).

We have a large data server that all our employees connect to, usually via a seperate terminal server. We have two terminal servers. However, for some mysterious reason, various clients and one of the terminal servers can no longer connect to the shared drive when mapped to it. However, the other terminal server still connects with the no problems, so the problem is not consistent across the network.

For those that cannot connect to the mapped drive, this is the error message I get:

Quote:

---

The mapped network drive could not be created because the following error has occured:
Logon Failure: The target account name is incorrect.

---

There are only two clues I have so far:

1) I've been getting a LOT of MrxSub event IDs lately, but this has been occuring for a while without any problems until today, so I doubt it's at the root of the problem.

2) Mapping to the actualy IP address instead of the server name does work for some reason. It's when you use the usual "\\servername\drive" that it fails to map.

Again, we've been doing this a long time without any problems, when all of a sudden these clients just failed to connect this morning.

WINS????

What is the Server OS...2k or 2003.

There was a WINS sploit out...

any updates recently??

Oh sorry, forgot to mention it's W2k.

And yes, updated it with the latest Windows patch last week.

from the server you are having trouble with...can you ping the dataserver by name??

Are all servers the same OS and patch level??

I just found a fix...Doesn't tell me what caused the problem, but it has resolved it. I just changed:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters

from the value 0 to 1, then rebooted. The mapped drives automatically reconnected and now all is well.

Thanks for the help Morgan.

Good to hear you resolved the issue...

MLF

I hate Mondays too :cool:

Glad you found a fix. I suspect that you have a workstation or some other system that has claimed "Master Browser." I used to get this once in a while when someone put in an IPX protocol on a subnet and it claimed the master browser role. Systems in that subnet could no longer map drives or hit some network resources, or be seen from other subnets. Check your WINS database to see if the domain master browser role or master browser role is on a system other than your domain controllers. This can take a while to fix if it isn't a rogue protocol.

Another place to check is your DNS. Make sure your A records are correct for the data server and you don't have anything else writing an A record or alias with a similar name. If you can hit the share with the IP, but not the NETBIOS name, you have a resolver issue somewhere. It is probably WINS, but doesn't hurt to check DNS.

Thanks guys.

I'm starting to have second thoughts on this idea though. Consider this:

Quote:

---

By default, Windows NT, 2000, and XP store two different representations of each password locally and on servers: the LanMan hash and the NTLM hash. The LanMan hash is stored for backward compatibility all the way back to Microsoft's ancient LanMan product, vintage early 1990's. It's not really needed on a network where only Windows NT, 2000, and XP systems live. The LanMan password representation is extremely weak, and can be easily cracked. No matter how complex and obscure your password is, an attacker can crack it in under a week due to the incredibly feeble encryption used to formulate the LanMan hash.

To significantly improve your security, your best bet is to eliminate the LanMan hashes altogether. On Windows 2000, you can accomplish this by creating the registry key HKEY_LOCAL_MACHINE\System\CurentControlSet\Control\LSA\NoLMHash. On Windows XP, use regedit to create the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\NoLMHash as a "REG_DWORD – Number" and give it the value of 1.

---

The key I set to "1" had to do with plain text passwords and as you can see in my prior post, it was a Lanman value. Might I have just weakened my password security by chance?

Quote:

---

I have just weakened my password security by chance?

---

My brain is a bit too tired to look into what the ramifications of the reg change are right now... But the simple question is.... Is this Term Server available publicly without the benfit of a prior VPN connection? If it isn't then you really don't have too much of a problem if your perimeter is seured.... Thoughts?

I have this same issue on occasion. Wondering if service pack 2 related, since I run XP. I have been having issues with the master browser and authentication on pre w2k boxes. Rebooting the master browser fixes the issue. This smells like file replication issues are probably happening along with the drive mappings.

Hi


just a compatibility thought

A few years ago, it was mandatory to set "enableplaintextpassword"
in order to be able to connect to SAMBA machines (lanmanworkstation
is the workstation service). Such a low password encryption level does
increase compatibility[1], however it makes it easier for an intruder to
use a network sniffer. In this context (requirements), it is a security risk,
of course, as you also know.


The registry key "enableplaintextpassword" can also be set using local
policies:
Administrative Tools,Local Security Policy,Local Policies,Security Options,"Send unencrypted password"


browser service and replication latencies

Quote:

---

2) Mapping to the actualy IP address instead of the server name does work for some reason.

---

This points me (as well as others (rapier57)) to the idea, that your problem had to do with the
browser service.
You can get information about your current master browser using browmon and browstat,
which are part of the resource kit[2]. Mainly, try to control which machines are
participating in the election process using
[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Browser \Parameters].
Here, MaintainServerList (Yes, No, Auto) controls if the host should participate
at all, IsDomainMaster sets the priority.


What puzzles me, is that your problem just appeared on a running system.
Apart from possible malware (always a possiblity :) ), it might be that some
propagation error occurred (but because of what? Patch, Restart, Conflicts,...):
"SPN for the domain that is hosting the replica has not been propagated."[3].


Inconsistencies in the Browser table might be simply eliminated by
refereshing/restarting the service (debug using browmon and browstat),
as mentioned by RoadClosed.
If I recall correctly, in Win2k you still need the WINS table in order to
resolve for the IP, based on the "servername" (Win2k3 uses DNS). I hope, this
makes some sense or am I confusing something?


Cheers


[1] http://snakefoot.fateback.com/tweak/...PWD_ENCRYPTION
[2] http://www.windowsitlibrary.com/Content/155/05/2.html
[3] http://www.chicagotech.net/systemerrors.htm

I figured it out.

Oddly, the LANMAN fix was only temporary. This afternoon after a reboot my workstation once again failed to connect to the shared drives.

I finally discovered that something in the last Windows Update I ran caused this. So I removed Security Updates KB885835 and KB885836. Rebooted, and now everything is connecting as it should.

This has been a concern of mine. This data server is fairly behind in updates and is thus missing a number of security patches, but my boss is against running updates for this reason. However, obviously this means we have upatched holes in the server's W2k OS.

Odd...I'm beginning to think there's more than one cause to this.

Yesterday, things continued to run smoothly across the network after those two patches were removed...except on two computers. That's two out of ~20 or so; the rest connect fine.

One is a workstation, and the other is the backup domain controller (?!). For some mysterious reason, neither of these will connect to the shared drives, even after the fix on the data server, even despite the fact that all other computers on the network are showing no other problems connecting yet.

Again, however, if it is directed to the shared drive via IP address as opposed to the usual computer name, it will connect.

So evidently I've only partially fixed the problem. So now I have to figure out why these two machines won't cooperate while all the others will.

A hint I see: In My Network Places, the data server is one of quite a few computers these trouble computers fail to see on the network with them. When I run a search on the data server by name, it comes up with location "unknown" instead of showing the name of the network (even though they're on the same network!).

Baffling eh? I'm quite stumped at the moment.

<edit> Another hint: I keep seeing repeated occurances of DNS Error 409 on this backup domain controller in question.

Quote:

---

The DNS server list of restricted interfaces contains IP addresses that are not configured for use at the server computer.
Use the DNS manager server properties, interfaces dialog, to verify and reset the IP addresses the DNS server should listen on. For more information, see "To restrict a DNS server to listen only on selected addresses" in the online Help.

---

However, the IP addresses are indeed configured properly.

Sorry for the annoying triple-posting, but I'm finding new stuff...

This is my first introduction to browmon.exe, so you'll have to forgive my ignorance. However, I installed the tool and ran it on this pesky backup domain controller. I can indeed see the data server, I just can't connect to it. So it's at least visible, and it does show up in browman.

Anyway, I'll keep digging and will post whatever I turn up next...

Well, now I've run browstat.exe, and still no clues that I see...

Shows that everything is running well...

Yesterday I was telling you that the data server wouldn't even appear in the browser. Now it does appear, only it cannot be accessed. It is the only computer in the browser that cannot be accessed. It returns the error "The target account name is incorrect".

And again, any other machine other than these two can connect to it.

So no luck yet finding anything odd with browmon or browstat...

AngelicKnight

I have read on many occassions that all MS servers and clients should be at the same patch level...or you will start to encounter communication issues! as the security patches fix things in the protocol, authentication privledges etc

Are the clients all 2k and up?? cause Ive seen some issues with 98 and 2000 servers??

Tell your boss that you have to update..backup that data server ..twice, verify both backups and test restore from both backups.....and UPDATE!!!

Patching isnt half as bad as the old NT4 days when you patched something...which inturn would unpatch something else....or break some thing.

Patching servers is not one of my favorite things, I backup, then backup again, then I verify..test restore...start late friday ( so I have the weekend to restore...just in case :( ) cross my fingers and do my old NT4 voodoo dance (some old habits die hard :) and update.

IMHO 2k patch management was an improvement on NT4
...2003 is a GREAT improvement...although I still do the dance ;)


MLF

Unfortunately my telling the boss we must patch isn't going to do me any good, such is the downfall of me being assistant network administrator until I eventually get promoted (hopefully).

However, I keep all of our clients and most other servers up-to-date. Consider:

The data server, when patched, will not share it's drives with anyone unless the clients connect via IP address as opposed to computer name. This is definately due to the patches I noted above.

All clients are patched.

The one DC that is having trouble accessing the data server was unpatched, but I patched it yesterday. No effect.

The backup domain controller is NT isn't it? Just a guess.

If you aren't going to patch the server just give up on the whole thing You are not updating compatibility fixes, drivers, patches to prolems that may fix your issues, and in addition just dangling out security carrot and the whole lot. While I agree that sometimes these things do cause issues and you should look at what is changing - but that is what BACKUP is for and rollbacks etc. The risk of severely outdate machines for outwieghs an inconcenience that someone can't access a file share for an hour while the bug is worked out. A succesful server is a MANAGED server. ;) Just directing this at your boss not you. I hate to see how many corrupt or dropped packets or data storage issues you have on those file servers. :eek: I have had ENTIRE data stores lost from outdates SCSI drivers and bios updates I chose to put off.

Well, as far as security, the reply you'd get would be "We're secured behind our SonicWALLs".

*sigh*

Tis the same guy who won't let me get an IDS and some cheap server room security cameras because of the cost and it being "overkill".

I totally agree with you. I'm definately going to have to be creative to figure out a way to do this without patching.

I just came back from lunch, and something interesting has happened as well. I have one workstation and one BDC right here in my office, and the workstation shares the printer on the BDC. Well guess what? My workstation can't print to the server's printer now, all of a sudden, because of an "access denied" error.

It's gotta be related...or I'm just having one really bad day.

I definately agree with you guys that something's gotta be up with name resolution for these machines. Figuring out WHAT, now, that's gonna be the trick. Keep the ideas coming!

Ok, I think I'm onto something else.

Note I said in the last post that my workstation here in my office can't connect to the printer that happens to be connected to the BDC also here in my office. So I started thinking, could this BDC be the source of all my problems?

Sure enough, this BDC will not connect to the data server's shared drives either. It can see the data server in the browser, but will not connect to it. Meanwhile, this worksation of mine has "access denied" when trying to connect to the BDC. So, would this BDC be our pesky problem child then?

I'll try some stuff out and get back with you guys...in the meantime, if you think of something, throw it my way!

Ok, now it's getting interesting.

I just ran browmon on this suspicious BDC, and sure enough the results are...odd.

It shows the proper PDC (note I say "PDC" here somewhat lightly, as according to M$, W2k doesn't assign a PDC...but you guys know what I mean -- the equivalent master role assigned this server), with it's state as online. Ok, all is well. But the next few collumns just don't make sense:

Type: Unknown
Servers: Unknown
Domains: Unknown

It lists two other W2k servers and identifies them as type Windows NT 5.0, 27 servers, 3 domains, but for some reason this all comes back as "unknown" for the PDC.

Note this BDC in question is fully patched.

Sorry Angelic if I missed it somewhere...are all the servers W2K???

The data server is a member server?? SP level?

What SP is the DC ??

What SP is the BDC??

The problem is if the PDC is doing the authentication using the updates...they are not being replicated or passed on properly.

Also...after you removed the updates ...did you reinstall the SP and other updates...I have one 2k server...that every so often a database update knocks the SP level down a notch...and the SP needs to be reapplied...must be a lanman thing.

Although I have never figures it out...I just reapply the SP and it all works again.

You know...cause this all started with a security patch update...you may be able to get free support from MS :rolleyes:

http://support.microsoft.com/gp/securityitpro

No-Charge Support
1-866-PCSAFETY
or
1-866-727-2338
This phone number is for virus and other security-related support. It is available 24 hours a day for the U.S. and Canada.

They may have a work around for you?

MLF

Heh, boss won't let me call MS because we have "licensing" issues. ;)

Yes, the entire network is nothing but W2k.

Let me take a look at those SP levels...Ok, everything looks to be SP4, even the servers missing hotfix patches.

Ok, just ran browstat on the BDC in question. It identifies the PDC no problem, as well as BDCs, but then check this out:

Quote:

---

Could not connect to registry, error = 5
Unable to determine build of browser master: 5
Unable to determine server information for browser master: 5
Unable to retrieve server list from [PDC]: 64

---

That tell you anything?

<edit> Found this googling:

Quote:

---

The error 5 is "access denied". You have to have administrative access to open
the registry (determine build) across the network.

---

Odd thing is, this IS with administrative access! :eek:

<edit 2> More googling uncovered that the error 64 message means "The specified network name is no longer available."

What the?!

Hi

I still cannot provide very constructive ideas, but your error message 5 sounds like
you have no access to the master browser from your "BDC" (remote registry),
which might also be reflected by the behaviour of the browser service.
/edit: ie: your bdc cannot obtain a proper browser list, and therefore, the
network neighborhood cannot be used, however you can connect doing a map
manually using the IP number. The problematic workstation seems to connect to
the "BDC", and therefore also suffers of this. Now, what causes this problem...

Just a thought: Might be something messed up with the ACL's while installing the
patches ?!

Just a reader: I have found 2 interesting resources, which however, might not
be of interest anymore...

[1] sequence for name lookups
[2] browser service resources

/edit.
oups, to quote morganlefay

Quote:

---

The problem is if the PDC is doing the authentication using the updates...they are not being replicated or passed on properly.

---

Cheers

[1] http://expertanswercenter.techtarget...975461,00.html
[2] http://labmice.techtarget.com/networ...rowsersrvc.htm

AK

One thing we used to do to resolve outlook connectivity issues in NT4 ...was to edit the HOSTS file on the client and add the IP address and server name

127.0.0.1 LOCALHOST
xxx.xx.xx.x SERVERNAME

Maybe worth a try?? on the client and BDC...just map all your servers in there...you can always change it back.
It required a reboot in NT4 ....not sure bout w2k


Maybe worth a try...although I think that the credentials are getting F&%ked do to the patch levels not being the same :(

MLF

EDIT\ make sure you save the file with no extension just HOSTS
Default location C:\winnt\system32\drivers\etc

Quote:

---

Just a thought: Might be something messed up with the ACL's while installing the
patches ?!

---

Good idea...I checked out permissions in the PDC's AD regarding access to this particular BDC, and it turns out the net admin user group (which I'm logged in under when running these tests) did not have full permissions, specifically lacking permission to alter the subtree. I'm not sure if that's related, but it's worth a shot, so I allowed permission there, and I'm about to see what happens next...

<edit> Didn't see your post there, Morgan. I'll look into that.

Bingo.

Whoever suggested a replication error (was it RoadClosed?) looks to have been right on the money.

One of our BDCs keeps mysteriously being promoted to PDC and kicking the PDC back down to BDC. So, I tried demoting this particular BDC to resolve that. Guess what? Demotion failed because of a replication error.

That's gotta be it. I've had similar replication problems with the global catalog before, and I never could figure out what was causing it. So I bet this is our gremlin.

<edit> Might there be a manual (alternative) process by which means to bypass the replication problem and demote the server anyway?

Ok, here's the next piece to the puzzle:

I read this here:

Quote:

---

As part of the demotion process, the DCPROMO utility removes the configuration data for the domain controller from the Active Directory. This data takes the form of an "NTDS Settings" object, which exists as a child to the server object in the Active Directory Sites and Services Manager.

The information is in the following location in the Active Directory:

CN=NTDS Settings,CN=&lt;servername&gt;,
CN=Servers,CN=&lt;sitename&gt;,CN=Sites,
CN=Configuration,DC=&lt;domain&gt;...

---

But in my AD, in the specified location, I only see this:

Name: &lt;automatically generated&gt;
From server: (PDC name)
From site: Default-First-Site-Name
Type: Connection

And that's it. No other entries. I then right-click that and select "replicate now" and then I get the following error:

Quote:

---

The target principal name is incorrect.

---

IMHO

You can bandaid your setup...and maybe it will work ...for now

But you will continue to have problems until you can bring all the servers up to the same patch level

Oh and by the way

Quote:

---

Whoever suggested a replication error (was it RoadClosed?) looks to have been right on the money.

---

That was me :D

Quote:

---

The problem is if the PDC is doing the authentication using the updates...they are not being replicated or passed on properly.

---

MLF

Thanks Morgan, I forgot!

Ok, I've discovered something else...

I went into AD to check out operations master roles...turns out it thinks this pesky BDC is offline (which it is anything but). So I go into the network browser, and sure enough, any attempt to access this BDC (though it does appear in the browser) is met with "access denied"!

So I log on to the BDC and start piddling around...Turns out that w32time is disabled. Aha! We all know that having the time services out of sync between two DCs can cause AD problems galore, so this could be the culprit! Odd thing is, it shouldn't be stopped; I've had Windows Time enabled and synced between all machines on the network since some time ago.

So I enable w32time, but when I try to start it up, I still get this message:

"The service cannot be started, either because it is disabled or because it has
no enabled devices associated with it."

Even though w32time is enabled once again, it still can't be started? What could be the cause of this?

Angelic:

I have stayed out of this conversation for one simple reason... trying to determine domain issues remotely is a lot like trying to determine what's wrong with your grannies car when she lives in LA and you live in NY..... It's not only very difficult it's also very dangerous when you are discussing a live network.

What I _do_ know is that since you inherited this domain you have had some "odd" issues. More than once..... and those issues seem to revolve around an AD domain that isn't functioning properly. IME, an AD domain is pretty much a "fire and forget" system if it is set up from scratch and properly managed in between. It strikes me that the system has been improperly put together over time and you are left with the dross that results from that.

I'll take issue with MLF on the patch issue.... Simply because I know that, properly managed, the patch level isn't a problem. However, I will say that if the domain isn't "intact", (for want of a better way of putting it), she may well be right in that it will exacerbate the issues you see.

Were I in your position, and I know this will 'hurt", I would drop the whole domain and start from scratch. The downside is the potential downtime... The upside is a network that doesn't randomly "flake out" on you..... Which peeves the users, gives you stress and generally isn't a good thing...

It's going to be a pain... I don't really have time to sit and list the considerations like every mapped drive you have etc.... You know.... But, in the long run, your issues will be solved.

I guess the biggest problem will be convincing your "genius" boss that it has to be done.... Why do I get the horrible feeling that he will tell you that "everything is just peachy"????? :rolleyes:

That's my best advice in your situation..... Sorry I can't be more helpful. There are things that are obvious in AD and things that have too many variables for me to feel comfortable saying "do this".... On my network I might _think_ about trying them... But I take responsibility for my network.... I really don't want to be risking someone elses network by telling them to try it when I have no real clue....

You have my best answer in this situation bearing in mind the history of the network in question..... And you know how much I _hate_ to say that........

Indeed, Tiger, indeed...Yeah, I'm fearful of even suggesting starting from scratch...

To my previous question...Does anyone know of a way to manually demote a server? As stated pior, I can't demote it by the typical means, because it won't communicate with the other DC ("access denied" problem). Demoting this particular server (it's the newest DC) may ease the situation...

Try this

Dang, I'm really screwed up at the moment. That didn't even work!

This is what I got:

Quote:

---

The operation failed because: The Directory Service failed to replicate off changes made locally. "Access is denied. "

---

That's with the proper admin account and password used...

Go back to my link and look at the sublinks too.....

About 6 months ago I redid my AD domain at home and because I have a pretty slow box for the server and I'm an impatient SOB I forced a reboot after the box appeared to hang during a dcpromo.... :o In response to a specific error message I found a way to force the server to believe that it is no longer a member of an AD domain on M$' web site... Unfortunately it was one of those accurate but cryptic error message and I have no clue what it was. There is a registry key out there that you can change from it's existing value to "NTServer" I believe it was and it's all it takes to con a server into thinking it is a standalone. Then you can run NTDSutils, IIRC, to run a cleanup and then dcpromo the box again..... Sorry, but it's all a bit fuzzy now but it worked for me in a situation that appears similar to what you may have now..... I tried searching for it for you yeserday and came up with nothing except the link I put there for you. The search terms I used were:-

NTServer registry key
AD domain force demotion
demote AD NTServer registry
force demotion

and a couple of others I don't remember..... If you have a specific error number search on that.... Good luck

Go back to my link and look at the sublinks too.....

About 6 months ago I redid my AD domain at home and because I have a pretty slow box for the server and I'm an impatient SOB I forced a reboot after the box appeared to hang during a dcpromo.... :o In response to a specific error message I found a way to force the server to believe that it is no longer a member of an AD domain on M$' web site... Unfortunately it was one of those accurate but cryptic error message and I have no clue what it was. There is a registry key out there that you can change from it's existing value to "NTServer" I believe it was and it's all it takes to con a server into thinking it is a standalone. Then you can run NTDSutils, IIRC, to run a cleanup and then dcpromo the box again..... Sorry, but it's all a bit fuzzy now but it worked for me in a situation that appears similar to what you may have now..... I tried searching for it for you yeserday and came up with nothing except the link I put there for you. The search terms I used were:-

NTServer registry key
AD domain force demotion
demote AD NTServer registry
force demotion

and a couple of others I don't remember..... If you have a specific error number search on that.... Good luck