Kaseya Community

Anyone Running Kaseya 7.0 Have Any Thoughts?

  • Agent procedures - We upgraded to 7.0 on 7/26 all agent procedures that were created before the upgrade are working fine for us. The issue we are having is that any new procedures that are created signed and approved by the Master role are still receiving the error "agent procedure has not been approved".  I personally am not a Master role user but have elevated rights to agent procedures and have found that I am able to approve procedures as long as I am not the last one to sign the procedure. I thought the approval of agent procedures was restricted to only those that have the Master role.  In any case we are finding that any newly created procedures cannot be run. Any guidance besides a schema update would be much appreciated.  

  • Ken, that doesn't seem to be expected behavior -- users with the Master role should be able to approve any procedures, and anyone without it shouldn't be able to approve any. Definitely get a support ticket created and we'll look into it right away.

  • Ken, sounds like a possible bug allowing to get to the signing process but it is not totally signing the procedures.  Have you had a full Master role person actually sign the procedures and then work?  There was one instance of somebody on here that had multiple roles(Master, and other).  It allowed them to approve but it seemed the lower role was still causing an issue of the procedures acting like they were not signed.  I know you said you did not have the Master role, but sounds similar.

  • For those of you using the backdoor fix for being able to run RDP sessions through the VSA server still I think your about to lose that functionality with today's update:

    Legacy VNC & RDP components in the VSA have been removed. (IP-301/CC-1838)

    I guess Kaseya has double-down on their stupid decision to remove RDP.

  • I also couldn't help to notice that today's patch does nothing to address the keyboard and mouse issues that people are seeing with this new remote control application....

  • "For improved security, restrictions have been added to the kaseyasupport account used by Kaseya Support to troubleshoot issues by customer request. The kaseyasupport account can no longer create, delete, rename, reset password, or force a password change of user accounts. Nor can the kaseyasupport account add or remove roles or scopes. (IP-298/PA-730)"

    This is funny since the last ticket I had opened, Kaseya support wanted me to create a different account/grant it full permissions and give them the password to it because "the kaseyasupport account does not work correctly"...  Needless, I refused to allow them a backdoor in and stayed in the session while they poked around.

  • 2014-07-29 14:20:27Z: Creating Kaseya HTTP IN firewall rule.
    2014-07-29 14:20:27Z: 
    Message:	Unable to cast COM object of type 'System.__ComObject' to interface type 'NetFwTypeLib.INetFwRule2'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{9C27C8DA-189B-4DDE-89F7-8B39A316782C}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
    ErrDepth:	0
    Stack Trace:	   at KaseyaInstaller.TestSupport.Tests.FirewallConfig.CreateRule(String name, Int32 protocol, String ports, NET_FW_RULE_DIRECTION_ direction)
       at KaseyaInstaller.TestSupport.Tests.FirewallConfig.FixIt()
    
    Test: Windows Firewall Configuration                    	Status: Fail                	Result: The following rules are configured:

    We got the same error message, is there any solution yet?



    Copying the error Message...
    [edited by: bj.Balegar at 2:05 PM (GMT -7) on Jul 29, 2014]
  • Patch 7.0.0.17 seems to have disabled this feature.

  • Someone messaged me about the high CPU utilization I brought up before so I thought I should post an update here as well. Please note, my opinions in it are just my speculation and opinions and this has been a steady work-through issue with support and they have been working with me every day on this. If it is actually connected or not is again, speculation on my part, I'm just trying to think things through. Here's my reply to the message I got as well and sorry for the length.

    ----------

    Sure thing, sorry. I'll post an update there and here. Sorry if this comes out cluttered, I'm still very much trying to process how things are happening to figure out everything so it's a pretty raw write-up.

    I've been working with support daily on a couple of items and this particular aspect kind of took a back seat but oddly enough is coming back to the front of my mind. They had me set the CPU affinity on my front-end box for the top most used java process. I tend to have 3 Java.exe processes, the highest used one seems to use all the CPU so I gave it an affinity of 2 cores out of the 8 (VM originally started with 4 cores and it would keep it at 100% day and night. I bumped it up to 8 cores and that alone cut the usage in half but still concerned me).

    The Java appears, to me, to be the Kaseya Application firewall they put in place, I think, but I would defer to them for certain. Now with this said, I've been having a problem where the front-end box (server 2012) seems to suffer port exhaustion to the point I would have to reboot the front-end, or taskkill java, then restart the kaseya.applicationfirewall, kaseya.channelservice and kaseya.relayservice services and would be back up but then down again shortly after.

    So the latest thing we have done is to up the dynamicport allocation on the front-end server from the stock 16,000ish ports generally allowed to be dynamically assigned, to 55,535 ports. We did this with the “netsh int ipv4 set dynamicport tcp start=10000 num=55355” from command prompt. Then do the same for UDP via “netsh int ipv4 set dynamicport udp start=10000 num=55355”

    We have been writing back and forth on this one lately and my concern right now, is that by limiting the affinity, I think I may have made things worse, by throttling what java.exe needs to truly process my agent connections and getting them to process and then drop. Basically I fear limiting java.exe is causing the application firewall to hold TCP ports open, thereby exhausting them until my server needs a reboot or to kill the java.exe then restart the services which starts the process over again.

    Time will tell, we normally got about 24 hours between issues, and it always seemed to happen when all use time zones were in business hours. It never started until West coast came into office, and as soon as East coast hit 5PM K would work again.

    ------------

    To add on to that message, I should also note that since upping the dynamicport allocations, my system is still online since we made the changes. Normally we would already be back down again well within an hour so it looks promising being at almost 3.5 hours online. I do still have a concern that someone with enough agents, if it does what my system is doing and it does turn out to be some sort of port exhaustion, that it could still occur. Now that several hours have passed I'll load up TCPView again and see if the numbers have altered at all. I'll try to be better about updating here.

  • Disabling Webroot Identity Shield fixed the keyboard issue for us.

  • Scrap my affinity aspect, forgot that over the past few reboots, we haven't been re-setting it. This is why I seem to be having an issue getting a good grasp on my own problems maybe heh.

  • 2014-07-29 14:20:27Z: Creating Kaseya HTTP IN firewall rule.
    2014-07-29 14:20:27Z: 
    Message:	Unable to cast COM object of type 'System.__ComObject' to interface type 'NetFwTypeLib.INetFwRule2'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{9C27C8DA-189B-4DDE-89F7-8B39A316782C}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
    ErrDepth:	0
    Stack Trace:	   at KaseyaInstaller.TestSupport.Tests.FirewallConfig.CreateRule(String name, Int32 protocol, String ports, NET_FW_RULE_DIRECTION_ direction)
       at KaseyaInstaller.TestSupport.Tests.FirewallConfig.FixIt()
    
    Test: Windows Firewall Configuration                    	Status: Fail                	Result: The following rules are configured:

    We got the same error message, is there any solution yet?

    ***  Solution is to disable firewall on all profiles ie Domain, Private and Public then run the fixit. You can enable firewall later when install has finished



    added problem to the post to make it clear what the solution is for..
    [edited by: Mark Bisson at 9:15 AM (GMT -7) on Jul 31, 2014]
  • This is really irritating. Come on Kaseya, seriously? KRC is great for workstations, but it's terrible for servers! Lack of multiple session support, all activity visible from the console, unable to specify screen resolution, and on and on... those first two features are critical for us!

    I've opened ticket #36674 regarding this, and we're not updating to 7.0.0.17 patch at this time. I'd encourage others to make their voices heard about this as well, create a ticket for it.

  • I spoke with Chad and session support and screen resolution will be addressed in 8.0.

    - Max

  • Is there anyway you can get RDP to at least not be specifically disabled so that we can continue using the workarounds posted here until that time? Not having a workaround for these issues for 2 months really isn't an option for us, we'd like to be able to keep current on patches.