File and Printer Sharing for Microsoft Networks Failing
 

I am running into an issue that the File and Printer Sharing for Microsoft Networks fails when my DELL 5580 is connected to a DELL D6000 Docking Station over USB-C with the current DisplayLink drivers (8.5.3595.0).

This issue does not occur when connected over WiFi or via the Network Adapter in the Laptop.

I've updated all drivers to the latest version and also the systems Firmware (BIOS).

The problem is resolved (work-around) by toggling the File and Printer Sharing for Microsoft Networks binding on the Network Adapter after every dock action or reboot.
I’ve found other people reporting this issue also, with the above work-around only and no actual solution.

https://social.technet.microsoft.com...tpronetworking

It is unclear what the root cause is and if the root cause is inside the DisplayLink driver, however it only happens in combination with the DisplayLink driver. Any support for diagnosing this?

Is there anyone who can test if this issue also exists at his/her system by connecting to \\computername\admin$

Hello Floris,

Interesting link. Neither of the products mentioned there use DisplayLink Ethernet.
Therefore this is unlikely to be a driver or device issue, but rather an OS one.

I'll ask Microsoft during my call next week how best to progress that.
Do you have a reliable reproduction? We are likely to be needing to gather/create logs of some sorts. I don't yet know which!

Kind regards,
Alban

You are right, I overlooked the Driver details for the Ethernet Adapter. It is a DELL driver.
Well looking again it does mention DisplayLink Corp. as provider.

https://www.displaylink.org/forum/at...1&d=1535955131

Reproducing is easy, every time the dock is plugged in the issue occurs. If you could get some movement at Microsoft that would be great, not much traction on the issue so far.

I’m more than willing to help gather logs for debugging purposes.

Afternoon,

I know (hopefully!) that the Dell D6000 uses DisplayLink Ethernet, I even have one on my desk.

The poster on the thread you linked on the Microsoft community are about Dell WD15, Dell DA200 and DA300. None of these products use DisplayLink technology and therefore not our driver.

I will ask what we need to get the bug rolling, it's good you have a reliable reproduction.

Kind regards,
Alban

DL Ref: 28632 - File and printer sharing for Microsoft networks failing on USB Ethernet adapters

Hello Floris,

Here are traces that might be helpful to find the root-cause the problem. Could you attach these ETLs to the thread or, if too big, send a link to the cloud storage of your choice so this can be downloaded and handed over to Microsoft? The email address is technical_enquiries@displaylink.com.
Please mention context and reference 28632 so the person picking up your ticket knows what to do with it straight away as I'm on holidays for a few days.

Turn on tracing on the “server”
- Open Admin command prompt and enter this:
Netsh trace start filesharing tracefile=c:\filesharing.etl

Turn on tracing on the “client”
- Open Admin command prompt and enter this:
Netsh trace start netconnection tracefile=c:\netconnection.etl
- Repro issue: Try connecting to the server
- Stop tracing:
Netsh trace stop

- Stop tracing on Server:
Netsh trace stop

Kind regards,
Alban

I'm really interested in this topic, since we have he same problem in our company.
The only difference is that we can not reproduce it reliable.

