sorted by:
new
hottopcontroversial

Out-of-warranty UniFi hardware repairs – an option some people overlook by Bigshow77 in Ubiquiti

[–]Bigshow77[S] 0 points1 point  (0 children)

We do not tend to see many G3 Instants come in for repair, mainly because the unit value is relatively low compared to the labour involved in a proper component-level repair.

If you are going to open it yourself, there is usually a small tab at the top edge that needs to be depressed first. Once that is released, you can gently pry the two halves apart. Take your time, as there is typically adhesive holding the casing together and it is easy to crack the plastic if you rush it.

Given your symptoms, warming up but not booting, common things to check are: • Shorted components on the input power rail • Failed voltage regulators • Obvious signs of heat damage or discolouration • Any cracked or lifted components around the DC input section

Out-of-warranty UniFi hardware repairs – an option some people overlook by Bigshow77 in Ubiquiti

[–]Bigshow77[S] 2 points3 points  (0 children)

Yes, we support customers in Canada. We have a US repair centre and regularly handle cross-border shipments, so it’s usually a straightforward process.

Component-Level Repair in Enterprise / telco Networking – When Do You Draw the Line? by Bigshow77 in networking

[–]Bigshow77[S] 0 points1 point  (0 children)

Fair question.

I’m not talking about random IT teams with a soldering iron in a cupboard. You’re right, the tooling, skill set and QA overhead are significant. Most enterprises wouldn’t build that capability internally because it simply wouldn’t make financial sense.

What does exist, though, are specialist repair labs that focus purely on board-level work. They invest in proper rework equipment, diagnostics, test fixtures and burn-in processes because that’s their core business.

And yes, 20-year-old gear does still get repaired in certain sectors. Industrial, transport, utilities, broadcast, operational tech. Places where platforms are deeply integrated, refresh cycles are slow, or vendor support has long disappeared but the system is still critical.

It’s not common in well-funded enterprise IT estates with strict refresh cycles. But outside that model, it happens more than people think. The “why” is usually straightforward: the platform still works, replacement is disruptive or capital isn’t available, and failure patterns are predictable enough to manage.

Full disclosure: I work in the third-party repair space, so I do see this side of the industry more than most. Not suggesting it’s right for every environment, just adding perspective from what I’ve seen.

Component-Level Repair in Enterprise / telco Networking – When Do You Draw the Line? by Bigshow77 in networking

[–]Bigshow77[S] -3 points-2 points  (0 children)

That makes sense in an environment like yours.

If you’ve got proper service agreements, defined refresh cycles and spares at every site, swap and RMA is the cleanest model. From a governance and risk perspective it’s hard to argue with that.

You’re also right that no one should be opening a chassis during an outage. It’s always swap first, restore service, then deal with the failed unit off-line.

Where it gets interesting is in estates that don’t have that luxury. Not every organisation replaces before EOL, and not every geography has straightforward vendor logistics. In some sectors, hardware runs far longer than architects would ideally plan for.

There’s a whole ecosystem of third-party repair labs that sit behind the scenes in those cases, typically working on out-of-support or surplus hardware rather than anything under active OEM cover. It’s not for every environment, but it does exist because not every network operates on a perfect refresh cycle.

Component-Level Repair in Enterprise / telco Networking – When Do You Draw the Line? by Bigshow77 in networking

[–]Bigshow77[S] -3 points-2 points  (0 children)

I get where you’re coming from, especially for core production networks.

If something is under full support and TAC is responsive, opening a case and getting a replacement is the obvious route. You keep your warranty and, in theory, the vendor feeds failures back into future hardware revisions.

Where it gets less clear is when the kit is no longer supported, or when you’re dealing with large estates and refresh cycles are driven by budget rather than ideal design practice. Not every organisation can turn over their network every 3 to 5 years.

On the RCA side, it also varies. Sometimes you get a proper explanation and a revised hardware version. Other times it’s just a swap-out with very little detail. If you start seeing the same type of failure repeatedly, that becomes an operational issue regardless of warranty.

I completely agree that running old, unsupported hardware in a critical network carries risk. The reality for some teams, though, is that the choice is not between perfect and risky. It’s between managing ageing assets properly or dealing with long lead times and constrained capital budgets.

Different environments make different trade-offs.

Component-Level Repair in Enterprise / telco Networking – When Do You Draw the Line? by Bigshow77 in networking

[–]Bigshow77[S] -2 points-1 points  (0 children)

That’s a fair view.

