The key to understanding how to manage moving a TDE encrypted database from one server to another is to understand that the private key of the certificate is the only key needed to decrypt the Database Encryption Key in the TDE enabled database. The encryption heirarchy below the certificate can contain different values for the keys, as long as it is fully functional. When the TDE Certificate and private key is restored, the server will encrypted it using the DMK in the master database. If a DMK does not exist and you create a new one, then it will protect the certificate private key with the new DMK. When you execute a command to create a DMK, the server encrypts it using the password you provide and also encrypts it using the SMK, so you don't need to create it with the same password because the server can decrypt it when needed using the SMK. As long as each keys in the heirarchy can decrypt the subsequent key, the TDE will work.

The encryption heirarchy in SQL Server is implemented based on the ansi x.917 standard. While backing up and restoring a DMK may not apply to TDE, it works well when restoring a database with column level encryption. If there were no command for backing up the DMK and SMK, then restoring a database with column encryption would require restoring the master database and implementing the same service account on the destination server to regain control of encrypted column data, which is practically rebuilding the server to restore one database.

The key to understanding how to manage moving a TDE encrypted database from one server to another is understanding that the private key of the certificate is the only key needed to decrypt the Database Encryption Key in the TDE enabled database. The encryption heirarchy below the certificate can contain different values for the keys, as long as it is fully functional. When the TDE Certificate and private key is restored, the server will encrypted it using the DMK in the master database. If a DMK does not exist and you create a new one, then it will protect the certificate private key with the new DMK. When you execute a command to create a DMK, the server encrypts it using the password you provide and also encrypts it using the SMK, so you don't need to create it with the same password because the server can decrypt it when needed using the SMK. As long as each keys in the heirarchy can decrypt the subsequent key, the TDE will work.

The encryption heirarchy in SQL Server is implemented based on the ansi x.917 standard. While backing up and restoring a DMK may not apply to TDE, it works well when restoring a database with column level encryption. If there were no command for backing up the DMK and SMK, then restoring a database with column encryption would require restoring the master database and implementing the same service account on the destination server to regain control of encrypted column data, which is practically rebuilding the server to restore one database.

The key to understanding how to manage moving a TDE encrypted database from one server to another is to understand that the private key of the certificate is the only key needed to decrypt the Database Encryption Key in the TDE enabled database. The encryption heirarchy below the certificate can contain different values for the keys, as long as it is fully functional. When the TDE Certificate and private key is restored, the server will encrypted it using the DMK in the master database. If a DMK does not exist and you create a new one, then it will protect the certificate private key with the new DMK. As long as each keys in the heirarchy can decrypt the subsequent key, the TDE will work.

The encryption heirarchy in SQL Server is implemented based on the ansi x.917 standard. While backing up and restoring a DMK may not apply to TDE, it works well when restoring a database with column level encryption. If there were no command for backing up the DMK and SMK, then restoring a database with column encryption would require restoring the master database and implementing the same service account on the destination server to regain control of encrypted column data, which is practically rebuilding the server to restore one database.

The key to understanding how to manage moving a TDE encrypted database from one server to another is to understand that the private key of the certificate is the only key needed to decrypt the Database Encryption Key in the TDE enabled database. The encryption heirarchy below the certificate can contain different values for the keys, as long as it is fully functional. When the TDE Certificate and private key is restored, the server will encrypted it using the DMK in the master database. If a DMK does not exist and you create a new one, then it will protect the certificate private key with the new DMK. When you execute a command to create a DMK, the server encrypts it using the password you provide and also encrypts it using the SMK, so you don't need to create it with the same password because the server can decrypt it when needed using the SMK. As long as each keys in the heirarchy can decrypt the subsequent key, the TDE will work.

The encryption heirarchy in SQL Server is implemented based on the ansi x.917 standard. While backing up and restoring a DMK may not apply to TDE, it works well when restoring a database with column level encryption. If there were no command for backing up the DMK and SMK, then restoring a database with column encryption would require restoring the master database and implementing the same service account on the destination server to regain control of encrypted column data, which is practically rebuilding the server to restore one database.