This relates specifically to Patch Management in ITSM, I do not have the ability to try the old patch management as it was already not available when I joined.
I do not want patches to auto install without first being reviewed by my team (WSUS is great for clients that I can have a WSUS server, but small clients it is just to much to have this). So I will not be scheduling profiles with a procedure to run patches at a certain time of the week or month. Instead I will be creating a procedure that can be manually executed at the time that I would like to install patches. So on the windows side I am setting the workstations to disable automatic updates. My question with this is how does Comodo Patch Management check the workstation for updates? And how often? Comodo still seems to see required updates even with windows auto updates disabled so it must check for updates on its own and not just look to auto updates to tell it what is needed.
Has anyone ran into any issues using WSUS and Comodo Patch Management? How about using a combination of WSUS for some clients and not using WSUS for some clients (smaller clients) with Comodo Patch Management for both?
I would like to be able to test patches on my internal systems prior to releasing to clients, it seems like this will be a bit cumbersome with Comodo Patch Management. If a new update comes out between the time I test internally and deploy to clients, the only way I am seeing to be able to not install these updates are to check patch management and hide the new updates before executing a procedure to install patches. How are others handling situations like this?
Last question is not specifically Comodo related. Does anyone use any kind of cloud type WSUS? Obviously not for saving on bandwidth, but more for controlling updates that are allowed to apply. Any recommendations on something like this? It would be great to be able to link some clients that do not have WSUS server into a cloud type environment to be able to help control updates alongside Comodo Patch Management.
Patch inventory collector collects the info about installed/missing patch(s) once per 24/hours. This is by design. So if customer installed patch(s) not through ITSM, the list of patches will be updated on ITSM not immediately but in ~24 hours time period. The information about installed/missing patch(s) isn’t stored on the device but on special server, so if customer refreshes the page on ITSM, he gets data from the server, not from endpoint. The new data will appear on the server after patch collector will collect new data, or after customer triggers some updates from portal.
Patch collector starts his work with delay 1 hour after PMservice is started. So if customer want to update the list of patches asap he has to restart COMODO services or just restart the endpoint, and after few hours (1 hour delay + collector work time) the list of patches for this endpoint will be updated on ITSM.
My understanding (and I might not be correct, it would be nice to have a white paper on this) is that WSUS does cause some conflicts with Comodo. Specifically the engineer I have in charge of patch management at one of my larger customers (400+ servers) said that the patch reporting from Comodo when the server was being managed by WSUS wasn’t correct (e.g. it wouldn’t show patches he knew were missing or had been installed). He had a call with Comodo and said that they indicated WSUS was the issue, he removed a swatch of servers from being managed by WSUS and only used Comodo and was happy. Because of the scheduling you can do with Comodo (which is a lot harder in WSUS) we went down the path of applying patches to non-critical first, critical last (so test, dev, qa, pre-prod, prod) and separated those with enough if a time span that we could simply kill the schedule if there was a discovered issue (would be nice if they had a PAUSE option). Hope this helps. I’m getting this a little second hand from my engineer since I wasn’t on the calls, but in tech support queries to Comodo I seemed to get the same answer.
@RayBTWIT I haven’t found any stand alone services which are similar to WSUS which run over the internet. MS released a tool in preview for their operations management suite for W10 patching using WUfB but I’ve not tried it.
Technically there is no reason you can’t just use WSUS. Only downsides are licensing (CALs etc) and the fact it’s WSUS. However it seems to be about the only way I’ve found to stage and deploy a W10 feature upgrades.
I want to first thank to everyone for bringing their experiences with WSUS and Comodo comparatively. Those kind of real life experiences are just priceless for us.
Good news is that we have using WSUS for Windows OS Patch Management already in our roadmap and expecting to deliver it before the second half of 2018. In the scope of our feature development, we are planning to make the admin select the server machine with WSUS configuration and make him/her decide the priority of patch detection and install among WSUS and Comodo. ITSM will expect the already configured WSUS machine and will not interfere with the WSUS configuration.
We are open to any kind of suggestions about this issueto leverage your real life needs.
Thanks again and best regards,
Emrah
Product Manager for IT&SM Patch Management, Monitoring and Procedures
@Raymond_Co Thanks for that information. That is very helpful to know the timings on things.
@DaveZChi Thanks for the info on this. I will keep an eye out to see if I notice anything as I will be doing some locations with WSUS server. I may look to phase it out as the capabilities of Comodo patch management are improved. Even having the ability to say run all patches older then so many days would be very helpful so I don’t have to manually go and install one by one to exclude any newer ones.
@Joners Thanks for the input. I looked into the WUFB and at first I thought it had some potential thinking it would be something similar to WSUS but newer. But unless I just didn’t understand it correctly, it did not seem like it was a separate server or anything, it looked to me like it was more of just configuration you can set in windows 10 to do updates with a little more control then normal updates. In my opinion Comodo ITSM Patch Management already has that beat. I will attempt some with WSUS, I do not have a ton of experience with it, but I should be able to manage. When I read about it online people either say why use anything different, it is free and works, or people just hate it :). Hopefully it will be good for me.
@emrahsamdan Would the intent be that we would still be able to use Comodo ITSM Patch Management alongside WSUS with this setup. Or are you saying if a WSUS server is specified then ITSM would just leave it alone?
Is there a script or anything available to force an updates check, whether it be the Comodo client doing the check or windows update running a check. I found the command wuauclt.exe /detectnow, but I do not think this works for me as I have auto update disabled.
People use WSUS because it works but it’s also crap.
If you use it do yourself a favour and make sure to read the documentation and follow the best practices. Biggest headaches are the integrated DB which doesn’t perform maintenance properly and the fact it can just decided it doesn’t want to work one day. Saying that once you have spun up a WSUS and applied all the GPs it’s a doddle to recreate.
WUfB is basically Windows Update but they let you defer updates or delay them. It’s a bit crap.