Hi all.

I really hope someone can help me on this one. The scenario is as follows:

(my domain I have replaced with "domain" for security)

SQL2012 [Server 2016 Datacenter]
printserver2011 [Server 2008 R2 Enterprise]
SQL2012-backup [Server 2008 R2 Standard]

Recently we moved our SQL2012 server to the cloud. A VM was created in Azure and the SQL DB was created, and log shipped up there. Our database now connects to it via a DNS redirect and works fine. The old local server was renamed to "SQL2012-backup" and still hosts our internal files. We are looking to move our file storage to the cloud as well, but all in due course.

Issue 1
The problems began shortly after the move. As SQL2012 (now SQL2012-backup) was our DC on our Active Directory, I think this is causing issues after the rename. The first problem I noticed was when creating user folders on the server, a couple of machines were pushed the new mapped drive using the group policy, however, most weren't getting it. The idea was to create a "U" drive where users could keep files on a backed up server as opposed to their local machines. It seemed random which machines would accept the new mappings.

Issue 2
Upon further inspection of the server, we have been getting hundreds and hundreds of one specific error in the System log of the SQL2012-backup event viewer:
A Kerberos Error Message was received:
 on logon session 
 Client Time: 
 Server Time: 6:30:49.0000 2/13/2019 Z
 Extended Error: 0xc0000035 KLIN(0)
 Client Realm: 
 Client Name: 
 Server Name: MSSQLSvc/sql2012.internal.domain.com.au:1433
 Target Name: MSSQLSvc/sql2012.internal.domain.com.au:1433@INTERNAL.DOMAIN.COM.AU
 Error Text: 
 File: 9
 Line: fdb
 Error Data is in record data.
Everything else seemed to be working, so I figured this was a "nothing terribly important" error. That was, however, until our mapped "E" drive (where all our documents reside) ceased to be reachable by terminals. I was told on 14/02/2019 that an employee was remotely accessing a VM I have set up for remote work the previous night and around "5:30pm", the E drive disappeared. It was unreachable. When I came in on the 14th, sure enough, our mapped E drive had a big red X on it on every machine. Looking through the logs, I found this error poking out:
The KDC encountered duplicate names while processing a Kerberos authentication request. The duplicate name is MSSQLSvc/sql2012.internal.domain.com.au:1433 (of type DS_SERVICE_PRINCIPAL_NAME). This may result in authentication failures or downgrades to NTLM. In order to prevent this from occuring remove the duplicate entries for MSSQLSvc/sql2012.internal.domain.com.au:1433 in Active Directory.
This error was at 5:31pm.

As a result, the UNC path does not work anymore to \\SQL2012-backup. \\ (and 2, there are 2 nics with concurrent IP's) works fine and displays all the appropriate shares. It's only UNC paths. I had to band-aid fix by disconnecting the mapped drive on each local machine, and reconnecting using the IP. I'm sure this is related.

I asked Dr. Google, and everything points to duplicate SPN's. I did the following and found:
C:\Windows\system32>setspn -X
Checking domain DC=internal,DC=domain,DC=com,DC=au
Processing entry 0
MSSQLSvc/SQL2012.internal.domain.com.au is registered on these accounts:
        CN=Server\, SQL,CN=Users,DC=internal,DC=domain,DC=com,DC=au

MSSQLSvc/SQL2012.internal.domain.com.au:1433 is registered on these accounts:
        CN=Server\, SQL,CN=Users,DC=internal,DC=domain,DC=com,DC=au

found 2 groups of duplicate SPNs.
I'm confused. They have the same name, sure, however, a port is specified to differentiate them (I think). Even then, if I list all SPN's I get:
C:\Windows\system32>setspn -L sql2012
Registered ServicePrincipalNames for CN=SQL2012,CN=Users,DC=internal,DC=domain
So. I'm assuming if I work out this duplicate SPN issue, I can then move onto the mapped drive issue.

Issue 3
We appear to have two AD's running. SQL2012-backup and printserver2011 are both ADs. One is supposed to be the master, the other is supposed to be a backup (there was a third as well, but that server is physically gone). I inherited this setup, so it's my issue now. Is there any way for me to rectify this?

Can anyone shed some light on what's happening here?