As you have already noted, you cannot follow symbolic links to UNC destinations over the network by default. You can change this behavior though by allowing the "Remote-to-Remote" type in the
symlinkevaluation parameter via fsutil.
But your enterprise sounds rather like a poor idea because it is creating a complex, rarely used structure without a real necessity. If you need to have a storage namespace which is independent from your server's name, have a good look at DFS and try to migrate there - it will save you a lot of headaches with server naming and share placement in the future.
If you happen to own an Windows Server Enterprise license, you will be able to create arbitratily named DFS roots (i.e. you can create a DFS root named like your server), thus allowing you a smooth transition from your current server name based scheme to DFS. Take a look at Microsoft's File Server Migration Toolkit for a number of utilities and guides helping you with the transition.
Alternatively, if you can rename srv1 (which would be the case if you have no services aside from the shares running on it or if you are willing / able to migrate those services away as well), you could follow the procedure which is commonly used for file server migrations:
- copy your data and migrate your shares from srv1 to srv2
- rename srv1 to srv1-old
- create a CNAME record for srv1 in your DNS domain zone pointing to srv2
- set DisableStrictNameChecking on srv2 to allow access to the Server service by an arbitrary computer name (including srv1)
- restart the Server service or reboot srv2
after that, users connecting to
\\srv1\share would access the share on srv2 instead.