DNS suffix is not appending only for SMB shares

We have a strange issue where intermittently we can't connect to a SAN share by using its single label name. When the issue happens I can ping the name and the suffix is appended correctly, but when I browse to the share with \\ it only works with the FQDN. A reboot fixes the issue, but I can't find any explanation as to why this is happening.

This is a production web server so I need to find a solid reason as to why this happening to give to the management.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Rich WeisslerProfessional Troublemaker^h^h^h^h^hshooterCommented:
Interesting.  Obviously there isn't a quick and easy answer.  My first thought is a problem with the Multiple UNC Provider (MUP), and that's mostly because of recent implementation changes in MS15-011.    But obviously standard name resolution is working... but there could be something broke with the MUP, or something is getting hung up with an alternate name resolution.

I need to clear up some assumptions.  
  1. When you say, "SAN Share" -- is this an SMB share configured directly on an appliance which is part of the SAN?  (I think the most recent generations of SANs I've seen offer this as a option.)  (What SAN are we dealing with in that case?)
  2. Confirm for me... "A reboot fixes the issue [...]".  A reboot of the webserver, which is the client machine in this case, correct?  Are you able to connect to the SAN share with any other client using a single label name?

But I assume the share in question isn't requiring mutual authentication and the client isn't configured to perform Client Side Caching on the share?

Are there any relevant errors/warnings on either the server or client event logs while the problem is occurring?
V0LUMEAuthor Commented:
Thank you for your response.

1. The SAN is Nexenta and the share is configured from the appliance web console.

2. Yes the web server is the client machine. We have 20 web servers which connect to the same share, but the issue is only affecting 2 servers in a HA pair.

The applications accessing the share connect with a domain user which has full permissions. For now I configured the virtual directory path with FQDN as a work around so the issue is not so important anymore. My inquiring mind wanted to know the root cause!

I've checked the logs on the days surrounding the issue and can't find anything related.
Rich WeisslerProfessional Troublemaker^h^h^h^h^hshooterCommented:
If the eighteen web servers which are not configured with HA do not experience the problem, and the two web servers which are do, I have to ask "What are you using for HA?"

For the single name, name resolution, are the clients using a DNS domain suffix, DNS domain suffix search list, DNS GlobalNames, WINS, or a broadcast?
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

V0LUMEAuthor Commented:
Sorry for the delay, I was on annual leave. I've just got in and one server has the issue again, but this time FQDN is not working either. I am looking into the event logs for more information.
V0LUMEAuthor Commented:
Strangely when I ping the  short name or FQDN it works fine. Just SMB connection is not working. I get Error code: 0x80004005 Unspecified error
V0LUMEAuthor Commented:
In answer to your previous question, all servers are configured with HA. The setup is 2 IIS 8 servers configured with shared config. The configuration is replicated with DFS, These sit behind 2 software load balancers which are Open Source "HAProxy".

The servers are in a child domain segregated for hosting purposes. I added the root domain to the DNS suffix search list using group policy.
V0LUMEAuthor Commented:
Update on the issue - I restarted IIS and now the short name works but the FQDN does not. I can't find any errors in the event log which match up to the issue.

I read online some people talking about running a Wireshark trace. Do you have any suggestions?
Rich WeisslerProfessional Troublemaker^h^h^h^h^hshooterCommented:
I don't know your SAN (Nexenta)... but does it have have SMB Hardening, or mutual authentication enabled on the share?  On the SAN can you see the connection attempts from the web server(s) when it is failing?  (On a Windows machine, I'd look in the Security Log during a period of time you know the web server was attempting to connect.)

If you're familiar with Wireshark and can run a trace while the problem is exhibited, that could be useful for tracking down the problem.  I suspect what you'll be looking for is an initial communication between the web server(s) and the SAN which fails, then some attempts using alternative methods to access the share... which then fail.  You'll want to focus on the initial failures...  Not certain what it'll be... :-(
V0LUMEAuthor Commented:
The SAN is managed by the hosting provider. They said the issue was with the SAN using SMB2 and Windows trying to use SMBv3. They said they applied a registry fix. I'm not convinced as it started working before they done the fix. I've attached a screenshot of Wireshark at the time of the issue.
Rich WeisslerProfessional Troublemaker^h^h^h^h^hshooterCommented:
Could be SMB version problem...  you can see in those packet transmissions that SOMETHING isn't happening the way it should in that packet capture.  We can see the request being sent multiple times to authenticate the user VOLUME\james.white .. but  the reply is a reset, so it keeps trying.

If this traffic is from your Web Server to the SAN/SMB server... yeah, it'd have to be a change on the SAN to correctly handle the authentication, but it looks like your webserver has already stepped down to SMB2 correctly.

I suppose we can hope the hosting provider just oversimplified their explanation, and their registry fix resolves the authentication problem.
V0LUMEAuthor Commented:
The registry fix we have to apply to make the server talk with the SAN is this:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" RequireSecureNegotiate -Value 0 -Force

I don't see how re-applying this could solve the problem. I imagine it will most likely break again soon! My next course of action is server rebuild.
Rich WeisslerProfessional Troublemaker^h^h^h^h^hshooterCommented:
Well, it's during the authentication that the you are having problems... and that setting is disabling the requirement for secure authentication negotiation.  I have more confidence that is a productive direction to go, based on what you showed in Wireshark.

I assume this is the article your provider is looking at: https://support.microsoft.com/en-us/kb/2686098

But note... your registry change should be a short term fix until the SAN hardware vendor provides an upgrade.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Server OS

From novice to tech pro — start learning today.