KLC unable to connect if DNS is unavailable on agent side

KB# KKB001013

QUESTION

KLC unable to connect if DNS is unavailable on agent side

SYMPTOMS

- Agent check-in policy is configured with a DNS name as the "primary kserver" and an IP as the "secondary kserver"

- primary kserver address can no longer be resolved on the agent machine due to DNS failure

- agent continues to check in using the secondary kserver address, but Live Connect fails with the following error in the "Start KLC" procedure on the agent:

CAUSE

This problem is a combination of the amount of time the DNS look-up takes to fail and the wait time of the browser side. The relay attempts to connect on 3 different addresses (name/IP from System > Configure page, followed by primary and secondary kserver addresses from Agent > Check-in Control) but it tries to resolve any DNS names before attempting the connection. If the DNS lookup takes more than ~6 seconds, the connection will fail due to time-out on the browser side relay plug-in.

SOLUTION

The issue will be addressed in the next release of Kaseya (v6.4).

This workaround can be used to gain remote access to the agent and resolve any DNS issue: -

1) go to Agent > Check-in Control and temporarily change any DNS names for the affected agent(s) to the matching IP addresses - allow 1 or 2 minutes for the change to be applied to the agent

2) go to System > Configure page and temporarily change "external name / IP address of Server" from DNS name to IP address

3) try Live Connect to the agent again

4) once the DNS issue is resolved, reapply the desired configurations

APPLIES TO

Kaseya v6.3

Duplicate Domain GUID in Kaseya Discovery

KB#:  KKB000990

QUESTION

Why am I getting error "Domain GUID reported by Netlogon is incorrect. Windows Active Directory issue must be fixed before this domain can be synced correctly"? Why are the Domain GUID's not matching correctly in Kaseya Discovery?

ANSWER

Kaseya Discovery checks for the domain GUID mismatch issue when it runs because it has been found to cause issues in the tracking of synced objects due to the fact that the domain GUID is incorrect in this case.

The cause is a bug in some OEM preinstalls of Windows Small Business Server (SBS). With this bug, the domain GUID entry in the registry entry "HKEY_LOCAL_MACHINE\SECURITY\Policy\PolDnDmG" on the DCs are out of sync with the Active Directory database. To fix it, we recommend updatingthisregistryentrytothecorrectdomainGUIDonallaffectedDCsincontactingMicrosoftsupportasper the domainarticlelinkbelow. The correct domain GUIDs can be found in the error message in Discovery.

Please review the KB article link to fix this issue:
http://support.microsoft.com/default.aspx?scid=kb;en-us;909639&sd=rss&spid=3208
PleasenotethattheregistryentrymustbeenteredinthecorrectformatbyswappingsomeofthebytesofthecorrectdomainGUIDandalsothatalltheDCsandworkstationsonthedomainmustberestartedafterthechange.
 
If any duplicate domains appear in Kaseya after the changes have been implemented on the Active Directory, please submit a ticket for further investigation.

APPLIES TO

Kaseya v6.3
Kaseya Discovery

Howtosetup*Setup the Kaseya Agent into a computer OS image

KB #: KKB000745

Question

Imaging a Mac machine with the Kaseya Mac Agent--------

----
Solution A)

1 - After all final preparations are done in your image, download the intended Mac Agent installer to the master image machine.

2 - Disconnect the machine from the network and install the agent. Verify that the agent's kaseyad.ini file (located in /Library/Preferences) contains the default values.

3 - Create the master image and deploy it to the targeted machines.

This should not allow an agent account and GUID to be created on the machine until it is again connected to the network (via the imaged machine, etc...).

-------

Solution B)

1 - Download the appropriate KcsSetup.app installer to a directory on the master image machine.

2 - Write a .sh script to execute the installer with appropriate admin privileges and place it in the /System/Library/StartupItems/ location. For it to only run once (only needed once), add the rm -f /System/Library/StartupItems/[SCRIPT_NAME].sh incantation to the end of the script so it deletes itself when done.

For KID 1.1.  If you want to deploy using BootMenu but can't PXE boot, and don't have a CD ROM drive you may want to create a bootable USB stick using the following steps.

1. Find kid11.iso on the VSA in \Kaseya\WebPages\ManagedFile\VSAHiddenFiles\ImageDeploy (or get the latest copy from here) and copy it to your local computer.
2. Download unetbootin from http://unetbootin.sourceforge.net (You probably want the download for Windows )
3. Run Unetbootin
4. Choose Diskimage, ISO, and point Unetbootin at kid11.iso 
5. Choose USB Drive, your USB drive letter, and push OK  

