@Zikato A status message of a CSS engineer in your neck of the woods.
> These Czechs are an amazing nation. It's a pity they weren't there at the creation of the world. They could have advised. But even Czechs can’t read minds, so tell me the case number.
I'm trying to convince another DBA here who is the person who maintains SolarWinds Database Performance Advisor that they don't need a sysadmin account to register instances, and that the DPA instruction manual shows exactly what to do. They keep insisting they need sysadmin, including "you can revoke sysadmin afterwards". Ohhhkaaay. nah thanks.
I just told them to share the screen with me so I could do it
sorry, asked
I'm expecting they will come back and say "but we need sysadmin"
on another matter, we just had a meeting with 7 senior people to discuss whether or not we should open a firewall port for SMTP between this newly deployed SQL Server and the SMTP service provider we've been using for almost 10 years.
FML
and in yet more news, just received this gem:
> Surface Command breaks down data silos by combining comprehensive external attack surface monitoring with internal asset visibility across hybrid environments to build a dynamic 360 degree view of your entire attack surface in one place.
Apparently SolarWinds DPA reports a job as failed even if it reports it succeeded if one or more steps fail.
The DPA DBA is recommending we use sp_stop_job to terminate the job instead of having the first step fail.
i.e. for jobs running on the AG secondary, the first step checks to see if the current node is the primary for the job's database. If the job is running on the primary, the step succeeds and the job proceeds, whereas if the job is running on the secondary, the step fails, causing the job to exit with status "succeeded".
they are saying instead of ending the step with status "failed", we should run sp_stop_job 'job_name'; and report success
SolarWinds is never going to get a good recommendation from me