none
Unable to share network resources now

    Question

  • Hello,

     

     I have several computers (mostly XP-Pro) domain networked through a Server 2000.

    After upgrading to to Windows XP Service Pack 3, each of the computers that had previously had shared resources on the network (printers, external USB hard drives), are no longer accessable to the network. If I uninstall the SP3 upgrade on a computer with a shared resource, that resource is available again.

     What can I do to correct this problem?

     

    Thanks,

     

    Michael

    Tuesday, May 13, 2008 2:20 PM

Answers

  • Robin,

    Pulling the hotfix is Microsoft policy I think.

    In a while we are all forced to apply SP3.

    So, the lazy people who didn't upgrade yet, will be forced to install SP3 with MS-update.

    Hopefully a real fix will be applied in this version.

    On the other hand there is a really simple solution given to me by a Microsoft tech guy.

    Replace the netlogon.dll with the one from SP2.

    All problems solved!

    Note: I have the English version of the hotfix, but I don't try to install it (If its not broken, don't repair it).
    Also a SP2 netlogon is available.
    If you want to have one of them, send me an E-Mail

    Friday, February 20, 2009 5:51 PM

All replies

  • Check that File and Printer Sharing is enabled.  Check that there are appropriate Firewall Exceptions for File and Printer Sharing are defined.  Check that, if you had "Simple Sharing" disabled before, that you have disabled it again after SP3.

    Wednesday, May 14, 2008 3:15 PM
  • Thanks Robin,

     

    I've tried all of those. I've disabled Windows Firewall. I've tried both states of "SSF". I've checked the

    states of the various things in the Reg\LSA area. They all match each other in the "with update" to "without update"

    conditions.
    Wednesday, May 14, 2008 6:20 PM
  • We are having a similar issue at my company.  We've found that if we manually add our company's primary DNS suffix all is working again with SP3.  We have also found that there are several keys namely the DHCPdomain key in HKLM\
    SYSTEM\CurrentControlSet\
    Services\Tcpip\Parameters which does not populate with SP3, as a matter of fact it's not even created. If we manually create it and add it in and then release and renew the IP the manually created key is removed.  We run a packet sniffer and can see that the handshake is being made, but for some reason the key's in the registry (we found 6 in total that require DHCPdomain) and not being created and this is what our DHCP is looking for.  This is a company wide issue, so the adding of firewall or things like that would not be a cause.  We've test a clean SP2 machine and all internal connections are available then the only change made is to apply SP3, and we lose all internal connections.  Any ideas please?
    Wednesday, May 14, 2008 6:48 PM
  • Does anyone at MS have any ideas why this is occuring, this is affecting our entire organization.  Anyone that upgrades to SP3 can't connect on our local network.  It's kind of impacting us.
    Thursday, May 15, 2008 2:41 PM
  • For what it's worth. I only seem to be seeing this issue with PCs which are members of a domain. If the PC was not a domain member (at least at the time of SP3 install) it seems to be unaffected. Has MS changed some aspect of how authenticatication works - perhaps treating systems not in the same domain differently?

     

     

     

     

    Friday, May 16, 2008 2:40 AM
  • Here is the exact error message I get when trying to connect to the SP3-ized computer that has

    a printer that had been accessible with SP2 with no problems.

     

    (computer name) "is not accessible. You might not have permission to use this resource. Contact the administrator of this server to find out if you have access permissions.

     

    There are currently no logon servers available to service the logon request."

     

    I've even tried creating an account on the computer that is not accessible that matches the

    computer trying to access, with the same results. But I shouldn't have to do this, anyway.

     

    WTF.................

    Friday, May 16, 2008 1:23 PM
  • Still no resolution.

     

    Monday, May 19, 2008 1:21 PM
  •  Michael @ Cherokee wrote:
    "There are currently no logon servers available to service the logon request."

    This indicates that the actual underlying error is a failure to join the domain, because it could not find a domain logon server.  The other problems follow from this.  Can you investigate this error any further?

    Monday, May 19, 2008 1:45 PM
  • The way we have each workstation set up, the user logs onto his workstation, not the domain. When the workstation accesses the hard drives on the server, the server authorizes access.

    The Server 2000 is setup to recognize the computers present and the users on the domain.

     

    All SP3 updated computers have no problems accessing data on the server, just not each other, shared, not shared or whatever. SP2, no problems sharing to other workstations.

     

    Monday, May 19, 2008 10:14 PM
  •  

    Evening Micheal

     Have you attempted to access the other Sp3 computer by clicking on start, run. Type the letters cmd. Press enter

    >_ ping your other computers?

     

    If you get an answer its not the networking. It may be something in group policy settings.

    Restart your computer. Log in as a FULL computer adminstrator. And then attempt to connect to another machine.

     

    If these users are going to be domain adminstrators.

     There is not problem in changing a user account from least adminstrator to full adminstrator.

     But using the fix mentioned in the Access denied posting.

       Downloading and using the subinacl.exe and the reset.cmd as posted.

     

    More then likely its the user account has access to at least adminstrator but not FULL adminstrator.

    Here is one resource from Microsoft.

     

    http://support.microsoft.com/default.aspx?scid=kb;en-us;251335

     

    Or if this is what you are looking for

    http://blogs.msdn.com/ts/archive/2007/04/19/how-to-enable-single-sign-on-for-my-terminal-server-connections.aspx

     

    If this doesnt answer your problem. Then please post back any additional questions or results. Thanks

     

    Cheers Keith

     

    edited in more then likely this is the answer to your problem. Seems to have been a known issue. And may also be fixed by downloading and installing dot net 1. sp1. if the following kb doesnt not totally fix your networking issues. please post back.

     

    http://support.microsoft.com/kb/951830

    Tuesday, May 20, 2008 4:31 AM
  • I checked each of the recommendations and none of those apply.

    I am able to ping any of the SP3 updated computers.

    All workstations have "joined the domain" and are able to access the server.

    What would have changed between SP2 (working fine) and SP3 (not)

    Also, see "myxer"s post from last week.

     

    Thanks,

     

    Michael

     

    Tuesday, May 20, 2008 7:11 PM
  • Is IPSec implemented in your domain policies? Can you try to acess SP3 machines after doing 'net stop policyagent' on both machines?

    Thanks,
    Satyendra
    Wednesday, May 21, 2008 11:49 AM
  • Is IPSec implemented in your domain policies? Can you try to acess SP3 machines after doing 'net stop policyagent' on both machines?

    Not applicable in my case. As I've said before, I think MS may have deliberately or inadvertantly altered the way authentication works between domain members and non-members. For me, provided that the machine viewing the PC with SP3 is a member of the same domain all is as before (SP3 was loaded). It's only when the machine is not in the same domain (but has credentials which previously worked).

    Wednesday, May 21, 2008 12:01 PM
  •  

    Try unsharing the resource before you upgrade. Once you upgrade to SP3 re-share the resource with the correct permissions.
    Wednesday, May 21, 2008 2:59 PM
  • Are you mapping drives using a script or does the computer remember the connection?  Are you putting the domain name in the username when connecting ("net use Z: \\someserver\someshare /user:me@mydomain.com" or "net use Z: \\someserver\someshare")?  I would try remapping drives using a fully qualified username and see if that helps any.

    Bill
    Wednesday, May 21, 2008 6:36 PM
  •  Bill Dewey wrote:
    Are you mapping drives using a script or does the computer remember the connection?  Are you putting the domain name in the username when connecting ("net use Z: \\someserver\someshare /user:me@mydomain.com" or "net use Z: \\someserver\someshare")?  I would try remapping drives using a fully qualified username and see if that helps any.

    Bill

     

    For instance, instructions for our employees go as follows:

     

    My Network Places-Entire Network-Microsoft Windows Network-Cherokeeinst (Our Domain)-

    Listed will be all of the Workstations as well as the server.

     

    Doubleclicking on anything other than the server produces the error mentioned in an earlier post.

    Except for one of the computers that has important shares, which has SP2 and is working fine.

     

    Wednesday, May 21, 2008 6:55 PM
  •  Bill Dewey wrote:
    Are you mapping drives using a script or does the computer remember the connection?  Are you putting the domain name in the username when connecting ("net use Z: \\someserver\someshare /user:me@mydomain.com" or "net use Z: \\someserver\someshare")?  I would try remapping drives using a fully qualified username and see if that helps any.

    Bill

     

    Nice idea, but in my case although the PC shows up My Network Places (where it should) I can neither "open" or view properties for the PC. Opening gets the "... no login servers..." message and properties get a "you are not authorised to access this resource..." message. This all worked prior to SP 3. So I've not even got as far as trying different permutations of the commands to attach to a share. I might give your ideas a shot anyway, just to gather a bit more evidence, but frankly I'm skeptical of it actually working.

    Wednesday, May 21, 2008 7:08 PM
  •  Chapmasj wrote:

     Bill Dewey wrote:
    Are you mapping drives using a script or does the computer remember the connection?  Are you putting the domain name in the username when connecting ("net use Z: \\someserver\someshare /user:me@mydomain.com" or "net use Z: \\someserver\someshare")?  I would try remapping drives using a fully qualified username and see if that helps any.

    Bill

     

    Nice idea, but in my case although the PC shows up My Network Places (where it should) I can neither "open" or view properties for the PC. Opening gets the "... no login servers..." message and properties get a "you are not authorised to access this resource..." message. This all worked prior to SP 3. So I've not even got as far as trying different permutations of the commands to attach to a share. I might give your ideas a shot anyway, just to gather a bit more evidence, but frankly I'm skeptical of it actually working.

     

    Wow, nearly the same posts at the same time. We must have the same problem....with the same update.

    Wednesday, May 21, 2008 7:23 PM
  • I've tried applying the patch KB951830 as suggested in the edit of a few posts ago with no success.  As for the mapping, all I'm doing is simply trying to connect to a shared drive I should be able to \\server\share and I get a network path not found. If I do it by IP address it's found fine.  When I do an ipconfig /all on SP2 I have the DNS Suffix Search List populated with our dns server.  After running the SP3 install and re-running ipconfig /all The DNS Suffix Search List is no longer listed at all.  Why does installing SP3 remove this field?  Remember this is on several test machines that are clean and have nothing else done to them other than to upgrade to SP3, so SP3 is changing something.  I appreciate all the help being put forward, but this is getting frustrating. thanks.
    Wednesday, May 21, 2008 7:28 PM
  •  myxer wrote:
    I've tried applying the patch KB951830 as suggested in the edit of a few posts ago with no success.  As for the mapping, all I'm doing is simply trying to connect to a shared drive I should be able to \\server\share and I get a network path not found. If I do it by IP address it's found fine.  When I do an ipconfig /all on SP2 I have the DNS Suffix Search List populated with our dns server.  After running the SP3 install and re-running ipconfig /all The DNS Suffix Search List is no longer listed at all.  Why does installing SP3 remove this field?  Remember this is on several test machines that are clean and have nothing else done to them other than to upgrade to SP3, so SP3 is changing something.  I appreciate all the help being put forward, but this is getting frustrating. thanks.

     

    Everything in ipconfig /all matches SP2 to SP3 with no change, but I still have my issue.

    Wednesday, May 21, 2008 7:48 PM
  • No reply to my suggestion have you tried it yet? Remove the shares, re-add the shares with the correct permissions once you have applied SP3.

     

    Wednesday, May 21, 2008 7:48 PM
  • The shares were not there to begin with unfortunately for me to remove them.  I'm simply typing into the Run bar the path for the share and I'm receiving this issue. Even simply pinging known server names gives a could not find host.
    Wednesday, May 21, 2008 7:52 PM
  •  djenkins83 wrote:
    No reply to my suggestion have you tried it yet? Remove the shares, re-add the shares with the correct permissions once you have applied SP3.

     

     

    I will be trying that this evening. The computer I can "experiment" on is occupied until then.

    Wednesday, May 21, 2008 8:05 PM
  •  djenkins83 wrote:
    No reply to my suggestion have you tried it yet? Remove the shares, re-add the shares with the correct permissions once you have applied SP3.

     

     

    Tried it now. I've used each of the permutations of the NET USE command. I've used the GUI and I've even tried the admin shares C$ and D$ - always the same result "There are currently no logon servers available to service the logon request. Like I said, I think MS has changed the way XP SP3 responds to a PC which is not in the same domain (or is in no domain at all).

    Thursday, May 22, 2008 12:10 AM
  •  

    Evening all

      Found this a few weeks ago. Didnt think it would fit this problem but its worth a try.

     

    http://blogs.technet.com/aralves/archive/2008/03/31/group-policies-preferences-client-side-extensions.aspx

     

    As covered here

     

    http://gomicrosoft.com/fwlink/LinkId=103735

     

    Going to attempt using this on my production system tonight and see if fixes some other problems also

     

    Cheers

    Keith

    Thursday, May 22, 2008 2:43 AM
  • Has anyone had any luck with this? I'm still searching for a reason why installing SP3 removes our DNS from the DNS Suffix Search List.
    Monday, May 26, 2008 5:43 PM
  •  Chapmasj wrote:
    always the same result "There are currently no logon servers available to service the logon request."

    Open "System Properties", tab "Computer Name", click button "Change".  Ensure that "Workgroup" is selected, and not "Domain".

    Monday, May 26, 2008 6:59 PM
  •  rdhw wrote:

     Chapmasj wrote:
    always the same result "There are currently no logon servers available to service the logon request."

    Open "System Properties", tab "Computer Name", click button "Change".  Ensure that "Workgroup" is selected, and not "Domain".

     

    Thanks for the suggestion, unfortunately it misses the point. It worked before SP3 was applied, it doesn't work now. I don't want to have to take my computers out of the domain (as it's not a practical option for me). What I'm looking for is ideally a fix which gives me back what I had before or at the least an explanation of what has been changed with SP3 to cause this effect and why it is now no longer possible.

    Tuesday, May 27, 2008 10:09 AM
  •  Chapmasj wrote:
    Thanks for the suggestion, unfortunately it misses the point. It worked before SP3 was applied, it doesn't work now. I don't want to have to take my computers out of the domain (as it's not a practical option for me).

    Yes, but does it work if you try?  We are trying to find out where the problem is.  Can you connect to the resource in a non-domain way, by quoting username and password?

    What I'm looking for is ideally a fix which gives me back what I had before or at the least an explanation of what has been changed with SP3 to cause this effect and why it is now no longer possible.

    Well, one thing that SP3 might do is mess with firewall settings.  The failure to find a logon server might be because the client has a firewall blocking the replies from the logon servers.

     

    Also, if the client gets its IP configuration from DHCP, can you check whether that phase is succeeding properly?

     

    Can you put a packet sniffer (e.g. Wireshark) on a test client to establish what is going wrong in the various exchanges with the various servers concerned?

    Tuesday, May 27, 2008 11:45 AM
  • With mine, each of the workstation users are logging on to the workstation they are on when booting up, then when the server resources are accessed initially, the login name/password are used, known by the domain and then "remembered". That is still functioning properly. It's when one workstation is accessed by another, there is no login name/password option or opportunity like before.......

     

    Tuesday, May 27, 2008 1:21 PM
  • Let me first be clear abt the common problem people are facing here. It is that after upgrading to SP3, the machine is not accessible from machines outside the domain which used to work previously with SP2 and vice-versa is not true. Everything works fine if we use the ip address?The machine you are accessing from is a sp2 or sp3 machine? Can you send the output of 'ipconfig /all' of the sp3 machine that is not accessible and also the sp2 machine from which you are accessing it and a little about the network architecture to karthik.viswanathan[at]microsoft.com that will help us unblock.


    Thanks
     Karthik V
    Friday, May 30, 2008 11:14 AM
  •  karthiram [MSFT] wrote:

    Let me first be clear abt the common problem people are facing here. It is that after upgrading to SP3, the machine is not accessible from machines outside the domain which used to work previously with SP2

     

    Exactly. In my case there is the added twist is that this is happening when the domain member machine is not on a network which is accessible from the domain and obviously local verification of credentials is being used. A typical scenario of this type is a work laptop which is used as part of a domain in the office and is used in a workgroup environment when at home.

     

     karthiram [MSFT] wrote:

    . Everything works fine if we use the ip address?

     

    Nope, using the IP address makes no difference. Interestingly one can reach the machine and log on using Remote Desktop and it appears in "my networlk places" as before but getting "properties" of the machine fails (as of course does reaching shares).  Machine responds to ping (as before) by name or IP address. I don't believe it's a IP networking issue. I think it is all about authentication.

     

     karthiram [MSFT] wrote:

    The machine you are accessing from is a sp2 or sp3 machine?

     

    SP2, SP3, W2K SP4 - all the same. I've even tried it with two PC's (with SP3) which are normally both part of the same domain, even they cannot reach each other (and they could before.

     

    Here is my theory: Domain member machines pre SP3 may try to authenticate with domain first and if the DC (or domain  as a whole) are not reachable, will attempt to authenticate using a local account (this is assuming of course that their is a local and domain  account) Post SP3 the domain member tries to authenticate with domain only and does not try any local accounts.

    Friday, May 30, 2008 11:55 AM
  • Thank you for this post. This is what I've been seeing and trying to say, but you said it in

    a way that I never could.

     

     

     

     Chapmasj wrote:

     

    Exactly. In my case there is the added twist is that this is happening when the domain member machine is not on a network which is accessible from the domain and obviously local verification of credentials is being used. A typical scenario of this type is a work laptop which is used as part of a domain in the office and is used in a workgroup environment when at home.

     

    Nope, using the IP address makes no difference. Interestingly one can reach the machine and log on using Remote Desktop and it appears in "my networlk places" as before but getting "properties" of the machine fails (as of course does reaching shares).  Machine responds to ping (as before) by name or IP address. I don't believe it's a IP networking issue. I think it is all about authentication.

     

    SP2, SP3, W2K SP4 - all the same. I've even tried it with two PC's (with SP3) which are normally both part of the same domain, even they cannot reach each other (and they could before.

     

    Here is my theory: Domain member machines pre SP3 may try to authenticate with domain first and if the DC (or domain  as a whole) are not reachable, will attempt to authenticate using a local account (this is assuming of course that their is a local and domain  account) Post SP3 the domain member tries to authenticate with domain only and does not try any local accounts.

    Friday, May 30, 2008 12:56 PM
  • Evening

     Micheal, Cherokee

      There is a partial fix posted by microsoft for DNS shares. Mighe help reduce the amount of problems, you all are experiening.

    http://www.microsoft.com/downloads/details.aspx?FamilyId=3262D5BE-EB48-4FB1-AB4A-AF9F22F40166&displaylang=en

     

      My guess is there is a bit more to this problem with proper rigstery edits. But hey this at least looks promising!

    I have a few resources I have downloaded that are suppost to be helpfull with registery edits. But I do not have your alls environment. And will be doing some more research tonight.

     

    Oh and you dual booters Ati has released a 8.6 vista  beta for all versions *x32 x64*. Not quite stable yet. But does promise some improvement!

     

    Cheers Keith

    Monday, June 02, 2008 5:54 AM
  •  rdhw wrote:

     Chapmasj wrote:
    Thanks for the suggestion, unfortunately it misses the point. It worked before SP3 was applied, it doesn't work now. I don't want to have to take my computers out of the domain (as it's not a practical option for me).

    Yes, but does it work if you try?  We are trying to find out where the problem is.  Can you connect to the resource in a non-domain way, by quoting username and password?

     

    Sorry it's taken me a while to get back on this (been away). I tried taking the machine out of the domain and surprise, surprise it becomes accessible. I'm now pretty convinced this problem is about authentication rather than networking.

     

    What I'm looking for is ideally a fix which gives me back what I had before or at the least an explanation of what has been changed with SP3 to cause this effect and why it is now no longer possible.

     rdhw wrote:

     

    Well, one thing that SP3 might do is mess with firewall settings.  The failure to find a logon server might be because the client has a firewall blocking the replies from the logon servers.

     

    Also, if the client gets its IP configuration from DHCP, can you check whether that phase is succeeding properly?

     

    Can you put a packet sniffer (e.g. Wireshark) on a test client to establish what is going wrong in the various exchanges with the various servers concerned?

     

    This is happening in a situation where there is no access to domain logon servers (and it's not unexpected/unintended).

     

    Consider as the typical scenario: Work domain member laptop being used in home office and not connected to work domain via a VPN, attempt to connect with share on this machine from one of the home office machines. It's a situation that the machine coped with (authentication using a local account rather than a domain account) pre-SP 3, but does not handle now.

    Monday, June 02, 2008 9:11 AM
  •  1stknight wrote:

    Evening

     Micheal, Cherokee

      There is a partial fix posted by microsoft for DNS shares. Mighe help reduce the amount of problems, you all are experiening.

    http://www.microsoft.com/downloads/details.aspx?FamilyId=3262D5BE-EB48-4FB1-AB4A-AF9F22F40166&displaylang=en

     

      My guess is there is a bit more to this problem with proper rigstery edits. But hey this at least looks promising!

    I have a few resources I have downloaded that are suppost to be helpfull with registery edits. But I do not have your alls environment. And will be doing some more research tonight.

     

    Oh and you dual booters Ati has released a 8.6 vista  beta for all versions *x32 x64*. Not quite stable yet. But does promise some improvement!

     

    Cheers Keith

     

     

    Nope, no effect at all.............

    Monday, June 02, 2008 1:18 PM
  •  Chapmasj wrote:
     

     

    Sorry it's taken me a while to get back on this (been away). I tried taking the machine out of the domain and surprise, surprise it becomes accessible. I'm now pretty convinced this problem is about authentication rather than networking.

     

    This is happening in a situation where there is no access to domain logon servers (and it's not unexpected/unintended).

     

    Consider as the typical scenario: Work domain member laptop being used in home office and not connected to work domain via a VPN, attempt to connect with share on this machine from one of the home office machines. It's a situation that the machine coped with (authentication using a local account rather than a domain account) pre-SP 3, but does not handle now.

     

    Exactly. I tried what you did, same results. Taking anything out of the domain, not practical.

    Monday, June 02, 2008 1:32 PM
  • Michael,

     

    I'm having the same problem as you in my home network (with XP Professional machines). The only difference is that I don't have a server domain (just Workgroup network). DHCP served by a Wireless Router DLink DIR-655.

    All used to work fine with XP Professional SP2.

    Cannot access shared resources after SP3.

    Can ping all the other machines. But can't access throught Network Places.

    When trying to browse My Network Places to access shared resources I got the error message \\MachineName is not accessible. You might not have permissions to use this resource. Contact the administrator of this server to find out if you have access permissions.

    If you get any useful solution, please let me know.

     

    JPGabarra

    Saturday, June 07, 2008 3:38 PM
  • I had a very similar problem and solved it by re-enabling Full Control permissions for the Shared Documents folder to the Everyone account.

     

    Details of what got me to do this can be found at:

    http://support.microsoft.com/kb/897103/en-us?FR=1&PA=1&SD=HSCH

     

    Everything now works fine - all shared folders are accessible to all machines on the network.

    Saturday, June 07, 2008 4:17 PM
  •  eejaybee wrote:

    I had a very similar problem and solved it by re-enabling Full Control permissions for the Shared Documents folder to the Everyone account.

     

    Details of what got me to do this can be found at:

    http://support.microsoft.com/kb/897103/en-us?FR=1&PA=1&SD=HSCH

     

    Everything now works fine - all shared folders are accessible to all machines on the network.

     

    Thanks for posting the idea, unfortunately it seems to be a the solution to another problem - didn't solve this one for me.

    Monday, June 09, 2008 2:30 AM
  •  JPGabarra wrote:

    Michael,

     

    I'm having the same problem as you in my home network (with XP Professional machines). The only difference is that I don't have a server domain (just Workgroup network). DHCP served by a Wireless Router DLink DIR-655.

    All used to work fine with XP Professional SP2.

    Cannot access shared resources after SP3.

    Can ping all the other machines. But can't access throught Network Places.

    When trying to browse My Network Places to access shared resources I got the error message \\MachineName is not accessible. You might not have permissions to use this resource. Contact the administrator of this server to find out if you have access permissions.

    If you get any useful solution, please let me know.

     

    JPGabarra

     

    Your symptoms certainly seem to tally with mine. You say this is a home network, have any of the machines ever been part of a domain (perhaps in the in the past)? My machines which have SP 3 and are not domain members are fine; it's just those which are in a domain that have a problem. Although when the machines are connected into a network where the domain (and one or more DC) are reachable other members of the domain can access as before (SP 3 was installed) - some are XP (with and without SP 3), others are W2K.

    Monday, June 09, 2008 2:44 AM
  • I do not know if either is relevant but, in an attempt to help the process along, can I throw in a couple of wild cards that might, or might not, provide some "out of the box" thoughts on getting this problem closer to a resolution:

     

    http://support.microsoft.com/kb/946937/en-us

    "Network Location Cannot be Reached" when accessing shares

     

    and

     

    http://support.microsoft.com/kb/297278/en-us

    Authentication May Still Be Required When You Use Cached Credentials

     

    If these are a waste of time, sorry, but I thought that I would give it a go.

     

    Best of luck

    Monday, June 09, 2008 1:15 PM
  •  eejaybee wrote:

    I do not know if either is relevant but, in an attempt to help the process along, can I throw in a couple of wild cards that might, or might not, provide some "out of the box" thoughts on getting this problem closer to a resolution:

     

    http://support.microsoft.com/kb/946937/en-us

    "Network Location Cannot be Reached" when accessing shares

     

    and

     

    http://support.microsoft.com/kb/297278/en-us

    Authentication May Still Be Required When You Use Cached Credentials

     

    If these are a waste of time, sorry, but I thought that I would give it a go.

     

    Best of luck

     

    First was not relevent (for my issue), second one was and it got me thinking. It appears that username has become case sensitive (I don't think it was before), perhaps not in all circumstances but certainly in this specific context. It looks like I have a fix! Thanks very much.

     

    I'd be very interested to know what has changed and why (anyone from MS care to comment?), but it looks like this one has been nailed. I'll do a bit more testing to be sure and will post back results in the next day or so (I'm a bit too busy to devote a lot of time to it right now).

    Monday, June 09, 2008 2:28 PM
  • Unfortunately this does not solve my issue of the DNS suffix reg entry being removed from the registry. I found this article that might be a possible reason why this is occuring as it does fit our company profile of domain.xx.xxx.  So what I am wondering is if SP3 in some way changes the DNS suffix to fix this security flaw. Can anyone confirm this.

    http://www.microsoft.com/technet/security/advisory/945713.mspx

    Monday, June 09, 2008 7:20 PM
  •  Chapmasj wrote:

    First was not relevent (for my issue), second one was and it got me thinking. It appears that username has become case sensitive (I don't think it was before), perhaps not in all circumstances but certainly in this specific context. It looks like I have a fix! Thanks very much.

     

    I'd be very interested to know what has changed and why (anyone from MS care to comment?), but it looks like this one has been nailed. I'll do a bit more testing to be sure and will post back results in the next day or so (I'm a bit too busy to devote a lot of time to it right now).

     

    Looks like I jumped to the wrong conclusion - although it did work, it wasn't because of case sensitivity. It certainly does seem to be something to do with caching credentials and failing to authenticate. If the credentials are explicitly entered in the "Connect using a different user name" in Map Network Drive it works, but if the mapping is removed (i.e. non-persistent mapping) then the credentials need to be explicitly re-entered again.  I must admit, I'm slightly confused by the behaviour at the moment; I'll explore a little more and hopefully at least be able to describe the symptoms more clearly.

     

    Sorry to have raised a spurious explanation, hope I didn't waste anyone's time because of it.

     

    Tuesday, June 10, 2008 2:55 AM
  • Here is my theory: Domain member machines pre SP3 may try to authenticate with domain first and if the DC (or domain  as a whole) are not reachable, will attempt to authenticate using a local account (this is assuming of course that their is a local and domain  account) Post SP3 the domain member tries to authenticate with domain only and does not try any local accounts.

    I agree with this assessment.  My non-domain machines can access shares on my domain machine when it is attached to the lan with the domain controller or when it is vpn'ed into the lan with the domain controller, but not when the machine is isolated from the domain.

     

    It appears that under SP3 if the authentication cannot reach the DC, it fails and gives the 'no logon servers...' message.  This is different from SP2 and a big step backward.

    Tuesday, June 10, 2008 12:48 PM
  • Is Microsoft aware of this problem?  Is there a plan to produce a hotfix to correct the coding error?

     

    Wednesday, June 11, 2008 4:19 PM
  • I have downgraded to SP2 until this gets fixed.

     

    Thursday, June 12, 2008 1:38 PM
  • Well, after not being able to find my own work around and not finding any help on the web that solved our issues, I've submitted to MS the problem along with our network captures etc etc etc.  I was told that this was something that hadn't been seen yet, and so they are going to be looking at it further to find out what's going on.  If something comes of it, I will post it here.
    Monday, June 16, 2008 5:57 PM
  • Good. Thanks myxer. It looks like I was right in my guess that this change was inadvertent. As I've seen for myself, once access to the share is re-established it works, at least until the access (to the share) is deliberately taken down, very odd. I'll watch out for progress with interest.

     

    Monday, June 16, 2008 6:37 PM
  • Thanks from me too, myxer. (Even though I've heard the "Oh, we've never seen/heard of that!" from

    manufacturers in the past). Please don't forget us......

    Monday, June 16, 2008 7:36 PM
  •  Michael @ Cherokee wrote:

    Thanks from me too, myxer. (Even though I've heard the "Oh, we've never seen/heard of that!" from

    manufacturers in the past). Please don't forget us......

     

    I can resonate with your scepticism (as a generality), but I find the admission that they knew nothing about it very plausible in this case. Let's hope that we've given them all the information they need to identify the source of our trouble and provide a prompt resolution. Oi Ballmer, got any interesting fixes for patch Tuesday?

    Monday, June 16, 2008 8:10 PM
  •  DonGolden wrote:

    Here is my theory: Domain member machines pre SP3 may try to authenticate with domain first and if the DC (or domain  as a whole) are not reachable, will attempt to authenticate using a local account (this is assuming of course that their is a local and domain  account) Post SP3 the domain member tries to authenticate with domain only and does not try any local accounts.

    I agree with this assessment.  My non-domain machines can access shares on my domain machine when it is attached to the lan with the domain controller or when it is vpn'ed into the lan with the domain controller, but not when the machine is isolated from the domain.

     

    It appears that under SP3 if the authentication cannot reach the DC, it fails and gives the 'no logon servers...' message.  This is different from SP2 and a big step backward.



    Yes there is a problem with the way SP3 handles authentication in this particular scenario. We are continuing to investigate the complete extent problem  at the moment. There are three possible workarounds that you can try based on your setup.


    Workaround -1:

    Remove the Sp3 box from the Domain & join it to Workgroup. Workaround works but might not be practical in all scenarios- Yes I know- But its a workaround- So just wanted to put it out there. users cannot rejoin Sp3 box to Domain unless DC is reachable again & may require IT desk support to do so again.


    Workaround -2:

                    Use Domain credentials to ‘net use’ to the share (Start->Run->\\<share-name> still fails with No Logon Servers). Workaround works as the user is authenticated using the cached credentials (assuming that user creds are present in the local cache given the machine is joined to Domain & user might have logged on in past); the cache persists across reboots. However it is required that the Domain User, whose credentials are being used to ‘net use’, be logged-on interactively on the Sp3 box (the machine can be in locked state).

     

    Workaround -3:

                    While trying to ‘net use’ using local user credentials, supply the Sp3 machine name as the domain name for that local user (<Sp3-machine-name>\<local-user>); e.g. “devbox01\testuser” where “devbox01” is the name of the Sp3 machine & “testuser” is the local user present on the Sp3 box. Note Start->Run->\\<share-name> won’t work & will fail with No Logon Servers with this workaround as well. The user needs to ‘net use’ to access the share. This works because we are able to bypass the Domain guessing logic implemented in Netlogon by supplying the machine name where SAM validation should happen.

     

    Let me know which one of these worked for you.

    Thanks
    J.
    Wednesday, June 18, 2008 12:13 PM
  •  msft-jayaramk wrote:


    Yes there is a problem with the way SP3 handles authentication in this particular scenario. We are continuing to investigate the complete extent problem  at the moment. There are three possible workarounds that you can try based on your setup.


    Workaround -1:

    Remove the Sp3 box from the Domain & join it to Workgroup. Workaround works but might not be practical in all scenarios- Yes I know- But its a workaround- So just wanted to put it out there. users cannot rejoin Sp3 box to Domain unless DC is reachable again & may require IT desk support to do so again.

     

    I can confirm that workaround 1 does work (well for me anyway). As you say, it is not practical since it requires the PC to be taken out of the domain.


     msft-jayaramk wrote:

    Workaround -2:

                    Use Domain credentials to ‘net use’ to the share (Start->Run->\\<share-name> still fails with No Logon Servers). Workaround works as the user is authenticated using the cached credentials (assuming that user creds are present in the local cache given the machine is joined to Domain & user might have logged on in past); the cache persists across reboots. However it is required that the Domain User, whose credentials are being used to ‘net use’, be logged-on interactively on the Sp3 box (the machine can be in locked state).

     

    Just tried this and I can confirm that it works.

     

     

     msft-jayaramk wrote:

     

    Workaround -3:

                    While trying to ‘net use’ using local user credentials, supply the Sp3 machine name as the domain name for that local user (<Sp3-machine-name>\<local-user>); e.g. “devbox01\testuser” where “devbox01” is the name of the Sp3 machine & “testuser” is the local user present on the Sp3 box. Note Start->Run->\\<share-name> won’t work & will fail with No Logon Servers with this workaround as well. The user needs to ‘net use’ to access the share. This works because we are able to bypass the Domain guessing logic implemented in Netlogon by supplying the machine name where SAM validation should happen.

     

    Yep, this one also works for me, I actually did this via the GUI (map network drive) - but the login as a different user details have to be "refreshed" each time that the mapping has to be remade. That was when I went up a blind alley thinking that case sensitivity was involved (it isn't). I've reused it since successful.

     

    Wednesday, June 18, 2008 3:45 PM
  •  

    Workaround -1:

    Remove the Sp3 box from the Domain & join it to Workgroup. Workaround works but might not be practical in all scenarios- Yes I know- But its a workaround- So just wanted to put it out there. users cannot rejoin Sp3 box to Domain unless DC is reachable again & may require IT desk support to do so again.

     

     

    This is infeasible for me since the SP3 box is my company issued laptop which must be on the domain for other reasons.


    Workaround -2:

                    Use Domain credentials to ‘net use’ to the share (Start->Run->\\<share-name> still fails with No Logon Servers). Workaround works as the user is authenticated using the cached credentials (assuming that user creds are present in the local cache given the machine is joined to Domain & user might have logged on in past); the cache persists across reboots. However it is required that the Domain User, whose credentials are being used to ‘net use’, be logged-on interactively on the Sp3 box (the machine can be in locked state).

     

    This is infeasible for me - it would mean sharing domain credentials with nono=-domanin personnel.

     

    Workaround -3:

                    While trying to ‘net use’ using local user credentials, supply the Sp3 machine name as the domain name for that local user (<Sp3-machine-name>\<local-user>); e.g. “devbox01\testuser” where “devbox01” is the name of the Sp3 machine & “testuser” is the local user present on the Sp3 box. Note Start->Run->\\<share-name> won’t work & will fail with No Logon Servers with this workaround as well. The user needs to ‘net use’ to access the share. This works because we are able to bypass the Domain guessing logic implemented in Netlogon by supplying the machine name where SAM validation should happen.

     

    This is how I did the authentication under SP3 (credentials wise) howeverI cannot test this with the net use because I have downgraded my machine to SP2.  I really need to have this work 'correctly' because I apply this technique widely.  In my opinon, the authentication should not fail when it cannot find a domain controller, but try local credentials before bailing.

    Wednesday, June 18, 2008 8:33 PM
  • After a bunch of trial and errors with MS (gotta admit, quite impressed with their deligence and customer communication on this one - good job Vishal).  It looks like it's been fixed for us, it looks like some amendements were made to an existing hot fix, the link is here. http://support.microsoft.com/kb/953761/en-us Revision was done yesterday, tested it today and it fixed our systems so that we are no longer having issues connecting our shared drives. Hope it helps others.
    Tuesday, June 24, 2008 6:34 PM
  •  myxer wrote:
    After a bunch of trial and errors with MS (gotta admit, quite impressed with their deligence and customer communication on this one - good job Vishal).  It looks like it's been fixed for us, it looks like some amendements were made to an existing hot fix, the link is here. http://support.microsoft.com/kb/953761/en-us Revision was done yesterday, tested it today and it fixed our systems so that we are no longer having issues connecting our shared drives. Hope it helps others.

     

    Well, I downloaded the hotfix, tried it on two machines, but unfortunately it made no difference at all. Any chance the wrong hotfix has been quoted? It did not mention this problem (which I thought was surprising) on the hotfix web page, only a reference to a DHCP problem.

    Tuesday, July 01, 2008 1:14 AM
  • I too have this problem at a remote site, and think it could become an issue with Laptops.

     

    This is not the "DHCP error", but a problem in using local credentials to access network resources on Windows XP SP3 machines that are members of a domain, but are not able to communicate with the domain, previously in SP2 it would try to contact a DC, then use local credentials, in SP3 it does not try local credentials and errors.

     

    After submiting network captures, and explaining the issue, Microsoft Support came back to say it is a behavioural change in XP SP3 to more "secure", (although, workaround C above works for me, and with a little logon scripting will have to be the workaround we use in production) however if there is Business justification by customer demand, they will issue a hotfix to correct it, although I think they should make it an option in Local Security Policy and controllable via Group Policy if they're concerned about Security and give Network Admins the choice to enable or disable per groups of computers (what they should have done and not just changed it without a thought for those setups that may use it).

     

    So, if anyone is still reading this or discovered this problem recently and reading this thread for the first time, you're not alone, contact Microsoft via https://support.microsoft.com/oas/default.aspx?ln=en-gb&prid=11273&gprid=522131 (free) and point them to this thread, and say it's been raised previously, you want to register your interest in a corrective hotfix.

     

    If it help, my case number was SRQ080709600393 if they're unsure what you're talking about.

     

    If there are enough requests, they'll make and release it.

     

    Andrew Stevens

    General Vending Services Ltd

    Friday, July 11, 2008 2:05 PM
  •  GVSLTD wrote:

    After submiting network captures, and explaining the issue, Microsoft Support came back to say it is a behavioural change in XP SP3 to more "secure",

     

     

    If it was a planned "enhancement" why was it not documented and publicised by Microsoft as such in advance of the release of SP3..

     

    As you can see, there are number of people who have "discovered"  this feature and are not impressed. Microsoft have "supplied" a fix which certainly does not work for me.

     

    Even if this is increased security - which I would dispute - it was an unwelcome surprise.To me it remains as a bug..

    Friday, July 11, 2008 2:43 PM
  • I've been quickly following this thread because I am having the same problem, but I run Vista, so I have not installed XP SP3. I did install Vista SP1 about a week ago, but I didn't have any problems, until a a XP user pointed it out 2 days ago.

     

    Since it was mentioned that using the IP address works, I though it maybe related to DNS running on our server. A DNS update was issued right around when the problem started, I am trying to determine if that is the cuause.

     

    Any thoughts?

     

    Saturday, July 12, 2008 6:15 PM
  •  David Held wrote:
    I am having the same problem

    The same as what? Please describe your problem carefully. Please say what works, and what exactly does not work.  Give the operating system version of both client and server, including service pack level.  Is either client or server on a Domain?

    Saturday, July 12, 2008 6:29 PM
  • Hello

    We have experienced the same issue; thanks to you all for such an informative thread.

    How to quickly summarize this problem is my problem right now <g>.

     

    P2P users on laptops began having the message recently:

    (computer name) "is not accessible. You might not have permission to use this resource. Contact the administrator of this server to find out if you have access permissions.

    There are currently no logon servers available to service the logon request."

    We have exactly the same situation as many here; domain laptop users, working out of the office, logged in to Windows XP Pro locally.  The scenario worked well in the spring, now has stopped working.

    We figured that SP3 was the logical issue, then when we began to uninstall SP3, we received dire warnings that many of our other apps may have problems.  That was a little scary, so we cancelled the uninstall and called Microsoft support.  Note: if you mention the magical phrase "SP3" you get the support for free.

     

    Well, 6 hours later (yes, 6) we had been through the usual culprits: uninstall Symantec AV (lots of blame always goes to this vendor first), disable Windows defender and firewall, let MS download some tracing software.  I kept mentioning this thread, and I asked many times if we could stop the "needle in a haystack" and just uninstall SP3.  But my MS rep seemed very determined to make it work, even though this thread summarized that there was no fix.

    During the 5th hour, while still on phone support with the MS rep, I followed this advice from this thread and went to the site:

    "So, if anyone is still reading this or discovered this problem recently and reading this thread for the first time, you're not alone, contact Microsoft via https://support.microsoft.com/oas/default.aspx?ln=en-gb&prid=11273&gprid=522131 (free) and point them to this thread, and say it's been raised previously, you want to register your interest in a corrective hotfix.

    If it help, my case number was SRQ080709600393 if they're unsure what you're talking about."

     

    I submitted a new request, quoted the above case number, explained what was happening, and provided my case number assigned to me by the MS rep currently on the phone.  Sent it on it's way and got a verify email that they had received my request.

    Guess what happened next?  Shortly after the email request, my MS rep on the phone said she had found new research on my issue, and that it is a "known bug" (yup, she really said those words) and there is currently no good fix except to uninstall SP3.  And, she said that you can ignore the warnings that are produced by the uninstall because "they are just warnings".

     

    Now, I do appreciate her time and tenacity.  But what prevented her from knowing about that bug right from the beginning of my call?  Why could I find it on the web, bring it to her attention, and yet she could not find out anything in the MS internal knowledgebase?  I find the entire scenario extremely frustrating.

     

    We are not a huge company, but time is time.  And we have wasted many hours on this issue.  And now we must spend time on uninstalling SP3 from 15 laptops and hope that no other apps are affected.  I will post again if I find anything new.

     

    Thanks so much for this forum and all the good input

    TECHDLS

    Friday, August 22, 2008 6:13 PM
  •  TECHDLS wrote:
    Thanks so much for this forum and all the good input

    ... and thank you, TECHDLS, for sticking with this with such tenacity.  Please let us know of any developments.

    Friday, August 22, 2008 10:09 PM
  •  TECHDLS wrote:

    Hello

    We have experienced the same issue; thanks to you all for such an informative thread.

     

    Interesting.

     

    As part of the diagnostic process did the Microsoft rep ask you to try installing this hot fix:

     

    http://support.microsoft.com/kb/953761/en-us

     

    It is referenced earlier in this thread by myxer on 24 Jun 2008, 6:34 PM UTC.

     

    myxer claims it worked, I tried it on two machines and it worked on neither. It appears that Microsoft themselves acknowledge that it is "caused" by SP3, is a bug and the only work around is either not to install SP3 (not a good idea in the long run) or to uninstall SP3 (and hope nothing breaks; not good in the long run either).

     

    For Microsoft to pass this off as an "enhancement" only has credibility if it was documented before the event (e.g. in the release notes or list of bug fixes for SP3). I'm glad to hear that Microsoft did not try to fob you off with the "enhancement" excuse; credit to them for that.

     

     Thanks to you for taking the trouble to document your experience. Hopefully it will at the very least remind Microsoft that there are a number of people still seeking a fix for this issue.

    Friday, August 22, 2008 11:57 PM
  •  

    Yes, Microsoft asked me to install

    http://support.microsoft.com/kb/953761/en-us

     

     

    Did no good.

     

    The issue is that the SP3 authentication has been 'improved' and it no longer accepts ip-address qualified credentials.

    Saturday, August 23, 2008 11:42 AM
  • The Microsoft rep did not ask me to install that hot fix http://support.microsoft.com/kb/953761/en-us

    She just admitted (after 6 hours) that it was bug; apparently not known to her.
    Saturday, August 23, 2008 5:00 PM
  • I know it was the XP SP3 install, because uninstalling SP3 made the problem go away.  Maybe SP3 changed two of the six computers in the workgroup so that the workgroup name became a domain name.  Or maybe those two computers always had the computer in a domain by the same name instead of the workgroup, and SP3 just tightened the requirements so the inconsistency had consequences that mattered.  Chapmasj's post pointed me to the correct place.  I changed the two computers that couldn't share resources any more to be workgroup members, not domain members.  Then I reapplied SP3.  The computers remained workgroup computers and things are working the way they used to be.  Whew!  Thanks!
    Sunday, August 31, 2008 9:15 PM
  • This happened to me recently and thanks to this thread, it point us to SP3 and uninstall it.  The shares worked fine as before.

     

    However SP3 will be good to have.  I'm not sure if there's a permanent fix on this. 

     

    Any ideas? Thanks!

    Thursday, September 25, 2008 1:14 PM
  •  

    Please see my earlier post:

     

     GVSLTD wrote:

    I too have this problem at a remote site, and think it could become an issue with Laptops.

     

    This is not the "DHCP error", but a problem in using local credentials to access network resources on Windows XP SP3 machines that are members of a domain, but are not able to communicate with the domain, previously in SP2 it would try to contact a DC, then use local credentials, in SP3 it does not try local credentials and errors.

     

    After submiting network captures, and explaining the issue, Microsoft Support came back to say it is a behavioural change in XP SP3 to more "secure", (although, workaround C above works for me, and with a little logon scripting will have to be the workaround we use in production) however if there is Business justification by customer demand, they will issue a hotfix to correct it, although I think they should make it an option in Local Security Policy and controllable via Group Policy if they're concerned about Security and give Network Admins the choice to enable or disable per groups of computers (what they should have done and not just changed it without a thought for those setups that may use it).

     

    So, if anyone is still reading this or discovered this problem recently and reading this thread for the first time, you're not alone, contact Microsoft via https://support.microsoft.com/oas/default.aspx?ln=en-gb&prid=11273&gprid=522131 (free) and point them to this thread, and say it's been raised previously, you want to register your interest in a corrective hotfix.

     

    If it help, my case number was SRQ080709600393 if they're unsure what you're talking about.

     

    If there are enough requests, they'll make and release it.

     

    Andrew Stevens

    General Vending Services Ltd

    Thursday, September 25, 2008 1:23 PM
  • Hi all,

    I had the same issues on myb computers.
    So I talked to a very friendly microsoft supportguy.
    He told me that a fix will be released in march 2009.
    That's a very long time.
    So he unofficialy informed me about a simple workaround.
    Replacing the netlogon.dll with the one of servicepack 2 will do it.
    And it did for me !!!!
    Hope it works for you too.

    René.
    Friday, December 26, 2008 12:50 PM
  • Friday, January 23, 2009 12:42 PM
  • I just spent the last two hours trying to get hold of this Hot fix.  As it is not public, you cannot download it.  If someone knows of a location ;) please post.  I have opened a case with MS (866) 234-6020.  They took my information and said they will call me back. Xfingers. 
    Friday, February 20, 2009 4:34 PM
  • Drew, there is a link at the head of the KB article "View and request hotfix downloads".  What went wrong when you used that link to request the hotfix?  It has always worked for me.
    Robin Walker
    Friday, February 20, 2009 4:40 PM
  •  The KB article has no public hotfixes. Please contact support if you need immediate assistance.
    Friday, February 20, 2009 4:43 PM
  • Also, when I was on the phone with MS, the first guy could not help me.  He transferred me to a "Knowledge Professional" or something.  He found the fix on his system but could not access it.  He said he had to elevated to another group. 

    I also opened a Chat Session as well hoping to find another avenue to the file.  He had the same issue.  It is only a dll. 
    Friday, February 20, 2009 4:48 PM
  • Drew, it looks like either that hotfix has been pulled from distribution, or that the hotfix request mechanism is temporarily broken.  You might be able to find old copies of it by searching for "WindowsXP-KB961853-x86-ENU.exe"
    Robin Walker
    Friday, February 20, 2009 4:59 PM
  • MS just called me.  They pulled the hotfix for further testing.  I was told it will be released back to the public within a week or two.
    Friday, February 20, 2009 5:29 PM
  • Robin,

    Pulling the hotfix is Microsoft policy I think.

    In a while we are all forced to apply SP3.

    So, the lazy people who didn't upgrade yet, will be forced to install SP3 with MS-update.

    Hopefully a real fix will be applied in this version.

    On the other hand there is a really simple solution given to me by a Microsoft tech guy.

    Replace the netlogon.dll with the one from SP2.

    All problems solved!

    Note: I have the English version of the hotfix, but I don't try to install it (If its not broken, don't repair it).
    Also a SP2 netlogon is available.
    If you want to have one of them, send me an E-Mail

    Friday, February 20, 2009 5:51 PM
  • MS release Version 2 of the HotFix.  The first version which was released in January was pulled.  The new version is WindowsXP-KB961853-v2-x86-ENU and can be "now" downloaded from article http://support.microsoft.com/kb/961853/.

    Monday, February 23, 2009 3:12 PM
  • Also... when you go to request it for download, it shows under release "sp4."  I assume this means it will be included in SP4 for XP. ???
    Monday, February 23, 2009 3:16 PM
  •  Well, SP4 means a post-SP3 hotfix.  Whether there will ever be an actual XP SP4 is a debating point.
    Robin Walker
    Monday, February 23, 2009 11:03 PM
  • I installed the update but it did not fix the problem.  I still get the error "There are currently no logon servers available to service the logon request".  I checked the netlogon.dll version and it was updated.  I updated both test laptops.  One laptop has SP2 and the other has SP3.  Has anyone had any luck with the hotfix correcting the problem?

    JM
    Tuesday, February 24, 2009 2:59 PM
  • JM, can you look at the Properties of this netlogon.dll and give us the full "File Version" string from the "Version" tab.  It should be: 5.1.2600.5755 (xpsp_sp3_qfe.090206-1316)
    Robin Walker
    Tuesday, February 24, 2009 8:47 PM
  • Robin, you listed the same version I have on the SP3 test laptop.  For SP2, the version is 5.1.2600.3520 (xpsp_sp2_qfe.090206-1239).  Thanks.  JM

    Tuesday, February 24, 2009 10:38 PM
  •  Which version is the correct one to use with SP3 and have network authentication work - 5.1.2600.5755 or 5.1.2600.3520?   Thanks!
    Tuesday, March 10, 2009 3:55 PM
  • You should use the one that the hotfix installs for you: it will choose the correct version.

    5.1.2600.3520 is the version number of a hotfix for SP2, which is not right for SP3.
    5.1.2600.5755 is the version number of this hotfix for SP3.

    There are some indications that this hotfix is not yet fully cooked, and might be subject to further revisions in the future.
    Robin Walker
    Tuesday, March 10, 2009 4:05 PM
  •  Is this a guarantee that network authentication will work with other computers when not connected to the domain?

    I have an application that requires this authentication and because my new laptops came configured with SP3, I would like a definitive answer that this version of netlogon.dll resolves the issue with authentication.


    Tuesday, March 10, 2009 4:23 PM
  • Hi...

    Thanks to everyone who have contributed so far it is shedding some light on my problem too.

    I'm the Network Admin in an office of auditors with 65 laptops.  I've been here about 8 months and grappling with this for more than half of it.

    When our auditors go out to the field they log in locally with a local admin account (same account name on every laptop).  They connect to each other through a router.  One computer has the master document.  They map to the common shared folder where the master document is located.  They can then sign out documents from the master audit file.  When they are done they sign those documents back in to the master file.

    Everything was great until I started to update to XP SP3.  Guess what...same problem everyone else has here.  Cannot map to the common shared folder (not even just the \\cname) on the computer that has the master document nor to each other.

    We get the   \\cname is not accessible....blah blah blah...no logon servers available error message.

    Cannot    Run>\\canme

    The only thing that works is to uninstall SP2.  Then all is normal.


    I tried the Hotfix listed here where the SP3 netlogon.dll   version blahblah.5755  is copied over to ssytem32 folder.  But it didn't solve the problem.

    NET USE with the local admin logon only gets me the 1311 error.

    But, NET USE with my domain admin logon gives authentication to the \\cname.  Then I can map a share.

    As was mentioned here before by others, I believe that the local logon credentials are not being searched after the domain credentials are tested.

    The only thing I can think of and haven't tried is to also create domain account with the same local account name so that the domain credentials are cached.  Then when out in the field, the user can login with the same name but log in to the local account instead of the doamin name.  I'll post my results.


    The thing is, Microsoft needs to fix what they broke...plain and simple.  Why is it so hard to be motivated to resolve this?


    It's Friday...have a good weekend.















    Friday, March 27, 2009 10:40 PM
  • Thank you DrewTRobertson !!!!
    That hotfix worked for me after two days suffering...
    Wednesday, May 06, 2009 1:01 PM
  • Hi all,

    As I mentioned earlier a workaround was to copy the SP2 netlogon.dll over the standard SP3 one.
    This worked for all systems. Two of them showed a very long login time.
    Running the last Microsoft servicepack (fix) solved that.
    When you now upgrade an XP SP2 machine to SP3, you'll see the new netlogon.dll of the upgrade is almost the same as the SP2 version.
    Tha last fix should work or else the problem has a different cause.

    Enjoy,
    René.
    Wednesday, May 06, 2009 3:17 PM