6. Unetbootin will copy the ISO files on to the USB stick and set it up for booting

7. Choose Exit.
8. Edit syslinux.cfg on the USB stick and add the extra parameters "nozswap noswap syslog text edd=on"
   to the line that begins "append initrd "

9. Your USB stick is now ready for booting.

*KID 1.0 Quick Checklist

KB #: KKB000906

PleasenotethatthisisforKID1.0only(Kaseya6.1/6.2)!  IfyouarerunningKaseya6.3thenyouhaveKID1.1andthisChecklistdoesnotapply.

Quick Checklist for KID 1.0.

Make sure your VSA is fully hot fixed.

Make sure your repository machine can connect to the VSA on port 80 (this can be manually changed to use HTTPS and port 443). See the following KKB article on how to do this: http://community.kaseya.com/kb/w/wiki/1012.aspx

No transparent proxies are in the way between the VSA and your endpoints to be imaged or the repository. We have found issues with SQUID stopping KID from download required components. Currently any proxy between the VSA and the repository is currently unsupported in KID 1.0.

You need to create a repository on each subnet where you want to create or deploy images. You will not be able to travel the repository to different networks and take images or backups. 

KID 1.0 will not span multiple subnets with a single repository. So a repository is required for each subnet.

The repository must be on a physical machine, not a virtual machine. Also the physical machine (or repository host) cannot run any other hypervisor systems including VMware Workstation or Microsoft Virutal PC.

The physical machine MUST have a SINGLE WIRED connection to the local network. Wireless network connections are NOT supported. 

The physical machine MUST have been audited by the VSA before it can used as a repository or it will not show up in selection for use.

Unless your existing network conflicts with the PXE default address range of 192.168.25.X/24, do NOT change this address range on your repository unless the default conflicts with physical machines on your network.

Make sure you're running a DHCP server accessible from the subnet where you have a repository and a working DHCP scope.

Make sure your target machines for image creation and deployment are configured to PXE boot before disk boot.

Make sure there is no other PXE server running on the same network as your KID repository.

Make sure you create your images on a system with the same sized, or smaller, hard drive as the machines you plan to deploy to.

A agent license is required for each repository.

Troubleshooting: General

Problem: Invalid column name ‘agentdisplayname' error in the machine history dialog.
Solution: Click on a different column header in the grid view -- this error occurs when the Machine column is selected for sort.

||Note - The ↑above embedded Youtube video uses Flash for desktops.
||If necessary, this can be downloaded and installed here.

||Note - If the ↑above embedded slides do not resolve or ask you to sign in, clear
||your web browser Google cookies & cache/data, and/or use another browser.

KB# KKB001018

SYMPTOMS

Live Connect > VPN function (KVPN) reports a successful connection, but there is no network connectivity to the remote network (pings do not respond).

CAUSE

The KVPN plug-in is unable to automatically add a route to the remote network on the Live Connect user's computer. This is a known limitation affecting all 64-bit versions of Windows. 

SOLUTION

The problem will be addressed programmatically in a future version of Kaseya.

Currently, the missing route must be added manually on the Live Connect user's computer. Here are the steps to achieve this: -

1) establish VPN connection

2) check the "assigned IP" of the VPN tunnel. In the above screenshot this is 192.168.212.2 but the sub-net address will depend on the local and remote network addresses. It will always end in .2 though.

3) run the following command from Windows command shell (cmd.exe): -

route add 172.16.29.0 mask 255.255.255.0 192.168.212.1

 (where 172.16.29.0/255.255.255.0 is the remote sub-net address and 192.168.212.1 is the agent side VPN tunnel address. This will be same sub-net as the "assigned IP" displayed in KVPN, but ending with .1 instead of .2).

It should now be possible to ping IP addresses on the agent's network.

APPLIES TO

Kaseya VSA (v6.2 and above)

QUESTION:

Why do KAV endpoints show a different license expiration than shown in the KAV UI?

ANSWER:

The endpoints are always going to show an expiration different from the license expiration shown in KAV.  There are  multiple licenses and timers in play that are integrated together to coordinate the Kaseya and Kaspersky licenses for the integrated KAV product.  The Kaseya license (the license by which you are billed) expires 1 year after installation to the endpoint, and is noted in the KAV module as the license expiration date for the endpoint.  At the end of that year, the number of expired licenses is increased by one, the agent ID is issued an unused license, and the unused license count is decreased by one.  All of this is independent of anything happening on the endpoint.

On the endpoint, we apply an initial 90 day license file at installation.  As that file nears expiration, 30 day extension license files are applied via the KServer during a maintenance process.  As long as the endpoint is flagged on the KServer as having a valid KAV license, it will be issued  an extended Kaspersky license.

