Need to add DNS search suffix search order on all workstations
I need to enable and add entries to the DNS suffix search order field on all my Windows 2000 workstations. Can anyone suggest an efficient way to do this to over 300 workstations? This is an AD network, so would there be a way to do this with a GPO?
I believe Jumble's solution is the best and easiest.
However, if you wanted you could change this setting on all the machines. This setting is stored in the registry as the following:
[HKEY_LOCAL_MACHINE\SYSTEM
"SearchList"="mynetwork.co
You could copy the above lines into a .reg file, change the setting to your liking. You could then update each machine's registry by typing "regedit /s new_setting.reg". This would automaticaly and silently update the registry with the new values. I believe with a setting like this you don't need to reboot the computer.
We use Tivoli software distribution here, so I would make a package and distribute it that way. You could also put this into a logon script or use SMS, etc.
Again, jumble's solution is much easier and the best solution.
However, if you wanted you could change this setting on all the machines. This setting is stored in the registry as the following:
[HKEY_LOCAL_MACHINE\SYSTEM
"SearchList"="mynetwork.co
You could copy the above lines into a .reg file, change the setting to your liking. You could then update each machine's registry by typing "regedit /s new_setting.reg". This would automaticaly and silently update the registry with the new values. I believe with a setting like this you don't need to reboot the computer.
We use Tivoli software distribution here, so I would make a package and distribute it that way. You could also put this into a logon script or use SMS, etc.
Again, jumble's solution is much easier and the best solution.
if you want to follow EschbacherG you would need to use the reg.exe -s not /s or regedit -s
ASKER
That's for the comments.
Jumble: We have tried using option 15 in DHCP and it doesn't work. Here is an explanation we found for why it doesn't work:
"This _isn't_ a limitation of the DHCP protocol at all, and _is_ a limitation of a specific vendor's implementation. In this case, the vendor is Microsoft; and the limitation is in their implementation of the _client-side_ of a DHCP negotiation. A Microsoft DHCP server is perfectly capable of sending multiple search domains to a long list of clients that will understand it; namely, anything with roots in Unix, i.e. Solaris, Linux, 'BSD, probably the new MacOSX, etc. All these use a simple space-delimited text string to list out possible search domains in their /etc/resolv.conf file (or equivalent), ie:
search bob.com other.domain.com some.final.domain.com
So all one has to do is type the domains into the space provided on the Microsoft DHCP server configuration, with spaces between each, and any client that deals with name resolution Unix-style will work just fine. Microsoft clients, however, list out each new domain on a new line, making it impossible to pass them a list of domains. The _client-side_ doesn't know how to deal with receiving a space-delimited list.
Summary:
Not a limitation of DHCP protocol
Not a limitation of Microsoft DHCP server (it's perfectly capable of sending a space-delimited text list of domains in DHCP field #015)
Not a limitation of probably every Unix-derived DHCP client (perfectly capable of receiving and using a space-delimited test list of domains)
IS a limitation of Microsoft DHCP client (doesn't know how to deal with a space-delimited text list of domains)."
EschbacherG: We don't have a distribution mechanism, like SMS on this network. We can't deploy this as a logon script because most users don't have admin rights on their PCs and thus the script wouldn't be able to modify the registry.
Jumble: We have tried using option 15 in DHCP and it doesn't work. Here is an explanation we found for why it doesn't work:
"This _isn't_ a limitation of the DHCP protocol at all, and _is_ a limitation of a specific vendor's implementation. In this case, the vendor is Microsoft; and the limitation is in their implementation of the _client-side_ of a DHCP negotiation. A Microsoft DHCP server is perfectly capable of sending multiple search domains to a long list of clients that will understand it; namely, anything with roots in Unix, i.e. Solaris, Linux, 'BSD, probably the new MacOSX, etc. All these use a simple space-delimited text string to list out possible search domains in their /etc/resolv.conf file (or equivalent), ie:
search bob.com other.domain.com some.final.domain.com
So all one has to do is type the domains into the space provided on the Microsoft DHCP server configuration, with spaces between each, and any client that deals with name resolution Unix-style will work just fine. Microsoft clients, however, list out each new domain on a new line, making it impossible to pass them a list of domains. The _client-side_ doesn't know how to deal with receiving a space-delimited list.
Summary:
Not a limitation of DHCP protocol
Not a limitation of Microsoft DHCP server (it's perfectly capable of sending a space-delimited text list of domains in DHCP field #015)
Not a limitation of probably every Unix-derived DHCP client (perfectly capable of receiving and using a space-delimited test list of domains)
IS a limitation of Microsoft DHCP client (doesn't know how to deal with a space-delimited text list of domains)."
EschbacherG: We don't have a distribution mechanism, like SMS on this network. We can't deploy this as a logon script because most users don't have admin rights on their PCs and thus the script wouldn't be able to modify the registry.
There is another tool I might suggest. It's called "psexec" ( http://www.sysinternals.com/ntw2k/freeware/psexec.shtml ). It allows you to remotely execute programs on a client pc without having to install any software on the client side. We use it here all the time (instead of having an end user try and figure out their IP address, we can just remotely execute ipconfig for them).
One great feature of it is that you can copy the program you wish to execute to the client computer. So, in our situation here, you could create a .bat file, and use PSEXEC to copy it and run it on. This batch file might say something like
reg.exe -s \\server1\utilities\update
The full usage of this program would be like this:
psexec \\clientpc -u Administrator -p password -c update_dns.bat
You could combine this with the "net view" command and create a script that loops through every PC in your domain.
One great feature of it is that you can copy the program you wish to execute to the client computer. So, in our situation here, you could create a .bat file, and use PSEXEC to copy it and run it on. This batch file might say something like
reg.exe -s \\server1\utilities\update
The full usage of this program would be like this:
psexec \\clientpc -u Administrator -p password -c update_dns.bat
You could combine this with the "net view" command and create a script that loops through every PC in your domain.
You're right that DHCP can't give out multiple domain suffixes, but in 2003 this has been added as a Group Policy object. See here:
http://www.serverwatch.com/tutorials/article.php/2200561
exerpt:
The following Group Policy settings are new in Windows 2003 server based domains:
Administrative Templates\Network\DNS Client - expanded well beyond what was available in Windows 2000 (in Administrative Templates\System\DNS Client folder which allowed only mandating the suffix used to identify the computer in DNS). With these settings you can control practically all DNS related features, such as client's DNS suffix search order, registration of PTR records, connection-specific DNS suffix, etc.
In the meantime, you could create a .reg file to update:
HKLM\System\CurrentControl
to set the value for "SearchList"
If the reg file is called from a login script, I think the user still has to click to accept it, but it's worth a try.
http://www.serverwatch.com/tutorials/article.php/2200561
exerpt:
The following Group Policy settings are new in Windows 2003 server based domains:
Administrative Templates\Network\DNS Client - expanded well beyond what was available in Windows 2000 (in Administrative Templates\System\DNS Client folder which allowed only mandating the suffix used to identify the computer in DNS). With these settings you can control practically all DNS related features, such as client's DNS suffix search order, registration of PTR records, connection-specific DNS suffix, etc.
In the meantime, you could create a .reg file to update:
HKLM\System\CurrentControl
to set the value for "SearchList"
If the reg file is called from a login script, I think the user still has to click to accept it, but it's worth a try.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks oBdA! That was exactly what I was looking for. Works perfectly!
I used this as well, works a treat, thanks very much.
Matthew
Matthew
Hi Guys,
I'm after the same solution but I don't exaclty follow the instructions given by oBdA.
Any chance of a clearer explaination? I can get to the Group policy MMC but I don't know exactly what to configure in there?
Do I need to open another question for this?
I'm after the same solution but I don't exaclty follow the instructions given by oBdA.
Any chance of a clearer explaination? I can get to the Group policy MMC but I don't know exactly what to configure in there?
Do I need to open another question for this?
I followed the directions, and I can see the policy being downloaded to the client via gpresult.exe, but the Search List still isn't taking affect. I have three DNS suffices in the Search List, separated by commas, and without spaces. Any ideas? Should this be a User policy? Or a machine policy?
Under the GPO, you see that it's within the main folder 'Computer Configuration' - so it's a computer policy...you need to add the GPO to a container that the PCs are in.
Sorry, I was looking in Server 2003 - you may not see it in a 'Computer Config' folder - but where the .adm file has CLASS MACHINE means that it's chaging HKEYLocalMachine ie. it's a computer policy.
I figured that since I wasn't able to add the template to the User Config, but I'm still not able to see the Search List taking effect. I've added the GPO to a container that does contain the PC's. I have another GPO already in place that has been working and I see the changes getting sent down to the PC's.
you do not need to configure the client pc.