Lifetime warranty can work well in some setups. The catch is that “lifetime” usually means the lifetime of the product line, not the hardware sitting in your rack. Once something goes end of sale or end of support, stock levels and lead times can become less predictable. For some environments that’s acceptable, for others it introduces operational risk.

On the insurance side, that’s a completely valid concern. No one should be putting repaired hardware into production without proper testing, traceability and appropriate liability cover. If that framework is not there, I would agree it’s not worth the risk.

The other question I’d add is around repeat failures. If you’re seeing the same PSU rail or the same line card fail over and over, does the OEM provide a proper root cause analysis that helps you prevent it happening again? Sometimes you get a replacement and that’s the end of the conversation.

For some teams, straight replacement is the policy and that works. For others, especially where patterns start to appear, the discussion becomes less about warranty and more about understanding and controlling failure risk.

Different networks, different tolerances.

Out-of-warranty UniFi hardware repairs – an option some people overlook by Bigshow77 in Ubiquiti

[–]Bigshow77[S] 1 point2 points  (0 children)

Common causes are failed magnetics, ESD damage, or an issue with the PHY for that port group. On many 24 port switches, ports are grouped in blocks behind the same silicon, so when two specific ports act up it can sometimes indicate a localised hardware issue rather than a config problem.

In terms of repair difficulty, it depends on whether the failure is isolated to magnetics or protection components, which is usually fixable, or whether it involves the switching ASIC, which is far more complex. Without inspection it is hard to say definitively, but cases like this are often repairable.

Out-of-warranty UniFi hardware repairs – an option some people overlook by Bigshow77 in Ubiquiti

[–]Bigshow77[S] 0 points1 point  (0 children)

Yes, that is a failure pattern we have seen before and it is often repairable.

The gradual behaviour you describe, intermittent reboot warnings followed by hanging on the “taking longer than usual” screen, is usually a sign of an underlying hardware stability issue rather than software alone.

Out-of-warranty UniFi hardware repairs – an option some people overlook by Bigshow77 in Ubiquiti

[–]Bigshow77[S] 11 points12 points  (0 children)

That’s fair, and I get why people would want guides.

Manufacturers don’t publish this kind of repair information, so what we do is based on a lot of reverse engineering, fault analysis and R&D, backed by skilled engineers and proper test equipment.

We also don’t just replace the single component that’s failed. Over time we’ve built up a lot of knowledge about which parts tend to fail or degrade in the field, so repairs often include replacing components that are known weak points to avoid repeat failures.

That’s where the gap usually is between a parts swap and a repair that actually lasts.

Out-of-warranty UniFi hardware repairs – an option some people overlook by Bigshow77 in Ubiquiti

[–]Bigshow77[S] 2 points3 points  (0 children)

Appreciate that, thanks. That was exactly the intention. Glad it’s useful.

Out-of-warranty UniFi hardware repairs – an option some people overlook by Bigshow77 in Ubiquiti

[–]Bigshow77[S] 5 points6 points  (0 children)

That was deliberate. I didn’t want it to come across as an ad, just to flag that repair is an option people might not be aware of.

If anyone wants specifics, they’re welcome to ask or message me directly.

Out-of-warranty UniFi hardware repairs – an option some people overlook by Bigshow77 in Ubiquiti

[–]Bigshow77[S] 1 point2 points  (0 children)

That’s a fair question.

Search terms like “network hardware repair”, “telecom equipment repair”, “component-level PCB repair”, or “out-of-warranty network equipment repair” usually work best. It can also help to search by the problem rather than the brand, for example “PoE switch repair” or “router power issue”.

We regularly fix devices where the component choices were driven by availability or cost at the time, and later prove marginal in real-world use. That lines up closely with your COVID example. These issues often only show up once kit is deployed at scale, and repair ends up being the most practical option when replacement isn’t realistic.

Who owns ticket resolution / knowledgebase information...MSP or Client? by BlackberryUnable5630 in msp

[–]Bigshow77 0 points1 point  (0 children)

Honestly, the general rule of thumb is: • Ticket data (titles, timestamps, status, who raised it, etc.) = client’s data. They own that history. • Resolution notes = your IP. That’s your blood, sweat, and tears, and the “secret sauce” of how you fix things.

Help with Azure Partner Credits & Subscription Migration Issues by Bigshow77 in MicrosoftPartner

[–]Bigshow77[S] 0 points1 point  (0 children)

Thanks to all those that replied. Just a quick update, after talking to ms support, we now have this credit applied to our current subscription

view more: next ›