DNS suffix search list...

[Lanwench [MVP - Exchange]]

I've got a client with a SBS2008 environment (migrated from W2k to W2k3 to
SBS2008 in a hair-pullingly frustrating project).

AD domain is internal.domain.com. An ipconfig /all on workstations and
servers alike pulls up both internal.domain.com AND plain old domain.com in
the DNS suffix search list.

I saw that on the server, the tickbox for "append parent suffix" was
selected (must've been there by default). I unticked it and voila, I have
only internal.domain.com as I'd like. (domain.com is real and I don't think
it's a good idea to have it in the search list)

Now, for the workstations, all of which have DHCP-assigned addresses - is
there any way to automate unticking that tickbox? It sure doesn't seem to be
something handled by DHCP.

[Ace Fekay [Microsoft Certified Trainer]]

that gets put in there by default, as you've seen. There's a GPO setting
that can control this. Are the parent domain resources being hosted
internally or externally, such as mail and web?

OTOH, instead of using a GPO setting, you can opt to create a domain.com
zone internally and provide necessary external names and IPs. Thist reduces
the additional adminstrative overhead of using GPOs to alter default
settings, whch is what I normally opt for. This alleviates trying to get it
to work, e.g, a guest machine, wihch wouldn't get the GPO applied, nor an
iPhone or Windows Mobile, if connecting to the internal WIFI.

==================================================================================================== ==
Using GPOs to configure DNS Search Suffixes

At this time Win2k3 DHCP cannot assign a DNS suffix search list. However,
you can assign a connection specific DNS suffix (option 015), which is added
to the search list. But, you can assign only one DNS suffix per client.

There is a GPO that assigns a custom DNS suffix search list to XP and Win2k3
clients which can be assigned by Win2k DCs if you upgrade the GPOs using a
Win2k3 or XP client.

Upgrading Windows 2000 Group Policy for Windows XP:
http://support.microsoft.com/default...b;en-us;307900

After the GPOs have been upgraded (if needed), expand the Group policy to
here to apply
the custom search list.
Computer Configuration
-Administrative templates
-Network
-DNS Client
==================================================================================================== ==

[Lanwench [MVP - Exchange]]

Thanks, Ace. The problem with setting up an internal domain.com zone is that
it's a real public domain (theirs) and I really don't want to deal with
having to keep the internal records matching the public DNS records.

Do you know whether the GPO settings will overwrite/supersede the DHCP and
local settings entirely? I want them to *only* have internal.domain.com.

I was really hoping there would be a netsh command to untick the box so I
could run it as a computer startup script.

I may be off base here in thinking that this issue is causing me problems
..... but they do have some occasional AD issues which may be related to
this.

[Ace Fekay [Microsoft Certified Trainer]]

Yes, it *should* overwrite any existing settings. As anything else, test it
with a test OU and a test computer account that has both, then move it to
the test OU.

I don't think there's a netsh command for this function, which is stated in
KB275553 (provided below).

Or use a reg entry in a script (pardon me if the syntax is incorrect for the
delete entry):
reg delete HKLM\system\currentcontrolset\services\tcpip\parameters /v
"SearchList" /d "domain1.com" /f
reg add HKLM\system\currentcontrolset\services\tcpip\parameters /v
"SearchList" /d "internal.domain1.com" /f

See the following for more info:

How to configure a domain suffix search list on the Domain Name System
clients
http://support.microsoft.com/kb/275553

http://www.experts-exchange.com/OS/M..._23984787.html

But all in all, I think it's administrative overhead. Just another factor
that you have to deal with and something else to go wrong, make sure is
getting applied, etc.

What kind of problems are they having? Accessing their public resources?
Maybe it's related to something else?

I like adding the zone. You can create the zone, then create a delegated
child domain called 'www' and provide the public nameservers on record. This
way if the IP changes, or there is a farm of webservers, as some ISPs have,
it will query the nameservers for the latest IP. Same with FTP, etc. If
their mail is hosted externally, and they're using POP accounts, create a
POP and SMTP host record for their external mailserver. I've done this many
times, and it alleviates having to deal wtih GPOs, reg scripts, testing,
etc. If you like, I can give you a hand with this.

[Lanwench [MVP - Exchange]]

Hey, Ace ... thanks again, man. We're having some problems with GPOs (rsop
on a client shows a lot of errors for 'security') and I was just thinking
this might be a good thing to clean up. It could be a red herring.

With regard to creating an internal zone for domain.com .... well, we have
many public hosts I'd need to create if I wanted ; not just www. We have
Exchange so mail isn't an issue, but and I really want them to work inside
and outside. Since we are now on SBS, we not only have internal.domain.com
as a forward lookup zone in AD, we also have remote.domain.com. It's getting
messy in there for such a tiny office!

That little tickbox is just bugging me. There must be a way to change just
that. Somewhere, somehow.

Just saw this reply - thank you so much, Nick. And Ace,. I did the 'create
the zone' thing after all. But I may try this suggestion anyway.

[Ace Fekay [Microsoft Certified Trainer]]

DNS messes are my forte! :-)

Kidding aside, I would opt for the DNS resolution so your solution is in one
spot, easily seen and administered. The other way adds complexity, but it's
your call.

As for the errors, they may be a red herring, and elsewhere. What's the
eventID? Is it by chance the SciCli 1704? Or rather, what is in the GPOs
that is not default to SBS?

And you are very welcome!

[Uncle_Nick]

Morning LanWench - if you want to kill the devolution tickbox, have a look
at this article

It refers to the registry key controlled by GPO - this will over-ride the
standard internal registry setting at:
HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\UseDomainNameDevolution
You could hit either regkey by script if you didn't want to pull in the
extra ADMX GPO template... and this will force your client to JUST resolve
hosts on
internal.domain.com

The key thing to observe with manual suffix lists, from the technet link
provided by Ace [The MAN] at
http://support.microsoft.com/kb/275553
is that if you distribute a suffix list then it blocks devolution and use of
primary or connection-specific suffixes... so write that list carefully !

[Ace Fekay [Microsoft Certified Trainer]]

btw - It's funny about this type of setting, whereas it is similar the way it works regarding removing other options, to using Restricted Groups with GPOs. It will remove anything else, including the Domain Admins added to the Local Admins if not specifically specified in the Restricted groups policy. I found that out the hard way about 4 years ago when I first implemented. I couldn't log into a workstation after implementing it. When I logged as the local admin, I found the Domain Admins were removed from the Local Admin group! What??? After sitting there for a few minutes, it dawned on me that the policy took complete control. Hmm... So when I started working with the search suffix GPO entry, I tested it and Voila! it did the same thing. Hmmm.... I don't remember reading that in the fine print, but then again, who does?!