We have customers that are looking into purchasing new servers with Server 2016 and would like to know when Kaseya will be officially support it?
They've release 220.127.116.11 - help.kaseya.com/.../index.asp
We are currently slotted to test both the agent and server deployment side of Windows Server 2016 for the VSA in v9.4 Beta3 due out next month. Once that is completed we will look at the effort to backport the agent code to support v9.3.
Hi Dana Epp
Just to give more info on this, we are also seeing 2016 starting to roll out. Agent installs fine but Agent procedure steps do not run because in the Perform Step on (All Windows Operating Systems) the new OS is not included in the All Windows Operating Systems group. Here's the exact error in the agent logs:
Informational: The IF True check was ignored because the client machine is running OS type 0xffffff9d which does not meet the All Operating Systems OS type criteria.
Is there a work around or a way to add the hex value into the All Windows Operating Systems so that our agent procedures can run on the new OS? Just thinking it's going to become even more time sensitive for folks to be able to run their procedures on the new OS before long.
What if you edited (or created new) procedures in question and set the Perform On to "All Operating Systems", then use a view and policy management to attach the procedure to 2016 servers?
I haven't tested this specifically, but you should be able to create a view using the Advanced Filters and define the OS version:
...or even the standard filters using Application Contains with the .exe version string of a server2016-specific executable.
Next, create a policy using the created view and assign the Agent Procedure to the policy. Assign the policy to the appropriate groups/orgs. The view should cause the procedure to assign only to the 2016 devices, even though the policy would be assigned to an entire group/org.
This is admittedly a little messy, but might get you over the immediate hump. I do recommend testing before applying to agents large-scale.
Unfortunately a view filter will have a tough time with "> 2012" which is what 2016 boxes show up as.
I guess we'll be waiting until next year to fully support 2016, since I wager that's when a usable version of 9.4 will land. (We never did the 9.3 upgrade.)
How about using the getRegistryValue step at the beginning of an AP to list the OSs (with the Perform On option set to "All Operating Systems") to check HKLM\Software\Windows NT\Current Version\Current Version:
msdn.microsoft.com/.../ms724832.aspx describes the values associated with each OS, so if you wanted all OSs, you could enter them all into this step. Perhaps even create a procedure that checks this and if the result is True, then use the scheduleProcedure step to call your existing procedure. That *might* make it a bit more flexible.
Great ideas Kaseya Community but it looks like procedure fails even when it's set to apply to all OSs.
Here's some new screenshots-
I don't have a 2016 server readily available to test, but if I have can think of something that might allow you to bypass that, I'll share.
Perfect thanks, looks like the only way around would be to edit that group to add the additional value if sits somewhere we can get at.
+1 for a workaround if available. Agent installs just fine, just the Agent Procedure engine isn't aware that Server 2016 is an OS...
Just ran up my first 2016 server. I'm having the same problem.
To sum up, Kaseya is not aware that 2016 is part of All Operating Systems.
I've created a View, that was easy. Problem is that any agent procedure that uses "All Operating Systems" as a filter in a step (which is about 100% of ours) does not run.
Kaseya, I have a new 2016 machine with an agent on it if you want to test. We can break it as much as you want....
TBH, I'm a bit surprised that you guys have not got this tested and working as yet. I know you're busy, but Microsoft didn't do a drive-by server OS release. It's been coming for a loong time.
Version 10.X of Server 2016 has been in Technical Preview since May 4th, 2015. Yes, it was RTMed a little over a month ago, and officially GA on October 12th (15 days ago), but the major version number hasn't changed from 10 since May 4th: en.wikipedia.org/.../Windows_Server_2016
If it's simply a matter of having the Server/Agent recognize the new version number in the Agent Procedure engine, it would be nice if this were expedited. I've got a few boxes out in the wild now that are Glorified Remote Control (TM) until this Agent Procedure issue is fixed (i.e. no monitoring that triggers agent procedures, no patching, no scripting... just Kaseya Remote Control and Kaseya Live Connect are working).
We hear ya. The issue is that there is some old legacy code compiled in the agent that isn't smart enough to detect all but specific operating systems. This is then compounded by code on the back end in the VSA that matches up to it. We are changing the design so that it can be more flexible and deal with any new windows versioning going forward, instead of always be compiling in support as new operating systems are released. Unfortunately it affects a whole bunch of areas, and we have to be careful not to break things with all the changes.
I could authorize them just to add the version code for Server 2016 and be done with it. It would be quick, and then when Windows 11 comes out, we would be stuck again. So be patient. We are updating the architecture to permanently handle this going forward. It takes more time, but will be done right.
Thanks for the response Dana Epp, maybe co processing both would be good, I understand the need for re architecture and coming into a mess but at the same time 2016 is rolling out regardless if we want it to or if we want to put a hold on it for awhile. I now have 6 2016 servers that have been deployed that like Brian Dagan mentioned we are not able to properly monitor and remediate. If you guys are targeting 9.4 as the time it will be supported we are at least looking at Jan before 9.4 is out and has had at least a few patch cycles.
I also have 5 2016 servers now in production and we are unable to manage them effectively due to this limitation. It would be nice to have the version code added now for Server 2016 so we can manage these servers ASAP as you say its quick. I still think the architecture to permanently fix this makes sense, but to me (and im sure others here), we need to be able to run procedures on these servers yesterday.
We too now have several 2016 Datacenter servers in production - echoing all that has been said above, we are also not able to install KAV on these boxes. They don't even show up in the view to try and install on them. If you can please also ensure that KAV will be compatible when they do come into support, that would be great.