Kaseya Community

2008 upgrade - our experience so far

  • After watching the forum and monitoring the status of the upgrade for almost two weeks, we decided to perform the upgrade a couple days ago.

    In typical Kaseya fashion, the upgrade EXE doesn't prompt/confirm when you run it (which is a tech etiquette faux pas, if you ask me) and doesn't provide any information or recommendations before it runs (such as reminding you to logoff all admins, shutdown service, etc.). Nonetheless, it ran and indeed we encountered multiple ASPNET errors while it ran due to the server being a domain controller. (I'm not sure how/why Kaseya didn't catch that in beta testing because it would seem an obvious choice to test the upgrade process on a domain controller).

    Despite those short-comings and even though it never told us that it had finished the upgrade process (the web page just seemed stuck forever), when we tried to login to the system, it worked. We almost accidentally ran the upgrade a second time (and since they don't offer a confirmation screen in the upgrade EXE, we had to manually kill the setup processes). But Kaseya was working and so we started to explore.

    Because of the ASPNET errors and after reading about it on the support pages, I assumed the new AD functionality wouldn't work. But it does. And it is very cool. The ability to see all AD users and computers is great. And we even tested an admin login authentication via AD and it worked as well.

    We alerted our clients that manage their own Kaseya/Acronis backups that the folder path would be changing to use the new GUID instead of name. And other than that, we just watched everything to see if anything broke. So far, things have been great.

    We started upgrading agents slowly because we were concerned it would cause problems. As we upgraded agents, we didn't notice anything different or problematic. Interestingly, though, we noticed that almost everything in 2008 works with the old 4.8 agent. Even the new AD Lanwatch stuff worked on 4.8 agents. SNMP/vPRO Lanwatch doesn't work until 5.0 agent and I assume the log parsing (which we haven't tested yet) only works with 5.0. But everything else, including remote control worked fine. We've upgrade a few hundred agents at this point to the new 5.0 and haven't had a single significant problem. The only minor problem that we've encountered when we upgrade the agent was this: on systems that we had assigned a "monitoring set" (i.e. monitoring disk space), immediately after upgrading those systems to 5.0, we received an alert from that monitoring set saying the threshhold was reach and was "zero". obviously, we checked and in reality the disk space was NOT zero. And when we look at the view of the monitoring log, it looks normal and appears to be running. So hopefully it is just a one-time glitch when upgrading and it will still work normally if/when the threshhold is actually reached.

    The new backup progress indicator and status screens are very nice. Remote control works well though we can't really tell the difference between VNC and K-VNC. Should we be able to notice a difference in look and/or function?

    One thing that we have not been able to figure out yet is how to convert our VSA admin accounts to AD-integrated logins instead. The help page says this:

    You can convert your own VSA logon to use your domain logon as follows:

    Open the System > Preferences page in the VSA.
    Enter your current VSA password in the Old Password field.
    Enter you domain and domain logon name, formatted all in lowercase as dom/username, where dom is your domain name and username is your logon name, in the Change Logon Name field.
    Enter your domain password in the New Password / Confirm Password fields.
    This enables you to logon to the VSA using your domain logon and have your VSA logon name and password managed using Active Directory. At the same time, you can continue to use all your previous VSA share rights, scripts and other administrator settings.


    However, when we go to the System > Preferences page, there is no "Change Logon Name" field. We can only change the password. We've tested both Master Admin and regular Admin accounts but neither one has that field. Anyone know how to convert VSA accounts? I have too many scripts and other things owned by my current VSA login so I can't simply start using a brand new login account. I need to convert it.

    Summary:
    The beta test process and upgrade program used by Kaseya, as pointed out by countless other individuals, needs to be seriously addressed. Many of the problems others encountered (and even the problems we encountered) should have been caught in beta. Or simply call this version the "early release" candidate so that when people try it out, they aren't expecting perfection on day one.

    Communication about the upgrade and everything also continues to be Kaseya's weak point. They need someone in their executive staff to take a class on business/customer communication styles. They just don't get the importance or effectiveness of clear and constant communication with the customer base. They seem to have selective hearing and selective speaking issues.

    Other than that, Kaseya did a nice job with this upgrade. There are indeed a number of very nice features. We're excited to try out the Mac agent but we're waiting for a bit more time to pass before we do it.

    The only big glaring thing that is still missing from Kaseya that we've discussed for years now is software asset management. Now just software license discovery (which Kaseya does moderately well at this point) but software asset management - i.e. the ability to enter into the system when you (or your customer) bought licenses, how many, and which applications found by the agent it applies to. And the ability to mark applications are "free" or "require license".

    There are many other enhancements that I hope to see from Kaseya over the coming year as well. But the software asset management is the most glaring, core piece missing that should be available in a system like this one.

    Also, I should note that we all pay a lot of money for both the software and support from Kaseya. It is time for them to invest more of it into their support processes/staff (because it is sorely lacking in both response time and quality of responses - not just during the new release, but all year long) and continued product enhancement - more features, more often. While we love the new features in 5.0, they were long overdue for a major enhancement and to be honest, we feel that they should have included even more new features - or should be seriously considering the new "user state" function as an enhancement to the core system rather than as one more opportunity to get more revenue out of their loyal customer base.

    Legacy Forum Name: 2008 upgrade - our experience so far,
    Legacy Posted By Username: kentschu
  • Good post. This process has been painful.

    I was also stumped by the change logon thing.
    If you go to system > logon policy and uncheck "prevent users from chaning logon" then you should be able to change to AD integrated.

    Seems to work alright although I am not sure why they use the forward slash instead of the backslash. I also noticed I had to enter my domain in lowercase. If I used upppercase it didn't work. Frankly if their program requires lower case it should convert the input box to lower automagically.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: dpope
  • dpope,
    Thanks for the info. That indeed allows us to integrated VSA logon to AD. Too bad they didn't mention that in the help files.

    I'm not sure that I'm convinced that doing the integration is a good thing, though. It has the appeal of using a "single sign-on" - which overall I'm a big fan of for security reasons (stronger passwords, less likelihood admins will write down password, etc.). HOWEVER, access to Kaseya is now dependent on the AD system providing the authentication being up. Our Kaseya server happens to live on our domain controller (for better or worse), so integration with AD for our admin users probably is fine (because if AD is down, Kaseya is probably down too). But for our customers that are admins, if their Internet connection or AD server is down and they want to research the problem and troubleshoot remotely via Kaseya, they won't be able to get in. We'll need to create a separate local login account that they can use in emergencies and that becomes a pain to maintain.
    Anyone have any thoughts on that aspect of VSA-AD integration?

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: kentschu
  • I just noticed another more serious problem with the VSA-AD integration. If we allow existing VSA admins to change their logon name (which is the only way to convert an existing VSA admin to AD integrated), the system does NOT validate the domain/username when the change is made. I made a change to a totally bogus domain/username and it let me do it. Now, I didn't logoff because I don't know how I would have gotten back in. And I changed it back to the correct name. But this is very dangerous.
    And since even Master Admins can't change logon names of existing admins, I assume we'd need to contact Kaseya tech support to fix it. And while waiting for tech support, the admin would be completely locked out of Kaseya.

    Why didn't they put in a validation routine when changing a logon to an AD-integrated logon name?

    BEWARE!

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: kentschu
  • For a secure system it is recommended that you do not use the same account for day-to-day activities as has elevated privileges over other systems.

    For the same reason that your day-to-day domain login should NOT be a domain admin, you should not use your day-to-day domain login to auth into Kaseya as any admin.

    However, there is great value to using this for the folks that want to use the remote features for their clients (like an alternate gotomypc).

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: rwitt
  • We don't see any value in using it for end-user remote access. VNC or any of the other methods in Kaseya pale in comparison to LogMeIn for remote control. So we setup LogMeIn Free for any users that want to work on their desktop remotely.

    I'm not sure I follow your logic regarding security and VSA-AD integration because I think you're actually confusing two separate issues - the issue of "least privilege" versus the issue of "authentication availability" that I was pointing out.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: kentschu
  • LUA has nothing to do with my reasons (although my previous post makes it sound like that).

    I use my domain AD privileges in a lot of places that shouldn't be trusted. From client computers accessing OWA, my mobile phone, my computer in the office ;-) and etc.

    If someone stole my domain credentials they would also have my K server credentials (if I used integrated auth).

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: rwitt
  • kentschu
    dpope,
    Thanks for the info. That indeed allows us to integrated VSA logon to AD. Too bad they didn't mention that in the help files.


    The optional ‘Change Logon Name’ field is documented in the help under ‘Logon Policy.’ We will add a cross reference to this documentation in the help section that describes converting a VSA login to use domain credentials.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: kaseya2
  • kentschu
    ... HOWEVER, access to Kaseya is now dependent on the AD system providing the authentication being up. Our Kaseya server happens to live on our domain controller (for better or worse), so integration with AD for our admin users probably is fine (because if AD is down, Kaseya is probably down too). But for our customers that are admins, if their Internet connection or AD server is down and they want to research the problem and troubleshoot remotely via Kaseya, they won't be able to get in. We'll need to create a separate local login account that they can use in emergencies and that becomes a pain to maintain...


    1) Kaseya will require the Domain Controller (DC) to be online during the 1st login attempt. If the DC is offline during subsequent logons, Kaseya will authenticate using cached credentials (similar to the way that you can still logon to a Windows notebook using AD credentials even if the notebook cannot connect to the DC).

    2) Note: you can define AD login accounts for each of your customers using their DC instead of yours. In this case, the customer can use their existing domain credentials, and the authentication happens against the customer’s DC (not yours).

    3) It is not ideal to host the Kaseya Server on a DC. You should consider moving it to a separate box.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: kaseya2
  • Thanks for the info. I did already know that we can authenticate our customers against their own domain credentials. And now that we know that it can use "cached" credentials, we will probably start doing that.

    Three questions:

    1) Will you be adding a validation routine when a user changes his/her logon name to use domain cred? Right now, it doesn't validate and it seems like it could end up stranding a user with no way to log back in.

    2) Is there a way to assign an existing VSA admin to a domain credential rather than asking them to change their logon name?

    3) What are the risks involved with hosting a domain controller on the same machine as Kaseya? Just the usual precautions regarding external access to domain controllers and the risk if they are compromised? Or are there specific aspects of Kaseya that make a domain controller more susceptible or hack-prone?

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: kentschu
  • kentschu

    1) Will you be adding a validation routine when a user changes his/her logon name to use domain cred? Right now, it doesn't validate and it seems like it could end up stranding a user with no way to log back in.


    In a future release, we are considering an enhancement in this area. It would either be a validation routine, or perhaps a way for a Master administrator to correct a compromised account (which would be useful beyond the AD scenario). For now, it would be wise to view the ability to change the logon name as a utility to be used as part of a controlled one-time migration of your existing accounts to AD (rather than permanently enabling the “Change logon name” field for general use going forward).

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: kaseya2
  • kentschu

    2) Is there a way to assign an existing VSA admin to a domain credential rather than asking them to change their logon name?


    No. Changing the login name is the only way to migrate an account at this time.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: kaseya2
  • kentschu

    3) What are the risks involved with hosting a domain controller on the same machine as Kaseya? Just the usual precautions regarding external access to domain controllers and the risk if they are compromised? Or are there specific aspects of Kaseya that make a domain controller more susceptible or hack-prone?


    The risks have nothing to do with Kaseya in particular. It is just the usual concern of having ports on your DC directly exposed to the Internet. Also, many sources suggest that DC machines should be exclusively dedicated to domain security, and 3rd party applications should be hosted on a separate machines whenever possible. Again, these are general security concerns that are not specific to Kaseya in any way. That said, the Kaseya Forum does not claim to be an authoritative source regarding Microsoft domain security.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: kaseya2
  • Yes, technically speaking, Microsoft doesn't recommend running just about anything on DCs - including but not limited to SQL (lite or otherwise), Exchange, and IIS. Various technical issues are cited, most notable rights of system accounts like Network, SYSTEM, etc. But the biggest reason is simply risk, as was already pointed out. Of course, one of the primary reasons for stacking this functionality is budget, so if you lack the budget for multiple boxes or virtualization, then you have to manage the risk and your mileage will definitely vary.

    Of course, things like SBS completely fly in the face of this (all of the above are piled on a DC as well) - so of course you manage the system differently and treat/protect it that much more carefully.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: BulletproofSean