The home folder could not be created because: The network name cannot be found

Recently have been unable to create user's home directory from our 2008 R2 DCs via ADUC. The target is a 2012 Failover cluster.
Attempting to use \\Servername\Drive$\Users\username results in the error "The home folder could not be created because: The network name cannot be found". The same if the IP address is used instead of the Servername. Pinging by server name works. Again this is a new issue and have not been able to ascertain any changes that may have resulted in this.
LVL 1
jmpattersonAsked:
Who is Participating?
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.

jmanishbabuCommented:
0
Nick RhodeIT DirectorCommented:
Why do you have \Drive$\ in there?  If you target a server you usually just \\servername\users\username.

Users is a targeted share.  Try browsing to the location branch by branch to test the path.
0
jmpattersonAuthor Commented:
jmanishbabu this has nothing to with the Remote Desktop, did you read the issue? Please do not post any comments on the question since you cannot ascertain the OS being used, thank you.


NRhode if you are creating the folder, not specifing a share, you must include the path, then you go and share. Again did you read the question this has worked going all the way back to NT 4.0 and was working (again) until very recently in our environment.
0
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

piattndCommented:
You actually shouldn't need the drive letter in there, you just need permissions established appropriately at the root share you plan on creating the home shares in.  This link describes those permissions and the procedure for doing the automatic creation.

My suggestion would be to look for the Users share and check the permissions at that location (both the share and NTFS permissions) as indicated in the link above.  If the permissions look good, try using that direct share name, as Nrhode suggested.
0
jmpattersonAuthor Commented:
piattnd The share is not created!! We are creating the folder hence why the UNC is required.
0
piattndCommented:
Friendly suggestion here.... the way to NOT get help on this site is to treat the experts like they don't know what they're talking about.  After all....it is you coming to us for help, not us asking you for help.

