DHCP and Domain suffix search order

We've got a multiple domain setup where we have a root domain (lets say
fizi.ca with DC's) and two sub-domains for faculty and students (lets say
students.fizi.ca and faculty.fizi.ca both with DC's).

We're working on implementing DNS Scavenging and cleaning up our mess of a
DNS server. Our DHCP server and DNS servers are located in the 'fizi.ca'
domain as well.

When we setup new faculty desktops we create them under 'faculty.fizi.ca'
and when we setup student lab desktops we create them under
'students.fizi.ca' and so those computers A records are placed in the
appropriate domain. When a user comes to our campus and connects to our
wireless or plugs into the wall they will have their A records created under
'fizi.ca'.

I just altered our DHCP Scopes for wireless and setup a new subdomain (no
DC's) called public.fizi.ca. New computers connecting to our wireless are now
placing their A Records into 'public.fizi.ca' which is exactly what we want.
The problem we're having is we put servers related to students under
'students.fizi.ca' and one's for staff under 'faculty.fizi.ca'. Some of those
servers can't be resolved when connected to wireless now if you type in their
name computer name. As an example we have a print server for students with a
FQDN of 'printserver.students.fizi.ca'. When I connect to wireless and
attempt to ping or access '\\printserver' it fails to resolve. If I type in
the FQDN everything is happy.

I configured option 134 "Hostname resolution order" to "0x2 hosts->dns" and
configured option 135 "Domain suffix search order" with "fizi.ca,
students.fizi.ca and faculty.fizi.ca". Shouldn't this solve the problem of
'printserver' not being resovable? Or have I missed a step?

On 5/14/2009 8:55 PM, FiZi wrote:
> I configured option 134 "Hostname resolution order" to "0x2
> hosts->dns" and configured option 135 "Domain suffix search order"
> with "fizi.ca, students.fizi.ca and faculty.fizi.ca". Shouldn't this
> solve the problem of 'printserver' not being resolvable? Or have I
> missed a step? I was hoping not to have to create CNAME records in
> 'fizi.ca' for all our servers.

I would recommend that you query DNS /before/ you broadcast to find
hosts. Doing this should speed up resolution for any thing that is not
in the same domain as the client computer.

I would also set up the search order for the local domain first followed
by the most likely domain (probably the parent domain) and then the
other domains. I.e. a student system would have the following domain
search order:

students.fizi.ca
fizi.ca
faculty.fizi.ca
public.fizi.ca

You may not even want to have all domains listed in the domain search
order for every domain. Do you really want public to search
students.fizi.ca much less faculty.fizi.ca.

Depending on what domain your main / common services are in you may not
even want to have fizi.ca listed at all.

If all else fails, answer these two questions (remembering that each
domain can have it's own domain search order):

1) What domains do you want the local domain to search
2) What order are matches most likely to be in. (Put the most likely
earlier in the list.)



Grant. . . .



Grant. . . .

On 5/15/2009 4:08 AM, Grant Taylor wrote:
> 1) What domains do you want the local domain to search

Something you might consider is setting up some ""magic (service) names
that are domain agnostic.

For example you may want to have systems use the host name of "smtp"
(with out any domain part) to allow the system to use the domain search
order to determine the proper smtp.<domain>.fizi.ca fqdn to resolve to
connect to. That way if a system moves from one domain to another it
will magically find the closest smtp server in it's domain.

Granted this is more important if things are not well connected, say
different campuses. If everything is on a LAN it will not make that
much difference.



Grant. . . .

"FiZi" <> wrote in message news:CF892F3B-AE84-4624-9AB9-...
> Wow I apologize for my spelling. I clearly should have re-read what I typed.
> Wish I could go back and delete/edit my post.
>
> I've corrected my typo's, spelling and thoughts below:
>
>
> We've got a multiple domain setup where we have a root domain (let's say
> fizi.ca with DC's) and two sub-domains for faculty and students (let's say
> students.fizi.ca and faculty.fizi.ca both with DC's).
>
> We're working on implementing DNS Scavenging and cleaning up our mess of a
> DNS server. Our DHCP server and DNS servers are located in the 'fizi.ca'
> domain.
>
> When we setup new faculty desktops we create them under 'faculty.fizi.ca'
> and when we setup student lab desktops we create them under
> 'students.fizi.ca' and so those computers A records are placed in the
> appropriate domain and can resolve any of our other servers. When a user
> comes to our campus and connects to our wireless or plugs intothe wall they
> will have their A records created under 'fizi.ca'.
>
> I just altered our wireless DHCP Scopes and setup a new sub domain (no DC's)
> called public.fizi.ca. New computers connecting to our wireless are now
> placing their A Records into 'public.fizi.ca' which is exactly what we want.
> The problem we're having is we put servers related to students under
> 'students.fizi.ca' and servers for staff under 'faculty.fizi.ca'. Some of
> those servers can't be resolved by their machine name when connected via
> wireless. As an example we have a print server for students with a FQDN of
> 'printserver.students.fizi.ca'. When I connect to wireless and attempt to
> ping 'printserver' or access '\\printserver' it fails to resolve. If I type
> in the FQDN everything is happy. The server has a A record and a PTR record.
>
> I configured option 134 "Hostname resolution order" to "0x2 hosts->dns" and
> configured option 135 "Domain suffix search order" with "fizi.ca,
> students.fizi.ca and faculty.fizi.ca". Shouldn't this solve the problem of
> 'printserver' not being resolvable? Or have I missed a step? I was hoping not
> to have to create CNAME records in 'fizi.ca' for all our servers.


Hello FiZi,

I wouldn't recommend keeping that Option 134. That is changing default behavior, which will work fine if left alone, if all search suffixes are on all machines in the forest. So trying to ping 'printer' which would be 'printserver.students.fizi.ca' will work as long as 'students.fizi.ca' is a Search Suffix.

However if trying to connect by a UNC, that uses NetBIOS or Direct SMB, depending on traffic allowance. If the wireless is blocking NetBIOS and DirectSMB, then it may not be able to connect. WINS will take care of this for you.

Is the wireless client getting an IP on the corp subnet, or is there a specific subnet for the wireless user?

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer


For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

"Efficiency is doing things right; effectiveness is doing the right things." - Peter F. Drucker
http://twitter.com/acefekay