Quantcast
Channel: Forums - Recent Threads
Viewing all 30534 articles
Browse latest View live

RE: 9.5.0.20 Patch Release - 03 April 2019

$
0
0

I still haven't updated from 9.4 and each of these posts is why.  As the upgrade installs the latest patch, I need a patch that actually produces a stable system!  I've scheduled a cancelled a weekend 3 times so far


Please be advised: MSPAssist.net has NO relationship to MSPAssist.com

$
0
0

It may be a case of imitation being the sincerest form if flattery, but we are completely separate entities and MSP Assist does not support or in anyway endorse their services.

Steve Wilson

steve@mspassist.com

RE: 9.5.0.20 Patch Release - 03 April 2019

$
0
0

I updated our new production server that was impacted by a bug where API-based writes to custom fields were writing incorrect Tenant (partition) IDs. This affected the ability to see custom fields in QuickView or drive views that reference the custom fields. One tenant worked fine but the other tenant failed.

After updating, the problem did not go away - but - after removing the policies, views, and custom fields and putting everything back, it all works, so it looks like that problem is solved. I'm not seeing any other issues, but we've only migrated around 100 of 3100 agents over so far.

Glenn

RE: Terrible Live Connect performance after deployment of 9.5.0.19

$
0
0

The issue of sometimes losing connection to a live connect (where it hangs and has to be restarted) only happens for me at one client who has particularly restrictive firewall rules, so it might be related to that somehow, but damned if I know, and like most people I don't have time or patience to work with kaseya support on it.  It doesn't happen all the time anyway so it's not too bad.  Otherwise the only problem I sometimes experience is never getting a connection when clicking the orb, and having to launch a liveconnect then remote control first (which almost always seems to work).  This is something I wish they'd fix.

Terrible Live Connect performance after deployment of 9.5.0.19

$
0
0

Deployed 9.5.0.19 last night and updated Live Connect on the workstations of the tech's and the agents to the latest version, however Live Connect responsiveness and performance is worse than ever. Anyone else experiencing this?

Clicking the "orb" for a remote session without launching live connect first, there is a ~30 second delay before the remote control window opens and is ALWAYS fails to connect.

Opening Live Connect via the Quick Launch (hovering the orb) will open and connect and then a remote session from that will work but frequently hangs and has to be relaunched

Example Log from a connection attempt made by direct clicking the "orb" of a machine

