UNC Path doesn't work, mapped drive does, powershell does...

[mvbighead]

So we're in the process of migrating from Domain 'domain.local' to Domain 'corp.net' (just example names for the purposes of explanation).

Trusts are in place, all is mostly fine. However, in the process of testing, I find that trying to access the UNC path of \\server.domain.local\privateshare$ results in an error of 'The system cannot find the file specified.' This also happens for public shares.

The strange thing is that I can access the share via PowerShell and peruse the directories. I can also map a drive and peruse the files that way. I simply cannot do start -> run -> \\server.domain.local\privateshare$\ from a corp.net computer and user account. What gives?

(As evidenced by the fact that mapped drives/Powershell works fine under the same set of credentials (from corp.net) you should be able to see that the server is pingable and there is no permission restricting access, so this seems to be something else. Just not when using UNC paths.)

Any ideas?

 

[imagoon]

Does "netdom query trust" return sane results?

Is DNS fully converged, IE can the workstation ping the domain controllers via name and see the SRV records?

 

[mvbighead]

Does "netdom query trust" return sane results?

Is DNS fully converged, IE can the workstation ping the domain controllers via name and see the SRV records?

Yep. Everything looks good there. The trust is working well in most respects.

I did manage to find out that I cannot even run a UNC path to a server in the new domain from a workstation in the new domain, so it isn't only restricted to the trust.

I apparently have a GPO in my old environment that isn't in the new environment yet. Just not sure what it is, and why it wouldn't also affect connectivity to a mapped drive or to PowerShell for that matter. Why would Windows Explorer not be allowed to hit any share?

 

[imagoon]

I would be shooting in the dark but I would suspect that the domain level security is set differently such as one requires encryption that the other doesn't have.

 

[mvbighead]

Funny thing, on both my systems in the new domain, neither can create a simple share. Just a message that pops up and says "Your folder can't be shared."

In addition, I cannot access the system I'm on using a local administrative share. IE - If on SYSTEMA I cannot go to \\SYSTEMA\C$\. The error is immediate, and is basically this:

 

[imagoon]

At this point I would be looking in the system logs to see what is going on. IE try connecting to a share then look in that servers security log. Typically there should be an event of some sort.

PS I would assume that you are an admin on SYSTEMA? C$ won't work otherwise. Does SYSTEMA resolve to itself? Does SYSTEMA.domain.com resolve etc? Are there any firewalls in place?

 

[mvbighead]

All names resolve fine. And, to make this even more ridiculous, I can map a drive to the path I am trying to UNC directly into.

The only issue is, no matter what I do, I cannot go to Start -> Run -> \\systema\c$\ and get Windows Explorer to pop up with anything. The strangest thing I have seen in a while, and I have been comparing local security options for shares with my other domain and everything is identical.

Long story short, no combination of \\192.168.1.1\c$\; \\systema\c$\; \\systema.corp.domain\c$\ work. But, any of those work fine when mapping the drive.

Windows Firewall is enabled, as is McAfee. I did a restore defaults on Windows Firewall (some blogger referenced engaging MS support and something about the traffic not going up the stack), but that didn't help. I've checked as many setting as I can find in google, but nothing seems to relate. I am really thinking this is some policy in the new domain, but I do not have access to prevent policy inheritance to start with a clean slate with which to test.

There's gotta be a setting somewhere, I just ain't finding it.

 

[mvbighead]

Oh, security logs show events of packets being dropped. Turn off Firewall, no events, but the problem still remains (even after a reboot).

 

[seepy83]

Is it only like that with administrative ($) shares? I only ask because I've seen it on my work network where I will be sitting at an end-user's PC, with them logged in as a regular non-admin users, and if I try to access a c$/d$/etc share and enter domain admin credentials, I get an error saying it's not accessible. Single domain environment (although we did go through a migration a couple years ago), and I've never bothered to research to find out if it's normal behavior for Win7/2k8.

I could be barking up the wrong tree, but if it's only happening on admin shares, they may be related.

 

[imagoon]

Do you have a clean machine to test against? IE remove mcafee, disable the windows firewall and test. You haven't done any 'tweaks' to remove icons or anything have you?

What is the error code under details? Is there any odd ball network providers on the machine? The explorer Namespace could be invalid also.

I am shooting all over since this is a rather odd issue.

 

[mvbighead]

To be honest, this machine is already pretty clean, just built it yesterday.

I've disabled Windows firewall a few times on varying different tests with no effect.

McAfee is installed, and I am currently unable to unlock and disable it. The protection log isn't showing anything being blocked though.

Error code was something like 80700200 or similar. When I get back to it, I'll give you the exact numbers. Didn't really get me anywhere on google though.

No oddball providers. I've put in a request to get GPO inheritance blocked for this machine to clean it up further. I may also build a VM tomorrow with which to test.

