Kaseya Community

ORG custom fields

  • I see that in the  settings in System is a tab marked ORG CUSTOM FIELDS.

    Are these accessible via scripts? Having custom fields at the ORG level would be very handy for having things like Opt Outs for certain kinds of updates for all machines in an Org.

  • Hi Oliverm

    I 100% agree but I don't think you can do anything with these fields - while I am a big kaseya user I have trialled labtech and they have something very similar but with theirs you can access it via scripts / via policy management just magic, you can create your own fields and make them drop down boxes / tick boxes etc.... Really well thought out - kaseya I hope your listening.

    We setup a custom field while testing - Question was  - Managed Services client - Yes / No - if you tick yes then the client gets all the policies relating to monitoring / patching etc - tick no then they get nothing and the agent menu changed.... One of my all time favourite features (nerd) but seriously lacking in Kaseya.

    Rant & praise for competitor over.... :o)

  • yeah. Labtech is great. If we ever moved from Kaseya then it would be to labtech. Saying that we have another year on our payments to Kaseya so it wont happen any time soon.

    The Kaseya Policy Module *could* have been so similar to that ability, applying whole sets of policies to a machine based on criteria but it just missed the mark

  • As per mmartin's comments I have also not been successful in accessing these fields as they appear to be part of the Org only and from what I have managed to figure out is used as part of the Service Desk and Billing modules in Kaseya.

    It might be possible to do a custom sqlcmd query however that is a bit complicated so an easy alternative is to use a feature that I have noticed very few Kaseya Admins actually use and it's called Manage Variables. These variables are assigned by machine group instead of Org or Agent and can be used in Agent Procedures. I personally use these a lot in my agent procedures and they are very handy. Examples that I use the Manage Variables for are:

    • Server Agent GUIDS for BES, Exchange and File Servers
    • FileShare UNC and Directory Path
    • Notification varaibles such as email addresses, Notification messages and Times
    • Network Information such as Internal and External DNS servers, DHCP host IP, internal Gateway IP address, Connection Gateway IP address
    • Domain name and PDC name for use with Agent Procedures that can join a computer to a domain.
    • Site SLA and Company Name
    • ESET download credentials
    • Exchange mail store and log paths
    • Kaseya Agent custom name and Kaseya ID

    I would also like to see the ability for us to use the Org fields in our agent procedures as it would decrease the amount of duplication for variables like Service Level Agreement, Company name etc...

    [edited by: HardKnoX at 2:06 PM (GMT -7) on 10-26-2011] typo
  • I would still like to see Kaseya actually do a set of webinars or Bootcamps for the advanced Kaseya users to teach them stuff like how to use the custom sql commands or for guys like Ben to share their awesome knowledge on scripting techniques using Kaseya Agent Procedures. If there is a way to access the Org field in Agent Procedures show us how to do it.

    The last "Advanced" Kaseya scripting course here in Auckland was a real let down as the guy that ran it dumbed down the whole sessions because too many of the attendees had no Kaseya scripting knowledge and he also ended up showing us a lot of VB scripting stuff which is not Kaseya scripting. For an "Advanced" training session that cost $1400 NZD it was really lame as I really didn't get anything new out of it.

    @Oliverm sorry if I hijacked your post, however I think it applies to the core problem around undocumented features like Org fields and their usage...

    [edited by: HardKnoX at 2:09 PM (GMT -7) on 10-26-2011] typo
  • Oh, you were there too HardKnoX? :) I agree, it was very focused on working around Kaseya's limitations rather than within them.

    I get quite frustrated as this seems to be the default.

    I've had a ton of conversations which have gone similarly to this:

    Me> I want to do X

    K> You can't actually do X, but here's a convoluted method to run a script which writes a text file, then you schedule another script which downloads a VBScript, which parses that text file, and schedules something else to run a fake EXE. You then set up an alert condition which does sees that EXE and runs another script on box Y which finally does X!

    Me> Please tell me you're kidding?

    K> *Blink* No, why?

    I've said it before, this is NOT automation, and it's not very liberating. It makes things needlessly complicated, and never seems to improve. Instead, we get things like Service Desk (for which a ton of existing substitutes exist), and KAM (which doesn't work properly), instead of the basic product being simplified and streamlined.

    This is turning into a rant, but what I'd like to know is who at Kaseya do I need to talk to to get this approach fixed, and ask for a focus on making the base product work as it should without insane hoop-jumping requirements to perform what should be simple tasks?

    I guess I'll now await my annoyed phone call from support... ;)

  • @Greig McGill Well at least that person that called me about that can't tell me that I  was non-constructive in my first reply because I'm sure what I posted is a constructive work around to a non-constructive or non-existing function in Kaseya Big Smile

  • Hey Guys,

    I have looked at the SQL database and the tables which hold the values are kasadmin.orgCustomFields and kasadmin.orgCustomFieldsDef. There is a view of kasadmin.vbo_Organisations_CustomFields which does link those databases but you will deffinatly need to create your own SQL view to link this and something else that has the agent guid and org ref in it so when a script is run it would know which machine you are talking about.

  • I've not managed to get at these fields with scripts.  However, I have been able to do select statements to them in SD.  So, we put in the customers internal ID number and certain alerting options such as 24x7 etc.  We can then use this to filter alerting.   In SD we actually do quite a few SQL select statements and on at least one occasion Kaseya decided to rename a table on me.  That was real fun to figure out.  It would be nice if getting items from custom fields were more streamline.

  • Hi All

    We use these fields all the time .. and have created our own SQL views which we then reference within Scripts. We do the same at the Audit level as well so it is possible. What I'd like to find out is why there is a limit of only 20 custom fields per Organization , but there seems to be no limit in the Audit per machine

  • guys, this sounds like what I need for my SD, but I'm unclear on some specifics, can anyone help.

    We populate the org custom fields with information that I would to pull into SD.

    So my query is, when I create a new ticket can I have the ticket auto populate a field in the ticket with one of the custom fields in the org.  The immediate example is a custom field in the ticket form that when customer a is selected it auto populates with their status in accounts, i,e, on hold etc.

    Or when we schedule an install as the reason for closing the ticket it checks to see if they are allowed to have on site install based on a value in the field that was created in the org custom fields.

  • NIKNAKS456, you can do what you're asking. On one of your steps just do a SQL SELECT query to pull back whatever info you want.  You do need to know SQL to use this and you will want to log into your db to make sure you get the right query before you go on. A basic query with the tables you'll most likely need is:

    SELECT     kasadmin.vbo_OrgMachine_List.machName, kasadmin.org.orgName AS Company, kasadmin.org.orgType, kasadmin.orgCustomFields.fieldValue

    FROM         kasadmin.vbo_OrgMachine_List INNER JOIN

                         kasadmin.org ON kasadmin.vbo_OrgMachine_List.orgName = kasadmin.org.ref INNER JOIN

                         kasadmin.organization ON kasadmin.org.ref = kasadmin.organization.ref INNER JOIN

                         kasadmin.orgCustomFields ON kasadmin.organization.orgFK = kasadmin.orgCustomFields.orgFK

    Of course you'll need to add a where statement and such but this will give you a starting point.

  • Thanks Sam, this shows the fields well and when I figured out the WHERE syntax all looks well.

    Query is now how to make it run the query when the engineer is creating the ticket and selects the ORG from within the ticket?

  • Well, you need to create a sub-procedure with the query.  Depending on what you're doing and when you want it to happen you'll have to figure out what triggers the sub-procedure.  You can then use variables in your query.  So, you can use the [$Machine$] variable in the where statement to limit to the machine that the ticket is based on for example.

  • OK I see that - In my case that would be too late.

    We were hoping the query and result could be run when the user selects the org from the ticket create window.  So user creates a new ticket, selects the company from the org picker, then the field I have created populates with the data in the org custom field.

    If it runs after the ticket window has been closed it's too late, unless I'm not getting it.

    Thanks again