Having said that, lets clarify something:  "...hence why the UNC is required".  You do realize that a UNC path has nothing to do with the drive letter, which is actually called the Administrative share of the drive (something that's automatically created for administrative purposes).

If you read the entire link I sent you, you'll realize that what dictates whether or not a folder is created automatically has to do with the share permissions and NTFS permissions, not the use of an administrative share (C$, D$, etc).  Check the server to ensure you have a share called \\server\users or \\server\users$.  Then check the share and NTFS permissions to ensure they meet the requirements of this functionality as described in the article I linked.  Once you confirm those permissions, use that UNC path using the users share name, not the C$.
0
jmpattersonAuthor Commented:
piattnd That is not the way it works, the effort here is to create the folder, not a share or shared folder. You use the admin share so that the folder (Users) is reachable and the new folder will be created in that folder.
As to your comment in reference to my comments, I have zero tolerance for those that do not read the issue blurb.
As a type of test if you were to use Windows explore to try and view a non-shared item it is the same in the UNC using the admin share. I am sure you have viewed \\servername\c$ for whatever reason.
All the DCs and the domain admin have permissions to the various admin shares. Why this is perplexing is that this process has actually been used here for years. I have reviewed updates, etc. in an effort to determine what may have resulted in this issue. You get the standard general error message 0X80004005.
I think the big clue here is network name not found or the permissions (corrupt) to the admin share are not in place?
thanks for trying to help.
0
piattndCommented:
I am completely aware of what you're attempting to do here.  I think the issue here is an administrator not understanding or following best practice for shares and home folders.

If \\server\users is not a share, create it, set the permissions as instructed by the link I've referred to several times, then try the folder creation through ADUC.  If you're not willing to do this, delete your question as you're really not looking for an answer.

Good luck with this issue.  I've put in my 2 cents.  Maybe another expert will be willing to be more patient with your extreme lack of respect or true understanding for the technology you're attempting to get working.
0
jmpattersonAuthor Commented:
Respect is earned....you cannot access the admin share is the core issue it has nothing to do with anything else.
0
Nick RhodeIT DirectorCommented:
For the most part following best practice in mind that is an old method of doing things and has been revised along time ago.

I did however run into the issue utilizing a software program that needs to access the admin shares and it was an object audit policy described here which resolved the issue which might apply in your situation being with server 2012.

http://social.technet.microsoft.com/Forums/windowsserver/en-US/9807a799-bea3-46ad-92a5-732779135f98/problems-accessing-administrative-shares-remotely-windows-cannot-access-servernamesharename

In agreement with piattnd, your demeanor is not appropriate, professional, or even necessary for when your the one asking the question on a help site.  Our purpose is to assist with resolving your issue.  We are not familiar with your environment or how its configured so we ask simple questions in hopes of getting a better understanding of your current situation.  My question is to why is it configured that way for (as stated earlier) it is not best practice and is an old method of doing things which has been out-dated but as you still see windows 98 systems still out there in the world, still around and not forgotten.
 
As I recommend to all my young techs, it is always advised to use best practice guides and to support them as a standard rule to follow.  Best practices should be used as a guideline for they might not always apply to a certain situation but are there for a reason.
0
jmpattersonAuthor Commented:
The DCs are 2008 R2 and the Cluster is on Server 2012. I have three (3) roles installed and vey recently (last) Friday I could access the storage resources via \\servername\x$ or whatever. Today I am unable to access two (2) of these resources via the admin share.
So the question boils down to why? I can ping each resource no problem. So again why would I not be able to access these other resources. Of the items I have considered (by the way the GP object auditing off has been in place for a while) is DNS records for these static entries, permissions, etc.
Please point to where Best Practices advise against accessing the admin share, thank you.
0
piattndCommented:
It's not against best practice to access the administrative share.  When dealing with shares and home folders for the users though, best practice is to create a share in which you can fully manipulate the security settings on both the share and NTFS permissions to your liking.  You cannot modify the share permissions for the administrative shares as they were designed specifically for administrative access, not user access.

In regards to the direct solution of the question that was posted, which deals with the automatic creation of home folder directories, it does not require (nor does Microsoft's blog article explaining the procedure) accessing the administrative share.

I can't speak for why you are now unable to access the administrative share of your clustered 2012 resource.  I've worked on many clusters (none were 2012) and didn't have issues.  Which of the 2 (or more) servers is currently serving up the resource you're trying to hit and can you access the administrative share by the IP or name of that server currently owning the clustered resource?
0
jmpattersonAuthor Commented:
Oddly enough I cannot access the admin shares via IP, although can ping name okay. I can access via the "active" node. So if I have two nodes MS1 & MS2 I can access if I \\MS1\Adminshare$
0
piattndCommented:
The following link suggests that this behavior is because of a technology they implemented in 2008 and carried over to 2012 called "File Share Scoping".

http://social.technet.microsoft.com/Forums/windowsserver/en-US/36bf2610-1fb4-4581-a573-5de2ec405004/win-2008-r2-sql-cluster-network-path-cannot-be-found

They link to this Microsoft blog article that explains file scoping:

http://blogs.technet.com/b/askcore/archive/2009/01/09/file-share-scoping-in-windows-server-2008-failover-clusters.aspx

This is another link where they point to file scoping as the issue:

http://social.technet.microsoft.com/Forums/windowsserver/en-US/ceeaff37-43ee-430f-b312-74c1e001356e/cant-access-c-share-on-2008-r2-cluster

It sounds to me that you'll need to scope the administrative shares so the cluster name will serve them up.  I don't have access to a 2008 or 2012 cluster right now to test this theory, so I'll leave that to you.
0
jmpattersonAuthor Commented:
The "solution" was to run a Repair of the Cluster Resources in the Failover Cluster Manager by going to the Cluster Core Resources section, offline the resource, then repair it (right click). I did this to both the Cluster Name and the File Server Role Server Name.
I'am unsure what exactly was the issue, but it now works.
0

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
jmpattersonAuthor Commented:
It is what resolved the issue, the other points were awarded for effort
0
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
Windows Server 2012

From novice to tech pro — start learning today.