Kaseya Community

.NET Framework 4 on Kaseya webserver = fail ?

  • Hi,

    We're eager to know if someone else installed .NET Framework 4 on their Kaseya webserver.

    We did this after being told, by kaseya personel, to install all available patches for SQL and OS


    After doing this we couldn't log into kaseya anymore, and only got an error message on the ASP .NET State Service.


    I'd also appriciate if someone could tell me the what the 'path to executable'  on the ASP .NET State Service should be, prior to installation .NET Framework 4.


    Thanks in advance.

    [edited by: Micke at 1:50 AM (GMT -8) on 2-10-2011] Spelling
  • Hi Micke

    I specifically wrote down on some training notes in BIG BOLD lettering not to install .NET 4.0 - I'm not a huge note taker so it must have been reiterated.  I also noted on the 6.1 install notes it mentions installing all patches but I omitted the 4.0 and the link below tells me that the server is still on 3.5



  • I wish I had your notes last night...

  • Looking at the release documentation it is a little unclear.  Install every patch to me means as it says (and as you've done) and install everything however they do stipulate 3.5 in the System Requirements - help.kaseya.com/.../K2-System-Requirements61.htm

    I've seen our SQLguys change something in IIS when older versions of .NET were required but can't remember how it was done. Any takers?

  • Hi Micke,

    If you are still experiencing problems with .NET 4 installed, you can tell the IIS server to use 3.5 using IIS Manager. Depending on which version of Windows you are running, try opening IIS Manager. Then select the server in the Connections panel on the left. This will display actions that you can perform on the server on the right of the window.  Select the option "Change .NET Framework Version" and select "v2.0.xxxxxx" from the popup window.  Click OK, and then restart IIS.  That should get you back into the Kaseya system without any problems.  Hope that helps!


  • Has anyone managed to get .NET 4.0 running successfully on their KServer?

    If so, was it a big process?

    I'd like to get it on there for another web service, but obviously don't want to break Kaseya!

  • I have installed .NET 4.0 on my servers ... After a restart the Kaseya Webinterface works without problems ...

    My system is running on two Windows 2008 R2 Servers (1 for Webinterface; 1 for Database)

  • I got same error ..uninstalled the .Net 4.0 and all went well

  • Does anyone know if .NET4 is now ok for the kserver?

  • My experience with .NET 4.0 on the KServer has been as follows:

    Don't do it.

    The saga began back in September of 2011, when we were trying out N-Able's management platform as a faster way to do client onboarding.   Unbeknownst to us, their "lightweight" Agent package also installs .NET 4.0 as a prerequisite, and N-Able's crack Sales team (sarcasm) decided that it would be best to push their Agent to all machines on our production network, citing the fact that our test/dev environment wouldn't show "real life" usage.  /Sigh

    Immediately upon installation of .NET 4.0, the ASP.NET State Service stopped, which took down Kaseya.  I restarted the ASP.NET State Service, and in researching why it went down, discovered the Event Logs pointing to the installation of .NET 4.0 as the culprit.  Needless to say, we are no longer talking with N-Able (for many reasons, this being the least of them).

    System stable... or so I thought... so I ignored .NET 4.0's presence and moved on.

    Twice within the next month, and at least 10-12 times between then and two weeks ago, my KServer would become unresponsive in the following pattern:

    1) Remote Control would cease operation, and anyone attempting to RC to a machine received the following error (note that one could not also telnet to the server on port 5721, the default port):


    2) The "Private Queues" in the MSMQ (Microsoft Message Queueing) management console (Server Manager > Features > Message Queueing) would start backing up

    3) After about an hour and a half or so, we would receive the dreaded "KServer Stopped" error, and would have to reboot the server

    After a very long-running ticket with Kaseya Support (so long, in fact, that the oldest notes are no longer even visible in their ticketing system (!)) and sending log after log after a number of crashes, and stumping Specialist after Specialist, we all arrived at the conclusion that the server needed rebuilt.

    Many hours later (including a three hour migration process (not terrible, for the record, but also not the most accurately documented process either)), we had our production KServer running on identical hardware.

    Everything was fine... until yesterday, when I needed to install .NET 4.0 as a prerequisite for Bright Gauge's Agent to send ksubscribers data to their reporting engine.  Keep in mind that I hadn't yet put 2 + 2 together (i.e. correlated .NET 4.0 to anything but an ASP.NET State Service cycling)...

    2:00 PM - Installed .NET 4.0 on the KServer and quickly restarted the ASP.NET State Service... all looked hunky-dory
    9:30 PM - KServer (still running) stopped listening on port 5721, Sev1 opened with Kaseya Support
    11:30 PM - Working with Kaseya Support... representative and I had a mutual epiphany regarding the timing of .NET 4.0 installation when the problems started on the old server and now, with the new server, the problems recurring only a few hours later
    11:45 PM - Removed .NET 4.0 and bounced the server, all is back to normal

    Now, with the caveat of Your Mileage May Vary (YMMV), I'd strongly suggest that you not install .NET 4.0 on the KServer.  I'm 99.5% certain that this was the cause of the issues outlined above.

    If I hear a definitive cause from the Developers, I'll pass it on here, but for now, Don't do it!  Smile  $0.02

  • we have .net 4 on our SQL box but not the VSA and everything is just fine has been there for ages and ages

    How is bright gauge ?

  • Sorry to hear you've had such problems Brian. We've got .NET 4.0 on our KServer (where Kaseya and SQL are installed) and it has been on there for months without issue.

    We already had .NET 4.0 on there when I installed the BrightGauge agent, therefore it was not a problem for us. However, I was aware of the issues that some people were having with .NET 4.0 on their KServer, so I mentioned it to Jaime at BrightGauge - he said that it was not essential for the BrightGauge agent to be on the KServer, therefore you can install it elsewhere where it is safe to install .NET 4.0.

    Hope this helps.

  • @Michael: BrightGauge is great.  We're a Kaseya / AutoTask shop, so having the integration and the ability to run reports on both systems simultaneously (i.e. pull data from both sources and put it in a damn handsome single report) is great for us.  I'm still digging into it, but I like what I see so far (and the pricing model isn't bad either).  Smile

    @Simon: Thanks for the follow-up regarding your experience with .NET 4.0, and relaying the fact that you've heard of other folks having trouble (even though your server has .NET 4.0 and works fine... with screenshot evidence, no less Yes).  Absolutely nothing against BrightGauge here (many modern apps require the .NET 4.0 framework)... they just happened to be the catalyst for me installing .NET on the "new" KServer, which then correlated for me the fact that the same issues I'd outlined happened on the "old" server shortly installing .NET 4.0 as well.  I ended up installing the BrightGauge Agent elsewhere and it works great... the KServer was just "more convenient" in that I'd only have to open port 2666 for Bright Gauge's IP range to an already-existing NAT rule, but no biggie.

    Brian @ BrightGauge is great to work with, and I've found their support to be very responsive... and they do have a 30-day refund policy, so I think it's definitely worth a try for anyone who is looking for better reporting.  They'll be at Kaseya Connect this year as well.

    I'm still working with Kaseya Support to further isolate/duplicate/eliminate this issue... at this point, it would appear that, when the problem occurs, everything appears to stay running process-wise, and that agents that haven't lost their port connection to my KServer continue to report in and process normally... only that the new connections to port 5721 never connect, Remote Control breaks, and the KServer eventually stops.

    What I'd found yesterday seems to be a similar issue with a web-based application ceasing to accept inbound connections after a random interval and the installation of .NET 4.0: http://forums.iis.net/t/1167668.aspx 

    At any rate, I'll provide updates here if/when a correlation is "officially" acknowledged/fixed by Kaseya.

  • I am also interested in brightguage, but nothing on their website really inpired me too much in terms of Kaseya reports.

    What they need to spin up is a demo environment that I can login to and start playing with the reports without investing my time/money in trying out their software by screwing with my production environment (in which I would have blown it all to hell with that .net issue for sure)

  • @Mark.Hodges: So far, their reports are pretty good (and better than Kaseya's built-in reports).  I'll be interested to see what gets implemented from the BrightGauge User Voice forum (http://brightgauge.uservoice.com/forums/83871-feedback-forum) before Kaseya unveils their new 6.3 reporting engine at Kaseya Connect (or earlier?).  At the moment though, BrightGauge's ability to author a report that combines data from AutoTask and Kaseya through the same interface is a no-brainer $129/month spend for us.

    Brian Dosal @ BrightGauge would be more than happy to run a demo for you... I think the issue there is that one can't really open up a customer's production systems to public scrutiny (i.e. the reason I won't be publishing a sample report for one of our customers here, as much as I'd like to).  When he demoed BrightGauge for me, he was running live reports on his MSP clients, but short of setting up a virtual environment or "faking" the data, I'm not sure of a good way they could demo it without exposing customer data.

    In regards to blowing up the KServer... the saga continues.  .NET 4.0 has been uninstalled, but the issues persist.  Waiting on Microsoft to call me back so that I can apply the hotfix mentioned in the IIS forums earlier on in this thread.  Still not sure if .NET 4.0 caused irreperable harm (i.e. I'd now have to rebuild the KServer... again...) or if something else is at play here.  Updates will follow... Huh?