samba - Nov 2018 - No good way to migrate 4.1 on Server A to 4.7.6 on New Server B

Hi Rowland,

The old server is Debian 3.2.101-1 running a compiled-from-source Samba 4.1.0.
The new server I'm trying to migrate to is Ubuntu Server 18.04LTS, running a
package-installed (apt) Samba 4.7.7.

Old server name: isofs 10.4.0.2
New server name: isofs2 10.4.0.3

Domain: ISO.PRIVATE

smb.conf:

[global]
	netbios name = ISOFS2
	realm = ISO.PRIVATE
	server role = active directory domain controller
	workgroup = ISO
	ldap server require strong auth = no #Was required for FSMO transfer from old
server
	dns forwarder = 1.1.1.1
	vfs objects = acl_xattr
	map acl inherit = yes
	hide dot files = yes
	store dos attributes = yes
	idmap_ldb:use rfc2307 = yes
	mangled names = no
	oplocks = no

[netlogon]
	path = /var/lib/samba/sysvol/iso.private/scripts
	read only = No

[sysvol]
	path = /var/lib/samba/sysvol
	read only = No


Where it's at now:

- FSMO transferred to new server. I used Migrate, not Seize, as I hope I can
roll back to the original server if I can't get things working on the new
server by Monday morning.
- GPO manually rsync'd to new server. 
- "samba-tool ntacl sysvolreset" then run on new server, as well as
"samba-tool dbcheck --cross-ncs --reset-well-known-acls --fix --yes".
- Old server demoted via "samba-tool domain demote -Uadministrator"
- Based on your comment below re: DNS updating, I just ran
"samba_dnsupdate" on the both old and new servers. It returned
"No DNS updates needed".

What's happening:

Errors in log.samba on new server:

../source4/librpc/rpc/dcerpc_util.c:737(dcerpc_pipe_auth_recv)
  Failed to bind to uuid e3514235-4b06-11d1-ab04-00c04fc2dcd2 for
ncacn_ip_tcp:10.4.0.3[49152,seal,krb5,target_hostname=d4c15af5-dfd5-4650-95de-c354a7256d15._msdcs.iso.private,abstract_syntax=e3514235-4b06-11d1-ab04-00c04fc2dcd2/0x00000004,localaddress=10.4.0.3]
NT_STATUS_UNSUCCESSFUL
 
On Windows:

Can only log into DOMAIN\administrator. I can run "Active Directory Users
and Computers", add a new user. But cannot log in as a user. Get error
"The trust relationship between this workstation and the primary domain
failed".

RSAT: Group Policy Management says is can't contact the domain controller.




 
-Glenn


On 2018-11-25, 5:23 AM, "Rowland Penny" <rpenny at samba.org>
wrote:

    On Sun, 25 Nov 2018 04:29:26 -0500
    Glenn Bergeron via samba <samba at lists.samba.org> wrote:
    
    > After many, many, many hours of trying, and lots of research both on
    > this list, the Samba Wiki and elsewhere, I think I’ve finally come to
    > the conclusion that there is no way to seamlessly migrate between
    > servers.
    > 
    >  
    > 
    > Backing up and restoring (using samba_backup) doesn’t work.
    > Permissions hell with Windows.
    
    The old samba_backup script wasn't very good and there wasn't
actually
    a restore script. The latest Samba versions have a new way of backing
    up and restoring Samba through samba-tools.
    
    > Joining the new 4.7.7 server to the old 4.1 DC server, waiting for
    > replication, then demoting the old server doesn’t work. It’s missing
    > all the GPO files, RSAT utils either don’t work or barely work (no
    > computer accounts listed for example), and workstations have their
    > System Events log filled with not being able to find or connect to
    > the domain server, DCOM errors relating to permissions, etc. 
    
    When you join a new DC, quite a lot of the required DNS records are not
    created until you restart Samba or until samba_dnsupdate runs.
    As for the GPO problems, They will not be on the new DC until you copy
    them there, this is because Sysvol is not replicated between DC's
    
    > I’m trying to not have to tell all the users that they’re going to
    > have whole new Windows profiles and lose all their settings, because
    > I can’t port anything and I have to start the AD server from scratch.
     
    > 
    > Hasn’t anyone done this with any success? And if so, why isn’t there
    > a solid document somewhere? I’m sorry I sound frustrated, but I’m at
    > my limit with this what should have been a simple migration from old
    > dying server to new server.
    > 
    
    I am sure that this has been done successfully, otherwise this list
    would have been full of posts similar to yours.
    
    Samba is a rapidly changing target and part of your problem could be
    the large jump between your versions, 4.1 to 4.7
    
    What OS are you using ?
    
    Rowland

Update to the below: Amazingly, I now seem to have everything working. All told,
for this migration project, there were a lot of things that had to be manually
fixed after transferring to the new server. The final few things I had to do
tonight seems to have cleared the rest of my issues up. Those were:

