So the library GPO is linked somewhere above this user's OU and is using security filtering to apply to the library security group only?
Have Domain Computers been given read permission?

@David_CSG said in Opinions: Ansible vs. SaltStack:

For real road-warriors, I’ll leverage our RMM (Solarwinds), which is ok (I have to overcome shortcomings for the Mac with custom shell scripts, and shortcomings for Windows with custom powershell).

But I’d much rather leverage Ansible where possible.

Or you could use Salt to manage your in house and your road-warriors.
Though learning Ansible is probably a better career move (searching saltstack on stackoverflow jobs returns 7 results, ansible 106)

However, I believe that salt generally makes more sense for user computers than ansible

@David_CSG so what's your plan for ssh into laptops that are out and about?

@scottalanmiller said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

I think you must be missing what's going on here. This removes the requirement to integrate more directly with MS Office, instead relying on a separate library that is provided standalone from Office and thus allows saving to Excel. We've had zero issues with using this library, which is actually pretty uncommon for us.

The issue is flexibility. Using third party libraries, you can integrate with Excel or with anything else. Using the Office libraries, every user, in ever system, is bound by the limitations of the most problematic. It makes deployments more costly, and more complex.

That's true, it's the kind of self perpetuating lock-in that has served Microsoft so well. People use Excel, and they ask for saving to Excel spreadsheet, so we create the integration specially to allow Excel and not include ODF, then we help keep the industry locked into using Excel because that's all we support unless you want to just save to CSV.

As for the cost and complexity of deployments... that could be true, except that the installation of our main software is already so complex and costly that dealing with potentially installing this library is the easiest part. I think we probably only have one other developer who would be able to figure out how to install it. I've never heard of any client's IT that have been able to figure out how to install it (just calls from those who have tried), client services has to do literally every install.

@scottalanmiller said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

@Dashrender said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

@wrx7m said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

The ERP's dependency might be actually be ACE, and not Excel itself
https://www.microsoft.com/en-us/download/details.aspx?id=54920

Hmm. I don't know about that. We don't have access installed on the ERP server or any of the other systems.

It's a shared DLL, just installing Excel would install it on a system

That's some pretty crappy software using that engine if that's the case.

If they specifically want to create a feature which is an integration with Microsoft Excel, should they not use the tools provided by Microsoft to do so?

Absolutely not. That's considered one of the biggest, most amateur and/or "don't care about users" programming blunders. It's one of the most common red flags for bad software. Calling it the "tools provided by Microsoft" makes it sound logical, but when you describe it as "tools provided by Microsoft that require the end users to purchase, maintain, support, and constant fix integration with a tertiary product", then it is clear why only a total idiot or truly uncaring developer would do it. And as it is the second most well known "total screw up" for software development inclusions, there is absolutely no viable excuse for a programmer doing it (the most well known is hard coding to SQL Server for no reason.)

This is one of the standard "free for developers, screws the customer" tools that is used as the industry wide example of how lazy developers are lured into making bad software in order to forcible funnel money into a vendor. And it raises the actual cost of the end product, while generally making it flaky and unstable. We make a fortune supporting software that works this way because the MS Office products deregister or have problems all of the time and it is impossible for the software makers to support it. It literally makes their software "not work" reliably.

It's also one of the most common examples of what huge blunders happen when developers get to make decisions without the insight and oversight of operations teams. Because using these tools is easy for the devs, at the cost of totally screwing the end users and operations teams.

I think you must be missing what's going on here. This removes the requirement to integrate more directly with MS Office, instead relying on a separate library that is provided standalone from Office and thus allows saving to Excel. We've had zero issues with using this library, which is actually pretty uncommon for us.

We do support saving to CSV, but people specifically want excel, and believe it or not, they actually get confused by CSVs. I think this is thanks to how Excel implements CSVs, as well as poor spreadsheet training courses, as well as people who probably aren't qualified to touch a computer.

Honestly, our program is built on a series of poor choices, but I don't think this is really one of them.

@Dashrender said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

@wrx7m said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

The ERP's dependency might be actually be ACE, and not Excel itself
https://www.microsoft.com/en-us/download/details.aspx?id=54920

Hmm. I don't know about that. We don't have access installed on the ERP server or any of the other systems.

It's a shared DLL, just installing Excel would install it on a system

That's some pretty crappy software using that engine if that's the case.

If they specifically want to create a feature which is an integration with Microsoft Excel, should they not use the tools provided by Microsoft to do so?

@wrx7m said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

The ERP's dependency might be actually be ACE, and not Excel itself
https://www.microsoft.com/en-us/download/details.aspx?id=54920

Hmm. I don't know about that. We don't have access installed on the ERP server or any of the other systems.

It's a shared DLL, just installing Excel would install it on a system

The ERP's dependency might be actually be ACE, and not Excel itself
https://www.microsoft.com/en-us/download/details.aspx?id=54920

How about the free version of MS Teams until you get your licencing sorted out?

Don't forget about MS SQL licencing