I'm not sure where to post SSMS bugs anymore - or even look to see if it's a preexisting bug, but I've just found one that cost me several hours: when generating a SAS token from SSMS's object explorer to restore from a backup on blob storage, SSMS does not prompt you to overwrite a pre-existing expired token. As a result, the "generated" token is not saved as a credential and the restore continually fails because it still tries to use the "stuck" expired one. The only way to get SSMS to actually use the new token is to manually drop the old one first by running the following sql:
DROP CREDENTIAL [https://<credential name>]
where <credential name> is typically the URL to the blob storage container, and can be found by running
SELECT name from sys.credentials
Once the stuck token is manually dropped, the user can then go create a new one through object explorer and the restore will actually use it and succeed.
This is a bug because the object explorer makes no attempt to save the generated SAS token as a credential and doesn't notify the user that the token they just generated will not be used.
I believe SSMS should either prompt the user to overwrite the pre-existing credential ("You already have a credential with that name. Would you like to overwrite it with this one?", or at least notify the user that their token cannot be used until they manually drop the expired one.
