Kaseya Community

What defines a view label?

This question is answered

So we're just starting to get acclimated to Kaseya in general with the release of 6.3 and I've had the fun of installing it here internally first before we start getting it out into the wild.  One of the interesting things I found with the 10 agents reporting to the KServer (3 servers, 7 workstation) is that one of the workstations shows up under the two views with the Terminal Services label applied.  This server does not have the role installed and so I'm trying to determine what exactly is going on with this server that would trigger this appearance in the TS views.  Does anyone happen to know exactly what this label looks for?  That would certainly give me a good starting point and I've not been able to find anything on it thus far.

Thanks,
SKliemann

Verified Answer
  • This info from our Pro-Serve team:

    There was a bug that improperly detected TS machines that got fixed fairly recently.  Look for hotfix:

    File: /WebPages/ManagedFiles/VSAHiddenFiles/serverRolesAudit.lua

    Hotfix 4355/Revision 189464

    Comment: removed terminal server key check, just check for the registry value

    Tickets: CS138517

    Could be what is going on...the latest agent 6.3.0.6 fixes it. Also make sure Latest Audit runs periodically since this process applies agent side LUA hotfixes and the bug was in ServerRolesAudit.lua on the agent. If this is not the case we would need to see the machine in question, raise a ticket.  

    We look for the TSAppCompat registry value and if it is equal to 1 then server is a TS Application Server.

  • The patch did the trick after running audits.  Glad to have that resolved.  Thanks for the assist.

  • Hi All,

    FYI - VSA v6.3 Hotfix #: 6965 has been released to address this. Simply get latest hotfixes in your VSA and then re-run a latest audit on your issue Windows Agent machines and you will be good to go from there.

    Note for SaaS - This hotfix will be applied on this coming Saturday (Apr-27-2013) Maintenance Window. After that is completed, simply re-run a latest audit on your issue Windows machines and you will be good to go with this.

    @James - We were informed that the SBS item was supported, but then there were issues with it due to the max amount of monitorsets used with it (63 + default total). So they are re-working a more efficient way for that to be done eventually for SBS. Feel free to make a feature request ticket on that as well as they working on doing this efficiently in enhanced form for SBS-based systems eventually.