We are using an universal docking station from Targus (https://www.targus.com/uk/universal-...power-acp77euz), which are utilizing a DisplayLink ethernet chip, for our Dell and HP laptops.

Once the error occurs, it can be reliable linked to the docking station.
Unplugging ethernet from the docking station and connecting it directly to the laptop eliminates the problem with available shares. Reconnecting to the docking station results in shares not found.
This can be repeated over and over again with the same results.

Unfortunately, since this problem is rather infrequent (and regarding to company compliances), i can not provide (publicly) network traces to help further investigating into this problem.

Kind regards,
Stephan

Hello Stephan,

I've received traces from Floris through a ticket. We used them to create a bug report to Microsoft.
We only managed to reproduce the opposite in our labs. Also, as the issue is reported on other technologies, it seems Microsoft is the best placed to advise us on the next step.

Kind regards,
Alban

Hello Stephan and Floris,

We have received the feedback to check if this could be caused by SMBv1 being unavailable.
http://aka.ms/smb1rs3
http://aka.ms/stopusingsmb1

I understand that you have a different behaviour on Wi-Fi than USB, so I am not sure of the relevance. Would you be able to check nonetheless as we don't have internal reproduction of this issue?

Kind regards,
Alban

I am still running Windows 10 version 1703, so that can't be the issue. Also I am reproducing the issue by just doing a loopback on my system by going to \\hostname\admin$ or \\hostname\c$.

SMBv1 is installed as a Windows Feature. However, if I query it's status with PowerShell I get the following output:

Hello.

Sorry forgot the late reply.

I found a workstation, which had this problem at the time, and had a look on these settings.
I did the same test like Floris did, but for me both protocols shown up as True.

So i think this problem can be excluded on my side.

Kind regards,
Stephan

I have this exact problem as well. Finally figured out today that it only happens when the laptop is docked which then lead me to this thread. This issue happens for me whenever the laptop is docked. Same result whether using ethernet or WiFi when docked. Using latest version 8.6 of DisplayLink as well.

Running Windows 10 v1803 on ours and my SMB results are the same as Floris'. Please advise on any other logs that can be provided to resolve this.

Edit: Should also add that enabling SMBv1 does not resolve this issue either.

Is there any update from Microsoft based on the additional information provided to them?

Hello, no, there isn't.

Is there any update/ETA on this?

Hello,

The contact I had on the ticket stopped replying and I didn't get what Microsoft asked for to understand the problem.
As I don't have a reproduction in the office, I can't progress this.

Unless someone wants to take the time to provide the information, Microsoft won't progress on that issue and it will stay blocked.

Kind regards,
Alban

What specific information do you need provided, I have a number of machines with this issue in our environment.

Hello,

Microsoft gave me a script to be ran. The issue seems to appear with any kind of network adapter, DL or 3rd party.

I can share that tool, but privately as, to protect users from logs download, you won't be able to get attachments from the forums.
Would you please send an email to Technical_Enquiries@DisplayLink.com with "28632: File and Printer Sharing for Microsoft Networks Failing" as the subject line so a ticket can be created and I can attach it to a reply?

Kind regards,
Alban

sent you an email.

Is there any update to this issue? As a help desk tech, the inability to remotely connect to a client laptop that is connected to a docking station and or browse remotely via Windows Explorer is very frustrating.

Hi All

I was just reading this thread and it reminded me of a known issue in Windows when you have connected too many USB Ethernet adaptors and they are stored in the registry. You get weird behaviour of the connection working but unable to connect to network shares.

It was a problem in Windows 7, and not sure if it has been solved for Windows 10. There is a thread on it here:

https://social.technet.microsoft.com...ork-interfaces

And here:

https://social.technet.microsoft.com...tpronetworking

Worth checking if this is the issue, especially if you use hot desking, so will end up with many different USB Ethernet entries in device manager, if you move desks a lot.

Wim

I don't think this is the issue or at least isn't in our environment. The only that that changed was going from a Windows 7 Pro laptop to a Windows 10 Pro laptop. The docking station and all peripherals remained the same.

Still no update on this?

Admin Share Issue with Dell 6000 Dock
 

Is there an update on this? I am having the same issue where some of my Dell 7280's and 7290's that are docked with Dell 6000 docks I am unable to C$ into. If I remove them from the dock and put them on wifi or even hard wire directly into the laptop, I can then C$. Please help!

Exactly, what I am experiencing at my office. It makes helping users remotely almost impossible!

Any update?

I have found a fix. See below.

https://superuser.com/questions/1240...can-by-localho

Someone also developed a command line program to automate the share fix.

I have deployed the fix to run silently on affected clients, had them restart and now can browse to to \\host\c$ and connect via Dameware Mini Remote Control!

We are having the same issue. We have 700 work stations and about 100 of them have the issue at any given time. This is a big deal for us because we use PDQ to manage our PC's, which relies heavily on the file sharing ability.

It might be more of a Windows issue, but it's for sure related to the dell docking station (D6000). There appears to be a communication problem with the netbios between the dock and the Windows PC. I have no clue what I'm talking about beyond that, so that's all I'll say.

Like the previous poster, I found the same "fix". I had all effected users run this fix silently. https://github.com/filippobottega/Sh...ster/README.md They must be docked to their main docking station when they run it.

It rebuilds the binding of the network adapter interface. Basically it fixes the communication between the Windows pc and the Dock Nic adapter. The only issue with this is when they use a different dock, it breaks the communication again. Luckily, it reconnects when they go back to their home dock. Although, I'm still not positive the binding stays permanent.

This isn't a fix though. We swap docks all the time for one reason or another. Supposedly Windows 1809 will fix this issue, so I've been deploying it for the past few weeks. But it's too early to tell if it's making a difference.