Help with DNS alias to new server

Hi,

I have an old PC which is basically running an application which I want to
migrate onto a server.

However there are approx 500 client installs which point to this server by
name.

What I have done so far is copy the application across and have then deleted
the PC's DNS record and Computer Account out of AD. I have added its old IP
to the new server (So it has two IP's its new one and the old PC one). I have
then created an DNS alias record of the old name which points to the old IP
(Now being hosted on new server).

I then had to add the registry key DisableStrictNameChecking and reboot the
new server. So far this all seems to be working...

However I am confused from googling about whether I need to run a tool
called setspn, to basically add the old hostname to the new server's account?
I believe this is only necessary for if startup scripts access the
\\alias\share ... if this is true can anyone tell me why?! I would really
appreciate the help.

"UselessUser" <(E-Mail Removed)> wrote in message
news:BFDBB856-B912-40EE-81BD-(E-Mail Removed)...
> Hi,
>
> I have an old PC which is basically running an application which I want to
> migrate onto a server.
>
> However there are approx 500 client installs which point to this server by
> name.
>
> What I have done so far is copy the application across and have then
> deleted
> the PC's DNS record and Computer Account out of AD. I have added its old
> IP
> to the new server (So it has two IP's its new one and the old PC one). I
> have
> then created an DNS alias record of the old name which points to the old
> IP
> (Now being hosted on new server).
>
> I then had to add the registry key DisableStrictNameChecking and reboot
> the
> new server. So far this all seems to be working...

You did not need to use DisableStrictNameChecking.

1. An Alias (CNAME) Record does not point to an IP#,...it points to an "A"
(Host) Record. You probably created a Host Record instead of an Alias.

2. Since there is no longer any other machine by that name, there is no
situation where you have two names with the same IP# nor do you have two
IP#s on the same name.

Here's all you should have done.

1. Move the Site to the new machine.
2. Eliminate the old machine and remove its AD Account, then remove its DNS
and WINS entry in the DNS and WINS Services. The IP# is irrelevant.
3. Create in DNS an Alias (CNAME) Record using the Name of the machine you
removed. Point to CNAME Record to the "A" Record of the Machine that now
has the web site.
4. If the server already has existing Web Sites on it, then you can use Host
Headers to distinguish them apart. The Host Header is nothing more than the
"name" in the URL. So if the URL is http://www.mysite.com/sales/index.html
then the Host Header is www.mysite.com . It is pretty simple, you should
easily be able to find information on that if you need to. By doing this
you can run an almost unlimted number of sites on the same IP# and Port#.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/downlo...7/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/e...epartners.mspx
-----------------------------------------------------

"Phillip Windell" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 2. Since there is no longer any other machine by that name, there is no
> situation where you have two names with the same IP# nor do you have two
> IP#s on the same name.

If you put mutiple IP#s on the same machine it should only register the
primary IP in DNS. You should not try to add duplicate "A Records" with
different IP#s. Basically you'd just add the IP#s to the machine and leave
it alone and leave DNS alone.
But I think you should just forget about the old IP of the retired machine,
you don't need it for anything. Keep the design "simple" and "under
control".

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

Hi,

Sorry I have not been very clear...

You are correct in that I have created an "A" record to the old server's IP
which is now being hosted on the new server.

The application actually consists of a shared folder with executables and a
few files in, it is not a website (Sorry if I misled you with that).

This is why I used the DisableStrictNameChecking registry change, as per a
Microsoft KB as otherwise when attempting to connect you get a system error
52 because the server service will not accept a connection for a hostname
which isnt its own (Without that reg change)...

Does that make more sense? In this example do I need the "A" record?

"Phillip Windell" wrote:

> "Phillip Windell" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 2. Since there is no longer any other machine by that name, there is no
> > situation where you have two names with the same IP# nor do you have two
> > IP#s on the same name.
>
> If you put mutiple IP#s on the same machine it should only register the
> primary IP in DNS. You should not try to add duplicate "A Records" with
> different IP#s. Basically you'd just add the IP#s to the machine and leave
> it alone and leave DNS alone.
> But I think you should just forget about the old IP of the retired machine,
> you don't need it for anything. Keep the design "simple" and "under
> control".
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
>
>

"UselessUser" <(E-Mail Removed)> wrote in message
news:BF81FF7C-70D9-40B9-B4B5-(E-Mail Removed)...

> This is why I used the DisableStrictNameChecking registry change, as per a
> Microsoft KB as otherwise when attempting to connect you get a system
> error
> 52 because the server service will not accept a connection for a hostname
> which isnt its own (Without that reg change)...

I have never had that problem with executables on the file server. I've
moved them to completely different machines, never even kept the old
name,...they executed fine.

> Does that make more sense? In this example do I need the "A" record?

If the old machine (particularly the "name") is gone from the LAN and no
longer listed in DNS or WINS, you just create a CNAME (Alias) Record in DNS
using that old name and point it to the current A (Host) Record of the
machine that the executable are now shared from. That's it. The IP# is
irrelevant. When the users try to go to the old network path (the old name)
it will resolve to the IP# of the current file server (no matter what the
IP# is) and it should all work fine.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

Hello,

he has 500 station with \\oldname\share\application.exe that he doesn't want
to change on all these stations.
That's why he needs the disablestrictnamechecking, because the new server
see incoming netbios connection on another name than it's own name.

I would anyway clean all station to the new name (or a generic one, through
dfs or network drive letter), at least over time.

--
Cordialement,
Mathieu CHATEAU
http://lordoftheping.blogspot.com


"Phillip Windell" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> "UselessUser" <(E-Mail Removed)> wrote in message
> news:BF81FF7C-70D9-40B9-B4B5-(E-Mail Removed)...
>
>> This is why I used the DisableStrictNameChecking registry change, as per
>> a
>> Microsoft KB as otherwise when attempting to connect you get a system
>> error
>> 52 because the server service will not accept a connection for a hostname
>> which isnt its own (Without that reg change)...
>
> I have never had that problem with executables on the file server. I've
> moved them to completely different machines, never even kept the old
> name,...they executed fine.
>
>> Does that make more sense? In this example do I need the "A" record?
>
> If the old machine (particularly the "name") is gone from the LAN and no
> longer listed in DNS or WINS, you just create a CNAME (Alias) Record in
> DNS using that old name and point it to the current A (Host) Record of the
> machine that the executable are now shared from. That's it. The IP# is
> irrelevant. When the users try to go to the old network path (the old
> name) it will resolve to the IP# of the current file server (no matter
> what the IP# is) and it should all work fine.
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or
> Microsoft, or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
>

Hi,

I am not sure if you fully understand what I am trying to say... Maybe you
should try it because honestly it is not as simple as that!

Examples of what I am facing are here:

http://www.phwinfo.com/forum/showthread.php?t=163254
http://support.microsoft.com/kb/281308

This one is what you suggest and what I have tried!
http://www.bitslope.com/2007/08/smb-...s-aliases.html

http://tech.givemethe.net/node/64

This must do something also..

http://www.softpedia.com/get/System/...NAME-Fix.shtml

I have got it working (However I may attempt to use a CNAME record rather
than the A record setup) but the question really posed is what does setspn do
and do I need that?

"Phillip Windell" wrote:

> "UselessUser" <(E-Mail Removed)> wrote in message
> news:BF81FF7C-70D9-40B9-B4B5-(E-Mail Removed)...
>
> > This is why I used the DisableStrictNameChecking registry change, as per a
> > Microsoft KB as otherwise when attempting to connect you get a system
> > error
> > 52 because the server service will not accept a connection for a hostname
> > which isnt its own (Without that reg change)...
>
> I have never had that problem with executables on the file server. I've
> moved them to completely different machines, never even kept the old
> name,...they executed fine.
>
> > Does that make more sense? In this example do I need the "A" record?
>
> If the old machine (particularly the "name") is gone from the LAN and no
> longer listed in DNS or WINS, you just create a CNAME (Alias) Record in DNS
> using that old name and point it to the current A (Host) Record of the
> machine that the executable are now shared from. That's it. The IP# is
> irrelevant. When the users try to go to the old network path (the old name)
> it will resolve to the IP# of the current file server (no matter what the
> IP# is) and it should all work fine.
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
>
>

"Mathieu CHATEAU" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> he has 500 station with \\oldname\share\application.exe that he doesn't
> want to change on all these stations.
> That's why he needs the disablestrictnamechecking, because the new server
> see incoming netbios connection on another name than it's own name.

Ok, so it is due to the Netbios side of things? I did wonder about that
after I sent the post.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

you got it, if it was iis, no issue except setting the good host header

--
Cordialement,
Mathieu CHATEAU
http://lordoftheping.blogspot.com


"Phillip Windell" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Mathieu CHATEAU" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>> he has 500 station with \\oldname\share\application.exe that he doesn't
>> want to change on all these stations.
>> That's why he needs the disablestrictnamechecking, because the new server
>> see incoming netbios connection on another name than it's own name.
>
> Ok, so it is due to the Netbios side of things? I did wonder about that
> after I sent the post.
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or
> Microsoft, or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
>

No you don't.
I have a file server that respond to two names, i only needed the
disablestrictnamechecking.
It works great
W2K3 cluster

Must be something else

Is it Windows 2003 ? or XP ? seems you spoke about pc...
If it's XP, then the key is useless as pointed out by robert Waters on this
for
Solution:
1) Add the alias in the registry, using HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Services\lanmanserver\parameter s\OptionalNames
Ref: http://www.jsifaq.com/SF/Tips/Tip.aspx?id=0062
2) Disable the Windows XP SP2 'loopback check' ("authentication fails
if the FQDN ... that you use does not match the local computer name"
Ref: http://support.microsoft.com/default...b;en-us;896861

Tips:
Enabling account logon events in local security policy showed login
failure events 537 having a status code 0xC000006D
(STATUS_LOGON_FAILURE); checking eventid.net (http://www.eventid.net/
display.asp?eventid=537&eventno=194&source=Securit y&phase=1) led to
the solution.

Mathieu: Setting DisableStrictNameChecking was not necessary because
XPSP2 by default uses only NTLMv1 (non-kerberos) authentication; if I
had been using a server OS, NTLMv2 would have been enabled and
DisableStrictNameChecking would have been required. But if you hadn't
replied, and I hadn't started my google search using that term, I
never would have gotten anywhere Thanks!


--
Cordialement,
Mathieu CHATEAU
http://lordoftheping.blogspot.com


"UselessUser" <(E-Mail Removed)> wrote in message
newsA6C9DE2-BC7B-415F-86AF-(E-Mail Removed)...
> Hi,
>
> I am not sure if you fully understand what I am trying to say... Maybe you
> should try it because honestly it is not as simple as that!
>
> Examples of what I am facing are here:
>
> http://www.phwinfo.com/forum/showthread.php?t=163254
> http://support.microsoft.com/kb/281308
>
> This one is what you suggest and what I have tried!
> http://www.bitslope.com/2007/08/smb-...s-aliases.html
>
> http://tech.givemethe.net/node/64
>
> This must do something also..
>
> http://www.softpedia.com/get/System/...NAME-Fix.shtml
>
> I have got it working (However I may attempt to use a CNAME record rather
> than the A record setup) but the question really posed is what does setspn
> do
> and do I need that?
>
> "Phillip Windell" wrote:
>
>> "UselessUser" <(E-Mail Removed)> wrote in message
>> news:BF81FF7C-70D9-40B9-B4B5-(E-Mail Removed)...
>>
>> > This is why I used the DisableStrictNameChecking registry change, as
>> > per a
>> > Microsoft KB as otherwise when attempting to connect you get a system
>> > error
>> > 52 because the server service will not accept a connection for a
>> > hostname
>> > which isnt its own (Without that reg change)...
>>
>> I have never had that problem with executables on the file server. I've
>> moved them to completely different machines, never even kept the old
>> name,...they executed fine.
>>
>> > Does that make more sense? In this example do I need the "A" record?
>>
>> If the old machine (particularly the "name") is gone from the LAN and no
>> longer listed in DNS or WINS, you just create a CNAME (Alias) Record in
>> DNS
>> using that old name and point it to the current A (Host) Record of the
>> machine that the executable are now shared from. That's it. The IP# is
>> irrelevant. When the users try to go to the old network path (the old
>> name)
>> it will resolve to the IP# of the current file server (no matter what the
>> IP# is) and it should all work fine.
>>
>> --
>> Phillip Windell
>> www.wandtv.com
>>
>> The views expressed, are my own and not those of my employer, or
>> Microsoft,
>> or anyone else associated with me, including my cats.
>> -----------------------------------------------------
>>
>>
>>