Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 527
  • Last Modified:

Domain rename 2003 Mixed Mode vs 2000 Native Mode

We have 2 Domains:
The old one is "xyz.com" and is running on a 2000 domain controller that no one authenticates to any more. AD is in 2000 native mode. This domain is a listed domain in "whois" with networksolutions.com and I feel we really should be using it.

The second one is "xyz.local" and is running on two 2003 domain controllers in mixed mode. All the staff authenticates to this domain. One of the DC's also runs Exchange 2003 but is not yet our primary mail server. It's just there for testing before we switch over from an older legacy system.

What I want to do is to move everything back to the xyz.com domain. For all practical purposes I don't even need to have xyz.com's DC on as it's an older box that is not reliable.

The Exchange application could be un-installed if that would make things more do-able.

There are 3 other member servers still running 2000 that will be upgraded to 2003 soon.

I will be having external OWA clients logging into Exchange in the future so will need to set up CA and SSL then.

What's my best option ?
  • 3
  • 2
  • 2
3 Solutions

Is it possible to create trust relationships between the two domains? If your 2003 domain/forest only has 2003 dc's then you should go to functional level 2003 for the domain and forest. You can then use ADMT to migrate between domains.


You can also change the name of your w2k3 domain. See this link: http://www.petri.co.il/windows_2003_domain_rename.htm
What has to be done with Exchange see this link:
note that a windows "domain" name and your publically registered domain name with network solutions are two totally different things.  they just both have the name "domain".  one is a windows domain name, and the other is your public dns domain name.  If you want them both to have the same name "xyz.com" that is OK and perfictally acceptable (some will dissagree however).   The trick is setting up your DNS correctly.  you will have two seperate dns servers for the xyz.com domain name (one public, one private).  the public one will probably be hosted by network solutions, and the private one will be hosted by you and used only by your LAN clients.  nobody from the outside should have access to or be pointed to your private (windows) dns server.

the public server will resolve to your public dns records and host our MX record
ex.  www.xyz.com will resolve to where is the public address of your www server

the private server will resolve to your private IPS:
ex.   dc1.xyz.com will resolve to where is the private IP of your domain controller.
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Of course someone will disagree that you have the same name insided and outside :-) The problem will be mostly for the users since they will have a problem to know when they are using a resource inside or outside since they will have the same name.
with proper dns configuration it will be (and should be) transparent to users.   for example, if users want to go to your www site they should access it the same way from inside and outside the network by going to www.abc.com.  if you use  abc.local as the dns naming scheme inside the office they will be confused since they will have to know TWO DNS addresses for everything. For example, if a user is at home they will access the site by going to www.abc.com, but if they are in the office they will have to think "oh, im in the office right now, so i will have to access our site by going to www.abc.local instead of www.abc.com like i do when im at home." Using two seperate dns schemes is more confusing for users, not the other way around. 1 is simpler than 2 always.  the trick is or the system engineer to do the thinking, not the users. After all, thats what we get paid for.
Yes that is true if they shoul access the same server from inside and outside but normally you have a public web-server that is accessed with www.abc.com that is in a DMZ while users inside use an intranet server www.abc.local. If you have the same name on both of them you most likely will not have the same content. You will not be able to connect to print servers and shares externally that is available internally but if you use the same name on the servers then users will get confused and ask why they can not do this or that.
If you have users that need to access from home they should do so via VPN that will connect them to the internal network and then they already know all the resources that is available to them and they will not get confused and think that they can use the rescources on a public web server.
Ok, I think that this post may be getting off-topic a little from what the customer wants. The customer just wants to migrate to another domain. I understand and appreciate what everyone is saying about internal and public domain names and whether to keep them seperate or the same.

Just a tip on that though, you can have the same domain name internally and externally with seperate DNS infrastructures. You can add an A record on your internal DNS to reference "www" and point to your web server so your users do not have to remember two names.

This post can go in many directions, but let's help the customer by providing best practices and documentation.
There are some articles referencing this:

DNS Namespace Planning:

The following is an excerpt from an article with Small Business server but the naming practices are the same with 2000 and 2003 domains

Three practical methods to name the DNS domain are: • Make the name a private domain name that is used for name resolution on the internal Small Business Server network. This name is usually configured with the first-level domain of .local. At the present time, the .local domain name is not registered on the Internet.
• Make the name a sub-domain of a publicly registered domain name. For example, if the publicly registered domain name is Contoso.com, a sub-domain of Corp.contoso.com can be used.
• Make the name the same as a publicly registered domain name.
Most Small Business Server customers should use the first method. The following list describes some of the advantages when you use a separate and private domain name for the local Small Business Server network: • The management of the local namespace is controlled by the Small Business Server Server. When you use a private FQDN for local DNS name resolution, the DNS server becomes the start of authority for the local domain. This result means that a query to external DNS root servers is not required for local resource name resolution.  
• The security may be increased for your DNS server by not enabling zone transfers by means of the zone transfer properties of the forward lookup zone. Because dynamic registration of internal hosts can occur with the DNS server, if you disable the zone transfers from external clients, you can limit the exposure of internal host names to the Internet.
• The natural separation of internal and external networks occurs because of the use of a separate internal namespace. A client query generated from the Internet for www.contoso.local does not return any valid domain information because .local, at the present time, is not a registered domain name. However, by using the Web Publishing rules in Internet Security and Acceleration (ISA) Server, internal Web sites can be hosted externally and viewed by using resolvable domain names. This hosting still requires a registered domain name as well as the appropriate public DNS records that resolve to the external IP address of Small Business Server. Refer to "Configuring Publishing" in ISA Server Help for more information about Web Publishing rules.
The disadvantages of using the sub-domain of a publicly registered domain name or a publicly registered domain name include, but may not be limited to, the following issues: • Internal clients may be able to resolve resources on the internal domain, however, queries to external resources of the domain are not resolved by the DNS server. For example, if the internal network namespace is configured by using the publicly registered domain name of Contoso.com, only resources that have "A" (Host) records in the forward lookup zone for Contoso.com are available to local clients. This behavior can pose a problem if Contoso.com hosts resources, such as, a web server by means of an external provider or Internet service provider (ISP). Any queries from internal clients to www.contoso.com are resolved as a negative query by the local DNS server because the "A" record for "www" does not exist in the forward lookup zone for Contoso.com. For clients to access external resources, "A" records must be added to the forward lookup zone of the DNS server for those resources.
• The use of a publicly registered sub-domain name can pose the same problems as described for a publicly registered domain name. If at any time, the start of authority for the registered domain (Contoso.com, in this example) adds records for sub-domains, the currently configured private sub-domain may become public.
Name resolution problems that are created by using a publicly registered domain name can be avoided by planning the private namespace around a .local first-level domain so that, in this example, Contoso.com and Contoso.local are both available to internal clients, but Contoso.com is only available to external internet clients.



Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 3
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now