Complicating my AD Scheme -- Request for Advice

  • Thread starter Thread starter Mike Sullivan
  • Start date Start date
M

Mike Sullivan

Our small company is growing. We currently have a single AD domain
structure with 30 workstations. We are setting up two new companies as
DBA's of our existing and would like to save on resources until the new
ventures are profitable. Essentially they will operate as departments of
our company but we need to maintain a certain new image to the outside world
so they are technically different companies. We are running a Mixed Mode
Win2K domain with all Win 2K servers. I never got a chance to convert to
native mode after removing NT4 servers, but don't see any reason I can't do
it now. We have the following setup:

WEB -- DEDICATED to serving our web sites.
ISA -- DEDICATED to firewall, proxy and VPN/RAS
TERM SVR -- DEDICATED Win2K Advanced Server used primarily for Outlook and
Access Front End to SQL Server.
SQL 2K -- Wink 2K Advanced Server (is also a DC, secondary DNS server and
does backup for itself)
EXCHANGE -- THE WORKS (Everything else -- EXCHANGE 2K, DC, DNS, DHCP,
FILE/PRINT/FAX, ANTIVIRUS, BACKUPS, ETC)
25 Win 2K Workstations
5 Win XP Pro Workstations

We obtained 3 servers to integrate into our network, and want to accomplish
the following.

One new server needs to be our new database server, Old database server can
be reused in next step of setup.
New Database server will be loaded with Windows 2003 Enterprise Edition as
OS
Each company will need to have their own exchange servers.
All workstations need to be able to log in to any of the "Companies" from
the login prompt by choosing the domain at the bottom.
Users that use terminal server need to be able to login to any of the
"companies" as well.
Key resources must be accessible from any "Company" With appropriate
permissions, of course.
Each "Company" will use a different back end database, but all running off
the same SQL server.
Downtime needs to be minimal but is acceptable on Sundays.

Proposed solution: (Assume current domain name is company.local)
Original domain will be left with all workstations, ISA server, SQL
server, Terminal server, and the original exchange server, but no longer
running exchange, but no users other than admin and some service accounts.
First company setup will be what has been our existing company.
Weekend 1: Install SQL 2K on new server with new name in existing
domain. Migrate database. Let old server sit powered down for the week.
Weekend 2: Reformat and Setup old database server as new Win2K DC in
new domain called original.company.local. Install Exchange 2K on this
machine. Migrate Exchange from company.local to original.company.local.
Weekend 3: Create newcompany1.company.local and
newcompany2.company.local subdomains using other 2 servers, installing
exchange on each and creating user accounts.

After weekend 3, I would have 4 domains and any workstation would
automatically be able to log into any of them as they are still joined to
the original domain and the others are subdomains. I should be able to
delete user accounts from original domain after weekend 2, but would wait
until weekend 3 for fail-safe reasons. I know I have greatly simplified
this, but am I missing any major funtionality pitfalls or nightmares? My
use backup exec, and I have daily full backups of the exchange and sql
machines rotating for 1 week anyway so I have some fall back. I consider
myself to be a "decent" admin, but although I am patient and can stumble
through anything, this is a pretty major jump and I have very little time as
boss wants weekend 1 to be this weekend. Any feedback even if it is a
thumbs up would be appreciated.
 
I think my first and major thought on this is why go through all of the
trouble to make sub domains of you existing AD structure? If you are
looking to present an image that you have separate companies through
different domain names you can accomplish this through DNS for your web
server and through e-mail accounts in Exchange 2K. I would propose that you
create new OU's (organization units) for each company. Next purchase new
Internet domain names for the different companies. Point all of the new
domain names at your existing web server and use the virtual hosting
capabilities of IIS to delegate the correct domain name to the correct
virtual server. This could be accomplished by using multiple IP addresses
on the web server or by using the HTTP request to control which virtual
server answers the HTTP request. Finally use recipient policy's on the
Exchange server to set the correct e-mail domain name for users in each
company. Recipient policies can be based off of a LDAP query so you can
have Exchange generate e-mail domain names off of which OU a user is located
in.
This configuration I believe will accomplish what you are looking to
achieve. The only caveats are that you are not truly separate organizations
so if you choose to spin off one of your sub companies they will need to
pretty much start from scratch. This problem would also exist in your
proposed solution since you cannot split an active directory domain up. You
could go so far as to create separate AD forests as a way of splitting up
the companies but this would really require much more equipment but the
companies would truly be separate. If you have any questions feel free to
e-mail me or just post a reply.