- Change the DHCP server on the firewall so it gives out the new server's IP
for the DNS server.
- Shut down old server
- For each user profile, change their roaming profile path to the new server,
from the old one. IE: Changed from \\isofs\profiles\<username> to
\\isofs2\profiles\<username>.

What I tried first and what failed was changing the DNS entry for
"isofs" on both old and new PDC's to isofs2's IP. You would
think that would have worked but I guess not.

I wish I had documented every little silly thing I had to do and fix throughout
this project, but 50 (not really) different things to try I'd spend most of
the time re-writing docs. I guess that answers my question on why no doc has
been written yet for this __

 
-Glenn


On 2018-11-25, 6:04 PM, "Glenn Bergeron" <glenn at
gbitservices.ca> wrote:

    Hi Rowland,
    
    The old server is Debian 3.2.101-1 running a compiled-from-source Samba
4.1.0. The new server I'm trying to migrate to is Ubuntu Server 18.04LTS,
running a package-installed (apt) Samba 4.7.7.
    
    Old server name: isofs 10.4.0.2
    New server name: isofs2 10.4.0.3
    
    Domain: ISO.PRIVATE
    
    smb.conf:
    
    [global]
    	netbios name = ISOFS2
    	realm = ISO.PRIVATE
    	server role = active directory domain controller
    	workgroup = ISO
    	ldap server require strong auth = no #Was required for FSMO transfer from
old server
    	dns forwarder = 1.1.1.1
    	vfs objects = acl_xattr
    	map acl inherit = yes
    	hide dot files = yes
    	store dos attributes = yes
    	idmap_ldb:use rfc2307 = yes
    	mangled names = no
    	oplocks = no
    
    [netlogon]
    	path = /var/lib/samba/sysvol/iso.private/scripts
    	read only = No
    
    [sysvol]
    	path = /var/lib/samba/sysvol
    	read only = No
    
    
    Where it's at now:
    
    - FSMO transferred to new server. I used Migrate, not Seize, as I hope I can
roll back to the original server if I can't get things working on the new
server by Monday morning.
    - GPO manually rsync'd to new server. 
    - "samba-tool ntacl sysvolreset" then run on new server, as well
as "samba-tool dbcheck --cross-ncs --reset-well-known-acls --fix
--yes".
    - Old server demoted via "samba-tool domain demote
-Uadministrator"
    - Based on your comment below re: DNS updating, I just ran
"samba_dnsupdate" on the both old and new servers. It returned
"No DNS updates needed".
    
    What's happening:
    
    Errors in log.samba on new server:
    
    ../source4/librpc/rpc/dcerpc_util.c:737(dcerpc_pipe_auth_recv)
      Failed to bind to uuid e3514235-4b06-11d1-ab04-00c04fc2dcd2 for
ncacn_ip_tcp:10.4.0.3[49152,seal,krb5,target_hostname=d4c15af5-dfd5-4650-95de-c354a7256d15._msdcs.iso.private,abstract_syntax=e3514235-4b06-11d1-ab04-00c04fc2dcd2/0x00000004,localaddress=10.4.0.3]
NT_STATUS_UNSUCCESSFUL
     
    On Windows:
    
    Can only log into DOMAIN\administrator. I can run "Active Directory
Users and Computers", add a new user. But cannot log in as a user. Get
error "The trust relationship between this workstation and the primary
domain failed".
    
    RSAT: Group Policy Management says is can't contact the domain
controller.
    
    
    
    
     
    -Glenn
    
    
    On 2018-11-25, 5:23 AM, "Rowland Penny" <rpenny at
samba.org> wrote:
    
        On Sun, 25 Nov 2018 04:29:26 -0500
        Glenn Bergeron via samba <samba at lists.samba.org> wrote:
        
        > After many, many, many hours of trying, and lots of research both
on
        > this list, the Samba Wiki and elsewhere, I think I’ve finally come
to
        > the conclusion that there is no way to seamlessly migrate between
        > servers.
        > 
        >  
        > 
        > Backing up and restoring (using samba_backup) doesn’t work.
        > Permissions hell with Windows.
        
        The old samba_backup script wasn't very good and there wasn't
actually
        a restore script. The latest Samba versions have a new way of backing
        up and restoring Samba through samba-tools.
        
        > Joining the new 4.7.7 server to the old 4.1 DC server, waiting for
        > replication, then demoting the old server doesn’t work. It’s
missing
        > all the GPO files, RSAT utils either don’t work or barely work (no
        > computer accounts listed for example), and workstations have their
        > System Events log filled with not being able to find or connect to
        > the domain server, DCOM errors relating to permissions, etc. 
        
        When you join a new DC, quite a lot of the required DNS records are not
        created until you restart Samba or until samba_dnsupdate runs.
        As for the GPO problems, They will not be on the new DC until you copy
        them there, this is because Sysvol is not replicated between DC's
        
        > I’m trying to not have to tell all the users that they’re going to
        > have whole new Windows profiles and lose all their settings,
