nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Config Change Detection Mechanism

vhcato

Can anyone from SW tell me if there are plans to include a mechanism natively within Cirrus to detect config changes? For those of us who do not have Orion on the same server as Cirrus, we have to install our own syslog server or trap receiver in order to enable this function, but this really should be something that's bundled with the product. As it is, we have installed Kiwi Syslog in order to facilitate this, and it's working well, but it's just another component we have to purchase.

Find more posts tagged with

Accepted answers

All comments

vhcato

*** Update ***

I'm starting to see instances where ConfigAutoDownload.exe gets hung from time to time. It's happend a few times during periods of normal change activity within our environment, and it happens every time we use Cirrus to make a mass change. When it happens, it just sits there and ties up CPU resources until I go in and kill them. Is anyone else seeing this with v4?

AlbanyMike

I have about 25 - 40 instances of ConfigAutoDownlad.exe running on my Cirrus server which shoots CPU usage to 100%. About to open a ticket with SW.

chris.lapoint

Can anyone from SW tell me if there are plans to include a mechanism natively within Cirrus to detect config changes?

Syslog and SNMP Trap server is expected to make it into v5. This is an older post so I'm sure you've already seen this in the v5 BETA3 build.

chris.lapoint

I have about 25 - 40 instances of ConfigAutoDownlad.exe running on my Cirrus server which shoots CPU usage to 100%. About to open a ticket with SW.

Definitely open a ticket on this one. I'll let them know it's coming. We are aggressively fixing any issues with RTCD as part of the v5 release.

vhcato

I had a case open for this, but we never did find the root cause.

vhcato

Syslog and SNMP Trap server is expected to make it into v5. This is an older post so I'm sure you've already seen this in the v5 BETA3 build.

I saw the note about it in the Beta 3 docs, but unfortunaltely I can't remove Beta 2 or install Beta 3 because of an error concerning some files that are in use. I mentioned this on the V5 Beta forum and was told this is a known issue. So, I can't actually see it yet...

chris.lapoint

vhcato, can you forward me your case number? With respect to removing BETA2, see the beta forum. We've found the issue and have provided a workaround.

Derek

Hi Vic,

Just posted an update relating to the Beta 2 uninstall issue here.

Let me know how it goes.

vhcato

vhcato, can you forward me your case number? With respect to removing BETA2, see the beta forum. We've found the issue and have provided a workaround.

Yeap... 32581

chris.lapoint

It appears we're still waiting for some wire captures from you. We'll resend the request.

vhcato

I've been having some problems responding to the emails from Support that are supposed to update the cases. On several occasions, my responses show up as a blank message on your end, and I have no idea why that would happen.

Here's the last update I sent, but I never heard any feedback.

*** snip

I’ve been doing a few captures this morning to see if I can get a clean one to send to you guys, but it keeps getting hung and over-running the buffer on my probe. What I’m seeing is that whenever this problem happens, the Cirrus server is continuously talking to the SQL server, and the SQL server is sending the following error message back to Cirrus.

Could not complete cursor operation because the table schema changed after the cursor was declared.

Does this sound familiar? We have no stored procedures running against the Cirrus DB at the time the error occurs, so I’m not sure why it would think there was a schema change. I found an article on Microsoft’s site (http://support.microsoft.com/kb/930775) that may be related. I’ll have to find out if we already have SP2 for SQL on our server.

snip ***