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

Try applying this hotfix

http://support.microsoft.com/kb/2545735

Also check this article

http://www.w7cloud.com/home-folder-could-not-be-created-active-directory-fixed/

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.

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.

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.

piattnd The share is not created!! We are creating the folder hence why the UNC is required.

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$.

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.

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.

Respect is earned....you cannot access the admin share is the core issue it has nothing to do with anything else.

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.

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.

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?

It is what resolved the issue, the other points were awarded for effort