Kaseya Community

Naming Policy - exclusions

This question is answered

We have customers with multiple sites, some of them on very slow links (think remote mine sites) - staff often travel between these and we needed to apply specific settings/policies to agents in those locations. Enter 'naming policies' -  Automatically move agents between machine groups based on IP & GW address. 

5 minutes of configuring naming policies I could see a problem - when our tech's attend site their laptops are going to move into the customers machine group. What we need are exclusions.

Brilliant idea, lousy implementation. How does this get overlooked in a product that's main driver is process automation?

This has been posted a few times on here dating back to 2009;


Presumably others have lodged tickets with Kaseya about this over the years and still a very simple feature like this cannot be implemented.

Anyone from Kaseya wish to comment?

Verified Answer
  • Setup IP ranges at the sites on top of the gateway like this example:

    Main Office: -


    Mine East: -


    Mine Wast: -


    Then get a list of the Mac address for all of the tech laptops and create a reservations in DHCP putting the Laptops outside the naming scope.

    Mine East Tech laptop 1 IP:

    This will prevent it from changing groups on you.

    [edited by: K Arnott at 2:04 PM (GMT -7) on Oct 15, 2012] wording.
All Replies
  • Setup IP ranges at the sites on top of the gateway like this example:

    Main Office: -


    Mine East: -


    Mine Wast: -


    Then get a list of the Mac address for all of the tech laptops and create a reservations in DHCP putting the Laptops outside the naming scope.

    Mine East Tech laptop 1 IP:

    This will prevent it from changing groups on you.

    [edited by: K Arnott at 2:04 PM (GMT -7) on Oct 15, 2012] wording.
  • I was around in the early days of Kaseya when we first created Naming Policies. The challenge we were encountering before Naming Policies was that when we went to larger sites (many thousands of machines), not only was it painful to manually have to move machines into groups, but often even the IT guys didn't know what machines needed to be in what group. What they did know though was what IP address ranges were where. So Naming Policies was born. It was designed to solve the issue of naming machines enmasse automatically at the start of the rollout. I just wanted to clarify that this hasn't been 'overlooked' the function does exactly what it was designed to do.

    There is an easy way to solve your issue however, use DHCP reservations. You can use IP Blocks in Naming Policy that leave out the reservation addresses and just have the engineers add themselves to the local reservations for each site they visit. If you have central control of your customers DHCP you may even be able to do this centrally.

    [edited by: Ray Barber at 2:13 PM (GMT -7) on Oct 15, 2012] Only saw K Arnott's post after I submitted, sorry. Thanks for the detailed info K Arnott.
  • Hi Ray - thanks for taking the time to answer. I don't believe DHCP reservations is an easy way to solve the issue. That is labourious and manual. Surely that is going against Kaseya's own charter.

    A feature from what I can tell released 3+ years ago with a fundamental flaw, which I discovered within 5 minutes - yet there has been no movement to resolve it over the years.  Why do something half baked? It's just something so simple, a great idea, done badly. How hard could it possibly be to add an attribute to a machine to exclude it from this policy?

  • Ray - this is not a solution but it is a workaround although somewhat poor. Can you please tell us where this feature request sits as it is very old and is something I may have even created tickets for several times over the years.

    We would like to use naming policies at all our clients but I don't want to be adding DHCP reservations to all DHCP servers. I am sure I could script them up but it's a way too messy.

    JamesN - one thing we did was with our policy management, all of our client policy management views exclude machines with our domain name. This means that even if the laptop changes groups, at least they do not pick up the client settings.

    As for moving the machines back to our org, this can't be hard to script but I don't like it as the machine would be constantly bounding back and forth. I also don't like writing to the SQL directly in a script myself.

  • Ghetto - Thanks for the suggestion about the views. Currently we use one of the default All Workstation/Server views however I can update the customer policies to use a view excluding our own computers. That works around most of the issue.

    I will make up an SQL query you can schedule to run as a job on your SQL server which will move all of them back into the group group. Once I get ours working nicely I'll post it up for you to use.

  • Awesome - thanks James.

    As mentioned it will be a battle if the machine is at a client site, but perhaps we'll just run it once a day.

  • In fact you could write a policy that schedules the procedure on all clients, but only pick up machines that are part of your domain. Easy peasy.

    As for policy management views, I decided early on to create views specifically for Policy Management. This way if I decide to tweak them in the future it's easy.

  • OK here it is.. note the caveats at the bottom of this post though;

    Go to Audit > Machine Summary > Click 'New Custom Field';
    Name: machGroup_Override
    Type: String

    Find your tech workstations/laptops, Click 'Bulk Edit Custom' > Select 'machGroup_Override' from the drop down list > Enter the the name of the machine group your tech workstations/laptops should be moved back to. For example: company.root.workstations

    Log onto your SQL server that has the ksubsribers database > Open Microsoft SQL Server Management Studio > Connect to DB Server.

    Expand the server name > expand SQL Server Agent > Right-click 'Jobs'  > Select 'New Job'

    Name: Kaseya machGroup_Override

    Click 'Steps' > Choose 'New' 
    Step Name: Execute Query
    Type: Transact-SQL script (T-SQL)
    Database: ksubscribers

    USE ksubscribers
    UPDATE machNameTab SET
    machNameTab.machGroupGuid = machGroup.machGroupGuid,
    machNameTab.groupName = machGroup.reverseName,
    machNameTab.displayName = machNameTab.machName + '.' + machGroup.reverseName
    FROM auditRsltManualFieldValues val
    JOIN auditRsltManualFields Fields
    ON Fields.id = val.fieldNameFK
    JOIN machGroup
    ON val.fieldValue = machGroup.groupName
    Fields.fieldName = 'machGroup_Override'
    AND machNameTab.agentGuid = val.agentGuid
    AND val.fieldValue <> ''


    Click OK
    Click Schedules > Choose 'New'
    Name: Kaseya machGroup_Override
    Type: Recurring
    Frequency: Set up however you want.. I have ours running every 5 minutes 

    Click OK > Click OK

    Additionally, If you use KPM you should adjust the views on your policies to exclude agents with your org name in the machGroup_Override field. This will stop your customer policies applying to your tech workstations when naming policy moves them around. You could use the domain name, however we have a handful of machines off the domain so went with the method below;

    Edit the view > scroll down and tick 'Advanced agent data filter' > Click 'Define Filter' > Scroll to the bottom and in the 'machGroup_Override' enter 'NOT *yourorg*' > Click Apply
    For example, if your machGroup_Override is set to 'company.root.workstations'  the value of machGroup_Override on the filters page should be 'NOT *company*'

    Caveats / Notes / Exclusions

    - Use at your own risk.
    - This does not exactly replicate the process Kaseya perform themselves via Agent > Change group menu. For a full idea of that view 'changegroupdata.asp' in C:\Kaseya\WebPages\AgentTab' on your KServer. In summary Kaseya does the following steps;
    -  Checks licensing is not at max before the move for backup, KES and KDPM modules
    -  Updates  displayname, machgroupname and machgroupguid for the agent in the machNameTab table
    -  Updates all the tickets with the updated groupname for the agent

    I really shouldn't be surprised the ticketing module is completely separate from the rest of the core; In anycase, the SQL query above only performs the middle step, It does not check licensing or update the tickets for the agent. As this only applies to our tech laptops I don't really care.

    I would not use this against any customer agents unless you went to the trouble to replicate changegroupdata.asp in the SQL job. This whole undertaking was just to move our tech computers back to the correct org and not skew any reports etc.

    Kaseya - I really hope naming policy is fixed in the next release.


    [edited by: jamesn at 8:07 PM (GMT -7) on Oct 23, 2012] these are my edit notes.
  • As already explained, Naming Policy is not broken, so there is nothing to fix. It is a tool for naming machines, hence it being called 'Naming Policy'. If it was designed for moving machines around it would have been called something else, like 'Moving Policy' (terrible example name, I know!). This use case you have explained it not what Naming Policy is for, it's for one-off naming process during roll outs, it's not designed to move machines multiple times based on moving from site to site

    Now that is not to say that the use case that you guys are talking about is not valid and useful, I'm justing explaining that pointing at Naming Policy and saying it's 'broken' is not going get the end result you are looking for.

    @jamesn - while you are correct in that you can hack our code and circumvent some of the controls to get you this result, it does mean that our support team will have every right to refuse you support the next time you have an issue. We can't support different versions of our code base all over the place, and if we change any of our code that gets delivered by a hotfix, it could break your system. I really do NOT recommend to anyone to play with the code, its just not a viable long term solution.

    I do believe the other suggestions were starting to head in the right direction around using Policy Management. Groups and names are really just for identification purposes, so you can find individual machines when you need to, or know which machines are part of what business unit/ geography. In all the implementations I have been involved with over the years, no one ever managed to successful reconcile groups/machine names with settings in a way that made sense.

    Hence myself and others at Kaseya that were involved with customer roll outs starting using the concept of ID roles. Not Roles as we have in the UI today for controlling functional access, but as a way of identifying what the actual role of a machine was. Kaseya covers a wide range of functionality, from security to backup to general management of machines, and what gets applied in terms of those settings is more about what the machine _is_, i.e. what its used for, than its location. Very often today machines move, but their purpose does not often change. And so eventually Policy Management was born. And it is continuing to evolve, there's a number of updates to it in 6.3

    So my very long way of getting to the question is: why are you using Naming Policy in the first place? Why do you leave it switched on on customer sites?

    If I can undertand what purpose you are using it to serve, perhaps there is a need for some other functionality and I'll do my best to get that added. Or it may be that there is a better way to get to your required solution that already exists today. I'm not going to put my phone number on a public form, but feel free to email me at ray.barber @kaseya .com and I'll send you my contact details so we can talk and you can run me through the scenario. If there really is a gap here I'd like to understand it better. Or if there is not, hopefully we can come up with an answer and post it back here for everyone.

    [edited by: Ray Barber at 4:25 PM (GMT -7) on Oct 27, 2012] typos
  • Ray, if you look all over this forum people are 'hacking' kaseya out of necessity. Seemingly simple tasks are not possible, or illogical decisions forced upon us. One such item is a 'naming policy' which does not allow for exclusions or overrides.

    As for your assertion it was created only for naming machines, synonymous with its name, I will take your word for it. Though I refer you to the naming policy page in Kaseya; which at the top states:

    "Automatically assign machines to group IDs based on machine data
    Note: Group ID changes take effect after the next Full Checkin for each machine"

    Even the kelp page lists the primary function of 'naming policy' as moving machines between groups:

    "The Naming Policy page defines the IP address criteria used to automatically re-assign machines to a different machine group. Each machine group can be assigned multiple naming policies.
    Naming policies can also force the renaming of a machine ID, if the machine ID name doesn't match the computer name, reducing confusion when administering managed machines."

    Can you blame me for interpretting this as meaning "move machines between groups based on IP/GW combination"?

    My use case scenario is in my OP.

    Some settings need to be applied at a site level. I really can't see how you could consider that outside the realm of possibility. Group policy allows for site based GPO linking for this precise reason. Additionally, it is nice to know where a machine is at a glance (our machine groups are named per site).

    Kaseya could easily support this if only 'naming policy' was developed a little further.

    [edited by: jamesn at 7:26 PM (GMT -7) on Oct 28, 2012] formatting
  • @JamesN - Ray is right - this is a feature request, not a "fix" as such.

    Ray - to quote:

    "In all the implementations I have been involved with over the years, no one ever managed to successful reconcile groups/machine names with settings in a way that made sense."

    Really? I do not understand this statement. I would imagine most MSPs out there are using something along the lines of clientname.cityname or clientname.suburbname for clients with multiple sites in the same city. I would imagine most in-house implementations would be naming their orgs or groups based on location or department. Have I mis-interpreted something here?

    We rely on naming policies heavily as a permanent setting and here are some of the reasons:

    1. We sometimes have old installers lying around in logon scripts etc. that put machines into the wrong groups. This keeps things tidy for us.

    2. We often just use a generic installer that puts machines into the unnamed group and then we rely on naming policy to tidy this up for us. We have resorted to this after a lot of machines affected by 1.

    3. As clients move between their own offices, it's nice to know where they are. It also means with policy management they will pick up the correct file source settings.

    4. It can be a nice way to keep things tidy when a client is renamed. Not all agents pick up the setting properly so this sorts it out for us (even if we have to go and re-delete an org with the old name every now and then).

    I could go on but as you can see the short version is some of us like to use naming policies as a long term solution, not just for initial roll-outs. I have wanted the ability to exclude specific agents from naming policies for some time now (probably 4 years or so) because, as has been mentioned many times, we want to leave naming policies in place permanently but we also do not want our own staff laptops jumping from client to client as they currently do. As my feature requests for this are quite old, can you please give me an update on where these are at?

  • "@JamesN - Ray is right - this is a feature request, not a "fix" as such."

    Only if you consider naming policy to only name machines. Kaseya's own documentation makes it clear it's primary function is to move machines between groups. It has a fundamental flaw, therefore it needs a fix.


    I agree on all your other points about why someone would use naming policy as a permanent feature. We use it very similarly.

    [edited by: jamesn at 8:16 PM (GMT -7) on Oct 28, 2012] ok
  • This is amazing, I logged in to ask about the exact same issue, and this post was top of the list. Thanks for ths info.

  • Did anyone ever come up with a workround for this? Exclusions to naming policy would be ideal, but this is obviously not going to happen.

    We have the exact same problem that is mentioned above - techs visiting client sites with laptops every day.

    Creating exclusions or reservations for every DHCP scope at every client site is simply not an option, the estate is too big for this to be practical, and we'd prefer not to have to directly manipulate the database as has posted above, although it really is tempting!