Towards the end, I realized it's probably related to the speed of moving the cursor. If you move it fast enough, you can click it (you'll see it at the end of the attached video), but if you're slow, then you cannot.

Not sure it's a huge issue, but something to consider might be the pop up going to a side so your cursor's attention doesn't compete between other updates above/below and release note links.

As context, I'm on an M2 MacBook Air (latest OS, 27.2.1) and using Safari (27.2) in this video.

Attachments:

• Screen Recording 2026-11-13 at 10.50.30 AM.mov

I have a rather vanilla blueprint which I created a few "default settings" that I want applied (i.e. new zones, basic firewall rules). When I apply the blueprint, the settings get pushed down as expected. Then, if I ever remove that site from the fabric or the blueprint, it deletes those applied settings, including any other rules that may have been created within those pushed zones. If this is expected, I think there needs to be a review and at least a wording change for the popup displayed when prompting for removal of the site from the blueprint.

I’d like to understand a behavior in the People section of a UniFi Fabric. I’m trying to work out whether it’s intended or a UI/sync quirk.

Setup

• Fabric with 3 people, all UniFi accounts

• Account 1: owner admin account, Owner of the Fabric

• Accounts 2 and 3: regular admins

• All three have the role “Fabric Admin” (“Fabric settings + full admin rights for all sites”)

• sites in the Fabric, hub-and-spoke SD-WAN

What I see
Under “Sites” in a person’s profile, I’d expect just one entry, “All Sites”, because the Fabric Admin role already covers everything. That’s exactly what the owner admin account shows. Admin rights are “Full” and greyed out, and the Endpoint Services (One-Click WiFi/VPN, door access) are customized.

For the two regular admins there are additional per-site entries below “All Sites”:

• Admin 2: “All Sites” plus Site A and Site B

• Admin 3: “All Sites” plus Site A only

Endpoint Services config

• Under “All Sites” for both admins: Endpoint Services set to custom, One-Click WiFi on for all sites, One-Click VPN only for the hub site, door access off.

• The extra entries (Site A, Site B) show the same effective values: WiFi on, VPN on only for the hub site, door access off.

• So the extra entries look redundant to me, since the effective permissions are identical.

Things I can’t explain

1. Hovering over “Remove site” on any of the extra entries shows a tooltip, translated from German: “This site cannot be removed because it is inherited from the Fabric Admin role.” This appears on every per-site entry, so none of them can be removed. But the owner admin account, which has the same role, doesn’t show any per-site entries at all. Why do some accounts show inherited per-site entries and others don’t?

2. The two admins have the same role but a different set of extra sites. Admin 2 has two, Admin 3 has one. I never intentionally configured per-site permissions for either.

3. If the role grants access to all sites anyway, why are only some sites listed individually, and not all of them?

Questions

• Is the combination of “All Sites” plus per-site entries intended when the person has the Fabric Admin role?

• Do the per-site entries override “All Sites” for Endpoint Services, or are they just displayed?

• Can I clean this up, or is it a display or inheritance artifact? Has anyone seen it before?

Thanks for any insight!

Best regards

Sven

Have Network, Access, & Protect running off the UDM Pro, with Drive running off the UNAS Pro 4. Merged both sites into one in site manager. Have plans to deploy Talk soon, but need to figure out the problem below first.

Problem is, I have to manage two sets of users now between the UDM Pro, and UNAS Pro 4. Is there any integration coming soon to merge this, or am I missing something?

Does fabrics help with this since it's physically one 1 site?

I'm trying to deploy a Blueprint created from an existing UCG Fiber to another UCG Fiber, but deployment is blocked by a Network Application version requirement.

Source device used to create the Blueprint:

UCG Fiber

UniFi OS 5.1.35

Network Application 10.6.109

Target device:

UCG Fiber

UniFi OS 6.0.17

Network Application 11.0.99

The Blueprint was created successfully. However, when I try to deploy it to the target device, I receive a message stating that Network Application 11.1.39 or newer is required.

As far as I can tell, version 11.1.39 has not been publicly released, so I cannot update the target device to meet this requirement.

Is this an incorrect minimum-version check in Site Manager, or is there another reason why a Blueprint created from Network 10.6.109 would require an unreleased version to deploy?

Has anyone else encountered this issue, and is there a workaround?

Thanks!

Attachments:

• 2026-11-11 16_47_24.png

Insert the "OMG, I CAN'T BELIEVE YOU HAVE THAT LITTLE BANDWIDTH, THATS CRAZY"... Well when you manage HUNDREDS of sites for your customers, the $10/month internet which works PERFECTLY is better than paying $200/month for basic fiber or a standard fixed Starlink install which continues to go up every day it seems!!! it's about overhead! Now that we got that out of the way, continue below (lol):

Here lies the issues - Updates! We do recognize the update sizes in the Releases section and for example, we have a $129 gateway ultra needing 5.1.35 and it's about say 756MB in size and that's not even including Network which also will need updating. Basic math shows that update will take about 3.5 hours just to download it on this low bandwidth connection. In this case the console shows offline the entire time the download is going even though the SD-WAN is still connected and data is still flowing with excellent latency.

Is there a way we can get an ETA meter / bar showing not only the size of the update (Network, Protect, Talk, the OS, Ect ect) but also the progress of said update to be able to accommodate these slower connections? We also have some tower sites we manage which have dedicated fiber but it's only a 2Mb/2Mb connection - same deal, 4 times faster than the Starlink standby but still VERY LITTLE bandwidth for these large updates that NEED to be done.

