Kaseya Community

Secondary Kserver

  • I am wondering what to use the secondary kserver option under agent checkin for. IE can I setup a second Kserver with all the same info as my primary?

    Assuming yes I expect I should have the sql server not on the primary kserver but on another machine that way I can install two kservers that will both look to the same DB.

    I confess I have not made it all the way through the 400+ page vsa manual but i have skimmed it. If it's in there and I missed it I apologize

    I am hoping to have two kservers setup on different wan's for redundancy. I'd like to do the same with my sql db as well. Can anyone give me some insight into how they have deployed their kservers?

    Thanks in advance.

    Legacy Forum Name: Secondary Kserver,
    Legacy Posted By Username: iamnet
  • My understanding is that you can only have 1 K server at this time (the K server redundancy abilities are a bit lacking although you can probably have redundancy at the SQL level....and of course Virtualization is another story.)


    Anyway, the secondary K server option is in case the agent can't get to the primary, for example, we utilize a DNS entry for 1 and an IP for another....that way, when DNS is not working on a machine/network, we can still utilize Kaseya as the agent is still talking to the K server.

    NOTE: It is also my understanding that the agent will 'fall back' to the secondary server entry for everything except for remote control. Remote Control functions utilize the primary entry only. Check the documentation for further details.

    Legacy Forum Name: How-To,
    Legacy Posted By Username: pdxkid
  • Kaseya will tell you that running a secondary K server violates you license, so take that for what it's worth.

    We use the primary/secondary to point to different WAN links that both run into our network. If the primary ISP drops for any reason, the agents are still checking in. We use IPs for both, not DNS names. We monitor DNS resolution separately.

    pdxkid is correct, the RC functions do not work when agents are checking into a secondary server address. This includes control, FTP and chat in our experience so far.

    Legacy Forum Name: How-To,
    Legacy Posted By Username: arobar
  • Ok so if I understand correctly...

    If primary is down then the agents can still see the secondary which will keep the agents from going offline and stopping running processes such as an in progress backup, for example.

    My original thought was to run a kserver on network A pointed to a sql db and a kserver on network b and point to the same db but it looks now as that is not going to accomplish much. (No remote etc without primary)

    I should use ip addresses or at least have the secondary on an ip incase dns is down.

    Summing up my goal: To have two 'noc's' so that if one lost connectivity, fire etc the secondary could carry the load for a time. (Secondary wasn't initially going to be much more than an offsite office space running a few vanilla boxes. Just enough to keep agents checking in and allow for remote access things.

    I have little virtualization skill/knowledge at this point so if i'm overlooking that route that's why.

    How are some of you folks providing redundancy on your primary Kserver? Just running backup images etc and screen printing the recovery password?

    Legacy Forum Name: How-To,
    Legacy Posted By Username: iamnet
  • If you are worried about redundancy you can use a product like CA Xosoft WansyncHA to replicated all files and SQL DB to a secondary server. The Kaseya product can be installed "but" not licensed. You can license it if you need to failover.

    Another thought on this is to cluster your SQL servers (putting Kaseya Application on a standalone server by itself) and have an image of Kaseya going daily. If anything happens to SQL, the cluster will handle failover withough Kaseya going down. If the K server goes down, blow the latest image into another server (perhaps a virtual server?) and bring it back online.

    Or you can go with straight imaging and just restore the whole thing as needed.

    In other words, K does not have a good roadmap for live redundancy (the ability to keep Kaseya going even if 1 server fails). Following ideas like I just stated, we'd have to figure out how to do this ourselves (and of course support it ourselves).

    Definitely a weakness in the product.

    Legacy Forum Name: How-To,
    Legacy Posted By Username: boudj
  • arobar
    Kaseya will tell you that running a secondary K server violates you license, so take that for what it's worth.

    We use the primary/secondary to point to different WAN links that both run into our network. If the primary ISP drops for any reason, the agents are still checking in. We use IPs for both, not DNS names. We monitor DNS resolution separately.

    pdxkid is correct, the RC functions do not work when agents are checking into a secondary server address. This includes control, FTP and chat in our experience so far.


    To answer the OP, according to the documentation, the secondary KServer setting is for use during migrations. We used it when we rebuilt our KServer and it worked great.

    Michael

    Legacy Forum Name: How-To,
    Legacy Posted By Username: RCS-Michael
  • So you had a bare metal image of the current primary. Restored that image to a new server then while you powered down the primary and swapped cables etc the secondary kept the agents alive.

    How do you utilize the secondary kserver if you can't license it? Seems to install it I'd need to put in the key. Unless I hear what isn't being said...

    Legacy Forum Name: How-To,
    Legacy Posted By Username: iamnet
  • Install it and then take the service offline (it can't report back to K).

    Legacy Forum Name: How-To,
    Legacy Posted By Username: boudj
  • In my case, we have two different internet connections at our office, from two different ISPs (for general Internet failover, reduendancy, etc).

    We have one K server. We have one firewall (SonicWALL NSA 3050).

    The SonicWALL is configured to send kaseya traffic (ie. port 5721) from both of the pulic IPs (from both ISP's) to the internal IP of our K Server.

    Agents are configured with public IP#1 from ISP#1 as their Primary Kserver address, and Agents are configured with public IP#2 from ISP#2 as their Secondary Kserver address.

    This configuration gives us Internet/ISP failover, reduendancy for managing our clients via Kaseya. (Of course, I am still screwed if thie firewall dies, or my kserver dies, but we have other backups in place to deal with those). I just didn't want my Agents to be unabel to communicate with our kserver, with my ISP had issues.

    Hope this helps wiht an understanding of pssible uses for Primary and Secondary K Server.

    Lloyd

    Legacy Forum Name: How-To,
    Legacy Posted By Username: lwolf
  • We just had an instance where our clients are using OpenDNS for part of the blocking features, however, the domain where our DNS is hosted at was having a bit of problems with their servers, so OpenDNS really had no where to look up the primary server which was specified as support.domain.com. Beings how the clients were utilizing OpenDNS and Kaseya trying to report to the primary server via DNS, nothing but failure. However, months ago before this happened, and consulting with other IT peers, we set our secondary Kaseya check-in server to the IP address. When the problem with the hosted DNS server went down, the Kaseya clients on the managed workstations switched on over to the secondary server, via IP address, and were able to check into the server. However, the problem came up mid-day with other IT admins here at the office, not being able to use the Remote Control function of Kaseya. After going a few rounds with OpenDNS and NetworkSolutions (which uses WorldNIC's DNS servers) the problem was finally found, with WorldNIC's DNS servers having all sorts of problems throughout the day.

    Our original setup was to for the Kaseya check-in servers was 'DNS.1STHOST.COM' and secondary being 'IP.ADDRESS.HERE.93'. Swapping the two around, all clients took the update, nothing skipped a beat, however this also resolved the ability of Remote Control. A flaw with Kaseya? Please respond!

    Legacy Forum Name: How-To,
    Legacy Posted By Username: ljgrizzle
  • ljgrizzle
    Our original setup was to for the Kaseya check-in servers was 'DNS.1STHOST.COM' and secondary being 'IP.ADDRESS.HERE.93'. Swapping the two around, all clients took the update, nothing skipped a beat, however this also resolved the ability of Remote Control. A flaw with Kaseya? Please respond!


    This is referenced in the Kaseya help files and the KB. You could call it a "flaw" I guess, but it's more of a flaw with VNC versus Kaseya. See this KB for details. Boiled down: If the agents aren't checking into the primary address, remote control (KVNC & KFTP) will not work.

    I've submitted it as a feature request a while back, but I think it's all to do with the VNC server binding to a particular address, and changing this on the fly either isn't possible or isn't realistic (for example, just because some agents check into the secondary address doesn't mean all are... How do you handle that situation?). I'm told it's been added to the feature request list, but it sounds non-trivial so I wouldn't expect it to be coming down the pipe anytime soon.

    Legacy Forum Name: How-To,
    Legacy Posted By Username: arobar