changing a domain name

Our local domain is a top level domain (company.com). We don't actually own company.com on the web so our websites are mycompany.com. This has proved to be problematic for a variety of reasons. The latest find has been an exchange issue. That said I am thinking of proposing we change the domain name from company.com to either company.local, mycompany.local. I am leaning on doing the mycompany.local. Has anyone ever done this? We have about 75 computers and 20 servers. We have mostly XP clients. Most of our servers are either 2000 or 2003 with 1 2008 box. We are planning to upgrade our 2000 boxes soon. Our DCs are Windows 2003.

Find more posts tagged with

Comments

Essendon

I havent done this either, but I have this link saved from my self-study > Domain Rename Technical Reference: Active Directory

Should be good (I hope!) experience for you.

Bl8ckr0uter

Honestly I am pretty pissed off about the whole situation. I mean all of this is because I am trying to get DROIDS to talk to our mail server. I mean honestly. I am about ready to give up on this because it is going to be technically impractical. Changing a domain name is a major thing to do for just 6-7 phones.

qwertyiop

Maybe I missed something but whats the problem with your Droids connecting to Exchange?

Bl8ckr0uter

qwertyiop wrote: »

Maybe I missed something but whats the problem with your Droids connecting to Exchange?

In short, the UCC cert won't work because we our internal mail server cannot be reached via a FQDN. Put a different way, out internal domain name is a top level domain which we do not own, therefore the CSR keeps bombing out.

Here is my full thread about it. Skip to the end:
http://www.techexams.net/forums/off-topic/57055-exchange-2k7-touchdown.html

Devilsbane

knwminus wrote: »

Honestly I am pretty pissed off about the whole situation. I mean all of this is because I am trying to get DROIDS to talk to our mail server. I mean honestly. I am about ready to give up on this because it is going to be technically impractical. Changing a domain name is a major thing to do for just 6-7 phones.

It is a major thing to do period and comes with great risks. I was working on a project for school which required setting up AD. I didn't make the disk large enough in for my VM so I couldn't install IIS. The guy I was working with had a bigger disk and since our projects were basically identical I decided it would be easier to just take his and keep working. I spent hours trying to figure out how to change the domain name and finally threw in the towel and started over.

I agree it shouldn't be done for just a few droids. But you should really have your own domain name anyway. If not today, it is bound to happen someday so maybe this could be the driving force?

undomiel

Exchange 2007 is what you're running, right? That prevents a rename, you'll have to do a migration to a brand new domain. The Microsoft Exchange System Attendant service does not start on a computer that is running Exchange Server 2007 after you rename a Windows Server 2003 domain

Mojo_666

The domain name should not cause any issue with your mail domain, so you should be able to work around it using DNS, domain renames are not to be taken lightly but they are doable although very few people have done them.
This is the best write up I have seen on how it actually went down.

Active Directory Domain Rename - Not Difficult At All | 1 of 10

Bl8ckr0uter

If I am doing something wrong please enlighten me but I can tell you that when I enter the CSR into Godaddys request tool it says you must use a FQDN. Like I said we don't own the top level domain that AD is using. If you know of any other ways to fix this help a brother out lol.

Mojo_666

knwminus wrote: »

If I am doing something wrong please enlighten me but I can tell you that when I enter the CSR into Godaddys request tool it says you must use a FQDN. Like I said we don't own the top level domain that AD is using. If you know of any other ways to fix this help a brother out lol.

When you configure the MX records at a site like go daddy you typically configure a HOST A and then the MX

So say your email domain is mycompany.com you would configure a host A for mail.mycompany.com and point it to your email servers external facing IP

Then you configure the MX to point at mail.mycompany.com (an bonafide FQDN), which in turn resolves to the IP........make sense?

Bl8ckr0uter

Mojo_666 wrote: »

When you configure the MX records at a site like go daddy you typically configure a HOST A and then the MX

So say your email domain is mycompany.com you would configure a host A for mail.mycompany.com and point it to your email servers external facing IP

Then you configure the MX to point at mail.mycompany.com (an bonafide FQDN), which in turn resolves to the IP........make sense?

You lost me. I am not configuring the host record or the mx record I am submitting a CSR to get a certificate. We have one exchange server to servers as all roles (including CAS). So what I was expecting to do is go on our exchange and go into IIS and generate the CSR. That is easy to do and works fine. The problem is when I paste the CSR I get an error stating that:

