news:e2ZJiRr8JHA.4976@TK2MSFTNGP04.phx.gbl...
> Hi, guys 'n gals -
>
> 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.
>
>
>

> "Lanwench [MVP - Exchange]"
> <lanwe***@heybuddy.donotsendme.unsolicitedmailatyahoo.com> wrote in
> message news:e2ZJiRr8JHA.4976@TK2MSFTNGP04.phx.gbl...
>> Hi, guys 'n gals -
>>
>> 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.
>>
>>
>>
>
>
> Hi Lanwench,
>
> 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.aspx?scid=kb;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
> ======================================================================================================
>
> Ace

news:%23zDgda08JHA.3916@TK2MSFTNGP02.phx.gbl...
>
> 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.

> "Lanwench [MVP - Exchange]"
> <lanwe***@heybuddy.donotsendme.unsolicitedmailatyahoo.com> wrote in
> message news:%23zDgda08JHA.3916@TK2MSFTNGP02.phx.gbl...
>>
>> 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.
>
> 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/Microsoft_Operating_Systems/Q_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.
> Cheers!!
>
> Ace

news:OTLlEo28JHA.1880@TK2MSFTNGP05.phx.gbl...
> Ace Fekay [Microsoft Certified Trainer]
> <ace***@mvps.RemoveThisPart.org> wrote:
>> "Lanwench [MVP - Exchange]"
>> <lanwe***@heybuddy.donotsendme.unsolicitedmailatyahoo.com> wrote in
>> message news:%23zDgda08JHA.3916@TK2MSFTNGP02.phx.gbl...
>>>
>>> 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.
>>
>> 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/Microsoft_Operating_Systems/Q_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.
>> Cheers!!
>>
>> Ace
>
> 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.

"Lanwench [MVP - Exchange]" wrote:

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

> "Lanwench [MVP - Exchange]" wrote:
>
>> 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.
>>
>
> Morning LanWench - if you want to kill the devolution tickbox, have a
> look at this article:
> http://www.insidetheregistry.com/regdatabase/viewvalue.asp?valueid=320
>
> 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 !
>
> Good Luck
> Nick

"Lanwench [MVP - Exchange]" <lanwe***@heybuddy.donotsendme.unsolicitedmailatyahoo.com> wrote in message news:%23eTQDg2$JHA.760@TK2MSFTNGP05.phx.gbl...
> Uncle_Nick <Uncle_N***@discussions.microsoft.com> wrote:
>> "Lanwench [MVP - Exchange]" wrote:
>>
>>> 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.
>>>
>>
>> Morning LanWench - if you want to kill the devolution tickbox, have a
>> look at this article:
>> http://www.insidetheregistry.com/regdatabase/viewvalue.asp?valueid=320
>>
>> 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 !
>>
>> Good Luck
>> Nick
>
> 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.
>
> You both rock.
>
>

:-)