Servername same as Domain name

[yeti]

I have a server called "server" and the domain name is "server.com".
So my Servers FQDN is "server.server.com" I am convinced that his is a
"bad thing" but am having trouble finding any KB articles for any side
of the argument. Does anyone have any info on the subject.

Also, I know that best practices and proceedures say that Domain
Controllers should only be domain controllers and not have many other
functions (such as database servers), again I am looking for a KB
article that strongly supports this position.

Last one: Multi-homed domain controllers. Good, bad, or ugly?
Database programmer is convinved that having a DC with 2 NICs on 2
seperate subnets won't affect domain preformance. NIC 1 (192.168.x.y)
to domain, NIC 2 (10.1.q.r) direct connection to database server. I
personally think this is the stupidest idea I've ever heard, but he
wants a "faster", "dedicated" connection between the DC and the
Database server.

If I am wrong on any of these points, please tell me. If I am right,
please help me find some documentation to support my position.

TIA

 

[Joe Richards [MVP]]

1. RE: server name the same as domain name. This may cause confusion if the
samaccountnames are the same because it could impact name to sid conversions. I
am not aware of any public KB articles. But just because there isn't a public KB
article doesn't mean something isn't bad. There are three levels of KB articles,
public, private, and internal. Public is what most people can get to. Private is
what partners like MVPs and directly connected vendors and some companies who
have paid for some extremely expensive support can get. Internal is what only MS
internal folks can get to. Just because you don't see an article doesn't mean
one doesn't exist.

2. You probably won't find a KB that says a DC shouldn't have multiple functions
as well because MS specifically sells a product called Small Business Server
that wraps a bunch of functions together. However, again, this doesn't mean it
is a good thing. The more functions you have on your DC the more vectors that
are availble for compromise. The domain controllers are the bastion of your
domain security. If a single DC is compromised, your entire infrastructure is at
risk. I would rather lose a dozen SQL servers to compromises than a single DC
because that single compromised DC means that every server and workstation in
the domain is now compromised.

3. As for the multihoming. I am not a fan of multihoming because most people
don't configure it properly. If multihoming is configured with only the single
default gateway on the primary NIC and route statements for any needed routing
on the secondary it *should* work ok. However you need to be very careful to
verify that DNS registrations are correct or else you will confuse a lot of
clients and the other domain controllers. I would question why there is even a
need for a direct connection to a SQL Server. If it is for auth, there should be
no issue in that traffic going across the network normally assuming your network
is working well and your main NIC isn't saturated. I would question a couple of
items as well. A. How does the SQL Server find the DC? Keeping in mind that you
don't want the DC registering the SQL connection if it is private between those
two. B. If the SQL Server is multihomed, how do you prevent it from simply going
across the main network. C. What happens to the SQL server if it forces all of
its connections across that dedicated connection and that DC pukes or has to be
rebooted for maintenance during the week? DCs are designed to be tin soldiers,
you set up a lot and as they fall down, another one is used by the clients
because they have DC Locator services.

There isn't a person on earth that could get me to set this special dual NIC
setup like this. I have run some very large orgs with some very heavy duty apps
and have never needed direct connections like this. Exchange is the only app
that could come close enough to generate enough traffic to require a direct
connection and I won't configure it that way either, though I will put the GCs
and Exchange servers on the same switch with the same VLAN in a dedicated
logical AD site. I also fight people who want to just hardcode in specific DCs
for use. There are times where it is unavoidable because that is the way the
application is written (such as the Exchange RUS or ADC) and it can't be
corrected because there is a state requirement due to object syncing but in all
other cases, tough find another way. I have said that to many people running
UNIX and JAVA based apps which only have a slot for a single LDAP server to be
entered. They tend to front end that capability then. The folks that tend to
want to build apps this way are either lazy or simply bad application folks.

joe

 

[yeti]

I somewhat oversimplified my "last one" question. Basically the
programmer wants to have a server in a seperate phyisical location from
the main data center. This server will be a "replication server" where
all the database info is replicated to and incase of disaster in the
server room. The second NIC in this server would be just for the
replication of the data and we want to keep this large amout of traffic
off the normal LAN. This server will only run the database and service
client request if the server room blows up. The problem is he also
wants this to be a domain controller. Obviousally, if this is a DC,
it will always be servicing client request, and would continue to do so
incase of server room disaster. Mostly I was worried about the
mulit-homed DC issue, as I was afraid it would cause DNS and AD
replication issues.

This is a weird corporate politics issue. The last IT manager was
fired due to a massive infistructure failure. The main application
programmer is stepping in and the suits are giving him whatever he
wants without question. I am just a droid with a good understanding of
the theory but not so much practicle experiance. The programmer is
going to be gone in 6 months or so, and I want to have as much
documentation now saying "you should not do this and this is why" so
that when there is all kind of network issues I can point to my
documentation and say "I am not responsible because I pointed out that
this probally would not work very good"

So anyways, thank you for clearing up some of what I needed.