As for shooting all over... yeah, me too. I can't find anything. Most people are referencing loosening settings to share with Ubuntu or something. I have a server (2008 R2) in the same environment, and I have the same exact problems with it. Everything in my old environment is happy.

 

[imagoon]

I would also be curious to see a wireshark sniff of the connection.

 

[classy]

This sounds like a permissions problem. I would review my group policies and run gpresult on the machines having problems and compare with those not having problems.

 

[classy]

Is this a new forest as well?

 

[mvbighead]

Well, got policies blocked, still got the problem.

Seems like it is limited to Windows Explorer only. Also, I cannot create a new share. Admin shares are the only thing that exist by default, and it just tells me that "This folder can't be shared" when I attempt to create a new share.

I've run Procmon to look for 'Access Denied,' nothing.

I can map a drive to whatever path I have permissions to, but I cannot runline directly into it using the UNC path. I can also use powershell to get into the path, copy/run executables/whatever.

The only limitation is Explorer.exe. I did see a support article, but the patch was "not applicable to that system." And, the patch didn't directly describe the problem I was having.

I am in the process of building a new machine (VM). Getting it to work in my domain, then moving it over to the new domain in the OU with blocked inheritance to see what happens, and then moving that into an OU where inheritance isn't blocked (will snapshot prior to that).

I'm quickly running out of ideas. Local Security policy options for shares seem to mimic what I have in the old environment, not sure what else would impact Windows Explorer in this fashion.

 

[mvbighead]

Not sure if this helps, but I CAN runline into a share on a PC in the new domain and, with that domain's credentials provided, access the share on the drive (I could add permissions for my account on the other domain, but I don't think that is necessary).

So, the shares are working there. I just can't pull them up with Windows Explorer on a machine in that domain.

 

[seepy83]

I would honestly open a ticket with Microsoft. It will cost you a little bit, but it would probably be worth it.

 

[imagoon]

What is in HKLM\system\currentcontrolset\control\networkprovider\order

is

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace\{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\explorer\Desktop\NameSpace\{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}

present? What values?

 

[mvbighead]

New machine, tested on my domain, worked fine. Moved to the blocked inheritance OU, was working fine, then magically disjoined the domain. Upon reconnecting, it doesn't work.

EDIT: I believe it disjoined because it had a prior computer object that I deleted from AD, and re-added to the blocked inheritance OU. I suspect that when it joined, some server didn't have the new data, and it joined in the wrong OU. Later causing AD to reset the object, I assume.

No McAfee, no anything other than Windows.

My boss had suggested what seepy83 suggested, and I may be going that route come Monday. Gonna give this time to sink in.

Imagoon, I have actually checked all those keys and they are correct (the compare identically to my machine that works). I'll try to get you the values, but I had to take my system offline to allow someone else to do something else.

 

[mvbighead]

Updated the title to be more accurate.

Getting a bit closer. Seems to be a GPO specific problem. Some of my settings have been migrated. I have access to a separate OU that doesn't have any OU specific policies applied, and UNC path access works as expected.

Getting closer, but not seeing anything that is immediately obvious in the policies, yet.

 

[imagoon]

I am definitely interested in seeing what this is...

From GPO it would make me think is has something to do with security policy on one of the domains like enforcing a certain authentication method or using certs etc. I hate these types because there is so many things to test in most cases and you are firing blind.

Off chance that one of the domains has say NTLMv2 disabled for security reasons but say NTLM Session on? Or something a bit more advanced like tweaking Kerberos on the Domain?

 

[mvbighead]

Actually, when I move the system to the OU that is causing it to break, the system stays broken until the snapshot is restored.

This leads me to believe that I a key in the registry is being modified, and that key remains when the system is moved to an OU that doesn't cause the problem.

I found this key, which may be the cause:
CLSID\{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}\ShellFolder

Based on this article (http://www.sevenforums.com/tutorials/39699-network-add-remove-navigation-pane.html) it removes the network options from Windows Explorer.

Gonna try to apply the key manually and see where that gets me.

 

[imagoon]

I seem to recall that any reg key pushed in to HKLM is permanent because it occurs outside of the the GPO structure in the registry. So you may be on to something there.

 

[mvbighead]

Can't apply key because only the trusted published has rights to make changes in that path. Not admin, not system, etc. The key I pushed was already there, but I am nearly positive that something isn't happening when the policy is applied, and the key is changed to something different.

Edit: Scratch that, SYSTEM has the privileges, but the key isn't being applied. ???

EDIT2: Took ownership of the parent folder, then of the shell folder, and suddenly some keys populated. Rebooting now.

 

[mvbighead]

Well, that location is the problem. Permissions are stripped from the folder when policy is applied, and the key change doesn't occur. Now to find why the permissions are being stripped.

Once I applied the right key (Attributes - Reg D Word - b0940064), Windows Explorer functions as expected.