Reject connection by machine name, accept connection by DNS alias

Hi,

I have an esoteric problem - not sure the best approach, but here are my
thoughts.

This question has to do with disaster recovery operations and testing. Here
is the scenario:

Two machines:

MachineName_dev
MachineName_prd

Two DNS aliases:

DNSName_dev --> MachineName_dev
DNSName_prd --> MachineName_prd

During disaster testing (DR) and/or actual disaster operations, the PRD
environment points to the DEV environment:

MachineName_dev up as usual
MachineName_prd down

MachineName_prd --> points to MachineName_dev
DNSName_prd --> points to MachineName_dev

Two server processes:

IIS supports a web based application (SAS Activity Based Management)
Other TCP based application (SAS metadata server)

OK, the questions.

During DR, I don't want any inadvertent use of "DEV", as things are
configured for PRD - ABM on DEV machine configured for replicated PRD
backend database, SAS MDS on DEV machine configured for replicated PRD
metadata repository. I don't want our end users doing things in the DR
environment, thinking it's DEV, and messing up the PRD environment when
reverting back to PRD configuration.

I can manage the DNS connection requests by temporarily deleting the DEV
alias. But I can't control direct connection by the DEV machine name.

IIS - is there a way to reject incoming requests based on incoming server
name, accepting http://MachineName_prd/whatever and
http://DNSName_prd/whatever, but rejecting http://MachineName_dev/whatever
and http://DNSName_dev/whatever. I'm thinking URLscan could be used here.

All TCP connections - a better (?) approach may be to reject client
connection requests by Machine_dev, but allow connection requests via
DNSName. I can then shutdown all connection requests to DEV during DR.

Of course, if I implement #2, I have to consider all scenarios, such as
network drive mapping to these machines (public shares are used to access
key directories on these machines). To do this, AFAIK we'd need to
implement http://support.microsoft.com/kb/281308/en-us.

Thanks for any advice you can provide.

Regards,
Scott

P.S.: I'm not the network administrator, and know just enough to be
dangerous. Any advice given I'll have to forward to our network admins for
consideration.

Yes , you are right
it is esoteric

may be it helps inverting rd

regards jk

Thanks Juergen, not sure 1) what "inverting rd" means, or 2) if it was a
serious reply.

regards sb

"Juergen Kluth" <jkluth-(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Yes , you are right
> it is esoteric
>
> may be it helps inverting rd
>
> regards jk
>

I don't think anyone is even going to understand the scenario you are trying
to "paint".
I know that is doesn't make any sense to me.

--
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.
-----------------------------------------------------

"Scott Bass" <sas_l_739 at yahoo dot com dot au> wrote in message
news:492521ba$0$7558$(E-Mail Removed)...
> Thanks Juergen, not sure 1) what "inverting rd" means, or 2) if it was a
> serious reply.
>
> regards sb
>
> "Juergen Kluth" <jkluth-(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Yes , you are right
>> it is esoteric
>>
>> may be it helps inverting rd
>>
>> regards jk
>>
>
>