Net Use h: /home doesn't work on NT and Win9x clients.
Greetings:
Here's my problem.
I have a Windows 2000 domain with mostly Windows 9x and NT 4 clients.
I created a user in a certain container. Then, I pointed
this user's home directory to a share on the Domain Controller. When I login as the user, I get an error
on the login script process (The errors are given later). The error occurs when issuing the following command on both Windows95, Windows98 and WindowsNT workstations. The error does not occur on Win2K clients.
net use h: /home
However, the error does not occur on the subsequent
command.
net use s: \\MyServer\shared$
When I issue "net use h: /home" at the DOS prompt I
get the same error.
To further complicate things, I know the user has
rights to their home directory because when I map to
it directly, as in "net use h: \\MyServer\austins$",
the command completes successfully.
Here's the final kicker. When I make the user a part
of the "Domain Admins" group, everything works fine.
The error I get on the NT machines states the following when the user is not in the "Domain Admins" group.
"Unable to determine home directory"
The error I get on the Win9x machines states the following when the user is not in the "Domain Admins" group.
"Error 5: You do not currently have access to this file. The file may be marked read-only, or it may be part of a shared resource such as a folder, a named pipe, a queue, or a semaphore. You can use the ATTRIB command to change
the read-only attribute, or try again later when the file may be available."
I loaded the DSCLIENT on a Win9x workstation
to see if that makes a difference. It didn't. It would appear that there is a rights problem for non-Win2K clients in setting the home directory variable. You see the home directory information must be read at login, then
the environment variables "HOMEPATH", "HOMEDRIVE" and
"HOMESHARE" must be set from the user profile.
Finally the home directory itself can be mapped with
"net use <drive letter> /home".
Since placing the user in the "Domain Admins" group
solves the problem, it must be a rights issue. Any
thoughts you have on this matter are greatly
appreciated.
Thanks for the help.
--
Don
Here's my problem.
I have a Windows 2000 domain with mostly Windows 9x and NT 4 clients.
I created a user in a certain container. Then, I pointed
this user's home directory to a share on the Domain Controller. When I login as the user, I get an error
on the login script process (The errors are given later). The error occurs when issuing the following command on both Windows95, Windows98 and WindowsNT workstations. The error does not occur on Win2K clients.
net use h: /home
However, the error does not occur on the subsequent
command.
net use s: \\MyServer\shared$
When I issue "net use h: /home" at the DOS prompt I
get the same error.
To further complicate things, I know the user has
rights to their home directory because when I map to
it directly, as in "net use h: \\MyServer\austins$",
the command completes successfully.
Here's the final kicker. When I make the user a part
of the "Domain Admins" group, everything works fine.
The error I get on the NT machines states the following when the user is not in the "Domain Admins" group.
"Unable to determine home directory"
The error I get on the Win9x machines states the following when the user is not in the "Domain Admins" group.
"Error 5: You do not currently have access to this file. The file may be marked read-only, or it may be part of a shared resource such as a folder, a named pipe, a queue, or a semaphore. You can use the ATTRIB command to change
the read-only attribute, or try again later when the file may be available."
I loaded the DSCLIENT on a Win9x workstation
to see if that makes a difference. It didn't. It would appear that there is a rights problem for non-Win2K clients in setting the home directory variable. You see the home directory information must be read at login, then
the environment variables "HOMEPATH", "HOMEDRIVE" and
"HOMESHARE" must be set from the user profile.
Finally the home directory itself can be mapped with
"net use <drive letter> /home".
Since placing the user in the "Domain Admins" group
solves the problem, it must be a rights issue. Any
thoughts you have on this matter are greatly
appreciated.
Thanks for the help.
--
Don
also see here it notes that changes have been made in the network services
http://www.jsiinc.com/subf/tip2700/rh2755.htm
http://www.jsiinc.com/subf/tip2700/rh2755.htm
so after all that is said, You will have to create different logon scripts based on the OS of the machine the user is logging on with
Two problems.
1.) The problem is that NT 4 has never had the /home parameter, this is a Windows 95/98/2000 supported parameter only. So the whole thing is not at all related to Windows 2000. NT 4 and 2000 connect the h: drive automatically, so the only client to worry about is WIndows 98.
To overcome this, I suggest that you simply modify your script so it detects the OS:
if [%OS%]==[Windows_NT] goto EndHome
net use h: /home
:EndHome
Problem2:
This is not normal Windows 2000 behaviour. There must be something messed up at your side. As a first step, to rule out the easy things, check both (!) the share's "NTFS file" permissions and the share's "share level" permissions.
Armin
1.) The problem is that NT 4 has never had the /home parameter, this is a Windows 95/98/2000 supported parameter only. So the whole thing is not at all related to Windows 2000. NT 4 and 2000 connect the h: drive automatically, so the only client to worry about is WIndows 98.
To overcome this, I suggest that you simply modify your script so it detects the OS:
if [%OS%]==[Windows_NT] goto EndHome
net use h: /home
:EndHome
Problem2:
This is not normal Windows 2000 behaviour. There must be something messed up at your side. As a first step, to rule out the easy things, check both (!) the share's "NTFS file" permissions and the share's "share level" permissions.
Armin
ASKER
Hi,
NT does have a /home parameter to the net use command. You can disconnect your home drive in "My Computer" and re-attach it with ...
net use <desired drive letter>: /home
I realize that I don't need to use that command for getting the home drive mapping under NT. In fact, I do successfully select the proper OS in the login script to avoid issuing this command on NT clients.
Anyway, that's not my problem. The problem is that when my Win9x/Me clients issue the "net use h: /home" command, either from the login scipt or just the DOS prompt, I get the following error.
"Error 5: You do not currently have access to this file. The file may be marked read-only, or it may be part of a shared resource such as a folder, a named pipe, a queue, or a semaphore. You can use the ATTRIB command to change the read-only attribute, or try again later when the file may be available."
As I mentioned, the home folder share can be mapped at a DOS prompt by the following...
net use h: \\MyServer\MyHomeFolder$
The user has full control in both the share and file permissions and the home folder property is set correctly as ...
\\MyServer\MyHomeFolder$
--
Don
NT does have a /home parameter to the net use command. You can disconnect your home drive in "My Computer" and re-attach it with ...
net use <desired drive letter>: /home
I realize that I don't need to use that command for getting the home drive mapping under NT. In fact, I do successfully select the proper OS in the login script to avoid issuing this command on NT clients.
Anyway, that's not my problem. The problem is that when my Win9x/Me clients issue the "net use h: /home" command, either from the login scipt or just the DOS prompt, I get the following error.
"Error 5: You do not currently have access to this file. The file may be marked read-only, or it may be part of a shared resource such as a folder, a named pipe, a queue, or a semaphore. You can use the ATTRIB command to change the read-only attribute, or try again later when the file may be available."
As I mentioned, the home folder share can be mapped at a DOS prompt by the following...
net use h: \\MyServer\MyHomeFolder$
The user has full control in both the share and file permissions and the home folder property is set correctly as ...
\\MyServer\MyHomeFolder$
--
Don
The home folder share name must match the username exactly - if you put a $ sign on the share it must also be in the username. I suggest you omit the $ and use permissions.
ASKER
Bullion,
Incorrect. The username does not have to even be remotely close to the name of the share. I do this all time. That's why I'm so puzzled. I have a sub domain where the scipts work fine, but remember, my setup for this problem domain works flawlessly when the user is placed in the Domain Admins group.
By the way, the use of the "$" is for making the share hidden.
--
Don
Incorrect. The username does not have to even be remotely close to the name of the share. I do this all time. That's why I'm so puzzled. I have a sub domain where the scipts work fine, but remember, my setup for this problem domain works flawlessly when the user is placed in the Domain Admins group.
By the way, the use of the "$" is for making the share hidden.
--
Don
>my setup for this problem domain works flawlessly when the user is placed in the Domain Admins group
makes me really think a permissisons issue. check and recheck your permissions and gpo's. I thinnk you may have conflicting gpo's
makes me really think a permissisons issue. check and recheck your permissions and gpo's. I thinnk you may have conflicting gpo's
and I have a typing issue
permissisons = permissions
LOL
permissisons = permissions
LOL
Hopefully you've already been helped with this question, but thought you'd appreciate knowing this.
WindowsUpdate has new updates for .NET users; Details follow - Microsoft .NET Framework
The .NET Framework is a new feature of Windows. Applications built using the .NET Framework are more reliable and secure. You need to install the .NET Framework only if you have software that requires it.
For more information about the .NET Framework, see http://www.microsoft.com/net. (This site is in English.)
System Requirements
The .NET Framework can be installed on the following operating systems:
Windows 98
Windows 98 Second Edition (SE)
Windows Millennium Edition (Windows Me)
Windows NT 4.0® (Workstation or Server) with Service Pack 6.0a
Windows 2000 with the latest service pack installed (Professional, Server, Datacenter Server, or Advanced Server)
Windows XP (Home Edition and Professional)
You must be running Internet Explorer version 5.01 or later for all installations of the .NET Framework.
To install the .NET Framework, your computer must meet or exceed the following software and hardware requirements:
Software requirements for server operating systems:
MDAC 2.6
Hardware requirements:
For computers running only a .NET Framework application, Pentium 90 mHz CPU with 32 MB memory or the minimum CPU and RAM required by the operating system, whichever is higher.
For server operating systems, Pentium 133 mHz CPU with 128 MB memory or the minimum CPU and RAM required by the operating system, whichever is higher.
Recomended software:
MDAC 2.7 is recommended.
Recommended hardware: For computers running only a .NET Framework application, Pentium 90 MHz CPU with 96 MB memory or the minimum CPU and RAM required by the operating system, whichever is higher.
For server operating systems, Pentium 133 MHz CPU with 256 MB memory or the minimum CPU and RAM required by the operating system, whichever is higher.
How to use -> Restart your computer to complete the installation. No other action is required to run .NET Framework applications. If you are developing applications using the .NET Framework, you can use the command-line compilers or you can use a development environment, such as Visual Studio .NET, that supports using the .NET Framework.
How to uninstall
To uninstall the .NET Framework: Click Start, point to Settings, and then click Control Panel (In Windows XP, click Start and then click Control Panel.).
Click Add/Remove Programs.
Click Microsoft .NET Framework (English) v1.0.3705 and then click Change/Remove.
More here http://www.microsoft.com/net/
The .NET topic is being considered for addition to our All Topics link soon, so this may interest you as well:
https://www.experts-exchange.com/newtopics/Q.20276589.html
EXPERTS POINTS are waiting to be claimed here: https://www.experts-exchange.com/commspt/Q.20277028.html
":0)
Asta
WindowsUpdate has new updates for .NET users; Details follow - Microsoft .NET Framework
The .NET Framework is a new feature of Windows. Applications built using the .NET Framework are more reliable and secure. You need to install the .NET Framework only if you have software that requires it.
For more information about the .NET Framework, see http://www.microsoft.com/net. (This site is in English.)
System Requirements
The .NET Framework can be installed on the following operating systems:
Windows 98
Windows 98 Second Edition (SE)
Windows Millennium Edition (Windows Me)
Windows NT 4.0® (Workstation or Server) with Service Pack 6.0a
Windows 2000 with the latest service pack installed (Professional, Server, Datacenter Server, or Advanced Server)
Windows XP (Home Edition and Professional)
You must be running Internet Explorer version 5.01 or later for all installations of the .NET Framework.
To install the .NET Framework, your computer must meet or exceed the following software and hardware requirements:
Software requirements for server operating systems:
MDAC 2.6
Hardware requirements:
For computers running only a .NET Framework application, Pentium 90 mHz CPU with 32 MB memory or the minimum CPU and RAM required by the operating system, whichever is higher.
For server operating systems, Pentium 133 mHz CPU with 128 MB memory or the minimum CPU and RAM required by the operating system, whichever is higher.
Recomended software:
MDAC 2.7 is recommended.
Recommended hardware: For computers running only a .NET Framework application, Pentium 90 MHz CPU with 96 MB memory or the minimum CPU and RAM required by the operating system, whichever is higher.
For server operating systems, Pentium 133 MHz CPU with 256 MB memory or the minimum CPU and RAM required by the operating system, whichever is higher.
How to use -> Restart your computer to complete the installation. No other action is required to run .NET Framework applications. If you are developing applications using the .NET Framework, you can use the command-line compilers or you can use a development environment, such as Visual Studio .NET, that supports using the .NET Framework.
How to uninstall
To uninstall the .NET Framework: Click Start, point to Settings, and then click Control Panel (In Windows XP, click Start and then click Control Panel.).
Click Add/Remove Programs.
Click Microsoft .NET Framework (English) v1.0.3705 and then click Change/Remove.
More here http://www.microsoft.com/net/
The .NET topic is being considered for addition to our All Topics link soon, so this may interest you as well:
https://www.experts-exchange.com/newtopics/Q.20276589.html
EXPERTS POINTS are waiting to be claimed here: https://www.experts-exchange.com/commspt/Q.20277028.html
":0)
Asta
ASKER
Hi,
Thank you all for your suggestions.
The actual problem was resolved and I forgot to close out this question.
The problem was in Active dirtectory itself. There is a hidden OU in Active Directory called "ForeignSecurityPrincipals
Thanks again.
Thank you all for your suggestions.
The actual problem was resolved and I forgot to close out this question.
The problem was in Active dirtectory itself. There is a hidden OU in Active Directory called "ForeignSecurityPrincipals
Thanks again.
ASKER
Does anyone know how to close this question without deleting it?
Since it has been resolved, I think this one should be placed in the archives for the future. If the only way to do this is to accept someone's comment as an answer, then I would like to choose StevenLewis because he was correct in that it was a permissions problem.
Does anyone have a problem with that?
Since it has been resolved, I think this one should be placed in the archives for the future. If the only way to do this is to accept someone's comment as an answer, then I would like to choose StevenLewis because he was correct in that it was a permissions problem.
Does anyone have a problem with that?
I don't LOL
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
http://support.microsoft.com/support/kb/articles/Q285/3/51.ASP