@dashrender said in Server 2012 R2 not installing Updates:

@scottalanmiller said in Server 2012 R2 not installing Updates:

@dashrender said in Server 2012 R2 not installing Updates:

@itivan80 said in Server 2012 R2 not installing Updates:

I never ever liked windows update service. In one hand they fix some issues but in the other hand they create more unnecessary issues. I am glad you were able to isolate the update and made it work congrats.

I agree that MS should do better at making updates, but all things considered - with millions if not billions of combinations and different setups - they could definitely have way more issues.

But Jason - Linux Distros have billions upon Billions of deployments and they don't have these issues... or so we're told.

Exactly. Why are Linux distros, BSD distros, and MacOS distros all able to do this with very, very few issues, but MS constantly having issues with it?

Also, the issues that people have are really never about different combinations with Windows. It's Windows itself breaking, things that have little to nothing to do (in most cases) with configuration or third party components.

Also, other OSes update a lot more than Windows does.

This is a great question - of course one of which I do not have an answer. Though I guess it's likely to do with fundamental design differences - does nix use DLLs? There's no registry on nix either (at least not in general) - this poor design choices by MS could be all the reason for the problems.

Could be, but are also things that they can fix. But Linux uses config files like a registry. And Linux has shared libraries. And once in a while they have issues, but fixes are normally easy. But how many of these Windows update issues are related to DLL and registry issues since 2003? Not many, I don't think.

@dashrender said in Server 2012 R2 not installing Updates:

@scottalanmiller said in Server 2012 R2 not installing Updates:

@dashrender said in Server 2012 R2 not installing Updates:

Of course though - this thread is about Windows Server, not desktop - where this should be MUCH less of an issue with properly designed code.

Same code, they don't make it twice. Less hardware hotplugging, but probably just as many lines of code in use.

Less desktop apps on the platform, but you're right - the base code is the same.

Fewer desktop apps, maybe. But in the Windows world, server often is treated as a desktop (like 90% of the time) so the reduction is rarely what you'd hope. And there tends to be lots of server-only code too, often running as desktop apps.

It is worth pursuing this thread because this was someone two weeks ago facing this same issue but trying to say that option 2 was the "only" option and that a legacy bandaid should be seen as a modern approach. It's an acceptable bandaid in many cases, but it is a 1998 way of fixing things. Legacy by any IT standard. That doesn't make it wrong or bad, but it is old and exists only to fix layers of the same problems.

https://mangolassi.it/topic/24043/vdi-options-modernization

Are you sure that the firewall is the issue? Typically you don't need to allow outbound traffic, that's open by default 99% of the time. Otherwise "nothing" works and you are having loads and loads of issues.

Often asset discovery tools don't work over the WAN, they require an open LAN.

What actual protocol and firewall are we looking at here?

@dashrender said in Help Sorting out a Firewall Issue:

I don't have the full port range open on my Firewall for RTP ports for my phones.

They aren't servers, either.

@dashrender said in Help Sorting out a Firewall Issue:

I thought this is what ALG was supposed to solve (but instead often more frequently breaks).

ALG has no real world purpose. There is no problem to solve.

@mr-jones said in Help Sorting out a Firewall Issue:

Could you expand on why that doesn't make sense? Is port negotiation not a functionality of TCP?

Because you are thinking of WMI as being like HTTP, FTP or SMTP (single protocol.) In all those cases, yes, port negotiation is built in to TCP. But this is why I asked for the protocol details from the beginning, because this is not that simple. This is like SIP.

First, when we talk about port negotiation in TCP the server is always a static port and is always protocol based. It doesn't negotiate, it's published. This is the Port 135 that you know for WMI. WMI then responds on a random port, that's the negotiation.

When you are dealing with HTTP, FTP, etc. that is all that there is.

The port 65849 in your example is not WMI, it is DCOM. The problem here is that DCOM is not published or open. WMI is not using that port. WMI tells the client that it wants them to initiate a DCOM client and reach out to the DCOM server on a dynamic IP (it's dynamic to you and me, it's static to the protocol.)

So the DCOM port needs to be open. Since DCOM has no known port, we'd have to open all available ports for DCOM to listen OR we need the WMI application to be allowed so that whatever ports the DCOM server is using at the moment are open.

