It's been many years and we are now upgrading our on Premise VSA Server. We are currently on 126.96.36.199. Moving the ksubscribers, images and such is not an issue.
Looking for best practices to move Agent Procedures and existing schedules, Monitor sets and all uploaded programs and custom scripts.
Any suggestions? I have the R92 Kaseya Server Setup guide, but moving those areas are not mentioned.
If you move ksubscrubers database, most scripts schedules monsters audits etc. Should move also. You need to copy one or two folders over - the one that scripts are uploaded to (sorry, forget the name) and the one that the getfile() procedure saves to. 95% of things are in ksubscrubers anyhow.
Craig is right, most things should be no problem.
I know Kaseya has a procedure for this, since we discussed this with them a few weeks ago. So, I think you can just create a ticket and ask for some background info. From what I heard it should be possible to migrate everything, I got the impression there are script to assist you. However, specifics were not discussed, but we could be migrating from 188.8.131.52 too. Do share what the results are....
I thought so and just wanted to be sure. I am aware that since we use custom icons and favs, we need to copy over the WebPages\themes\default\images folder.
Thanks for the advice, now if I can only get the darn sql backup to restore! keep running into Restore of sql backup failure almost immediately after we try.
marcb , if you are simply moving the database to a new server, it is pretty straight forward, and there should be some good KBs on how to do that. I think there are 2-3 directories on the Kaseya Web server that need to be copied over. As long as you keep the same IP, the agents should just check in.
If you are doing a fresh install and MIGRATING your agents, then things get more interesting. You can export/import most of your settings, but the challenge is how to re-apply them. If your setup was pretty basic, then you can use a template or Policy Management to re-assign all your monitoring and settings.
If you were using Backup, KAV, KES, or KAM, then it is much more difficult to migrate, a full database move would be easier. Good luck!
I'm trying to restore the SQL backup file to a new sql server 2012 and continue to get the error message that the transact-SQL Statement CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 10240 MB per database.
The backup file is only 3.24 GB. Not sure where the error lies in SQL.
SQL Express has a 10GB per database limit. Are you sure you are using SQL Server Standard edition or better? The database backup at 3.24GB is compressed, so no indication as to the actual database size.
Combo, thank you! I have a paid license for SQL Server 2012 and 2014. I will upgrade the express version which has the 10gb limit to the paid 2014 version. Although my current server is SQL 2012 Express and is just fine.
Will advise if the full version made the difference.
Upgraded to full version (licensed) SQL Server 2014 and with SP1. Now when I try to restore the ksubscribers.bak file the error message is "The backup set holds a backup of a database other than the existing 'ksubscribers' database.
I'm clueless now as I right clicked on the ksubscribers database and chose a backup.
It sounds like you are trying to restore over the top of a 'blank' ksubscribers database. I think you need to remove that blank database and then restore your backup as a new ksubscribers database. I believe this should be done before Kaseya is installed, so not 100% certain how it will go after installation..
Yep, that was it. Worked immediately after I removed the new ksubscribers database! Support is still looking into this. I will close my 5 day old ticket....
Thank you Combo!
I'm glad to hear you were able to get this resolved with the help of the community. Out of curiosity, I took a look at your ticket and it looks like it was opened just before midnight PDT on Friday night. Our Asia-Pacific support team responded when they came online on Sunday (their Monday) and there were a couple of exchanges yesterday.
I know there are times when Support is not able to resolve issues as quickly as many would like, and the team is working hard to improve overall resolution time of tickets. The Support organization offers 24/7 coverage for business-critical issues (see the Kaseya Support Policy for details on Severity levels) and extended business hour support for all other issues. Because our Support team is stationed around the globe, most days there is a Support office within their normal working hours. The weekend, however, does create a gap in coverage; Severity 1 coverage covers this gap for business-critical issues and other severities will generally be handled on the next business day.
I understand there has been some times where the initial response has not been as timely and do appreciate how delays in resolving tickets - caused by any reason - can have significant impact on your ability to run your business. I do, however, see Support has been quite responsive with this particular issue which, with many thanks to the Kaseya Community, was resolved within one business day.
Brande, My ticket was not created as Critical or Severe (most critical level) as that should be reserved for systems that are completely down or going down. Immediate assistance should be reserved for those systems in true immediate need. I am always keenly aware of others time and efforts and try not to burden resources when the need is uncalled for.
I chose the second level of support because I was creating a new server and while my existing server is well and functioning, time is on my side and I could wait to get this done.
I do not have a problem with support regarding this instance as I believe it was being handled in an appropriate manner by Kaseya support.
Thank you for the review and explanation.