Yeah that would be the way to do it, an initial dynamic one off grant to a role.

In multi subnet having all the IPs registered is correct and by design.

Again you need to use a provider which understands multisubnetfailover option like MSOLEDBSQL and set the MultiSubnetFailover=True connection...

What are your subnet masks then? /24s /25s /26s etc?

Just used to /24s and then 11.89.12.1-11.89.12.255 would be the full single subnet, not having it split in 25/26/27s etc.

Because you have incorrectly setup your infrastructure.

It is all single subnet so you only need 4 IP addresses.

Remove an IP from the WSFC and remove an IP from the listener...

This in Azure?

You setup the cluster / AG as a DNN or a VNN?

If DNN then the setup is right, thats the limitation of DNNs you need to use a...

New server

Restore all your user databases  - Don't do anything with SSISDB, do not backup and restore this, this is what got you into this mess in the first place.

Create...

Again, I still so go and start on a clean environment, going to be your easiest option I think at this stage instead of trying to piece the information provided...

Create a role and grant the execute to the table types once to this role, then when new people need that access grant them access to the role.

            
February 1, 2024 at 9:24 am
            
#4371267

            
            
                                                
        

SP3 - 6300

Then either 6435 or 7029 depending if you use the Azure Connect Features or not.

Oh boy, I think you need to go and read up on how to properly handle the SSISDB.

Someone / some team has a serious learning curve, SSISDB cannot just be...

You can't delete the key.

Go get the old server back, backup the key, restore the key or start the new server again from scratch and reimport all your packages.

So you copied SSISDB from one server to another?

Yeah there's a bunch of steps you need to do to make that happen successfully.

When you first create the catalog on the...

Yes expected.

The download site also states that v19 will not uninstall or change v18 in anyway.

https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver16#download-ssms

The SSMS 19.x installation doesn't upgrade or replace SSMS versions 18.x or earlier....

Ah that time thing may make sense.

All our servers and clients are in UTC so they all match the time stamps in the logs.

As for reading that much data, well...

Logs are captured at server local time.  So if it is 5hours earlier, then the server must be set as your local time -5 hours.