Ok, the user finally got back into town after being on the road and
i've had a chance to check what you've each have asked as well as i
have more symptoms to report:
- I've disabled McAfee for testing purposes and rebooted
- I've looked for the settings that Robbin suggested "On slow
connections, automatically work offline" - but it is greyed out and
not selectable.
- I checked the Opportunistic File locking (both on the server and the
client) as Les suggested and there was no entry in the registry for
"EnableOplocks" -- i checked the LanmanServer and the
Lanmanworkstation just to be safe...neither the server nor the laptop
had the key...
When he got back online this morning, again - he still has an internet
connection, but he can't go to any share for some reason and his
Outlook is reporting "disconnected" (all of this is using a direct
connection to the server using a gigabit ethernet cable, not wireless
- his wireless is turned off) and the error on a send/recieve is "the
server is not available" 0x8004011d.
I wanted to test his connection on a different ethernet to rule that
out, so i brought it into my office and the password login box popped
up asking for his password (like when you are offsite using RPC over
HTTP. I asked him if that comes up all of the time looking for a
password and he said that it does - he didn't know that on the network
it isn't supposed to.
Also, his offline files sync still isn't synching as before.
So, new symptoms and not fix after suggestions...i am wondering if i
remove/delete his computer from the server and reconnect it using a
different computer name if that will restore things properly?
thoughts?
thanks,
jared
On Thu, 6 Aug 2009 09:02:29 -0500, "Les Connor [SBS MVP]"
<les.connor@newsgroup> wrote:
>\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
>
>EnableOplocks REG_DWORD 0 or 1
>Default: 1 (true)
>Specifies whether the server allows clients to use oplocks on files. Oplocks
>are a significant performance enhancement, but have the potential to cause
>lost cached data on some networks, particularly wide-area networks.
>
>By default, the registry entry is 1 (oplock enabled), as a rule of thumb you
>should set this key to 0 (disable oplock) when sharing files with
>Xbase++/Clipper/FoxPro and MS-Access. We have not encountered any
>performance drawbacks in real-world scenarios after having disabled oplocks.
>However problems with Xbase++ file-based database applications simple went
>away after re-configuration of the server.