Update 2/13/2012: Starting 3/1/2012, the initial license will be reduced from a 90 day license to a 60 day license.  Kaspersky sets a 120 day shelf life expiration from date of license code generation.  This has caused an issue where endpoints will display a "Your license will expire in X days" in certain circumstances.  This issue is resolved when the initial license key expires, as at that time a new update.key license can be applied, extending the license for an additional 30 days, but can be disconcerting to end users during the time that the message is displayed.

Background: Because of the 120 day shelf life from the time the license is generated, if the endpoint is installed near the end of the month the 120 day shelf life becomes the limiting factor on the licenses, instead of the 90 day and 30 day license term.  

Example: Kaspersky licenses are generated 2/1/2012, setting shelf life expiration to 6/1/2012.  An endpoint is installed on 2/25/2012, at which point the 90 day license will have an expiration of 5/25/2012 (end of 90 day term), and the 30 day license will have an expiration of 6/1/2012 (end of shelf life).  This will cause the endpoint to display "License will expire in 'X' days" starting at about 5/17/2012.  On 5/25/2012, when the 90 day license expires, a current 30 day license will be applied in its place, extending the endpoint license through 7/1/2012, and the expiration warning will stop.

Update 7/1/2013: Because of a recent increase in the incidence of endpoints displaying the "License will expire in 'x' days" message, an update to both KAV 1.4 and KSC 1.0 is in process that will add a "Fix Kaspersky Key" button to the KAV UI that will delete the currently assigned rolling Kaspersky key, and reapply both the initial and update key currently available on the VSA.

Contractually, we cannot completely disable the license expiration pop-up, and because of the licensing schema outlined above, the license expiration information is only available on the local endpoint, we do not have the means to gather the local endpoint license expiration for reporting to the VSA and/or KAV module.

To summarize:

Kaseya KAV license: 1 year, noted in KAV module

Kaspersky KAV license: initial 90 day 60 day, rolling 30 day extension on kserver checkin, noted on endpoint.

As long as the Kaseya KAV license is valid for the endpoint agent ID, the rolling 30 day license should be applied out automatically as the previous nears expiration.  We have seen cases where the endpoint will display either a "License will expire in 'X' days" message or "License Expired" message.  In these cases, open a support ticket, and a specialist will be able to investigate why the updated licenses are not being pushed to the endpoint.

APPLIES TO:

KAV 1.1

KAV 1.2

KAV 1.3

KAV 1.4

KB# KKB001019

SYMPTOMS

Backup fails on Kaseya Backup client with Acronis v11. Backup Log reports this error: -

Backup failed - An error occurred while executing the command.| Error: 0x1510008| $module = "acrocmd_vs_37608"| Tag: 0x7A8E520180FDC065|ProtectCommand: Failed to execute the command.| Error: 0x1330029| $module = "agent_protection_addon_vs_37608"| Tag: 0xE6792A5EE190DDA7|Step 'Backup' has failed.| Error: 0x1490002| TraceLevel = 1 (0x1),| $module = "gtob_backup_command_addon_vs_37608"| Tag: 0x8EDC81EA38FABA52|The activity has been canceled.| Error: 0x1350032| $module = "service_process_vs_37608"| Tag: 0x8D165E86FB819578|TOL: Failed to execute the command. The 'Backing up' command backs up the specified data to the specified location.| Error: 0x1350016| TraceLevel = 1 (0x1),| $module = "gtob_backup_command_addon_vs_37608"| Tag: 0x8D165E86FB8195FF|The running task has been canceled.| Error: 0x8F0003| IsReturnCode = 1 (0x1),| $module = "disk_bundle_vs_37608"| Tag: 0x1CD98AAE889424F6

CAUSE

The command line interface (CLI) in Acronis v11 prompts the end user if a backup cannot be completed in some circumstances, for example: -

• the image location disk runs out of space during the backup
• the image location becomes unavailable during the backup (e.g. drive is disconnected)

When the backup is run from Kaseya, it runs under the SYSTEM account or the "agent credential" account, so end user prompting is not possible.

The "running task has been canceled" message means that the Acronis backup job could not complete without end user interaction.

SOLUTION

Kaseya and Acronis Engineering teams are working to improve logging in this scenario, so an explicit error message is displayed depending on the condition that is preventing the backup completing (for example "disk is full").

However if you see this error message, use the following steps to troubleshoot: -

1) check that the image location has sufficient space to create the backup. This can be done using the "Check free space" button on the Image Location page, and comparing the amount of space with the size of the existing backup set.

2) ensure that the image location is available for the entire backup windows. If backing up to a network share, make sure the server or NAS device is always available and check for any network issues.

FURTHER INVESTIGATION

If the issue persists, please open a Kaseya support ticket and provide the following information: -

1) if you have provided support with access to your VSA, specify the affected agents

2) complete error message from Backup Logs page

3) Acronis raw log - this is an XML file that an be accessed by clicking on the "failed" hyperlink in the "Result" column

4) agent procedure log from time the backup started until time of failure

5) details of troubleshooting steps taken so far

APPLIES TO

Kaseya Backup v5.0

Acronis v11.x

KKB000896

SYMPTOM

Unable to expand the file selection list using Internet Explorer v9 or higher. This affects the following functions: -

• Recovery > Restore
• Recovery > Manage
• Backup > Schedule

Other browsers (IE8, Firefox, Chrome) are not affected.

CAUSE

There is a compatibility issue between IE9 and the current Java framework used for the Kaseya user interface.

SOLUTION

This issue has been resolved by a Hotfix - please update to latest Hotfix on your VSA

>System >Configure - Get Latest Hotfix

KOB 2.0 Hotfix- 3599 - Fix File Tree on IE 9/10. Fix quickview in 6.3    
Filename: WebPages\KOB\ASPx\controls\clientSideIncludes.ascx

APPLIES TO

Kaseya Data Backup (KDB) v2.0

Kaseya VSA framework (all versions)

Internet Explorer v9 and above

KB# KKB001017

QUESTION

When reviewing Status > By Machine page and after running a KSDU scan, the Machine Version column is not updating or blank.  Also KSDU is reporting successfully deployments of the software; however, the module lists the machines as being out of date even though they are not.

ANSWER

The KSDU Latest Scan or Baseline Scan is failing. This can be due to a wide variety of issues and we will continue to update this KB to accommodate the KSDU errors thrown. KSDU scan errors can be found by navigating to the Schedules page, selecting the agent & associating scan schedule, and clicking on the View History button.

A list of errors is shown below:

Error 215 / Certificate Errors - Some Firewalls, Anti-Virus, Security products and HTTP proxies can interfere with Ninite's connections and cause this. To resolve this matter, please attempt the following troubleshooting steps:

• Add the following sites to your firewall/proxy’s whitelist:
  • ninite.com on port 443
  • cloudfront.com on port 80
  • ocsp.digicert.com on port 80 OR crl3.digicert.com on port 80 OR crl4.digicert.com 80
• Turn off “Check for Server Revocation” option in Windows Internet Options (Advanced Tab).
• Add the following exclusions to the Anti-Virus/Security software on the endpoint (if applicable):
  • The Agent Working Directory (i.e. C:\kworking)
  • The Agent Install Directory (i.e. C:\Program Files\Kaseya)
• Make sure the date is set correctly on the endpoint.
• Please attempt to use the KSDU Offline Scanner for endpoints that do not have an internet connection. The scanner can be configured in the Application Settings page under the tab Offline Scanner. Note: This option is only available in Kaseya VSA 6.3 / KSDU 1.1

Skipped (program running/locked) - Close the software being updated, and possibly any open browser(s). Then try the install again.

Skipped (misc.)– Please contact support for further assistance.

Agent Procedure errors– Please contact support for further assistance.

If the above steps do not resolve the issue, please contact support for further assistance.

MORE INFORMATION

https://ninite.com/help/errors/

APPLIES TO

Kaseya Software Deployment & Update (KSDU), Kaseya VSA 6.3, KSDU 1.1

Eventlog collection in 6.3

A recent hotfix has introduced a new feature where dependency on eventlog collection to invoke eventlog alerts has been removed and alerts can function without it. Please note that this feature does not disable the eventlog collection feature at all and it can be activated from Agent Tab > Event Log Settings.

What is required to activate this feature?

1 - Get latest hotfixes in your VSA

Note - SaaS VSA users already have them

2 - The Windows Agent must be up to date at Agent version 6.3.0.7 or above.

Note - If under 6307 on your Windows agent, choose to force update it via the Agent > Update Agent page

Eventlog alert Behavior in version Kaseya Version 6.2 (Previous method)

VSA automatically collects Eventlog Level and Type when corresponding eventID is set for alerting.

Applies to:

Kaseya Version 6.3

KB#: KKB000859

From time to time we receive requests for a list of Kaseya Cloud IP address ranges.  The Kaseya Cloud IP addresses do not change frequently however we cannot guarantee advanced notice of changes at all times.  When possible, advanced notification will be provided.  

To ensure successful delivery of Alerts and Alarms via Kaseya's e-mail relays, the following IP addresses should also be added as firewall rules on port 25:

• 79.125.7.9
• 122.248.234.122

There are new Alternate Relay Servers to improve Remote Control, KLC and FTP features.  These remote relays should also be added as firewall rules on port 5721:

• 23.21.215.151
• 23.21.255.96
• 46.137.245.248
• 54.217.217.109
• 54.232.121.142
• 54.248.126.90
• 54.252.98.101
• 177.71.182.232
• 184.169.149.141
• 184.169.166.254
• 196.33.249.106
• 196.38.93.170
• 197.96.18.202
• 202.93.250.66

KB # KKB000748

�

�

KB#:  KKB000458

QUESTION
I attempt to create a package using the Kaseya packager (kpacker.exe) but why does it continue to fail?

When you launch the generated .exe you get the following message: Unexpected end of file when processing package. Possible corrupt package file. Install failed.

ANSWER
The package generated may be 2 GB or larger. Due to operating system limitations, Windows cannot run an executable file larger than 2 GB in size.

This issue only affects old, unsupported versions of Kaseya software, and has been resolved by a later version of Kpacker.exe, which generates a separate .dat file to hold data for the package if it would exceed 2 GB in size.

MORE INFORMATION
You must be running Kaseya v 5.x and above to take advantage of this functionality in the product. Please note that Kaseya v4.8 and Kaseya 2008 are no longer supported.

APPLIES TO
Kaseya 4.8.1 and below

• Microsoft Releases an Office 2010 patch on “Patch Tuesday” (the second Tuesday of each month).  Microsoft does not add the patch to the MUC the same day.
• You scan an endpoint running Office 2010.  The patch will not appear in Kaseya Patch Management because the patch has not been added to the MUC.
• Microsoft adds the Office 2010 patch to the MUC on Thursday.
• The patch does not appear in Kaseya Patch Management because you have not scanned an endpoint that might need the patch.
• You scan an endpoint that does not have Office installed.  The patch does not appear in Kaseya Patch Management because the machine scanned cannot make use of the patch and therefore is not needed in the environment.
• You scan an endpoint running Office 2010.  Kaseya recognizes that the newly-released patch is needed by an endpoint in your environment.  The patch is added to your view in Kaseya Patch Management.
• Unless you have the default action set for this type of patch, the patch will appear as Approval Pending and will not be deployed.  You must Approve or Deny the patch in Patch Policy.

Microsoft Update Catalog (requires Internet Explorer 6.0 or later):  http://catalog.update.microsoft.com/v7/site/Home.aspx

KB#:  KKB000256

QUESTION

When I filter by a certain group, it shows tickets from other groups as well. The machine or group appears in red, sometimes with a "?" in place of a machine name,and the tickets are visible regardless of the group filter.

ANSWER

When this occurs, this specifies that they have "orphaned tickets". Orphaned tickets occur when customer's delete a group/org/machine ID that is associated with tickets. The ticket will no longer be associated to anything, so since it can no longer be filtered by their own group/org/machine ID, they will appear when filtering by any other existing group/org. You can identify an orphaned ticket by going to the Ticketing tab > View Summary page. The ticket association will appear in red:

Customers have the following options to correct this issue:

1. Delete all orphaned tickets
2. Re-associate them with an existing machine group/org/ID
3. Create a new org and call it for example, Orphaned Tickets, then associate all orphaned tickets with it

APPLIES TO

Kaseya VSA v6.0, v6.1, v6.2, v6.3

KB# KKB001020

QUESTION 

Can the Discovery LAN Scan run across multiple subnets?

ANSWER

Unfortunately Discovery is unable to scan across multiple subnets in most circumstances. For Discovery to populate the Discovered Devices page, the module needs the results set to be returned back for the Quick Scan and Deep Scan. If one is missing, Discovery is not able to populate the pages.

It is true that the Quick Scan will find the device, as the scan essentially does Ping request to the devices within a network. However the Deep Scan looks for the MAC address and other network related data from those devices. Within certain network environments, the configuration does not allow the MAC Addresses, and other network fingerprints, to be passed in between subnets and because of this, Discovery is currently not able to populate the Discovered Devices page with devices outside of the Network Probe's subnet.

Workaround: We kindly advise to run the LAN Scan on each network subnet or, if applicable, adjust the network environment so that the MAC Address and/or other network fingerprints are not stripped going across the subnets.

We are actively looking for alternative routes to obtain these devices and bypass the limitations currently known.

APPLIES TO

Kaseya Discovery (KDIS)