Home > 3rd party, dba > What Does Confio’s IgniteFree Install on Monitored Instances

What Does Confio’s IgniteFree Install on Monitored Instances

I was trialling Confio’s IgniteFree software on a development box and wanted to see what exactly gets created when you register an instance for monitoring. Confio states that their installs are “Agentless”, which is true.

I asked Thomas LaRock (blog | twitter) if IgniteFree creates any objects on the server. Answer:

short answer: #ignite does not require creating objects on the monitored instance. –@SQLRockstar (emphasis mine)

What I did discover though, objects do get created on the monitored server.

So what gets created?

USE [master]
/****** Object:  User [DOMAIN\user]    Script Date: 01/21/2011 13:15:11 ******/
/****** Object:  Schema [DOMAIN\user]    Script Date: 01/21/2011 13:15:10 ******/
/****** Object:  Table [DOMAIN\user].[ignite_temp]    Script Date: 01/21/2011 13:15:11 ******/
CREATE TABLE [DOMAIN\user].[ignite_temp](
	[index_val] [tinyint] NULL,
	[name] [varchar](50) NULL,
	[internal_value] [int] NULL,
	[char_value] [varchar](255) NULL
GRANT SELECT ON fn_get_sql to [DOMAIN\user]
Categories: 3rd party, dba Tags:
  1. January 22nd, 2011 at 09:01 | #1

    Hmm – did you trace this to see it in action? Something seems a little off here. I don’t think any product should be granting VIEW SERVER STATE to BUILTIN\Administrators – even if the product is in that group, it shouldn’t be granting rights to people outside of itself. My guess – and this is just a guess – is that you were scripting objects after Ignite ran in order to see what the differences were, perhaps with a data or schema comparison product?

    It might be more accurate to set up a trace, then install Ignite and watch what happens so you can catch the exact commands.

    • January 22nd, 2011 at 09:54 | #2

      @Brent: I saw this while profiling two different test servers during registering. It did a few more things, but this is what I noted as important. If I register another instance I’ll save the output for verification. So yes, it really does grant VIEW SERVER STATE during registration.

  2. January 22nd, 2011 at 10:06 | #3

    If it’s granting VIEW SERVER STATE to BUILTIN\Administrators during registration, is it running under SA? What account is it running under? Is that account part of BUILTIN\Administrators? Are you monitoring SQL Server 2008 or an earlier version? If it’s 2008, BUILTIN\Administrators shouldn’t even be there by default, so that grant statement should error out. (It shouldn’t even be running, but I’m really curious now.)

    • January 22nd, 2011 at 10:13 | #4

      @Brent: Monitoring 2005 SP3. I was running both the registering process and monitoring process under my account which is sysadmin. BUILTIN\Administrators is registered on that server as sysadmin as well. I want to do another test using differing accounts for registering vs. monitoring and see what it does, then save the trace and post it.

  3. January 24th, 2011 at 20:20 | #5


    Thanks for posting this. As I said, we don’t require this table. I couldn’t say much more because (1) I have a 140-char limit on Twitter and (2) I was in the middle of a board meeting. Still, I wanted to get you an answer. Had I known that you intended to run a trace and blog the results I would have asked for you to include a lot of the information that Brent has already asked about.

    It is my understanding that the table you see is legacy code that simply has not been removed from the install process. I believe that in previous versions of Ignite this table had been used for two purposes:

    1. So we can recognize ourselves as a user that the QuickPoll process should ignore.
    2. To get # CPUs (it executes “master..xp_msver ProcessorCount”, and puts the result in ignite_temp which we then query).

    It is not clear to me if those two items are applicable any longer. In fact, I believe the QuickPoll is already filtering for the Ignite user in a different manner. I will ask our engineering team to verify these details once again and also ask they leave a comment on this blog.

    Please keep your trace running and report back anything that seems odd. We’ll do our best to clean up whatever we can and as quickly as we can.

    • January 24th, 2011 at 20:31 | #6

      Tom, thanks for commenting. At the time, I didn’t figure on posting this, but thought it might be useful for anyone else considering using IgniteFree. I haven’t had a chance yet to do another install, but will save the results when I can.

  4. Dean Richards
    January 24th, 2011 at 20:50 | #7

    Saw your post and I will be looking into this. I am a Sales Eng for Confio and have sent this question over to the dev team to determine what is happening. I will be back to you as soon as I can. Thx, Dean Richards

  5. January 27th, 2011 at 16:42 | #8


    At this time that table is indeed being used. I believe there are plans to remove it from a future version. Let me know if the presence of this table is causing you any concern.

    Please continue to run additional tests using different accounts. I would be interested to see the results. I believe that the presence of [BUILTIN\Administrators] is due to the fact that DOMAIN\user is a member of that group, but your future tracing should confirm for us one way or the other.

    Thanks again for your help, and for kicking the tires on Ignite.

    • January 27th, 2011 at 16:47 | #9

      Tom, Thanks for doing the research. It’s not causing concern, as right now we’re testing this in development and QA, so we’re a little more loose on object creation. If we plan on taking this to production, we just needed an authoritative list of what the footprint will be. It’s pretty darn small, so that’s great. Having no objects would be even better as the only thing that would need approval would be access for the service account.

      Thanks again for taking the time to reply.

  1. No trackbacks yet.

%d bloggers like this: