Follow

Upgrading Kaseya Network Monitor 4.1 to version 5 (standalone)

There are two supported methods of upgrading Kaseya Network Monitor (KNM) standalone from version 4.1 to 5. Both methods require your existing 4.1 installation to be updated with the latest 4.1 build. You can find your build number by clicking “About” on the “Help” menu. Under “Version information”, it will tell you for example “Kaseya Network Monitor 4.1 (Build 8892)”. Upgrading is only supported for build 8892.

We have provided a function for upgrading your KNM installation by doing conversions of almost all settings. Version 5 is remodeled in many ways with more advanced, dynamic settings for groups, gateways, devices and monitors that include access settings for example. Because of this approach, automatic upgrading of some function will not be done. That is why we provide this guide, so that you can transfer your 4.1 settings to your new KNM v5 installation.

The settings that are not automatically upgraded, and covered in this document are the following:

  • License key
  • Log options will need to be reset in KNM v5
  • Lua scripts. The following functions will need to be changed:
    • TLuaFTPClient:Connect (remove credentials)
    • TLuaHTTPClient:Connect (remove credentials)
    • TLuaSSH2Client:Open (remove credentials)
    • TLuaWMIQuery:Execute (remove credentials)
    • TLuaFTPClient:Connect (remove credentials)
    • TLuaSFTPClient:Connect (remove credentials)
    • TLuaDB:Connect (remove credentials)
  • Networks
  • Passwords in data extraction API

License key

Due to changes in the license key structure, a new key has to be requested for KNM v5. To be able to upgrade from a previous version though, you will need to have a valid license key for KNM 4.1. During the upgrade, the existing license will be migrated to a trial license key. The new v5 key will have to be requested and entered in KNM within the trial time (default 30 days).

Log options

In the K menu, click on Log settings under Other. There you can set the logging options for Windows event log, Syslog and SNMP trap. New in KNM v5 is the retention options. The default setting is that all logs, records and top lists are kept forever but you can set each of them to a specified number of years, quarters or months.

Lua scripts

With the introduction of KNM v5, we no longer support the functions GetAccountUser() and GetAccountPassword(). We support three authentication methods for Lua scripts; No authenticationUse specific credentials in API:s andPerform Windows impersonation.

When choosing Use specified credentials in API:s you can choose which account (inherited or specific to the device) to user for the script, for example Windows domain account, SSH or VMware.

If you choose Perform Windows impersonation you can leave it at inheriting the credentials, or specify an account.

If you have a script where you need to send the credentials in a string to the device, for example with CIM (http) or VMware (http), you would need to set a password as an argument in the Lua script. See below for an example.

function OnConfigure()

Config = LuaScriptConfigurator()
Config:SetAuthor("John Smith")
Config:SetDescription("Using the password field in Lua")
Config:AddArgument("Username","Enter your username",LuaScriptConfigurator.CHECK_NOT_EMPTY)
Config:AddArgument("Password","Enter your password",LuaScriptConfigurator.CHECK_NOT_EMPTY+LuaScriptConfigurator.PASSWORD)         
Config:SetEntryPoint("main")

return Config

end

function main()

sUsername = GetArgument(0)
sPassword = GetArgument(1)

SetExitStatus(sUsername .. "/" .. sPassword,true)

end

This script would use a password field, and print them out as the monitor status, just as an example on how to use this.

Action lists and actions

Action lists no longer exist within KNM v5 since the function has been remodeled. Instead of static lists as in pre version 5, actions are now dynamic and can be inherited by nodes at a lower level. You can specify an action that applies to all child objects, and/or have specific actions per group, gateway, device or monitor. We differ between alarm actions and recovery actions.

Actions are migrated and the most used action will be set to be inherited from the top level group. Other actions will be set per device.

Actions (alarm or recovery) can be viewed and added by selecting the Actions tab on the object’s (monitor, device, group or gateway) information page. Turning on and off inheritance for alarm and recovery actions can be done by editing the object and on the Basic properties page, checking/unchecking Inherit actions.

Networks

The concept of networks in KNM 4.1 was basically to organize objects into separate groups. In KNM v5, grouping is built-in and more dynamic. A network in KNM 4.1 could be compared to a subgroup in KNM v5. The contact information that was kept for network objects in KNM 4.1 can be replaced by using Tags in KNM v5.