[I 2019-03-27T11-15-13.549Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.default] ---------------------------
[I 2019-03-27T11-15-13.549Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.default] Kaseya Live Connect Started. Version: "9.5.6991.10437"
[I 2019-03-27T11-15-13.549Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.default] ---------------------------
[C 2019-03-27T11-15-57.279Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.default] Timed out waiting for Admin Endpoint to connect. Exiting.
[I 2019-03-27T11-15-57.290Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.default] Initializing Layout for RECONNECT
[W 2019-03-27T11-15-57.297Z Pacific Daylight Time 6688 0x2d32dd11520] [default] libpng warning: iCCP: known incorrect sRGB profile
[I 2019-03-27T11-15-57.367Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Checking launch payload"
[I 2019-03-27T11-15-57.617Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Checking launch payload"
[I 2019-03-27T11-15-57.617Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Parsing launch payload"
[I 2019-03-27T11-15-57.617Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Acknowledge launch"
[I 2019-03-27T11-15-57.620Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Retrieving version information"
[I 2019-03-27T11-15-58.018Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Checking if application needs upgrade (Version installed: 9.5.6991.10437) (Version from server: 9.5.6991.10437) ) (Minimum version required: 9.4.6198.32701)"
[I 2019-03-27T11-15-58.018Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Application version verified"
[I 2019-03-27T11-15-58.018Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Authenticate admin"
[I 2019-03-27T11-15-58.021Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Acknowledged launch"
[I 2019-03-27T11-16-02.865Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Fetch admin authentication details"
[I 2019-03-27T11-16-03.372Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Retrieve agent information"
[I 2019-03-27T11-16-11.823Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Retrieve agent RC policy info"
[I 2019-03-27T11-16-12.270Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Retrieve agent authentication"
[I 2019-03-27T11-16-12.642Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Establishing endpoint connection"
[I 2019-03-27T11-16-12.643Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Connecting to endpoint..."
[I 2019-03-27T11-16-12.643Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.api] Connecting to Endpoint "561421668582178"
[C 2019-03-27T11-16-12.643Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.default] Admin control is not valid!
[I 2019-03-27T11-16-42.642Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "Timed out connecting to the endpoint"
[C 2019-03-27T11-16-42.647Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.js] "EndpointBroker closed!"
[I 2019-03-27T11-16-44.961Z Pacific Daylight Time 6688 0x2d32dd11520] [lc.default] Shutdown Complete

RE: Microsoft Teams installation for Mac

$
0
0

Hello Rohit,

Did you ever get a solution for this? I'm attempting the same but having no luck in the same place...the "cp" to the Applications folder.

Thanks,

Ed

Microsoft Teams installation for Mac

$
0
0

Hello All,

i have been trying to get the Agent Procedure working for installing Microsoft Teams in Mac OS but i have had no luck. I was successfully able to get this done for Windows OS. Below is the Scenario

1. Copy the Teams.dmg file to the local computer for Kaseya server [SUCCESS]

2. Mount the copied .dmg file as a new volume on Mac [SUCCESS]

3. Copy the content of the mounted volume to the Applications folder [This is where the procedure gets stuck. there are no errors though].

not sure what am i doing wrong.

Any suggestions is highly appreciated.

RE: Microsoft Teams installation for Mac

$
0
0

I had a similar issue with another .app install. I found that using several shellCommand lines to manually mount, copy, unmount, and delete worked for me. I was failing using the cp command though, so I used rsync.

rsync -a /Volumes/PCClient/. /Applications

This copies the entire contents of the mounted volume to the /Applications folder


RE: Microsoft Teams installation for Mac

$
0
0

I should have been more specific. 'PCClient' is just the name of my DMG that i've mounted. It should be changed to the name of your volume..

RE: Kaseya\Connectwise Integration broke from 9.5.0.19 installer

$
0
0

Hi Adam,

We have been experiencing the issue similar to @GDRBrian for 2 months now. We reinstalled the ManagedITSync multiple times, re-saved the key.json, adjusted the web.config to point to the correct location (there is no x86) and even without the IP restrictions, the Kaseya Server will not load the webpage and instead says

"Oops. Something went wrong.

The issue may be temporary. Please go back and try again. If the problem persists, please get in touch with our friendly support team. We're here to help."

with the URL being

"http://localhost:18081/Errors/error.html?aspxerrorpath=/KaseyaCwWebservice/ManagedIT.asmx"

I believe this is because the Kaseya Firewall / SSL Cert is re-written to a different port and is not on 443. This is hte same error and URL response that we get on either the Kaseya Server direct, the ConnectWise Server, or any other device on our network.

I've had a ticket open with ConnectWise for 2 months and they are no closer it seems to solving it than day 1 when it was submitted.

We're on .19 and not have not yet updated to .20. During the install of .18 / .19 (We had upgraded to /18, had the issue with < 2003 agents, then upgraded to .19 when available) we had never had the pop-up to disable Insecure Applications.

Any help is greatly appreciated here as a big part of our day to day is installing new agents and pulling configs / asset Tags into ConnectWise that we manage for Audits and thats been broken since early February.

RE: 9.5.0.20 Patch Release - 03 April 2019

$
0
0

just got news in that there is an update address our freezing issue in the next patch or two

RE: Kaseya\Connectwise Integration broke from 9.5.0.19 installer

$
0
0

What happens if you just go straight to http://localhost/KaseyaCwWebservice/ManagedIT.asmx

From the Desktop of Kaseya server itself.

RE: Kaseya\Connectwise Integration broke from 9.5.0.19 installer

$
0
0

I should point out that I get the *exact* same error if I try to go browse to http://localhost:18081/KaseyaCWWebService/ManagedIT.asmx

However going to http://localhost/KaseyaCWWebService/ManagedIT.asmx  Instead simply gives me "Bad Request" in the browser.

Which honestly is to be expected.  You can no longer test it in the browser.  The addition of that json public Key prevents you being able to test it in the browser.  You can't even really test it with the "test" button in Connectwise Manage.

The only real way to test it is to to run the integration from the Connectwise Manage server by going to the Management Setup table and clicking the "Sync Now" button, and then look at the log file that it generates, after it's done, (available on that same page in Manage).

In mine that's working for example it shows the following (santized) information as the top few lines of the file which indicate pretty clearly that it's working.  If it's *not* working there should be some kind of error message here, that should be helpful at least to Connectwise support in figuring out what's going on.

03:00:03: ManagedItSync - Company Name: <myCompanyHere>

03:00:04: ManagedItSync - Attempting to determine version of Kaseya installed at: http://<myvsaHost>/KaseyaCWWebService/ManagedIT.asmx

03:00:04: ManagedItSync -

-----------------------------------------------------------

Managed IT Integration

Managed IT Setup: Kaseya/K2

WS Location: http://<myvsaHost>/KaseyaCWWebService/ManagedIT.asmx

Login Location: https://<myPublicVSAHost>/access/logon.asp

-----------------------------------------------------------

03:00:10: ManagedItSync - The following machines are new to Kaseya.  Configurations for them have been created in ConnectWise:

03:00:10: ManagedItSync - 145031447232342 / <machinename1>

03:00:10: ManagedItSync - 431639507234214 / <machinename2>

03:00:10: ManagedItSync - 965800603923478 / <machinename3

03:01:00: ManagedItSync - The ConnectWise configurations for the following machines have been updated:

03:01:00: ManagedItSync - 101157890623413 / <yetanothermachinename>

Kaseya\Connectwise Integration broke from 9.5.0.19 installer

$
0
0

In light of the previous news releases about the vulnerability to kaseya server from the Connectwise Managed Sync app, we have been using the newer re-released update and also IP lock down to only the connectwise server and the site was not public facing (we ran all the test modules and showed as not vulnerable).

During the pre-req check form 9.5.0.19 KInstall, it ran a "Disable Insecure Connectwise Integrations; This fix-it disables insecure integrations with the VSA" (which it stated was installed, and then fixed it). It is now completely broken and wont sync.

We have always had kaseya sync to connectwise, and we also use IT Glue which syncs from\to Connectwise and from Kaseya directly. So new agent in Kaseya->New Config in connectwise->new config in IT Glue

IT Glue will pull the kaseya agents into it, but wont sync them back to Connectwise unless each new config is opened and re-saved (very unproductive)

Is anyone else using any other type of synchronization to get kaseya machines into connectwise

RE: Is Software Management Dead?

$
0
0

I am new to VSA and initially used SM but ran into problems with some updates not being applied.

Was advised to move back to Patch Management whilst maintaiing SM for 3rd Party patching.

Also told that there a number of internal tickets with engineering so at some point this will get addressed.


Is Software Management Dead?

$
0
0

I do not see to much activity in the forums on this..  We purchased it and have not used it due to its functionality and lack of 3rd Party apps compared to the old tool.. 

Where can we get more info on added software to the catalog and is Kaseya actually going to fix the current issues?

RE: Alternative Multi-Factor Authentication for VSA access

$
0
0

I am using AuthAnvil to secure access to VSA for Admins and am pretty much ignoring all the other options that come with it.

Shame there does not appear to be any integration options with the likes of MS Authenticator.

or MS Azure.

Alternative Multi-Factor Authentication for VSA access

$
0
0

Has anybody had any luck using an alternative vendor (such as the Azure MFA) to gain access to the Kaseya VSA?

My current organisation relies on the MFA token elsewhere and we'd like to use it for the VSA but it seems that it doesn't want to play ball.

I've used AuthAnvil previously and it certainly does what it is supposed to but the new pricing structure is out of reach for us as we only need MFA for a half dozen or so engineers. We don't need, nor do we want to pay for access to, the full-blown add-in interface with windows client authentication for logging onto the OS etc.

Cheers.

Phil.

Agent GUID Sequential Numbers

$
0
0

Hello All,

I have come across a client where they are requesting for the sequential numbering of the Agent GUID with 3 Characters in the starting. Could some one please help me with this.

The Kaseya is 9.5.0.20 and on on-premise server.

Thanks & Regards,

Vinay Kumar

RE: Alternative Multi-Factor Authentication for VSA access

$
0
0

The obvious situation here is all of the MSPs using Kaseya are sitting ducks until one of us gets compromised much like the scenario with Teamviewer* a few years back when they refused to add an extra layer of security for their logins (of which the majority use is on the MSP side) until it was too late. Kaseya should really consider the negligence on their part of not making the proper investments in securing their customers' logins. They would be wise to look to their peers in the industry, notably Teamviewer and Apple iCloud**, and not wait for the next big incident.

*arstechnica.com/.../teamviewer-users-are-being-hacked-in-bulk-and-we-still-dont-know-how

**nakedsecurity.sophos.com/.../celebgate-3-0-miley-cyrus-among-victims-of-photo-thieves

Viewing all 30534 articles
Browse latest View live


Latest Images