We have an old file server (2008 R2) used for data exchange between several devices. Those devices connect to a usual file share. Now we need to use another file server for exchanging data and retire the old server permanently.

However, changing the paths inside the devices would be a major problem. We would prefer to leave them intact. In addition, those devices are critical, and we have to immediately roll everything back should something goes wrong. So the idea we've developed is shutting down the old server, delete its A record from the primary DNS zone and replace it with a CNAME record pointing to the new server. I already did it before while retiring an old file server, and everything went smoothly. However, this time this method doesn't work. If I create a CNAME record and try to access the shared folder using it, I get the error "Windows cannot access PATH". In the same time, if I create another CNAME record with a name that didn't exist before, I can access the new server using it.

I suspect that it has something to do with an existing SPN in AD that points to the old server (HOST/old-server-name). Possibly I can create a new one using setspn command. However, what would happen to the old SPN if I do it? Will it be deleted or overwritten? If I remove the new CNAME record, will that SPN be recreated when the server is booting up? Or should I recreate the SPN manually? Can the old file server be accessed without a valid SPN record or if there is a wrong SPN record pointing to the new server?

P.S. I found some articles that suggest adding some LanMan parameters in the registry on the new server that remove strict checking of names. However, the new server works well with other CNAMEs even without that. I suppose it's not nece