To take it a step further, when these downloads are happening can we not show the console offline when it is in fact online, just downloading the update for hours and hours?

Thanks!

1. Adopt into the organization: When MSP team members adopt devices, they should go into the MSP organization, not the team member's personal account.

2. Organization-level ownership: The MSP organization, not an individual team member, should own the device.

3. Owner role transfer and multiple owners: Let us transfer the MSP organization's Owner role to another team member, or assign multiple Owners, so the organization isn't dependent on a single person.

4. Streamlined adoption: Either auto-adopt into the organization when a team member has configured it, or show a one-click "Adopt to Organization" prompt during device setup.

5. Custom roles and permissions: Let us create and configure roles and permissions within My Team.

Optional

6. Per-site fabrics on UniFi OS Server: For MSPs running UniFi OS Server with Multi-Site enabled to manage multiple customers, let us assign individual sites to their own fabrics instead of placing all of the server's sites in a single fabric.

I understand MSP Access and we are already using it; these are my requests on features or how it would work better.

I'm an integrator managing UniFi gateways for multiple business customers through the Site Manager API (cloud connector, owner API keys per organization).

Since today, 2026-11-05 around 05:40 UTC, every call through /v1/connector/consoles/{id}/proxy/network/... outside /integration/ returns 403: "insufficient permissions: the Connector reaches each application's public integration API (/proxy/{app}/integration/) only". The same calls worked on 2026-11-03. I found no announcement or changelog entry.

The Integration API covers networks, DHCP, DNS policies and firewall policies, which is great. But several security settings are only reachable through the legacy endpoints: Encrypted DNS / DNS Shield, Intrusion Prevention (mode, categories, engine update), Region Blocking, Honeypot. Today the only remaining way to manage them is the web UI, one console at a time.

Could you either restore connector access to the legacy endpoints, or add these settings to the official Integration API? A short notice before this kind of change would also help those of us who build on the connector.

Thanks.

I'm trying to understand the intended MSP architecture for UniFi Fabrics, because there appears to be a major limitation around UniFi OS Server and multi-tenant deployments.

We centrally host many customer sites on a single UniFi OS Server. Fabrics seem like an excellent way to provide proper customer-specific trust boundaries, especially when integrating separate Microsoft Entra ID tenants for UniFi Identity, One-Click VPN and One-Click WiFi.

The architecture I want is straightforward:

Customer A sites → Customer A Fabric → Customer A Entra ID

Customer B sites → Customer B Fabric → Customer B Entra ID

Customer C sites → Customer C Fabric → Customer C Entra ID

However, sites hosted on the same UniFi OS Server do not appear to be independently assignable to different Fabrics. The UniFi OS Server effectively seems to become the Fabric boundary.

If I'm understanding this correctly, that is a substantial limitation for MSPs. A centralized UniFi OS Server is otherwise ideal for managing large numbers of customer sites, but placing unrelated customers into the same Fabric defeats one of the major benefits of Fabrics: segregation of identity and trust domains.

The alternatives don't seem particularly attractive:

• Separate UniFi OS Server instance per customer

• Official UniFi Hosting/control plane per customer

• Purchase an IdP-capable UniFi console/gateway for every customer

• Keep unrelated customers together in one Fabric

We're gradually deploying UniFi gateways where they make sense, including UXG Enterprise, but many customers have relatively new Sophos XGS firewalls. Replacing perfectly serviceable firewalls simply to establish a customer-specific UniFi Fabric/Identity boundary would be difficult to justify.

Has anyone found a clean MSP architecture for this?

Specifically, can individual sites hosted by a single UniFi OS Server be assigned to separate Fabrics somehow, or is the current design effectively one UniFi OS Server = one Fabric?

If the latter is intentional, I'd be very interested to know whether proper multi-Fabric support for UniFi OS Server is planned.

Is there any documentation on what attributes Fabric is expecting to see at LDAP?!

P.S. the reason to use AD LDS is to sync users from two (or more) independent AD forests.

Something that would be nice in Site Manager, especially when there are multiple sites, would be the ability to put in some notes for the site, such as their street address and phone number.

Attachments:

• Screenshot 2026-11-03 125019.png

With the current People & Roles workflow, I’m having to repeat user information on individual sites. This is a step backward for anyone managing multiple sites, especially MSPs.

Please restore the ability to:

• Select an existing user from a centralized list and grant access to additional sites.

• Select multiple sites when assigning access.

• Define a role once and reuse it across sites, rather than manually configuring equivalent permissions on each one.

• See and manage a user’s site assignments and roles from their central user record.

Users and role definitions should be reusable. Site access should remain explicitly assigned. Reusing a person or role should not automatically grant access to unrelated customer sites.

The old workflow already solved the user-assignment problem. Please bring that efficiency back and apply the same logic to roles.

@UI-Team

Is there a way to permanently block invites from the site owner's email address? @UI-Team would be great to have a 'Block' option for these invites to permanently ignore them.

Thanks in advance!

But still there are things to do, fix or improve.

One thing, that concerns me a lot is only one owner per device/site/fabric. For Enterprise - we have a single point of faulure here - because what happens if the "owner" leaves the job/dies/automagically dissapears?

And there still a lot of undocumented things, that still requires an owner role to do something on the Unifi. Not everything is possible with the Super admin role (one of the example document is: https://help.ui.com/hc/en-us/articles/30979808349463-Getting-Started-with-UniFi-Fabrics - I don't see any "required owner role" in the required list).

Attachments:

• Screenshot 2026-10-26 at 5.15.44 PM.png