You must use a fully-qualified primary domain name for UCC Certificate Request.

Now our internal domain is company.com. We don't own nor do we have any control over company.com. Our websites are mycompany.com (which we have full control over). I have an A record the points to owa.mycompany.com which I wanted to point in our firewall to mailserver.company.com internally. This did not work since as it stands right now, we are still using the self assigned certificate and you cannot use that with owa (which you need to configure so you can use activesync

). That's where it stands now. If I am missing something let me know but I think it won't work because we need to own the FQDN of owa.COMPANY.com and we don't.

Mojo_666

knwminus wrote: »

Now our internal domain is company.com. We don't own nor do we have any control over company.com. Our websites are mycompany.com (which we have full control over). I have an A record the points to owa.mycompany.com which I wanted to point in our firewall to mailserver.company.com internally. This did not work since as it stands right now, we are still using the self assigned certificate and you cannot use that with owa (which you need to configure so you can use activesync ). That's where it stands now. If I am missing something let me know but I think it won't work because we need to own the FQDN of owa.COMPANY.com and we don't.

So if you own the domain mycompany.com, then the certificate you request should be for that or rather owa.mycompany.com? Ah I see why does the firewall need to look at mailserver.company.com? or rather why does the firewall require a cert? would they actually issue one if your domain was call company.local?

Bl8ckr0uter

Mojo_666 wrote: »

So if you own the domain mycompany.com, then the certificate you request should be for that or rather owa.mycompany.com? where is company.com coming into it?

Company.com is out internal domain name. We I generate the request, it comes from mail.company.com (name of our exchange server). mail.company.com does not exist on the internet. company.com does but we don't own it. Company.com internally is ours but externally is some dudes.

Mojo_666

knwminus wrote: »

Company.com is out internal domain name. We I generate the request, it comes from mail.company.com (name of our exchange server). mail.company.com does not exist on the internet. company.com does but we don't own it. Company.com internally is ours but externally is some dudes.

Ok say for example you had an internal domian called company.local and your email domain was corp.com and all the URL's your external clients typed was xxx.corp.com then all your certificates would need to reflect what the users typed (corp.com) and you could buy these from a CA, (godaddy for example) no problem because you own corp.com, your internal domain name does not come in to it, this is what I do not understand?

Bl8ckr0uter

That's what I don't understand either. My only assumption is that because most people have more than one exchange server and they have a dedicated CAS then possibly it is simply just common with UCC certs to use an external domain. I am not sure. I have only been support exchange for 4 days lol

Mojo_666

knwminus wrote: »

That's what I don't understand either. My only assumption is that because most people have more than one exchange server and they have a dedicated CAS then possibly it is simply just common with UCC certs to use an external domain. I am not sure. I have only been support exchange for 4 days lol

Are you generating a request from the server by chance?

Bl8ckr0uter

Mojo_666 wrote: »

Are you generating a request from the server by chance?

Yea I mean is there another way to do it? </noob>

Mojo_666

knwminus wrote: »

Yea I mean is there another way to do it? </noob>

That explains it then, you would use that typically if you were running your own CA. Not sure about go daddy but you should simply be able to go and buy a certificate based on the domains you own just from your control panel when logged in to their site...it's been a few years since I had to buy a cert, but I am sure you will figure it out.

Bl8ckr0uter

Mojo_666 wrote: »

That explains it then, you would use that typically if you were running your own CA. Not sure about go daddy but you should simply be able to go and buy a certificate based on the domains you own just from your control panel when logged in to their site...it's been a few years since I had to buy a cert, but I am sure you will figure it out.

so basically you are saying we need our own CA aka we need PKI?

Mojo_666

knwminus wrote: »

so basically you are saying we need our own CA aka we need PKI?

No, you need to go to a public certificate authority and buy a certificate for whateveryouneed.mycompany.com

What is the certificate for?

dynamik

No dude, just go to GoDaddy or whoever and get a cert for whatever the publicly-accessible FQDN is. You are making this 1000x more complicated than it needs to be. You could make mail.whatever.com point to a firewall that forwards to your mail server, and you'd be fine.

Edit: Too slow

Bl8ckr0uter

Mojo_666 wrote: »

No, you need to go to a public certificate authority and buy a certificate for whateveryouneed.mycompany.com

