Impacts of Changing ONLY a UCS Domain Name

UCS - Univention Corporate Server
#1

We are planning out a company name change. As part of this process we are going to need to change our domain names for various things (Email, Website, internal subdomains etc. Our existing servers both Linux, Unix, UCS and Windows will need to have their domains changed, the hostnames of the servers will not change, but to domain/subdomain on a FQDN will need to be changed.

Example, ucs-0001.operations.bebconsultingservices.com will need to be changed to ucs-0001.operations.b3bconsultingservices.com is a good example of the type of change we are looking to make.

Before we make this change in our Univention Corporate Server environment, we’d like to know what the impacts might/will be? I see there is an LDAP impact with a hostname change, however the hostnames are not changing in our current plan, just the domain/subdomain portion of a FQDN is what we are looking to change.

Our hope is that we won’t need to build a new server with the new domain for each and every existing UCS Server in the old domain. Then have to migrate data for apps and such.

Has any one just changed the domain, and left the hostname intact? Does anyone have a general step by step on how they did their migration? Any suggestions or recommendation is much appreciated.

We are at the planning stage of this project right now, and we have a plan in place for our linux, unix and windows environments . We now are needing to come up with a plan for our UCS/Univention Corporate Server environment.

Thanks!

Edit Domain
Domain & DNS Record Control
Mergen von UCS AD domains
Domain Join Tool - DNS 127.0.0.53 - How to handle it?
#2

Hey,

changing the domain name of a UCS system is something that should normally not be done. Instead setting up a new server with the new domain is usually the preferred choice. Why? Because there are so many things to change, and there’s very little automation.

Here are a couple of things you would have to do from the top of my head:

  • stop all services except for the LDAP server on the master,
  • change the baseconfig variables on the master server for the DNS domain name, the Windows domain, the LDAP base DN
  • rename the LDAP base DN in the LDAP server (possibly by dumping the whole LDAP tree with slapcat, changing the ldif file manually or with tools like sed or Perl, and re-importing that dump into a clean LDAP database),
  • commit all configuration files with »ucr commit«,
  • rename several objects in the LDAP tree which refer to the domain names (e.g. the DNS forward/reverse zone entries),
  • implement similar changes for the Samba 4 LDAP,
  • start the services on the master again,
  • on all other servers: set the baseconfig variables that deal with the domain name, DNS server etc,
  • join all other UCS servers to the new domain,
  • join all Windows servers to the new domain,
  • test everything

Most of these changes are dangerous in the sense that they can leave you in a state where services don’t work, or the synchronization between the servers doesn’t work, and you may find yourself in a situation that’s hard to recover from. That’s why setting up a new server structure with a new domain is the preferred way of implementing such a change.

I’m perfectly aware that setting up a new domain and migrating the existing information (users, groups, shares, DNS entries, etc.) is a lot of work. But so is implementing the aforementioned changes, and those are much riskier. There may be a point where an existing domain contains so much information to migrate that such a manual change of the domain name becomes worthwhile, though.

#3

changed BBCode to Markup

Mastodon