Q: Sanity checking path to success for AD Takeover with UCS

Hi, I wonder if I might ask for a gentle poke in the right direction.
I’m looking at using Univention-Core as a basic domain controller to take over this role at a small site running an old SBS server.

I’ve reviewed doc hints online → 9.3. Migrating an Active Directory domain to UCS using Univention AD Takeover — Univention Corporate Server - Manual for users and administrators

and I think I am starting off on the wrong foot / or at least I have mistaken understanding of the expected starting point

  • clean install of UCS in a modest sized VM
  • install goes smoothly, boot up, and quite early I am asked to choose from 3 scenarios
  • (1) create new UCS domain
  • (2) join exist UCS domain
  • (3) Join exist MS_AD Domain
    I kind of assumed “hah, I wanted number 3 since we are going to join the exist domain, then do the take over / harvest data and roles from that DC to this DC, then promote the roles / take control of domain / etc.”

After kind of trying to poke in that direction, the process fails, and I think the errors hinted to me that I create a chicken-egg problem with the path I chose.

ie, cannot do takeover if you are already member of domain (?)

so possibly can someone suggest/confrim
assuming I am on a clean UCS instance (ie, I will dump my failed attempt and do a clean fresh install again)
I get hostname assigned fine and DNS from local DNS-DHCP (ie, running on the existing legacy sbs DC)
then I should choose ?which of the 3? options regarding UCS “Domain setup” - do I want to pick “option1, new UCS domain” - let it proceed. Then install the “Domain Takeover” module - then kick off process - it will do all the things it wants to make for successful trajectory?

Sorry for having such a basic question, I hope this makes sense. The docs sort of don’t talk about “here is where you are starting at ground zero” so much as they assume? you are in a ‘good place to start’ - and I am simply not clear what this might actually be.

thank you!

Tim

https://docs.software-univention.de/manual/5.0/de/windows/ad-takeover.html

Hi @timchipman

As per the document you refer to:

The following requirements must be met for the takeover:

The UCS Directory Node (Primary Directory Node) needs to be installed with a unique hostname, not used in the AD domain.

The UCS Directory Node needs to be installed with the same DNS domain name, NetBIOS (pre Windows 2000) domain name and Kerberos realm as the AD domain. It is also recommended to configure the same LDAP base DN.

The UCS Directory Node needs to be installed with a unique IPv4 address in the same IP subnet as the Active Directory domain controller that is used for the takeover.

And then remember about this:

If the system is already a member of an Active Directory Domain, installing the Active Directory Takeover application removes this membership. Therefore, the installation of the Takeover application has to take place only shortly before the actual takeover of the AD domain.

So install UCS within the same network as your current DC. You can join the MS_AD as the takeover app will break that link once run successfully.

Make sure to activate UCS licence!

Install services i.e. DHCP, RADIUS, Print Server, Active Directory-compatible Domain Controller.

REMEMBER TO TAKE A WORKING BACKUP OF YOUR CURRENT DC!
Install and run the AD takeover app.

If the takeover fails, recover your old DC first; there is a good chance changes were made and you might be getting domain issues. Trying AD takeover once again will probably fail with "new DC object already in the directory error - or something to that sound).

Hope this helps

