Ho avuto lo stesso problema. Dopo aver parlato con il supporto di Azure, hanno scoperto che il problema era causato dal fatto che viene creata una chiave master del database vuota per crittografare le credenziali di archiviazione per il controllo (il controllo è un'impostazione facoltativa).
Tieni presente che le impostazioni di controllo del database vengono ereditate dalle impostazioni del server.
Ad ogni modo, il lavoro che hanno escogitato è stato:
- Disabilita il controllo sul server (o database)
- Rilascia la chiave master del database con
DROP MASTER KEYcomando.
Quindi l'esportazione funziona come previsto. Si spera che Azure risolva presto questo problema in modo che il controllo e l'esportazione possano lavorare insieme.
Aggiornamento del 21 marzo 2017 Soluzione migliore per la SM
Poiché la correzione richiederà del tempo per essere implementata, hanno anche suggerito una soluzione alternativa, che non richiederà alcun passaggio aggiuntivo (come la disabilitazione del controllo o i passaggi del blog) da parte tua per evitare questo problema. Dopo aver abilitato l'auditing, aggiornare la masterkey e impostare la password. L'impostazione di una password per la chiave master esistente ridurrà il problema. Inoltre, l'impostazione della password non influirà sul controllo e continuerà a funzionare. La sintassi per aggiungere la password è la seguente:
-- execute in the user database
ALTER MASTER KEY ADD ENCRYPTION BY PASSWORD = ‘##############’;
Il collegamento ha anche uno script PowerShell che puoi utilizzare per rimuovere l'istruzione SQL offensiva da .bacpac file.
