I’ve got a feeling that the admin console just looks at the sys.dm_database_encryption_keys DMV or some custom view/stored procedure that relates the database name to the database_id and returns the encryption state in SQL, you would not want Epicor storing its own copy of the key that would be bad.
I’m still digging into this and doing some testing, researching.
If you get a chance or have access to, could you run the following on a demo database.
from sys.default_constraints con
left outer join sys.objects t
on con.parent_object_id = t.object_id
left outer join sys.all_columns col
on con.parent_column_id = col.column_id
and con.parent_object_id = col.object_id
This counts the number of columns with default constraints. You can’t use Always On Encryption on these columns, which I was hoping you might be able to do, I suspect this is why Data Masking might have been introduced. It would take a lot of re-architecting on the database and the app side to sort that out, with modern development tools today, you might be in with a chance.
My document is going to include the three areas around TSQL with regards to Encryption. TDE, Backup and Always on encryption. I was hoping that you might be able to utilize Always on Encryption, but alas I don’t think that will fly, at least not yet.
Here is the first cut. I hope you find it useful. I know I enjoyed digging into this a bit deeper, a bit of a can of worms actually. Those MKEs, DEKs, and EKM OMG! The attached document outlines the different encryption methods with various links to examples, it didn’t make sense to reinvent the wheel. I perhaps could have gone into more depth on Column/Cell level encryption, where do you stop… Be as harsh a critic as you need.
Using SQL Server Transparent Data Encryption with E10