What is the certificate for?

A ucc cert for OWA, ActiveSync and Autodiscovery.

Mojo_666

knwminus wrote: »

A ucc cert for OWA, ActiveSync and Autodiscovery.

You might want to consider buying a wild card cert then save on buying multiple certs, but i'm not a cert guru so do some research before you buy.

Bl8ckr0uter

Mojo_666 wrote: »

You might want to consider buying a wild card cert then save on buying multiple certs, but i'm not a cert guru so do some research before you buy.

We already have a wildcard but that if for a different purpose. The way it was explained to me was that this was different than a wildcard cert. But even still the wildcard out need to be based off of a public domain, ie *.mycompany.com. The cert couldn't use *.mycompany.com and *.company.com which is a problem.

Mojo_666

knwminus wrote: »

We already have a wildcard but that if for a different purpose. The way it was explained to me was that this was different than a wildcard cert. But even still the wildcard out need to be based off of a public domain, ie *.mycompany.com. The cert couldn't use *.mycompany.com and *.company.com which is a problem.

We have established that you do not need company.com, the only reason that is even coming up is because you are doing a request for a certificate from a server with that domain extension all you need to is just install your wildcard certificate into your web server.

How do you think the millions of companies out there with internal domains called domain.local manage considering it is not even resolvable for the internet?

SSL certs for web services need to marry up with the URL being typed into the browser, that is all, nothing to do with local/internal domain names server names or anything else.

leefdaddy

knwminus wrote: »

We already have a wildcard but that if for a different purpose. The way it was explained to me was that this was different than a wildcard cert. But even still the wildcard out need to be based off of a public domain, ie *.mycompany.com. The cert couldn't use *.mycompany.com and *.company.com which is a problem.

You just get one for the internet based domain.

Bl8ckr0uter

Ok. Lets look at it this way. In another thread I was told this:

Claymoore wrote: »

You will need to include the netbios name as well as the FQDN of each server (or service). Since you only have the one server, the names should be something like:

owa.public.com
owa.private.com
owa
autodiscover.public.com
autodiscover.private.com
autodiscover
server.private.com
server

Now I have an A record for OWA.mycompany.com (external). I plan to add the other things to the other names on the cert when I get it. However, I am trying to generate the CSR from the mail server (like Go daddy told me to). As we have established, the internal domain name does not match the external domain name so my question is, how do I generate the CSR? You guys are saying "Just get one for the external domain name" but what do I do about the CSR? Where can I generate that? We do have an external web server that I could make a site called owa.mycompany.com on pretty easily and generate a CSR but would that work? Does the CSR have to be from the mail server?

Maybe I am being an id10t but when I had to get a wildcard cert working in IIS last month we actually created a website called *.mycompany.com, used that to generate the CSR, updated the metadata in IIS and applied the cert and it worked. Since there is no OWA.mycompany.com, should I just make one? Hmm....

Mojo_666

knwminus wrote: »

ad to get a wildcard cert working in IIS last month we actually created a website called *.mycompany.com, used that to generate the CSR, updated the metadata in IIS and applied the cert and it worked. Since there is no OWA.mycompany.com, should I just make one? Hmm....

Is it not the point of a wildcard so you do not have to specify what "*" is? as it represents anything?

RobertKaucher

I think you misunderstand the process... When generating a web server CSR you just provide the name. The external domain name could be anything: howthick.canibe.com, if you want. It is the external domain name that has to belong to you.

Common Name - The Common Name is the fully-qualified domain name - or URL - for which you plan to use your certificate, e.g., the area of your site you wish customers to connect to using SSL. For example, an SSL certificate issued for "www.yourcompanyname.com" will not be valid for "secure.yourcompanyname.com." If the Web address to be used for SSL is "secure.yourcompanyname.com," ensure that the common name submitted in the CSR is "secure.yourcompanyname.com."

http://help.godaddy.com/topic/746/article/5277

Generating a Certificate Signing Request (CSR) - Exchange Server 2007 - Search the Go Daddy Help Center

Bl8ckr0uter

I figured it out.

In 2007 you don't generate the CSR from IIS. You do it from powershell/exchange management console.

Bl8ckr0uter

RobertKaucher wrote: »

Generating a Certificate Signing Request (CSR) - Exchange Server 2007 - Search the Go Daddy Help Center

Yes! This^^^^