(2005-11-24) Connecting The Test Environment To The Production – What Is Your Opinion?
Posted by Jorge on 2005-11-24
- Little to no impact on the current environment (much safer)
- Fallback migration scenario is much simpler
- Object migration is non-destructive
- No sudden introduction of new AD DCs into production environment
- Phased migration is possible
- Direct use of ALL new AD functionalities as no legacy DCs are used
- Ability to install and configure the new AD environment without even it already being used and without impacting current environment and better possibility to implement new wishes/requirements
- Better possibilities to test current available functionalities and applications
- As migration contains more phases to accomplish, much slower
- Current NetBIOS name of NT4 domain cannot be reused. (unless the migration is performed twice using an Interim AD environment, or renaming it after the migration)
- Extra hardware needed for DCs
- Migration tooling needed migrate objects and re-ACL resources
- Objects must be migrated and resources must be re-ACL-ed
- Ability to keep current NetBIOS name of NT4 domain
- Current domain configuration is used
- No extra or very little extra hardware needed
- Quick implementation/migration
- No tooling needed to migrate objects or re-ACL resources
- When doing a software upgrade of DCs those DCs will be impacted and unavailable during a certain period (this is always true for the PDC)
- Eventual non-compatibilities (applications, services, drivers, etc.) on NT4 DCs must be solved by removing or upgrading to new versions prior to upgrading the OS.
- Fallback scenario’s are more difficult
- Limited use of new AD functionalities and only available after removal of all NT4 DCs
- Direct introduction of AD DCs prevents phased migration
- Implementation of AD without disrupting current environment is more difficult to realize
- More difficult to implement new configurations and to cleanup current crap
- Old default configurations may be kept instead of using new default configurations
- Less possibilities to test current available functionalities and applications
____
Building and using the test environment for scenario (2)…
Now, independent of the reason why you want to do an in-place upgrade of the current NT4 domain to an AD domain, to just test the migration you install a new BDC in the production domain and sync it with the PDC. You move that BDC into a test environment, and promote it to a PDC. For testing purposes you install an additional BDC in the test environment. To prepare for the domain upgrade you install 2 freshly installed W2K3 member servers, install and configure them with DNS/WINS/DHCP and configure them with "NT4Emulator" and "NeutralizeNT4Emulator" registry keys. After that reboot the servers!
So it’s time upgrade the NT4 PDC…but before doing so also configure it with the "NT4Emulator" and "NeutralizeNT4Emulator" registry keys and reboot the PDC.
After the PDC is up again the upgrade is started and after a while the first W2K3 DC has been introduced. That same W2K3 is also the first GC and hosts all FSMO roles. Followed by this is the promotion of the 2 W2K3 member servers to AD DCs. After the promotion these new DCs might be configured as GCs and the FSMO roles might be transferred to one of them.
As your environment may consist of legacy clients (you may need to update them first prior installing the first W2K3 DC with latest service packs and/or the DSClient) and W2K/WXP/W2K3 clients and server you may want to test authentication against NT4/W2K3 DCs, only W2K3 DCs and only NT4 DCs. If you are satisfied with the results you could remove the NT4 BDCs and the upgraded W2K3 DC. At this moment you are left with 2 W2K3 DCs and the Forest Functional Level is set to "Windows 2000" (choose if the domain will also contain W2K DCs) or "Windows Server 2003 Interim" (choose if the domain will only contain NT4 and W2K3 DCs). This choice is made during the upgrade of the NT4 PDC to a W2K3 DC. To stop the emulating stuff on the W2K3 DCs the "NT4Emulator" and "NeutralizeNT4Emulator" registry keys are removed and the DCs are rebooted. As soon as W2K/WXP/W2K3 clients and servers detect the W2K3 DCs not emulating anymore these clients and servers will upgrade their secure channel to use Kerberos for authentication instead of using NTLMv2.
So at this moment the migration has been tested and the results are satisfying. However, before doing this in production you just may want to test the (core) applications against an AD domain and additionally test the same applications against an AD domain in Forest Functional Level "Windows Server 2003". So how are you going to do this, if it is not possible to introduce those (core) applications on servers/systems into the test environment?
Now this is a wild and crazy scenario and I would love to know what you’re opinions are?
Discription of the wild and crazy scenario…
So at this moment you have 2 W2K3 DCs hosting a domain that is practically the same as in production (same name, sids, etc.) These servers also host DNS and WINS. Only the two DCs, their names and IPs are different. As you use a server based computing (SBC) solution in your production environment, you install a WXP client and a SBC server in your test environment. On that SBC server you install the front end applications that must communicate with the (Core) back end applications. All servers and clients in the test environment are setup to use only the DNS/WINS servers in the test environment both DNS and WINS will only return the DCs in the test environment as authenticating DCs! (For DNS nothing needs to be done, but for WINS you need to delete the 1Ch record and rebuild it by issuing NBTSTAT -RR on the 2 DCs in the test environment)
DNS and WINS in the production environment and test environment are not connected in any way!
A firewall will be placed between the production environment and the test environment and the following rules:
- No traffic whatsoever is allowed initiated in the production environment to the test environment
- The WXP client and the 2 W2K3 DCs are not allowed to communicate with clients/servers in the production environment
- The SBC server is allowed to communicate with all servers in the production environment except for the NT4 DCs in the production environment
In this scenario the following is true:
- User accounts, passwords, computer accounts, groups and memberships are exactly the same in the production environment and in the test environment
- The systems and users in the test environment will use the DCs in the test environment
- The systems and users in the production environment will use the DCs in the production environment
To test the (core) applications, a user logs onto the WXP client, sets up a session to the SBC server and starts on of the front end apps and that app connects through the firewall to the core application server in the production environment.
As you may see theoretically everything seems OK and it also seems no issues should occur with this. I’m wondering:
- If such scenario will work?
- Has anyone done this before?
- What could go wrong? (assuming the firewall is well configured and the DCs in both environments cannot communicate with each other!)
- If something goes wrong, what are consequences and what is the impact?
I would be very interested in your opinion concerning this wild and crazy scenario, so feel free to post ANY comments!
Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————
Jorge's Quest For Knowledge! 
PlaceHolder_After_Migration said
With permission from Joe Richards, his post was copied from ActiveDir and also posted here by me. Thank you Joe!
———————————————-
If the applications are important enough to be tested, get them into your
test environment. There are times other than domain upgrades, etc that they
will need to be tested as well.
Running test against production data is insane and asking for problems.
If I were a manager of someone who did this, they would be fired. If I was
the employee of a manager who said we had to do this, I would fight it tooth
and nail.
I would liken this to testing a new fix-a-flat mixture. You could put the
gunk into a flat tire on the freeway and run it up to 90 and see if it holds
or you could do it on a test track. If you did due diligence every step
along the way, you probably aren’t going to hurt anything. However, if you
missed just one thing you could hurl off your side of the road and kill a
family of six driving back from seeing grandma. After the fact, people would
be asking you questions like, how did you justify that risk in your head?
There are test environments for a very specific reason.
If you want to test in production, grow a set, sign up for the
responsibility and have at it for real, don’t think that a complicated set
of controls might help alleviate issues because even the set of controls is
being tested.
———————————————–
LikeLike
PlaceHolder_After_Migration said
I know how I think about it and what I
told the client that proposed this. I think your reactions say enough about
the wild idea. The client that proposed this was told by me and a collegue
that although it seems OK, the risks are too high and other alternatives
should be explored like putting the app (although modeled maybe) in the test
environment, etc. The “gut feeling” was not OK (or better yet, it was
wrong), because nothing should be missed (as you explain in your example)
and no mistakes could be made. All alternatives we gave were thrown away.
Main reasons: not possible, to complicated, no time, etc. After a while we
were getting the impression something else was on the agenda… We thought
he had promissed something to management and was trying to get us to say
“yes this wild idea is OK” as that seemed the possible answer to him. And if
something would go wrong guess who he would blame? The guy was not happy
with what we told him. I also advised him to ask the vendors of the app if
these work in a W2K3 environment with a certain functional level (what
issues could be expected) and I advised him to ask Microsoft the same
question as he asked us (with the remark that Microsoft probably is going to
say: “no way, don’t do that!, etc.”) Well, he called Microsoft and guess
what the answer was? DON’T DO THAT!
At that point the started complaining that technicians were not thinking and
helping him to accomplish this migration. (I was just hired for a day to
talk about implementing GPOs and the migration) Although I most certainly
knew the answer people would give, I was still interested WHAT people had to
say about it, but also HOW they would say it!
In the end I told him: “I advise against it, but if you want to, go for it,
cross the highway with your eyes closed! The slightest chance exists you
will survive it, but be prepared as you most probably will become roadkill.
For both you need to take responsibility. It is your decision!”
LikeLike