All Replies
  • This info from our Pro-Serve team:

    There was a bug that improperly detected TS machines that got fixed fairly recently.  Look for hotfix:

    File: /WebPages/ManagedFiles/VSAHiddenFiles/serverRolesAudit.lua

    Hotfix 4355/Revision 189464

    Comment: removed terminal server key check, just check for the registry value

    Tickets: CS138517

    Could be what is going on...the latest agent 6.3.0.6 fixes it. Also make sure Latest Audit runs periodically since this process applies agent side LUA hotfixes and the bug was in ServerRolesAudit.lua on the agent. If this is not the case we would need to see the machine in question, raise a ticket.  

    We look for the TSAppCompat registry value and if it is equal to 1 then server is a TS Application Server.

  • Thanks for the information.  Checking what I have it looks like I received the hotfix on the 15th of this month.  I do have the 6.3.0.6 agent on the machine as well.  The registry key you reference is also set at 0 and the latest audit ran on the machine only about 20 minutes ago.  It's still showing up in the views described in the original post so I'll chalk this one up as something strange and open a ticket.

  • ...there is an Agent Procedure in the 6.3 Standard Solution Package called "Run Now Server Roles Audit" that forces an immediate execution of the ServerRolesAudit.lua on the agent so that you don't need to wait for the regularly scheduled execution to take place (once per hour).

    If you're not on 6.3 or haven't installed the content which would allow you to manually force an update,  then you will need to wait up to an hour after the latest audit for the views to refresh.



    [edited by: Ray Barber at 5:10 PM (GMT -8) on Jan 24, 2013] .
  • Hi All,

    FYI - This issue is resolved and in queue for another hotfix. If you need it fixed immediately, file a ticket in the Kaseya Portal referencing this forum post link and we will manually patch your VSA for the moment. I will update this ticket thread once the hotfix is released as well for general notification purposes.



    [edited by: Dylan M. Lagi at 3:36 PM (GMT -7) on Apr 2, 2013] -
  • @SKliemann - If you already filed your ticket, let me know the ticket #, BTW. Thx.



    [edited by: Dylan M. Lagi at 3:36 PM (GMT -7) on Apr 2, 2013] -
  • @Dylan - Thanks a ton.  The ticket generated is Ticket CS142082.  Sadly I'm going to be out of the office for today and Monday while I do some on-site work, but I'll get a chance to take care of this ASAP when I get back.

  • @SKliemann - NP. Your VSA is patched and the ticket is updated as such. I will reply once more when the hotfix of this latest file is released. Smile



    [edited by: Dylan M. Lagi at 3:36 PM (GMT -7) on Apr 2, 2013] -
  • The patch did the trick after running audits.  Glad to have that resolved.  Thanks for the assist.

  • @Skliemann - Thanks for updating this thread with confirmation as well as our ticket. The hotfix is in queue and I will reply once more with details once the hotfix is released. Yes



    [edited by: Dylan M. Lagi at 3:36 PM (GMT -7) on Apr 2, 2013] -
  • Hi All,

    FYI - The hotfix for this has finally been released via VSA v6.3 Hotfix #: 4889. From here, using an appropriate account, ensure you get latest hotfixes in your VSA and then re-run a latest audit on your agent machines in question and you will be good to go from there.



    [edited by: Dylan M. Lagi at 3:35 PM (GMT -7) on Apr 2, 2013] -
  • Dylan - are there any more reported issues with serverrolesaudit? I read this post back on the 12th of April and found the script to force the serverrolesaudit.lua to run. That seemed to work successfully. I just deployed some additional policies based on server roles and they're not applying.

    Running the "Run Now Server Roles Audit" proc doesn't seem to do anything anymore even though its reported as a success.

    I looked in my hotfix history;

    13-Apr-13 6.3.0.0 Hotfix CS153180 - 6753 - new server level audit label detection from Matt WebPages\ManagedFiles\VSAHiddenFiles\serverRolesAudit.lua

    So it seems the day after I last tested it, a hotfix was applied and it doesn't appear to work at all for me now.

    Is there a way to debug this serverRolesAudit.lua? I've tried it on many different servers trying - file server, exchange server, TS/RDS server etc none are detected.

    Thanks,

    James

  • Hi James,

    Thanks for the reply indeed. I actually just confirmed that this recent hotfix caused some problems and the remediation hotfix to that is in queue. For now, you can fix the issue manually (On-Premise only) by going to your VSA and loading \Kaseya\WebPages\ManagedFiles\VSAHiddenfiles and then load the serverRolesAudit.lua file and on line 215 change DoesNotContains to DoesNotContain - that will resolve it.

    I will reply again to this thread once the hotfix is released as well.

  • Thanks Dylan,

    I've fixed that line up, at least it runs now, but it's still not working correctly.

    Here's an example system. 2008 R2, running Exchange 2010. Services.msc shows "Microsoft Exchange System Attendant" service as started (Service name: MSExchangeSA)

    Line 175 in ServerRolesAudit.lua;

    services["3"]     = { name = "MSExchangeSA", label = "Exchange Server", func = nil, installed = false }

    From the If statement block on line 215 it calls the function named 'isServiceRunning' which is meant to return true

    But after running the agent procedure, the server_roles_audit.xml generated has an installed="0" for every service, including exchange;

    <service label="Exchange Server" installed="0" />

    So there seems to be an issue either in the writing of the output or correctly identifying the service is running.

    Thanks,

    James

  • Also is there a place in Kaseya we can see which roles are assigned to a server?

  • OK one last update :) Cant find where to do this in Kaseya so I just found the DB tables;

    USE ksubscribers

    GO

    select machName, ref  from agentLabelValue

    join agentLabel on agentLabelValue.agentLabelFK = agentLabel.id

    join machNameTab on agentLabelValue.agentGuid = machNameTab.agentGuid

    Quick and dirty, it works

    BUT, what i found interesting was there was a server listed in the results of a new customer I added only today. It made me think that perhaps the auditserverroles called via the latest update procedure was somehow different.

    I forced a Latest Update on the exchange server I was mentioning in my post earlier and the server_roles_audit.xml was correctly populated.

    Not sure how they differ, but thought I'd add that info in.