Quantcast
Channel: KKB Wiki
Viewing all 118 articles
Browse latest View live

What partitions and File Systems are currently supported with KID 1.0?

$
0
0
Revision 3 posted to KKB Wiki by Andy Denley on 4/18/2013 2:44:09 PM

What partitions and File Systems are currently supported with KID 1.0?

Q. What partitions are currently supported with KID?

A. Currently with KID 1.0 we support only standard primary partitions. 

With File Systems we currently support FAT / NTFS from Windows 2000 and above.

*****CurrentlyGPTpartitiontypesARENOTSUPPORTEDfortakingordeployingimagestoo.*****

http://en.wikipedia.org/wiki/GUID_Partition_Table

With future releases of KID we are planning to include the following support. 

HPFS (Mac) and ExtFS(2/3) for Linux. 


What partitions and File Systems are currently supported with KID 1.0?

$
0
0
Current Revision posted to KKB Wiki by Tim W on 4/18/2013 10:14:41 PM

What partitions and File Systems are currently supported with KID 1.0?

Q. What partitions are currently supported with KID?KaseyaImagingandDeployment(KID)?

A. CurrentlywithWith KID 1.01.1 we support only standard primary partitions. 

With 

File SystemswecurrentlySystem support: FAT / NTFS from Windows 2000 and above, Ext2/3forLinuxbackups.

*****Currently 

DiskLayout: GPT partitiontypesARENOTSUPPORTEDfortaking or deployingimagestoo.*****

http://en.wikipedia.org/wiki/GUID_Partition_Table

WithfuturereleasesofMBR 

Note: KID weareplanningtoincludethefollowing1.0doesnot support . 

HPFS(Mac)andExtFS(2/3)forLinuxGPTdisklayouts,orExt2/3.

*Kaseya Linux Agent - Interim build release notes

$
0
0
Current Revision posted to KKB Wiki by amado.hidalgo on 5/10/2013 4:32:13 AM

*Kaseya Linux Agent - Interim build release notes

Agent,linux,VSA,interim,releasenotes,agentreleasenotes

KB Article #: KKB000768

Click here to load the contents of this page in a new window.
 

*Kaseya Windows Agent - Interim build release notes

$
0
0
Current Revision posted to KKB Wiki by amado.hidalgo on 5/10/2013 4:32:37 AM

*Kaseya Windows Agent - Interim build release notes

Agent,VSA,windows,interim,agentreleasenotes,interimreleasenotes

KB Article #: KKB000767

Note-IfthebelowiFrameembeddeddocdoesnotresolveorasksyoutosignin,clearyourwebbrowserGooglecookies&cache/dataand/oruseanotherbrowser,andoptionallytry

Clickhere to load thecontentsof this URL:http://win-agent-interim-release-notes-publicpageinanewwindow.
 

*Kaseya Mac Agent - Interim build release notes

$
0
0
Current Revision posted to KKB Wiki by Dylan M. Lagi on 5/10/2013 6:57:15 AM

*Kaseya Mac Agent - Interim build release notes

Agent,Mac,VSA,MacOSX,interim,agentreleasenotes

KB Article #: KKB000769

Click here to load the contents of this page in a new window.
 

Troubleshooting failed patch installs and failed patch scans and incorrect data on Patch Status page

$
0
0
Current Revision posted to KKB Wiki by Brande Schweitzer on 5/13/2013 8:07:03 AM

Troubleshooting failed patch installs and failed patch scans and incorrect data on Patch Status page

KB#:  KKB000781

 

QUESTION:

Troubleshooting failed patch installs and failed patch scans

 

This article may be helpful in troubleshooting the following issues:

  • Patch Scan fails
  • Patch Status shows no patch data (only dashes) even after patch scan
  • Patch Status shows no missing patches but you believe there should be some
  • Patch Status numbers do not appear to be changing over time when you believe they should
  • Patches show as Missing or Failed in Kaseya but are installed on the endpoint
  • Patches show as Missing or Failed in Kaseya they are not missing according to Microsoft Update

 

In order to determine whether this article may be applicable to the conditions you are experiencing, view the Agent > Agent Logs > Agent Procedure Log (called a Script Log prior to Kaseya v6.1) for the specific endpoint.


Note:  ensure you are reviewing the Agent Procedure log or the Script log, not the Agent log:


     or      

 

Locate the time of a recent Patch Scan.  If you see a log entry indicating, “Patch Scan check failed using the primary data source…” this article may help to resolve the issue.  If you cannot find a recent patch scan, go to Patch Management > Scan Machine, select the endpoint, and click “Run Now” to force a new Patch Scan.  Once the patch scan completes, review the logs.  If you do not find this error in the Agent Procedure log, this article does not apply.

 

