Internal Namespace Issue

Discussion in 'DNS Server' started by Craig Johnson, Apr 1, 2009.

  1. We have inherited an internal namespace that was created by an admin that is
    no longer with our company. The namespace already exists, and is registered
    to another company on the web. This is now creating problems when we want to
    issue certificates for our Exchange and OCS servers. If we purchase a 3rd
    party cert we cannot add the additional internal FQDN to support the clients
    connecting internally.

    I was just wondering if anyone had any suggestions.
    Craig Johnson, Apr 1, 2009
    1. Advertisements

  2. What versions & SP levels of everything do you run? Is Exchange running on a
    DC? A domain rename may be possible, although it is not for the faint of

    I'm not an SSL expert so I can't address that.
    Lanwench [MVP - Exchange], Apr 1, 2009
    1. Advertisements

  3. Your internal Active Directory Domain Name has absolutely nothing to do with
    the Internet directly. Simply come up with a new Name for the *public*
    presents and leave the AD Name the way it is. At the very worst you just
    won't be able to access the website of that particular company without
    creating a "www" A Record in you AD Zone with their IP#,...but if you have
    no need to interact with that company then don't worry about it.

    On your DNS you create a 2-Zone Split-DNS to cover the DNS for both your AD
    Zone and you Public Zone.

    For your Certificates, is like this....if this is primarily used against
    your Public FQDN then you do what I said above (Public FQDN spelled
    differently then the AD FQDN) then you are covered. If you do the certs
    against your AD FQDN and all the "activity" surrounding it is done only
    within your internal network,...then pick a good Server for the job and
    install the Windows Certificate Services and issue your own Certificates
    instead of going third-party.

    Renaming the Domain is possible but dangerous, Lanwench said.
    It would probably be just as easy to create a whole new Domain and use the
    ADMT to migrate everything to the new one and eliminate the old one. When
    creating the new Domain you have the opportunity to choose whether you want
    the AD FQDN and the Public FQDN to be spelled the same way of not. That is
    a personal preference with "consequences" in either choice,...but keep in
    mind that they are two entriely *different* things and have nothing to do
    with each other. They just both happen to share the term "domain" between

    Phillip Windell

    The views expressed, are my own and not those of my employer, or Microsoft,
    or anyone else associated with me, including my cats.
    Phillip Windell, Apr 1, 2009
  4. Thank you for your response... First off, renaming the domain is not an
    option. I don't need anymore headaches.

    My problem is... We have Exch07 deployed and it needs to be accessible by
    Outlook from both the inside and outside. So, we created a verisign cert to
    handle the external connections, however, the internal outlook clients are
    resolving to the FQDN of the server name and the AD domain, thus generating a
    cert warning. Just an inconvenience that we'd like to eliminate.
    Craig Johnson, Apr 1, 2009
  5. Ok,..well I don't know what to tell you there. Worse yet I have no
    experience with Ex2007 (probably never will). They will probably be on
    Ex2010 or Ex2012 before we ever replace our Ex2003.

    I would not rename the Domain. I would create a new Domain along side of it
    and mirgate over to the new using ADMT. Exchange is always going to make
    that a hassel in any case, way around that.

    Phillip Windell

    The views expressed, are my own and not those of my employer, or Microsoft,
    or anyone else associated with me, including my cats.
    Phillip Windell, Apr 1, 2009
  6. Then it sounds like something is screwed up somewhere. Your internal Outlook
    users should be connecting to - which should not
    exist on the public Internet. They should use only the private/internal DNS
    server IP address(es) in their ipconfigs, so there's no way that should resolve to anything outside your LAN.

    Users who connect using OL Anywhere should also be connecting to - using the SSL Certificate for the public
    FQDN/autodiscover, which proxies the information to -

    I suggest you post in to confirm your
    current settings are corerct.
    Lanwench [MVP - Exchange], Apr 1, 2009
  7. Actually, Craig, funny you've posted about this issue. I have a client with
    an internal domain name that is registered publicly with an entity in
    another country. I came in after the fact. Someone else had set it up.

    Keep in mind the cert needs to be for a UCC SAN certificate (unified
    communications certificate for Subject Alternative Name) for Exchange 2007
    and Outlook Anywhere to work. This means the cert must support multiple
    names. This is necessary for outlook Anywhere to work, as well as for
    ActiveSync Windows Mobile handhelds.

    When I created the cert, I had to specify it was for the following names: (for the public mail server name) (for the actual internal name that Outlook
    uses in the mailserver namefield)
    exchangeserver (the NetBIOS name for Exchange) (the public record for Outlook autodiscover

    We received a reply from the cert company that the "" name
    is registered elsewhere and they could not issue the cert. I told them to
    keep the order on hold, I will migrate the domain this weekend to a fresh
    domain, and recreate a new cert wtih the new name.

    It is a major PITA (pain in the rump), but is what it is, it's not what
    it's not, and it's what has to be done...

    Oh well... I wish you luck with your migration.


    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 for regional support phone numbers.
    Ace Fekay [Microsoft Certified Trainer], Apr 1, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.