Not the usual Group Policy Preferences - Drive Map issue
Hello
I have an AD DS server running Win 2k8 R2. I have a GPO for Drive Mapping through Windows Preferences, linked/enforced at the domain level, and security filtering is performed by group. I have a user who is a member of said group. I have no problem using GPO Preferences to map drives which exist on a Windows Server. However, I have several network shares which reside on an IBM i Series server and one Linux server. When I try to deploy these drives through GPO Preferences, the drive icons do show up on the client computers. When I log in as said user, the drives always show as disconnected. The drives which point to shares on Windows servers are fine. When I double-click the icons, I receive an error message that the username is not found with error code "The user could not be found 2221". It seems like it's trying to authenticate to the foreign servers with a domain account. I can manually map these drives, but they show disconneted at next logon. If I specify a username/password in the "Connect as" fields in the Drive Map Preferences GPO, it seems to have no effect. It doesn't matter if I use replace, create, or update in the GPO, the result is the same. All client systems are Win XP SP3 w/ XMLLite and GPO client side preferences update installed.
GPResult on the client systems shows that the GPO is applied with no problems. I'd really like to avoid using Logon scripts to achieve drive mapping for these shares, but increasingly it appears this is my only option. Can anyone shed some light on this??
Thank you
Pete
I have an AD DS server running Win 2k8 R2. I have a GPO for Drive Mapping through Windows Preferences, linked/enforced at the domain level, and security filtering is performed by group. I have a user who is a member of said group. I have no problem using GPO Preferences to map drives which exist on a Windows Server. However, I have several network shares which reside on an IBM i Series server and one Linux server. When I try to deploy these drives through GPO Preferences, the drive icons do show up on the client computers. When I log in as said user, the drives always show as disconnected. The drives which point to shares on Windows servers are fine. When I double-click the icons, I receive an error message that the username is not found with error code "The user could not be found 2221". It seems like it's trying to authenticate to the foreign servers with a domain account. I can manually map these drives, but they show disconneted at next logon. If I specify a username/password in the "Connect as" fields in the Drive Map Preferences GPO, it seems to have no effect. It doesn't matter if I use replace, create, or update in the GPO, the result is the same. All client systems are Win XP SP3 w/ XMLLite and GPO client side preferences update installed.
GPResult on the client systems shows that the GPO is applied with no problems. I'd really like to avoid using Logon scripts to achieve drive mapping for these shares, but increasingly it appears this is my only option. Can anyone shed some light on this??
Thank you
Pete
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
This may be related to other registry entries. There are registry entries that define the minimum authentication level for different connections. If that is the case you might be able to fix this using the Compatws.inf security template. Otherwise, it may come down to hunting through the registry for the magic setting. If nothing else, blame Microsoft and call it a bug.
From a security standpoint, I would prefer to not install the Compatws.inf template. I would leave the security as it is and just use the logon script. JMHO
From a security standpoint, I would prefer to not install the Compatws.inf template. I would leave the security as it is and just use the logon script. JMHO
ASKER
Ok, thanks for the insight. I've decided to stick with logon scripts to take care of the drive mapping for the shares on the nix systems.
ASKER