ANSWER: 

Patch Scan can fail to use the primary source for a number of reasons.  To explain this, it is necessary to first address the differences between the primary and alternate data sources.


The Primary Data Source for patch management is the Microsoft Update Catalog.  Kaseya leverages the Windows Update Agent (wua.api) to check the Microsoft Update Catalog (MUC) for all patches currently available and to determine which of those patches are applicable to the endpoint.  The Kaseya UI allows you to manage which patches should be installed via Patch Policy, but Kaseya is not "deciding" which patch(es) apply to a specific endpoint.

When the Primary Data Source is not available, the patch scan will defer to an alternate source.  This source, Windows Server Update Service (WSUS which, despite its name, is not applicable only to servers) is a .cab file that is stored locally on the endpoint.  As there is a file size limit to WSUSscn2.cab, it contains only an extremely limited number of patches - only current, active Service Packs, Security Updates, and Update Rollups.  For example, where the MUC might contain 10,000, the .cab file might contain only 100.  Of those, only one might potentially apply to the endpoint and if that patch is already installed (Windows 7 SP1, for example), then patch scan would not report any needed patches.

 

The Agent Procedure log will contain an error code indicating why the scan failed to use the primary data source.  This error is Microsoft-generated and will be formatted similar to 0x00000000.  You can often find some general information about the error code by searching the web.  Technet can be a good place to begin, and this site is also a good reference.

The failure of the primary data source is generally caused by only a handful of things:  firewall and/or proxy restriction, the Windows/MS update service being disabled by Group Policy (GPO), and/or the Background Intelligent Transfer Service (BITS) not being enabled on the endpoint.  There are some other, less common issues the can cause this, but these three contribute to more than 95% of the failures of the primary data source.

1.  Ensure the five websites necessary for patching are not disallowed by Firewall, Proxy, web filter or other security services (allow anonymous browse access to these sites).  The five sites are:

·         update.microsoft.com

·         download.microsoft.com

·         download.windowsupdate.com

·         www.windowsupdate.com

·         vsaupdate.kaseya.net


If you do not have direct access to the firewall/proxy configuration, you can verify this most of the time by logging into the endpoint using the account defined in Agent > Set Credential.  Using Internet Explorer (the MS sites require IE), browse to each of the websites listed.

2.  Verify MS/Windows Update is not disallowed by GPO for the endpoint or the user.  Because Kaseya leverages the wua.api to compare the endpoint to the MUC, disabling the service by GPO will cause the scan to fail using the primary source.  If you are unfamiliar with verifying GPO settings, please refer to 
http://support.microsoft.com/kb/328010 for detailed information regarding GPO settings.

3.  BITS is a built-in Windows service that can be managed in the same way as other Windows services (generally accessible by right-clicking "Computer" and selecting "Manage").  Ensure the service is enabled and set to start automatically.  You can find general information regarding BITS here:  
http://en.wikipedia.org/wiki/Background_Intelligent_Transfer_Service