WMI is one protocol and working fine. DCOM is another protocol and working fine. Your problem was that you were thinking of DCOM as part of WMI and that's what is confusing you. Either protocol on its own works as expected. What does not work magically is when you have one protocol (WMI, SIP) trying to automate another protocol connection (RTP, DCOM) because the network layer (firewalls, routers, etc.) have no way to know what is going on because it is happen in the application rather than in the network stack. There's no networking involved here, it's literally all inside the application. Not the application layer of the ISO OSI, but the actual application itself.

SIP is exactly the same with RTP. RTP is not a part of SIP. You can use RTP without SIP. You can use SIP without RTP. But by far the most common way is to use then together. SIP is a protocol for negotiating multiple RTP connections, among other things. So SIP is doing a lot. But in a typically phone call you have one SIP connection and two independent RTP connections. So there are three channels of communications going on at any given time.

Each one is independent and which service is the server and which is the client varies based on the channel. And on how the call is set up.

Each individual protocol is solid and straightforward. But when we try to look at them as "phone call" it is super complex. Because it is three individually simple network communications that have to happen coordinated together, in real time, handling lots of traffic, with both sides being client and server.

WMI might as well be a human using the computer. If it were, it would be like this...

WMI server gets request from WMI client. WMI server pops a message on the screen for the user to fire up a temporary DCOM server.

User double clients on "DCOM server", which randomly assigns itself an available port number from a giant pool and tells the user (on the screen) which port number it is.

User takes said port number and goes to Windows firewall and opens that port temporarily. Then the user responds in the WMI app that the port is ready.

The WMI client fires up a DCOM client that connects to newly available DCOM server and does its thing. When it finished, it tells the WMI client to tell the WMI server that it is done.

WMI server receives "finished" message and tells the human looking at the screen that it is done. Human closes DCOM server, then human removes open port from Windows firewall.

That "human" step is really happening, it is just automated with a script. But it's actually happening.

@pmoncho said in MeshCentral - Anyone tried this?:

@scottalanmiller

I misread that. Yeah only 140 agents.

Apparently I am far behind.

We use it pretty extensively

@pete-s said in Help Sorting out a Firewall Issue:

@scottalanmiller said in Help Sorting out a Firewall Issue:

@mr-jones said in Help Sorting out a Firewall Issue:

Could you expand on why that doesn't make sense? Is port negotiation not a functionality of TCP?

Because you are thinking of WMI as being like HTTP, FTP or SMTP (single protocol.) In all those cases, yes, port negotiation is built in to TCP. But this is why I asked for the protocol details from the beginning, because this is not that simple. This is like SIP.

First, when we talk about port negotiation in TCP the server is always a static port and is always protocol based. It doesn't negotiate, it's published. This is the Port 135 that you know for WMI. WMI then responds on a random port, that's the negotiation.

When you are dealing with HTTP, FTP, etc. that is all that there is.

The port 65849 in your example is not WMI, it is DCOM. The problem here is that DCOM is not published or open. WMI is not using that port. WMI tells the client that it wants them to initiate a DCOM client and reach out to the DCOM server on a dynamic IP (it's dynamic to you and me, it's static to the protocol.)

So the DCOM port needs to be open. Since DCOM has no known port, we'd have to open all available ports for DCOM to listen OR we need the WMI application to be allowed so that whatever ports the DCOM server is using at the moment are open.

WMI is one protocol and working fine. DCOM is another protocol and working fine. Your problem was that you were thinking of DCOM as part of WMI and that's what is confusing you. Either protocol on its own works as expected. What does not work magically is when you have one protocol (WMI, SIP) trying to automate another protocol connection (RTP, DCOM) because the network layer (firewalls, routers, etc.) have no way to know what is going on because it is happen in the application rather than in the network stack. There's no networking involved here, it's literally all inside the application. Not the application layer of the ISO OSI, but the actual application itself.

Good points! Actually FTP is also not really straight forward and has a similar mechanism with it's data and control ports - depending on if it's running in active or passive mode.

Ugh true, I should not have mentioned FTP. It's a mess.

@dashrender said in Issue with NGINX passthough TLS:

@scottalanmiller said in Issue with NGINX passthough TLS:

If you are just passing through, what is the point of Nginx? Just use HA-Proxy and set to TCP mode and TLS will pass through flawlessly.

Nginx' purpose is to tear the connection apart and inspect it, breaking TLS pass through.

I didn't know that.

At its core, Nginx is a web server. If you do TCP pass through, you are bypassing the core functionality.