Sean
 
-----Original Message-----
I think my first and major thought on this is why go through all of the
trouble to make sub domains of you existing AD structure? If you are
looking to present an image that you have separate companies through
different domain names you can accomplish this through DNS for your web
server and through e-mail accounts in Exchange 2K. I would propose that you
create new OU's (organization units) for each company. Next purchase new
Internet domain names for the different companies. Point all of the new
domain names at your existing web server and use the virtual hosting
capabilities of IIS to delegate the correct domain name to the correct
virtual server. This could be accomplished by using multiple IP addresses
on the web server or by using the HTTP request to control which virtual
server answers the HTTP request. Finally use recipient policy's on the
Exchange server to set the correct e-mail domain name for users in each
company. Recipient policies can be based off of a LDAP query so you can
have Exchange generate e-mail domain names off of which OU a user is located
in.
This configuration I believe will accomplish what you are looking to
achieve. The only caveats are that you are not truly separate organizations
so if you choose to spin off one of your sub companies they will need to
pretty much start from scratch. This problem would also exist in your
proposed solution since you cannot split an active directory domain up. You
could go so far as to create separate AD forests as a way of splitting up
the companies but this would really require much more equipment but the
companies would truly be separate. If you have any questions feel free to
e-mail me or just post a reply.

Sean


image to the outside
world any reason I can't
do and want to
accomplish Old database server
can database, but all running
off have very little time
as


.
Click to expand...
Mike,

I read through Sean's reply very quickly but think that
it looks good. I will speak to two points: OUs vs.
Domains and the Exchange situation.


OUs vs. Domains
Typically, with WIN2000 you do not really need sub-
domains like you did with WINNT 4. An Organizational
Unit usually suffices. I would tend to think that OUs
would suffice in your situation. If and when the day
comes that you need to break of those two "DBAs" then you
could create the domains ( either sub-domains, new trees
or entirely new forests ) and use ADMT v2 to move them
over. One advantage of this would be the savings in
hardware ( namely, you would not need to buy at least two
more servers! ). BTW - ADMT is Active Directory
Migration Tool. The one of which I am speaking is
version 2 ( thus, the 'v2' ). There is also a utility
called movetree but ADMT might give you more flexibility.

One of my weaknesses is IIS so I am not able to really
speak to Sean's ideas. They seem valid, though.

Exchange
Sean hit it right on the head. One of the great things
about Exchange 2000 is that one Exchange Server can be
the Authoritative Exchagne Server for
multiple "domains". It all has to do with the Recipient
Policies. I know that I have set it up once where the
determining factor was the "Company Name" attribute.
Take a look at Mark Fugatt's article at the following
links:

http://www.msexchange.org/tutorials/MF002.html
http://www.msexchange.org/tutorials/MF010.html

And here is a link to all of the articles that he has
written:
http://www.msexchange.org/articles_tutorials/author/Mark_F
ugatt/

Please know that if you were to need ( read: require )
truly seperated, distinct security boundaries ( as is
required in some industries ) then you would need to go
with seperate Forests. Domains in the same Forest are
not the security boundaries that they once were. Recall
that all domains in a domain tree explicitly trust one
another. In fact, these trusts are created / updated
when a new domain joins the tree. Furthermore, all
domain trees in a forest trust each other as well. These
trusts are also added / updated when a new tree joins the
forest.

Keep in mind that if you were eventually to go with
seperate Forests for the DBAs then you would need to
install an Exchange Server for each as Exchange 2000
is "restricted" to one Forest. This is due to the Active
Directory Partitions ( aka Naming Contexts ).

HTH,

Cary
 
I was unaware that I could not break off the domains.
Couldn't I just use features from Windows 2003 to rename
the peices as needed, creating a new forest out of them?
This is certainly the road I was planning on in the future
which was one of my key decision points to starting this
way.
 
Back
Top