If a WSUS server is configured in a domain with all machines updating from it, do they download the patches from the WSUS server if Kaseya is used to install a patch or does Kaseya force the machine to go to the source selected in Kaseya? What if the source cannot be reached (eg. Microsoft websites not allowed through a firewall, yet the machine can access the configured WSUS server)?
I found some information here, but not an answer: http://community.kaseya.com/kb/w/wiki/troubleshooting-failed-patch-installs-and-failed-patch-scans-and-incorrect-data-on-patch-status-page.aspx
It's very simple. No, Kaseya cannot use a WSUS server as the patch file source. Period.
Kaseya won't block or prevent any other patch service from running. Kaseya will do whatever patch job you've configured. Another patching service like WSUS will do whatever job you have configured it to do. They're independent of each other.
The exception would be if the other service requires that the Windows Update service and/or BITS service be in a different state than what Kaseya requires. Kaseya relies on both of these services to be running in order to leverage the Microsoft Windows Update Agent .api. If these services are not running, Kaseya will may not be able to complete patch scans and/or installations.
The drawback to using multiple services for patch installations is that you run the risk of installing patches via one service that are denied in the other service. Kaseya will report on any patches that are installed (as discovered via patch scan), but we can only identify the method of installation for patches installed by Kaseya OR installed by the Windows Update Agent.
Finally, you might find conflicts if the Windows Automatic Update state is not configured to be the same for both services. For example, if you have Patch > Windows Auto Update set to disabled within Kaseya but this is enabled via another service, then you may find that the setting gets changed each time one patch service does its work. If you have configured Windows Auto Update to be disabled in Kaseya, Kaseya will re-disable this every time a patch scan runs if the scan finds that the state has been changed. This could lead to some confusion for admins as the setting would toggle as each patch solution did its respective jobs.
To clarify, Windows Update service is not the same as Windows Auto Update/Automatic Updates. These two functions are explained here: community.kaseya.com/.../948.aspx
That does not answer my questions. I want to know where a machine actually downloads the patch from. Does Kaseya have the machine go directly to Microsoft's website to download even if you have a GPO set to point machines to a WSUS server? What if the machine can't get to the Microsoft websites but can get to the WSUS server?
Go to: Patch management\Configure\File Source.
AFAIK WSUS will have a file share available for computers to download the updateswhen using WSUS.
If you use WSUS to download all patches and have Kaseya appove or deny them, just have the computers point to the UNC path where WSUS stores its update files.
I think that should do the trick.....
I haven't looked at the WSUS directory where patches are stored, but does it pretty much store patches in the same method as Kaseya? If so, that might just do the trick.
The reason I ask is because some environments have servers which will not be going out to the Internet at all, and some environments we only manage servers for...so they also have a WSUS server with GPO's pointing machines to WSUS.
If WSUS can centrally download patches, there's no reason to have Kaseya use a different file source if they can share the same directory.
My concern would be that WSUS or Kaseya interfering with each other somehow...
Check the WSUS configuration and filepaths, there should be a WSUS directory on the root directory of one of your partitions, I believe that the msi/msp files for updates are stored there.
For example, if you've installed the WSUS DB on the D drive, check D:\WSUS, you'll see the following:
updateServicesDBFiles contains the database
WsusContent contains a lot of subfolders with all the update files.....
You could share that directory with certain permissions.
Kaseya downloads patches based on the File Source configuration for each individual endpoint:
If the file source is configured as Download from Internet, patches that are installed through Automatic Update function within Kaseya will be intalled via the Windows Update Agent on the endpoint. This is the same as when an end user launches Control Panel > Automatic Update (or Windows Update) and selects patches for installation. A distributable file is not downloaded in this case. However, if using the Patch Update or Machine Update function, Kaseya will download the distributable patch from the URL defined in Patch Management > Patch Location, store that file in the defined working directory on the endpoint, and then execute that patch using command line.
If the file source is configured as a LAN Share via Internet, a request is sent from the endpoint to the machine that hosts the LAN share. If the exact patch does not already exist on the share, the LAN share downloads the distributable file from the URL as defined in Patch Location. The LAN share then delivers that patch to the endpoint's working directory and the patch is executed via command line on the endpoint.
If the file source is configured as LAN Share via System Server, a request is sent from the endpoint to the machine that hosts the LAN share. If the exact patch does not already exist at that location, a request is sent to the KServer. If the KServer already holds that patch, it is distributed to the endpoint via the LAN share. If the KServer does not hold that patch, the KServer downloads the patch from the URL defined in Patch Location then distributes that patch to the endpoint via the LAN share.
If the file source is configured as Via System Server, the request is sent to the KServer to distribute the patch to the endpoint directly. If the KServer does not hold that patch, it will download the file from the URL defined in Patch Location and then distribute that to the endpoint.
You can define any shared folder on any endpoint to be a patch repository and use that share to distribute files to endpoints in the environment. As long as the shared location is available via a standard UNC call and the defined Agent > Set Credential has access to that location, the share can be used to distribute patch files.
Note: Any patches that are flagged as "Internet based install only" can only be installed via the Windows Update Agent. In these cases, there are no available distributable patches or insufficient documentation exists to determine which specific product(s) are the target of the patch. These patches install via the same method that Automatic Update uses when the file source is configured as "Download from Internet"
The details of the patch delivery process were discussed in the Patch TechJam this spring. You may find additional helpful information within that recording, available here: community.kaseya.com/.../73345.aspx
@Jeffro - I would be almost certain that the file structure in WSUS would be different than that used for Kaseya. I think the best option in your scenario where the machines and even the file source do not have direct access to the internet, would be to have the files distributed from the Kaseya server, most likely via a LAN share.
This does mean that if you continue to use WSUS you will be downloading patches twice but it may be that you could shut WSUS down, unless you are only using Kaseya to patch some of the machines at that site and want to continue using WSUS for others.
So if I select Download from Internet as the source, shouldn't the patches install using the WSUS server if it is configured as the source for Windows Update in the registry/Group Policy or does Kaseya simply start trying to download directly from Microsoft?
Seems silly not to allow downloading from a WSUS server.
On the contrary, I think it would be silly to download from WSUS. That is one more thing that can go wrong in an already complex process.
Jeffro, "download from Internet" means exactly what it says. It does *not* download from a WSUS server. ever. The downloads are sourced from whatever you have configured in the 'file source' screen.
Let us be very clear - a WSUS server is not supported or utilized or manged in any way when doing patch management through Kaseya. Having a WSUS server won't help. Kaseya Patch Management is designed to replace WSUS, not work with it. Kaseya patch managmeent works for *any* machine, including stand alone home computers, roaming laptops off the LAN (etc.); if K depended on first rolling out WSUS, patch managmeent wouldn't be able to support nearly as many types of machines or configuration scenarios.
Also, try to think about it logically, why on earth would you want to run not one, but two different patching systems at the same time???
Having said that, I can see where you're coming from; however Kaseya has never been designed to be "a third party replacement for the microsoft MMC-based suite of managmeent tools", which seems to be what you're implying.
Some reasons it would be nice to have Kaseya function with WSUS:
1. Some clients already have WSUS.
2. Some of our managed clients are not fully managed. For these clients, workstations still rely on WSUS.
3. Some machines can't reach the Internet. We can create a file source location on another local server, but again will store files twice if there is already a WSUS server.
4. If a client ever cancels their service they are not going to be updating from Kaseya anymore.
5. WSUS allows machines to install all patches, correct? Even patches which Kaseya cannot such as Internet Only patches?
Kaseya CAN install patches that are flagged as "Internet-based Install Only." These patches will install via the Windows Update Agent, not via a distributable file (downloaded .exe, .msu, .msi). As long as the endpoint has access to the internet and the necessary MS sites are allowed via firewall/web filter/proxy rules, these patches are fully installable via Kaseya. Some environments disallow endpoints from accessing the internet. In these cases, endpoints will not be able to install patches flagged as "Internet-based Install Only" because the environment is prohibiting such installations. However, this is not a limitation of Kaseya but, rather, a decision of the network admins/business requirements that are restricting this.
Kaseya leverages the Windows Update Agent (WUA) for all patch scans and some or all patch installations (depending on File Source Configuration). Kaseya does not support using WSUS as an intermediate player in patching systems. However, you may be able to leverage WUA through a custom-built dll to contact the WSUS server for patches. If done properly - and if supported by Microsoft - you may be able to get all WUA (including that traffic which is leveraging WUA through its .api) to direct patch requests to a WSUS server. You may need to contact Microsoft regarding whether this is possible. If WUA and WUA.api can be forced to direct all requests to a WSUS server, then it's conceivable that any third party dll that leverages the .api wouldn't know the traffic is being routed via the WSUS server. The players involved here, though, are all Microsoft tools - WSUS and WUA, WUA.api communications. Microsoft would need to provide the guidance on whether that solution is available.
I don't necessarily recommend this as, from Kaseya's perspective, this isn't something we would directly support. Information being returned regarding missing and installed patches would be based on results potentially coming from WSUS rather than MS's online patch sources. If the information provided by WSUS is inaccurate, Kaseya would be passing along those results. If the data provided by WSUS is not consistent with the format the Kaseya dll is expecting, data may be skewed and/or might be unwritable to the database. This is fraught with potential issues. I don't think it's a good idea, and I wouldn't recommend doing this. However, that isn't to say that it can't be done. MS would need to address that.