4.  If the patch scan error being thrown is 0x80248014 andtheendpointsinquestionareWindows7/Server2003orearlier, stop the Windows Update or Automatic Update SERVICE, delete c:\Windows\SoftwareDistribution, and then start the Windows Update/Automatic Update service.  This error often indicates that the SoftwareDistribution folder (Microsoft's temporary patch folder, similar to Temporary Internet Files folder for Internet Explorer) has become corrupt or unreadable to WUA.  The folder and any necessary contents will be recreated automatically by the OS.  If you choose, you can rename the folder instead.  Either way, you must stop the WUA service before making a change to the folder and restart the service after the change is complete.  The windows service name is wuauserv and can be called via command line using "net stop wuauserv" and "net start wuauserv".  Please refer to Microsoft documentation for further information.

IftheendpointsinquestionareWindows8/Server2012,thisiscausedbyMicrosoft'snewrequirementfortheseproductstomanuallyopt-intotheMicrosoftUpdateservice(whichisneededtorunthescanagainsttheonlinecatalog/primarydatasource). Microsoftprovidesdetailshere: http://msdn.microsoft.com/en-us/library/windows/desktop/aa826676(v=vs.85).aspx. Kaseyaispreparingahotfixaddressthis. Whilenoadminactionisrequired atthistime,VSAadminscanopttocreateacustomscripttodeploytoendmachinesorrequestendusersoptintotheserviceasawork-arounduntilthehotfixisreleased.


Please check these settings, adjust as necessary, and re-run patch scan.  If the scan continues to report the failure of the primary source, research the error code via a web search.  Three helpful sites are:

If you are able to determine the meaning of the error, search the web for possible fixes.  If you are unable to determine the error, or if the steps you find do not resolve the issue, please open a ticket with Kaseya Support.  We will attempt to help resolve the Windows Update error.


ADDITIONAL INFORMATION:

You can sometimes find additional information regarding patch failures in the c:\Windows\WindowsUpdate.log file and/or any KB Log files that might have generated.  You can access the available files either on the endpoint or within the VSA by navigating to Agent Procedures > File Transfer > Get File and selecting the endpoint.

 

APPLIES TO:

Patch Management

VSA (all versions)

 

Kaseya VNC components w/ Apple retina display agent machines

$
0
0
Revision 1 posted to KKB Wiki by Dylan M. Lagi on 5/15/2013 7:49:29 PM

KB #: X

Question: I have Apple retina-based (HiDPI) hardware. Will the Kaseya VNC components in the Remote Control tab, QuickView, and KLC work properly with them?

Answer:

At the moment, this is not possible due to a limitation with the x11vnc server software used by Kaseya on the Mac endpoints. Kaseya Engineering is presently working out a permanent solution to this as such. This KB Article will be updated appropriately once that fix is made available.

In the meantime, this manual workaround can be done on the retina display-based machines:

1 - Ensure that the retina-based hardware has at least one user logged in.
2 - Run this command: sudo defaults write /Library/Preferences/com.apple.windowserver DisplayResolutionEnabled -bool YES
3 - Log off all users on the hardware and log back in - the highest non-retina resolution option is available.
4 - Select this highest non-retina display resolution.
5 - Kaseya VNC usage to the endpoint will work properly from there.

Kaseya VNC components w/ Apple retina display agent machines

$
0
0
Revision 2 posted to KKB Wiki by Dylan M. Lagi on 5/15/2013 7:49:44 PM

Kaseya VNC components w/ Apple retina display agent machines

KB #: X

Question: I have Apple retina-based (HiDPI) hardware. Will the Kaseya VNC components in the Remote Control tab, QuickView, and KLC work properly with them?

Answer:

At the moment, this is not possible due to a limitation with the x11vnc server software used by Kaseya on the Mac endpoints. Kaseya Engineering is presently working out a permanent solution to this as such. This KB Article will be updated appropriately once that fix is made available.


In the meantime, this manual workaround can be done on the retina display-based machines:

1 - Ensure that the retina-based hardware has at least one user logged in.
2 - Run this command: sudo defaults write /Library/Preferences/com.apple.windowserver DisplayResolutionEnabled -bool YES
3 - Log off all users on the hardware and log back in - the highest non-retina resolution option is available.
4 - Select this highest non-retina display resolution.
5 - Kaseya VNC usage to the endpoint will work properly from there.


Kaseya VNC components w/ Apple retina display agent machines

$
0
0
Revision 3 posted to KKB Wiki by Dylan M. Lagi on 5/15/2013 7:54:53 PM

Kaseya VNC components w/ Apple retina display agent machines

KB #: XKB0001010

Question: I have Apple retina-based (HiDPI) hardware. Will the Kaseya VNC components in the Remote Control tab, QuickView, and KLC work properly with them?

Answer:

At the moment, this is not possible due to a limitation with the x11vnc server software used by Kaseya on the Mac endpoints. Kaseya Engineering is presently working out a permanent solution to this as such. This KB Article will be updated appropriately once that fix is made available.


In the meantime, this manual workaround can be done on the retina display-based machines:

1 - Ensure that the retina-based hardware has at least one user logged in.
2 - Run this command: sudo defaults write /Library/Preferences/com.apple.windowserver DisplayResolutionEnabled -bool YES
3 - Log off all users on the hardware and log back in - the highest non-retina resolution option is available.
4 - Select this highest non-retina display resolution.
5 - Kaseya VNC usage to the endpoint will work properly from there.

Kaseya VNC components w/ Apple retina display agent machines

$
0
0
Revision 4 posted to KKB Wiki by Dylan M. Lagi on 5/15/2013 7:55:58 PM

Kaseya VNC components w/ Apple retina display agent machines

Remotecontrol,VNC,retinadisplay

KB #: KB0001010

Question: I have Apple retina-based (HiDPI) hardware. Will the Kaseya VNC components in the Remote Control tab, QuickView, and KLC work properly with them?

Answer:

At the moment, this is not possible due to a limitation with the x11vnc server software used by Kaseya on the Mac endpoints. Kaseya Engineering is presently working out a permanent solution to this as such. This KB Article will be updated appropriately once that fix is made available.


In the meantime, this manual workaround can be done on the retina display-based machines:

1 - Ensure that the retina-based hardware has at least one user logged in.
2 - Run this command: sudo defaults write /Library/Preferences/com.apple.windowserver DisplayResolutionEnabled -bool YES
3 - Log off all users on the hardware and log back in - the highest non-retina resolutionresolutions option isare available.
4 - Select thisthe highest non-retina display resolution.
5 - Kaseya VNC usage to the endpoint will work properly from there.

Kaseya VNC components w/ Apple retina display agent machines

$
0
0
Revision 5 posted to KKB Wiki by Dylan M. Lagi on 5/15/2013 7:56:35 PM

Kaseya VNC components w/ Apple retina display agent machines

Remote control, VNC, retina display

KB #: KB0001010

Question: I have Apple retina-based (HiDPI) hardware. Will the Kaseya VNC components in the Remote Control tab, QuickView, and KLC work properly with them?

Answer:

At the moment, this is not possible due to a limitation with the x11vnc server software used by Kaseya on the Mac endpoints. Kaseya Engineering is presently working out a permanent solution to this as such. This KB Article will be updated appropriately once that fix is made available.


In the meantime, this manual workaround can be done on the retina display-based machines forusagewiththepresentsoftware:

1 - Ensure that the retina-based hardware has at least one user logged in.
2 - Run this command: sudo defaults write /Library/Preferences/com.apple.windowserver DisplayResolutionEnabled -bool YES
3 - Log off all users on the hardware and log back in - the non-retina resolutions option are available.
4 - Select the highest non-retina display resolution.
5 - Kaseya VNC usage to the endpoint will work properly from there.

Kaseya VNC components w/ Apple retina display agent machines

$
0
0
Revision 6 posted to KKB Wiki by Dylan M. Lagi on 5/15/2013 8:02:13 PM

Kaseya VNC components w/ Apple retina display agent machines

Remote control, VNC, retina display

KB #: KB0001010

Question: I have Apple retina-based (HiDPI) hardware. Will the Kaseya VNC components in the Remote Control tab, QuickView, and KLC work properly with them?

Answer:

At the moment, this is not possible due to a limitation with the x11vnc server software used by Kaseya on the Mac endpoints. Kaseya Engineering is presently working out a permanent solution to this as such. This KB Article will be updated appropriately once that fix is made available.


In the meantime, this manual workaround can be done on the retina display-based machines for usage with the present software:

1 - Ensure that the retina-based hardware has at least one user logged in.
2 - Run this command: sudo defaults write /Library/Preferences/com.apple.windowserver DisplayResolutionEnabled -bool YES
3 - Log off all users on the hardware and log back in - the non-retina resolutions option are available.
4 - Select the highest non-retinanon-HiDPI display resolution available.
5 - Kaseya VNC usage to the endpoint will work properly from there.

Kaseya VNC components w/ Apple retina display agent machines

$
0
0
Current Revision posted to KKB Wiki by Dylan M. Lagi on 5/15/2013 8:30:13 PM

Kaseya VNC components w/ Apple retina display agent machines

Remotecontrol,VNC,retinadisplay

KB #: KB0001010

Question: I have Apple retina-based (HiDPI) hardware. Will the Kaseya VNC components in the Remote Control tab, QuickView, and KLC work properly with them?

Answer:

At the moment, this is not possible due to a limitation with the x11vnc server software used by Kaseya on the Mac endpoints. Kaseya Engineering is presently working out a permanent solution to this as such. This KB Article will be updated appropriately once that fix is made available.


In the meantime, this manual workaround can be done on the retina display-based machines for usage with the present software:

1 - Ensure that the retina-based hardware has at least one user logged in.
2
2a - Run this command toenablenon-retina/HiDPIresolutionsavialable:

sudo defaults write /Library/Preferences/com.apple.windowserver DisplayResolutionEnabled -bool YES

2b-Ifrunningthatcommandisnotpossible/hasissues,downloadandusethisapptomakethenonHiDPI/retinaresolutionoptionsappear.
3 - Log off all users on the hardware and log back in - the non-retina resolutions option are available.
4 - Select the highest non-HiDPI display resolution available.
5 - Kaseya VNC usage to the endpoint will work properly from there.

Kaseya Discovery (KDIS)

Kaseya Discovery (KDIS)


Duplicate Domain GUID in Kaseya Discovery

$
0
0
Revision 2 posted to KKB Wiki by amado.hidalgo on 5/16/2013 10:10:46 AM

Duplicate Domain GUID in Kaseya Discovery

SBS, Windows Active Directory, Duplicate Domain, Probe Status error, Domain GUID reported by Netlogon is incorrect, Windows Active Directory issue must be fixed before this domain can be synced correctly

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 updating this registry entry to the correct domain GUID on all affected DCs in the domain. The correct domain GUIDs can be found in the error message in Discovery.

Please follow the steps (method 2) in the below link to fix this issue:
http://www.jigsawboys.com/2008/04/17/sbs-migration-fails-with-error-this-server-has-a-trust-relationship-with-domain_namelocal/
Please note that the registry entry must be entered in the correct format by swapping some of the bytes of the correct domain GUID and also that all the DCs and workstations on the domain must be restarted after the change.

 
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

Duplicate Domain GUID in Kaseya Discovery

$
0
0
Revision 3 posted to KKB Wiki by Tim Cruz on 5/16/2013 12:01:42 PM

Duplicate Domain GUID in Kaseya Discovery

SBS, Windows Active Directory, Duplicate Domain, Probe Status error, Domain GUID reported by Netlogon is incorrect, Windows Active Directory issue must be fixed before this domain can be synced correctly

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 updating this registry entry to the correct domain GUID on all affected DCs in the domain. The correct domain GUIDs can be found in the error message in Discovery.

Please follow the steps (method 2) in the below link to fix this issue:
http://www.jigsawboys.com/2008/04/17/sbs-migration-fails-with-error-this-server-has-a-trust-relationship-with-domain_namelocal/
http://support.microsoft.com/default.aspx?scid=kb;en-us;909639&sd=rss&spid=3208
Please note that the registry entry must be entered in the correct format by swapping some of the bytes of the correct domain GUID and also that all the DCs and workstations on the domain must be restarted after the change.

 
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

Duplicate Domain GUID in Kaseya Discovery

$
0
0
Revision 4 posted to KKB Wiki by Tim Cruz on 5/16/2013 12:02:21 PM

Duplicate Domain GUID in Kaseya Discovery

SBS,WindowsActiveDirectory,DuplicateDomain,ProbeStatuserror,DomainGUIDreportedbyNetlogonisincorrect,WindowsActiveDirectoryissuemustbefixedbeforethisdomaincanbesyncedcorrectly

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 updating this registry entry to the correct domain GUID on all affected DCs in the domain. The correct domain GUIDs can be found in the error message in Discovery.

Please followthesteps(method2)inreview the belowKBarticle link to fix this issue:
http://support.microsoft.com/default.aspx?scid=kb;en-us;909639&sd=rss&spid=3208
Please note that the registry entry must be entered in the correct format by swapping some of the bytes of the correct domain GUID and also that all the DCs and workstations on the domain must be restarted after the change.

 
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

What are the different roles in the Kaseya Customer Portal and how do I create and manage my Kaseya Portal users?

$
0
0
Current Revision posted to KKB Wiki by Robert.Vambeck on 5/17/2013 9:52:55 AM

KB#:  KKB001011

 

QUESTION

What are the different roles in the Kaseya Customer Portal and how do I create and manage my Kaseya Portal users?

 

ANSWER

In order to manage the Kaseya Portal Users for your Kaseya Portal account, you need to have the Manager or Administrator role.

You can create and manage your organisation's users in the Kaseya Customer Portal (go to Kaseya Portal>My Account>My Portal Users)

 

Below is an explanation of the three Roles that are available for you to assign to your users within the Kaseya Customer Portal:

 

User:

Access to: Inbox, Create new tickets & View own tickets, Resources (Documentation, Knowledge etc),  Direct access to Forums and Knowledge Base and Change Logon etc

 

Manager:

Same as User plus ‘My Portal Users’

Administrator:

Same as Manager plus ‘Credit Cards’, ‘Online Backup’, ‘Contract Summary’& ‘Account Aging’ Reports.

 

My Portal Users: Add, Edit, Delete, Enable, Disable and reset passwords for Users

Credit Cards: Add, Edit & Delete Credit Cards

Online Backup: Enable Cloud Storage for Kaseya Data Backup

Contract Summary: View Your Contract Summary

Account Aging: View Your Account Aging

 

 

Here is an image of the Kaseya Customer Portal while logged in with the Administrator Role:

 

APPLIES TO

This article refers to Kaseya On-Premise customers using the  URL 'https://portal.kaseya.net' to log into the Customer Portal.

 

This article does not apply to SaaS E-Commerce customers, please see: http://community.kaseya.com/kb/w/wiki/64.aspx

 

KLC unable to connect if DNS is unavailable on agent side

$
0
0
Revision 1 posted to KKB Wiki by Dominic Walsh on 5/21/2013 2:37:38 AM

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

Viewing all 118 articles
Browse latest View live