Our setup is this:

around 7000 Windows 10 clients connected to Azure cloud (education license, since they are schools)

One print server, running EveryonePrint, to get around the CAL licence requirement for connecting to a Windows print server.

No local domain, all our on-premise servers are standalone.

My thought was, to setup a CUPS Linux box, and serve all printers from there.
This has been troublesome, as I can't seem to make the drivers available for auto-install to the Windows clients.

So my question is this:
Is there anyone out there, that has a working setup with a Linux CUPS/Samba server, servicing Windows clients, and has an easy method of setting up printers and drivers on that server?

I have found some pages that indicates that I might be able to connect to the print server (CUPS) via Windows Print server console, but that is only if the whole setup is local AD and I have a domain admin or likewise to login to the Linux box.

I am aiming to setup this in a workgroup-only environment, so any hints are welcome.

Our network setup is one school, one subnet, with no broadcast. Layer 2 switches between locations. But servers (on their own subnet) are accessable from every subnet.
We have the possibility to add Cisco network helper setup to aid in broadcasts on specific ports, but I'm not sure if that will be of any help.

This post talks about how to do it. I tested it back in January on Windows 7 to RHEL7 CUPS print server and it worked.

The only thing I did differently than he wrote is I did NOT add my CUPS print server to Windows hosts file as my server is in DNS (as seen from the Windows server - see my post at the bottom of that thread).

This ought to work on Windows 10 but I don't have one to test from at the moment.

The Windows Wizard does prompt for Manufacture etc... but often you can use generic models.

I have always found the Samba documentation to be the best source of information.

This does not solve my problem.

I need to connect Windows 10/Server 2016 Print Manager to a Samba server, to be able to add printer drivers using the Windows GUI.
This is not possible without having some kind of common authentication, like Active Directory, since the Windows computer running Print Manager are unable to authenticate to a standalone computer.

I'm testing a Samba AD setup this weekend, and will post back how it goes.

My main problem is that I cannot install a MS AD on the network due to the license cost.
Maybe a Samba AD will do it, we'll see.

Also, adding drivers to CUPS/Samba is too difficult using Linux command line tools. I may be able to do it for a couple of printers, but we have close to 100, with different drivers.
And more is coming all the time.

My response was based on you saying:
That doesn't require any Samba or AD setup for printing. Just CUPS setup at the Linux server and adding the printers at the workstations. It would of course require setting up your multiple printers on the CUPS server but only require setup of the printers at workstations that are used by the local users.

For going the Samba route instead perhaps allend's post would be a good start.

It isn't clear to me why you think going the AD/Samba route would entail less setup. At some point you have to define all the printers somewhere no matter what you use. We've used Windows print servers, Linux with CUPS print servers and Printer logix which doesn't really spool but all 3 methods require defining all the printers somewhere central then configuring less locally on the individual Windows workstations/laptops.

Most places I've been have printers defined both in UNIX or Linux and in a central Windows setup. The former for use from server applications (e.g. Oracle financials, SAP) and the latter for printing from local apps (e.g. Word, Excel).

The CUPS setup I posted would actually work for both purposes as proven by my test back in January. Since we already have the Print logix setup on Windows workstations/laptops I didn't bother to roll it out to those - just tested it to see if it could be used.

At what stage cost is compared of adding AD on prim with doing all this work (time spent of employee(s)) to add 100s of printers in this method? I do not know how much setting up AD costs, but sure someone in your org can figure this out?

You'd be surprised at how many organizations don't actually calculate ROI or TCO when planning IT changes as opposed to the ephemeral "cost" they see in writing a check. Does it "cost" them $10,000 to write that check? If so they balk. The fact that they'll then use up $25,000 of labor to work around writing the check never occurs to them. At that point they'll then start complaining that nothing else is getting done because of all the labor dedicated to the project that wouldn't have been necessary if they'd written the check.

There are times when one can't write the check due to cash flow concerns and that should be the decision made but if so then a realization of the opportunity cost lost by tying up labor should be expected. However, most companies simply try to be cheap when it comes to writing checks and think that somehow they have unlimited hours from salaried employees.

All of that says nothing about the fact that many IT projects that would result in writing a check can be capitalized so the "cost" is amortized or depreciated over a period of years.

That's what is my problem.

If we have the cash, we could use Azure AD Premium, but that's not the case, and will never be, at least not in the next 4-6 years.

We are a municipality, and have had budget cut downs, so as much as I would like an on-premise AD (with the around 7000 CAL's needed), that's not going to happen.

Therefore I'm looking for a cheap way of making a print server available to all our schools without needing to pay the beast (Microsoft) for the CAL's they require for this.

One can say that MS Print CAL licensing should have been ditched back in the 90's, but it's still part of their main income.
One way to prove that, is that they demand a Premium Azure AD license to be able to sync our users/passwords back to a local premise server.

Therefore I'm stuck with a (very cheap) print solution that works most of the time, but are so buggy that I had to create a "restart 4 services including the print spooler" two times a day to minimize support calls.

But, I guess I just have to get used to swallow camels.

I am a step further to a possible solution, but it includes AD, and therefore I'm testing Samba AD right now.

As an AD with Windows clients it works fine, but I still have to get the Cups/AD thing to work.

I gave up on trying to replicate our Azure AD to the Samba AD server. That's obviously not what MS want to be possible.

So I'm going to try to maintain some Samba domain groups to at least limit printing within a school's subnet.

I will update this thread when I get some results.
This takes some time to test, as I test in my home lab, and then replicate it to some production test servers.

Samba AD is not that easy to get to work with newer Windows admin tools, so I need 4.8 to get it to work.
Currently trying a ppa with 4.8.5.