How to uniquely identify SQL instance

Well, it is somewhat possible to have an Instance GUID, but only if you are including [msdb] in your backup / restore process. Assuming that this is indeed the case, then just check the service_broker_guid field in sys.databases for the [msdb] database:

SELECT [service_broker_guid]
FROM   sys.databases
WHERE [name] = N'msdb';

It will be different across each instance, but should be consistent across restores of backups of the same [msdb] database. This even appears to hold true for the Express editions. And while I have not tracked this value across updates and Service Packs, I don't see why it would change unless forced to manually.

If you want to create new SQL Server instances from a "master" set of backup files (including [msdb]) and need the new instances to be seen as different, then just run the following after the initial restore of the system databases:

ALTER DATABASE [msdb] SET NEW_BROKER;

NOTES:

• The service_broker_guid field in sys.databases for the [master] and [model] databases is always set to 00000000-0000-0000-0000-000000000000 and cannot be changed via ALTER DATABASE [{database_name}] SET NEW_BROKER;.

• If you are using this technique to distinguish instances of SQL Server Express LocalDB, then the the service_broker_guid field in sys.databases for the [msdb] database will initially contain the same value for all newly created instances. In this case, you just need to execute ALTER DATABASE [msdb] SET NEW_BROKER;, just like when creating new instances from a backup restore.

There's no logical way to do this. How could you ever distinguish between a SQL Server that has been moved to a new host, and a new one that was created from a copy of another one? You can't, based only on the instance properties and contents.

The only way to do this is to make some information/table/parameter/configuration settings/etc. that keep track of it for you, which you (or someone/something) must keep up-to-date to reflect your MIS changes.

This may not be a complete answer to your question, but at least you will be able to identify that the SQL server has been moved to another host. You can use the date when the SQL Server was installed. It's actually a datetime when "NT AUTHORITY\SYSTEM" was created but it usually works just fine:

SELECT createdate as sql_install_date FROM sys.syslogins where sid = 0x010100000000000512000000

I just found another approach that may work even better. There is a checksum field in a registry that supposed to be unique for every SQL Server installation:

declare @Checksum nvarchar(512)
exec master.dbo.xp_instance_regread N'HKEY_LOCAL_MACHINE', N'SOFTWARE\Microsoft\MSSQLServer\Setup', N'checksum', @Checksum OUTPUT
SELECT @Checksum