because
        > I can’t port anything and I have to start the AD server from
scratch.
         
        > 
        > Hasn’t anyone done this with any success? And if so, why isn’t
there
        > a solid document somewhere? I’m sorry I sound frustrated, but I’m
at
        > my limit with this what should have been a simple migration from
old
        > dying server to new server.
        > 
        
        I am sure that this has been done successfully, otherwise this list
        would have been full of posts similar to yours.
        
        Samba is a rapidly changing target and part of your problem could be
        the large jump between your versions, 4.1 to 4.7
        
        What OS are you using ?
        
        Rowland

On Sun, 25 Nov 2018 18:04:05 -0500
Glenn Bergeron <glenn at gbitservices.ca> wrote:
> Hi Rowland,
> 
> The old server is Debian 3.2.101-1 running a compiled-from-source
> Samba 4.1.0. The new server I'm trying to migrate to is Ubuntu Server
> 18.04LTS, running a package-installed (apt) Samba 4.7.7.
> 
> Old server name: isofs 10.4.0.2
> New server name: isofs2 10.4.0.3
> 
> Domain: ISO.PRIVATE
> 
> smb.conf:
> 
> [global]
> 	netbios name = ISOFS2
> 	realm = ISO.PRIVATE
> 	server role = active directory domain controller
> 	workgroup = ISO
> 	ldap server require strong auth = no #Was required for FSMO
> transfer from old server dns forwarder = 1.1.1.1
> 	vfs objects = acl_xattr
> 	map acl inherit = yes
> 	hide dot files = yes
> 	store dos attributes = yes
Oh dear, you have confused Samba, 'acl_xattr etc' is built into a DC

Can I suggest you change the [global] part to just this:

[global]
	netbios name = ISOFS2
	realm = ISO.PRIVATE
	server role = active directory domain controller
	workgroup = ISO
	ldap server require strong auth = no #Was required for FSMO transfer from old
server
	dns forwarder = 1.1.1.1
	idmap_ldb:use rfc2307 = yes

> Where it's at now:
> 
> - FSMO transferred to new server. I used Migrate, not Seize, as I
> hope I can roll back to the original server if I can't get things
> working on the new server by Monday morning.
> - GPO manually rsync'd to new server. 
> - "samba-tool ntacl sysvolreset" then run on new server, as well
as
> "samba-tool dbcheck --cross-ncs --reset-well-known-acls --fix
--yes".
Do you sync idmap.ldb as well ?

Rowland

On 2018-11-26, 4:07 AM, "Rowland Penny" <rpenny at samba.org>
wrote:

    > 
    > [global]
    > 	netbios name = ISOFS2
    > 	realm = ISO.PRIVATE
    > 	server role = active directory domain controller
    > 	workgroup = ISO
    > 	ldap server require strong auth = no #Was required for FSMO
    > transfer from old server dns forwarder = 1.1.1.1
    > 	vfs objects = acl_xattr
    > 	map acl inherit = yes
    > 	hide dot files = yes
    > 	store dos attributes = yes
    
    Oh dear, you have confused Samba, 'acl_xattr etc' is built into a DC

    
    Can I suggest you change the [global] part to just this:
    
    [global]
    	netbios name = ISOFS2
    	realm = ISO.PRIVATE
    	server role = active directory domain controller
    	workgroup = ISO
    	ldap server require strong auth = no #Was required for FSMO transfer from
old server
    	dns forwarder = 1.1.1.1
    	idmap_ldb:use rfc2307 = yes



What do you mean by "vfs objects = acl_xattr" is built into a DC?
Unless you mean this is something that's changed in a newer version of Samba
than I originally had this option in. I added " vfs objects =
acl_xattr" long ago on the original server as a result of pain associated
with file permissions constantly being reset to only being writable by the last
person who saved a file on a share. At least, I think that was the reason - it
was a few years ago. It could have also had to do with the fact that, at the
time, there was a couple of shares that OSX machines had to access as well, and
they had their own idea of how to implement SMB.

I don't remember why I needed "map acl inherit = yes", and
"store dos attributes = yes", but they would have been added to solve
a problem. If they're there, then they seem to have worked. At least back
then.

The "hide dot files" also has to do with Macs accessing the shares, as
they drop a file called ".DS_Store" in every directory it touches.
    
    
    Do you sync idmap.ldb as well ?

I probably did afterwards without implicitly looking for that file, by
re-synching what's under /var/lib/samba. After all, things are suddenly
working now - after I did those last steps of changing the DNS on the
workstations to use the new server as its Primary, and changing the roaming
profile paths to reflect "isofs2".

One thing to add though. Now that I've shut off the old server, I'm
getting errors in the logs of the new server about not being able to connect to
- I assume the old server, probably to sync. I thought I prevented that but I
guess I missed a step. What did I miss?


    
    Rowland