Nginx has TCP pass through capability, so you CAN do this. But it is really intended to be a piece of a bigger picture. WHereas with HA-Proxy, this is its bread and butter and is way simpler.

https://fedingo.com/how-to-configure-ssl-tls-passthrough-in-nginx/

@pete-s said in Why Hyperconverged For Small Business:

@woodbutcher said in Why Hyperconverged For Small Business:

Is there truly a case for a hyperconverged infrastructure for a small business?

Not if you're looking for high availability.

Most small businesses lacks a lot of things to get a fault-tolerant high availability system. You need to look beyond the servers themselves because there are a lot of dependencies that also needs to be highly available. Like network, power, cooling etc.

Look at a commercial datacenter. It's usually redundant all the way through, from one end to the other.

Pete is spot on. The ability to do full HA by a company under 1,000 employees is nearly impossible and almost never valuable. The cost to actually do it is so absurd. But if you move to hosted, it can cost almost nothing. We have HA on things for pennies. The HA discussion is a big piece driving the ERP purchasing decision. WHoever chooses the ERP is the core decision maker about HA. Sounds like they likely decided HA was pretty far from a priority (which is reasonably accurate.)

@woodbutcher said in Why Hyperconverged For Small Business:

The concern with that approach would be minimizing data loss. Primarily transactions in the ERP, though the volume of these transactions is low relative to other companies. But I would guess with proper backups at the DB level, this could be minimized as well if they had to recover via a backup.

Unless you have DB level HA, nothing in your current set up (or in the HA setup!!!) will protect against transactional losses. Only proper database protection does that and nothing being discussed here touches on that.

@woodbutcher said in Why Hyperconverged For Small Business:

That was another thought as well. I don't think their existing 2 node ESXi system is n+1 anyway so they essentially are already in this position, but maybe without extended warranty. Hard to tell as I am just digging in and their internal knowledge is not great.

Easy test...

If you need N+1, you should have HA. If you need HA, it has to be HC.

So it all comes down to answering "is N+1 needed"? Chances are, no. It isn't now. Nor are the most reliable setups being used. So nothing here suggests HA is even on the radar. Going down to a single host will lower cost and, we assume, increase reliability too!

@woodbutcher said in Why Hyperconverged For Small Business:

With redundant PSUs, a healthy RAID setup, incoming power filtering, etc, the failure isn't likely to be a server death sentence. The issue (RAM, CPU, MB, etc.) would be resolved, fire back up the server and go back to making money.

Even on Wall St. that is how they handle it because single servers have better transactional integrity and better overall reliability costs.

SOme resources for your team. For real, sit down and make them watch these...

Youtube Video

@woodbutcher said in Why Hyperconverged For Small Business:

The previous IT guy was not really an IT guy and never took an interest in his job. I think the VAR identified this pretty quickly and are trying to one-up themselves with what they can get away with.

It's a standard model. "Fake" IT guy (or lazy, over his head, politically screwed, fill in the blank here) finds a sales guy that is willing to do something that kind of looks like his job for him, for "free" and gets the company to pay for it. The company gets insanely screwed while the VAR makes loads of money for being unethical, and the "IT guy" gets away without having to do the job he is being paid for. So the company pays double for something they aren't getting at all (IT guidance and protection.)

The tiniest audit or thought from management catches this. It's impossible hide. But it exposes how often CEOs take zero interest in IT and totally ignore it.

@woodbutcher said in Why Hyperconverged For Small Business:

My frustration is that I don't even do this full time and can't find a single drop of value this VAR is adding even though they claim to be experts at this.

That's how sales people work. And that your company had engaged a sales person to be an expert, it is caveat emptor. The sales person isn't pretending not to be a sales person, so 100%, absolutely all fault lies in the management at your company for engaging a sales guy and acting like he's an IT guy. As a business, it is their job to properly engage experts and hire them. And only themselves that are put at risk, so the decision is theirs.

@woodbutcher said in Why Hyperconverged For Small Business:

I'm no slouch but I am also not an IT expert. My background is mostly software development and manufacturing automation but also have experience with things like ERP and MES. Most jobs I take are with small companies and I end up doing or assisting with a lot of the IT work.

Then bringing in a real MSP/ITSP is the proper course of action. A qualified MSP will protect you and save you a ton of money. Going to a VAR means the company is throwing money away to avoid critical thinking. It's a common approach as it is quick, easy and very, very few people point out the obvious flaws in the process so it caters well to hubris.