Logon accounts

In KNM v5, each object can have a number of different types of logon accounts associated with it.

The following logon accounts, set at the object level, will be migrated from KNM 4.1 to be set for the device in KNM v5

  • Windows domain account
  • SSH2/Telnet account
  • VMware account

In KNM v5, we have a new range of different types of logon accounts and it’s structured in a much better way with having logon accounts inherited by nodes below. Logon accounts that are set at the monitor level will not be migrated over when upgrading. If you have monitors that require specific logon accounts, you can now specify the account type for the device and the monitor will inherit the settings. You will need to set which account from the device that the monitor should use though.

As a general tip, setting logon accounts is best done at the gateway or group level. That gives a much better control. Sometimes it’s not possible to use the same account for multiple devices though, then you can either separate a group of devices in a subgroup or you can set the logon account at the device level.

Passwords in data extraction API enhancements

In previous versions of KNM, passwords could be sent to the data extraction API using MD5 hashes. To enhance security, KNM now requires passwords to be sent using SHA256 hashes.

Converting statistics records

At the end of the setup wizard, you will be asked if you want to convert the statistics. You can choose to do this now, or run the statconverter.exe application within your KNM root folder at a more convenient time. Until you have done so, your statistics records prior to your upgrade will not be accessible through KNM.

Each file that is converted is registered in a database named cstate.rds. That means you can choose to convert the most recent statistics now, and continue at any time you like.

After the conversion is done, the service Kaseya Record Manager will need to be restarted.

In-place upgrade

  1. Document your settings

    - Log settings
    - Networks

  2. Stop the Kaseya Network Monitor service
  3. Make a copy of your KNM root folder, with all subfolders and files and store the copy at a safe place
  4. Run the KNM v5 installer to upgrade your installation
  5. Run the statistics records conversion tool, or opt to run it later
  6. Logon to your upgraded KNM installation and perform the tasks above to manually migrate the remaining settings
  7. If you have created your own Lua scripts, these will remain in your script folder but now they need to be edited according to the description above. You may or may not also have to edit each Lua script monitor, making sure that the authentication settings are correct.
  8. Go to K menu -> System settings -> Monitoring -> Gateway server settings, make sure the correct IP address is chosen and click "Save". You need to click on "Save" even if you only have one IP address to bind the gateway server correctly to the IP address.
  9. Restart the "Kaseya Network Monitor" service to create the new "Kaseya Local Gateway" service

Upgrading using a new server

  1. Stop the Kaseya Network Monitor service.
  2. Make a copy of your KNM root folder, with all subfolders and files and transfer the copy to a temporary location at the new server.
  3. Run the KNM v5 installer to upgrade your installation.
  4. At the end of the installation, you will be asked of you want to convert the statistics records. You can choose to do that now (year by year) or do that later by using the statconverter.exe application in your KNM root folder. Until you have successfully converted your statistics, you cannot access the statistics before your upgrade to version 5.
  5. Logon to your upgraded KNM installation. Compare your settings with your old installation and make the changes accordingly, regarding the manual procedures discussed in this document.
  6. If you have created your own Lua scripts, these will remain in your script folder but now they need to be edited according to the description above. You may or may not also have to edit each Lua script monitor, making sure that the authentication settings are correct.
  7. When you are done reviewing your upgraded installation and everything works as expected, you can then stop theKaseya Network Monitor service on the old server. A good thing to do is to disable the service so that you don’t run two installations with the same configuration after you for example reboot the old server.
  8. After stopping the Kaseya Network Monitor service on the old server, transfer the files from the statistics folder created after your upgrade from your old server to the new one. Then run the statconverter.exe application to convert the remaining statistics records. Restart Kaseya Record Manager.
  9. Go to K menu -> System settings -> Monitoring -> Gateway server settings, make sure the correct IP address is chosen and click "Save". You need to click on "Save" even if you only have one IP address to bind the gateway server correctly to the IP address.
  10. Restart the Kaseya Network Monitor" service to create the new Kaseya Local Gateway service
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

0 Comments

Article is closed for comments.