Thank you. I appreciate the feedback. It sounds like I can do either (1) create new or (3) join exist MS_AD_domain and the ‘takeover’ app will push things in the correct direction regardless of what I’ve done. I believe the other requirements are proper (ie, DHCP > assigned IP and localdomain.suffix to match the MS_AD given desired config as per the legacy AD_SBS server.

I think the bit I missed, is that there is a step required to push UCS into ‘core-only free’ license mode - ie, this is not active the case until manually done. I’ll confirm process for this. Then try again.

Part of my anxiety around the cut over process as well - in re-reading carefully - is that I had hoped to ‘try and see if it works’ - is not a reversible process - ie by opening the box and looking inside, I will change the quantum state of the cat in the box. or more accurately, by trying to answer the question of “will the Univention DC takeover go smoothly?” then my old SBS server will be changed as part of this ‘test’ process. regardless of the smooth or not smooth end state of this attempt. Part of the drama at this site, is that the SBS server is in a ‘delicate’ state currently, and almost entirely unmanagable. It still functions (barely?) as DC and FIleserver and VPN server. But RDP and console access are flakey. Ugh. So - "take a good backup of the source server’ before starting / so “you have a good rollback available” is actually nearly impossible, ultimately, and so this whole process is far too delicate.

most likely I cannot execute the test attempt until I have a maintenance window to allow me to do an unclean transiton migration if the UCS_DC_Takeover attempt is a failure. ie,

if the DC_takeover goes smoothly, then happy days
if the DC takeover goes badly, I need to plan on a day of work onsite to force cut over all the workstations, and join them to a new-clean AD_DC_DOMAIN that will be running on a totally different new clean UCS_Core server running a fresh-never-touched-domain with a totally-new-AD_Domain. (This site has ~25 users, mostly with physical desktop PC domain member computers, and joy-of-joy a term server as well which is a domain member). (The config is one that I inherited from prior systemadmin).

ie, the joy of trying to manage an old stale SBS server that is well past its end-of-shelf-life. This is not an issue with UCS, more an issue of Windows_AD server management / SBS server EOL being ignored for too long.

anyhow. I will see how it goes and I’ll update the thread once I have any update. In case this is an instructive / useful case for the archives / and others to learn from (ie, ‘there be dragons, tread carefully’ ?)

Tim

(* footnote - I realize in theory I can do console login, then windows-system-image-backup dump to a USB attached-disk - and it might work - so probably I need to do that before kicking this again. On the off chance it will generate a usable system backup. Ugh. I am so glad this is probably the last non-virtualized server I am managing. or not really managing well, more accurately.)

(* footnote2 - in addition to fix up UCS_License I realize I manually will need to install services as per your hints - ie “DHCP, RADIUS, Print Server, Active Directory-compatible Domain Controller.” - ie - by adding in the “DC_Takeover” app it does not install ‘dependencies’ automagically. So. All doable.)

I feel your pain… abandoned MS Server is a complete nightmare.

We were lucky enough to virtualize our old dc’s before we migrated.

I guess you could try p2v cloning and test installation, without affecting the running server.

Not the best tool but free and it allowed us to take a snapshot of MS2008. We run it in Hyper-V and tested the domain takeover:

Thank you! I am familiar with Disk2VHD and have used it over the years for various P2V migration with success. It is a good tool for sure!
Here I think my drama, is that - console is delicate - system is barely functional - so - I do have in theory weekly windows image backup being dumped to a USB drive. Possibly I will try to find a way to look inside that box and validate if the backups are there - without kicking over the box and “damaging the delicate cat” in the process. Ugh.

I realize maybe I will ask just in case - for those who have used the UCS - DC Migration tool. Do you recommend either of the following scenarios, more or less?

  1. after migrate DC roles to UCS server, and retire the old Windows DC server. Change the name and IP address of the UCS host to match the old windows box. OR add an alias name and IP onto UCS?
  2. don’t fuss with that and don’t try that, it may create drama. Just force clients to connect to \newUCS-DC-server for share files instead of \OldWindowsDC for share-files and get on with some transition in life. (And less risk of entanglement drama of Old<>new being mistaken identities and unwanted side effects?)

thank you all!
Tim

rename (additional dns entry) is done by ad takeover app - you only have to shutdown old windows dc’s

rg
Christian

Nice! that sounds great. Thank you for the added info.
Once I have more update on the tale of my sad tired SBS server I will followup to this thread. Probably will be 2-3 weeks out (approx) unless things go sideways sooner-not-later.

Tim,

I know this might be slightly late but please have a look at this: Looking for Advice on Univention Deployment and Best Practices - #2 by dzidek23

Some of it does not apply, as the UCS 5.2 is already available but planning some things before you start will make things much easier.

Thank you! I just had a look. This all sounds good. I think I am in an ok state (ie, things have not broken yet) and I was able to move forward a clean install of UCS this week / get it on a good-working-free-core license; and get core modules installed. And then did my ‘first pass’ sync of assorted fileserver data from the old-stale-DC onto the new-UCS server, about 150gb of assorted user legacy share data. Next step is to plan the cut over and pull the trigger and jump off the cliff and see if the parachute works or not :slight_smile: - but definitely you are right / that post is great / the advice to “DOCUMENT THINGS!!!” is rather a key one! :slight_smile:

thank you!

Tim