#StopRansomware: Vice Society

Summary

Actions to take today to mitigate cyber threats from ransomware:

• Prioritize and remediate known exploited vulnerabilities.
• Train users to recognize and report phishing attempts.
• Enable and enforce multifactor authentication.

Note: This joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.

The Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), and the Multi-State Information Sharing and Analysis Center (MS-ISAC) are releasing this joint CSA to disseminate IOCs and TTPs associated with Vice Society actors identified through FBI investigations as recently as September 2022. The FBI, CISA, and the MS-ISAC have recently observed Vice Society actors disproportionately targeting the education sector with ransomware attacks.

Over the past several years, the education sector, especially kindergarten through twelfth grade (K-12) institutions, have been a frequent target of ransomware attacks. Impacts from these attacks have ranged from restricted access to networks and data, delayed exams, canceled school days, and unauthorized access to and theft of personal information regarding students and staff. The FBI, CISA, and the MS-ISAC anticipate attacks may increase as the 2022/2023 school year begins and criminal ransomware groups perceive opportunities for successful attacks. School districts with limited cybersecurity capabilities and constrained resources are often the most vulnerable; however, the opportunistic targeting often seen with cyber criminals can still put school districts with robust cybersecurity programs at risk. K-12 institutions may be seen as particularly lucrative targets due to the amount of sensitive student data accessible through school systems or their managed service providers.

The FBI, CISA, and the MS-ISAC encourage organizations to implement the recommendations in the Mitigations section of this CSA to reduce the likelihood and impact of ransomware incidents.

Download the PDF version of this report: pdf, 521 KB

Technical Details

Note: This advisory uses the MITRE ATT&CK^® for Enterprise framework, version 11. See MITRE ATT&CK for Enterprise for all referenced tactics and techniques.

Vice Society is an intrusion, exfiltration, and extortion hacking group that first appeared in summer 2021. Vice Society actors do not use a ransomware variant of unique origin. Instead, the actors have deployed versions of Hello Kitty/Five Hands and Zeppelin ransomware, but may deploy other variants in the future.

Vice Society actors likely obtain initial network access through compromised credentials by exploiting internet-facing applications [T1190]. Prior to deploying ransomware, the actors spend time exploring the network, identifying opportunities to increase accesses, and exfiltrating data [TA0010] for double extortion–a tactic whereby actors threaten to publicly release sensitive data unless a victim pays a ransom. Vice Society actors have been observed using a variety of tools, including SystemBC, PowerShell Empire, and Cobalt Strike to move laterally. They have also used “living off the land” techniques targeting the legitimate Windows Management Instrumentation (WMI) service [T1047] and tainting shared content [T1080].

Vice Society actors have been observed exploiting the PrintNightmare vulnerability (CVE-2021-1675 and CVE-2021-34527 ) to escalate privileges [T1068]. To maintain persistence, the criminal actors have been observed leveraging scheduled tasks [T1053], creating undocumented autostart Registry keys [T1547.001], and pointing legitimate services to their custom malicious dynamic link libraries (DLLs) through a tactic known as DLL side-loading [T1574.002]. Vice Society actors attempt to evade detection through masquerading their malware and tools as legitimate files [T1036], using process injection [T1055], and likely use evasion techniques to defeat automated dynamic analysis [T1497]. Vice Society actors have been observed escalating privileges, then gaining access to domain administrator accounts, and running scripts to change the passwords of victims’ network accounts to prevent the victim from remediating.

Indicators of Compromise (IOCs)

Email Addresses
v-society.official@onionmail[.]org
ViceSociety@onionmail[.]org
OnionMail email accounts in the format of [First Name][Last Name]@onionmail[.]org

TOR Address
http://vsociethok6sbprvevl4dlwbqrzyhxcxaqpvcqt5belwvsuxaxsutyad[.]onion

IP Addresses for C2	Confidence Level
5.255.99[.]59	High Confidence
5.161.136[.]176	Medium Confidence
198.252.98[.]184	Medium Confidence
194.34.246[.]90	Low Confidence

See Table 1 for file hashes obtained from FBI incident response investigations in September 2022.

Table 1: File Hashes as of September 2022

MD5	SHA1
fb91e471cfa246beb9618e1689f1ae1d	a0ee0761602470e24bcea5f403e8d1e8bfa29832
	3122ea585623531df2e860e7d0df0f25cce39b21
	41dc0ba220f30c70aea019de214eccd650bc6f37
	c9c2b6a5b930392b98f132f5395d54947391cb79

MITRE ATT&CK TECHNIQUES

Vice Society actors have used ATT&CK techniques, similar to Zeppelin techniques, listed in Table 2.

Table 2: Vice Society Actors ATT&CK Techniques for Enterprise

Initial Access
Technique Title	ID	Use
Exploit Public-Facing Application	T1190	Vice Society actors exploit vulnerabilities in an internet-facing systems to gain access to victims’ networks.
Valid Accounts	T1078	Vice Society actors obtain initial network access through compromised valid accounts.
Execution
Technique Title	ID	Use
Windows Management Instrumentation (WMI)	T1047	Vice Society actors leverage WMI as a means of “living off the land” to execute malicious commands. WMI is a native Windows administration feature.
Scheduled Task/Job	T1053	Vice Society have used malicious files that create component task schedule objects, which are often mean to register a specific task to autostart on system boot. This facilitates recurring execution of their code.
Persistence
Technique Title	ID	Use
Modify System Process	T1543.003	Vice Society actors encrypt Windows Operating functions to preserve compromised system functions.
Registry Run Keys/Startup Folder	T1547.001	Vice Society actors have employed malicious files that create an undocumented autostart Registry key to maintain persistence after boot/reboot.
DLL Side-Loading	T1574.002	Vice Society actors may directly side-load their payloads by planting their own DLL then invoking a legitimate application that executes the payload within that DLL. This serves as both a persistence mechanism and a means to masquerade actions under legitimate programs.
Privilege Escalation
Technique Title	ID	Use
Exploitation for Privilege Escalation	T1068	Vice Society actors have been observed exploiting PrintNightmare vulnerability (CVE-2021-1675 and CVE-2021-34527) to escalate privileges.
Defense Evasion
Technique Title	ID	Use
Masquerading	T1036	Vice Society actors may attempt to manipulate features of the files they drop in a victim’s environment to mask the files or make the files appear legitimate.
Process Injection	T1055	Vice Society artifacts have been analyzed to reveal the ability to inject code into legitimate processes for evading process-based defenses. This tactic has other potential impacts, including the ability to escalate privileges or gain additional accesses.
Sandbox Evasion	T1497	Vice Society actors may have included sleep techniques in their files to hinder common reverse engineering or dynamic analysis.
Lateral Movement
Technique Title	ID	Use
Taint Shared Content	T1080	Vice Society actors may deliver payloads to remote systems by adding content to shared storage locations such as network drives.
Exfiltration
Technique Title	ID	Use
Exfiltration	TA0010	Vice Society actors are known for double extortion, which is a second attempt to force a victim to pay by threatening to expose sensitive information if the victim does not pay a ransom.
Impact
Technique Title	ID	Use
Data Encrypted for Impact	T1486	Vice Society actors have encrypted data on target systems or on large numbers of systems in a network to interrupt availability to system and network resources.
Account Access Removal	T1531	Vice Society actors run a script to change passwords of victims’ email accounts.

Mitigations

The FBI and CISA recommend organizations, particularly the education sector, establish and maintain strong liaison relationships with the FBI Field Office in their region and their regional CISA Cybersecurity Advisor. The location and contact information for FBI Field Offices and CISA Regional Offices can be located at www.fbi.gov/contact-us/field-offices and www.cisa.gov/cisa-regions, respectively. Through these partnerships, the FBI and CISA can assist with identifying vulnerabilities to academia and mitigating potential threat activity. The FBI and CISA further recommend that academic entities review and, if needed, update incident response and communication plans that list actions an organization will take if impacted by a cyber incident.

The FBI, CISA, and the MS-ISAC recommend network defenders apply the following mitigations to limit potential adversarial use of common system and network discovery techniques and to reduce the risk of compromise by Vice Society actors:

Preparing for Cyber Incidents

Maintain offline backups of data, and regularly maintain backup and restoration. By instituting this practice, the organization ensures they will not be severely interrupted, and/or only have irretrievable data.
Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure. Ensure your backup data is not already infected.
Review the security posture of third-party vendors and those interconnected with your organization. Ensure all connections between third-party vendors and outside software or hardware are monitored and reviewed for suspicious activity.
Implement listing policies for applications and remote access that only allow systems to execute known and permitted programs under an established security policy.
Document and monitor external remote connections. Organizations should document approved solutions for remote management and maintenance, and immediately investigate if an unapproved solution is installed on a workstation.
Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (i.e., hard drive, storage device, the cloud).

Identity and Access Management

Require all accounts with password logins (e.g., service account, admin accounts, and domain admin accounts) to comply with National Institute of Standards and Technology (NIST) standards for developing and managing password policies.
- Use longer passwords consisting of at least 8 characters and no more than 64 characters in length;
- Store passwords in hashed format using industry-recognized password managers;
- Add password user “salts” to shared login credentials;
- Avoid reusing passwords;
- Implement multiple failed login attempt account lockouts;
- Disable password “hints”;
- Refrain from requiring password changes more frequently than once per year unless a password is known or suspected to be compromised.
  Note: NIST guidance suggests favoring longer passwords instead of requiring regular and frequent password resets. Frequent password resets are more likely to result in users developing password “patterns” cyber criminals can easily decipher.
- Require administrator credentials to install software.
Require phishing-resistant multifactor authentication for all services to the extent possible, particularly for webmail, virtual private networks, and accounts that access critical systems.
Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts.
Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege.
Implement time-based access for accounts set at the admin level and higher. For example, the Just-in-Time (JIT) access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model). This is a process where a network-wide policy is set in place to automatically disable admin accounts at the Active Directory level when the account is not in direct need. Individual users may submit their requests through an automated process that grants them access to a specified system for a set timeframe when they need to support the completion of a certain task.

Protective Controls and Architecture

Segment networks to prevent the spread of ransomware. Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to—various subnetworks and by restricting adversary lateral movement.
Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting the ransomware, implement a tool that logs and reports all network traffic, including lateral movement activity on a network. Endpoint detection and response (EDR) tools are particularly useful for detecting lateral connections as they have insight into common and uncommon network connections for each host.
Install, regularly update, and enable real time detection for antivirus software on all hosts.
Secure and closely monitor remote desktop protocol (RDP) use.
- Limit access to resources over internal networks, especially by restricting RDP and using virtual desktop infrastructure. If RDP is deemed operationally necessary, restrict the originating sources and require MFA to mitigate credential theft and reuse. If RDP must be available externally, use a VPN, virtual desktop infrastructure, or other means to authenticate and secure the connection before allowing RDP to connect to internal devices. Monitor remote access/RDP logs, enforce account lockouts after a specified number of attempts to block brute force campaigns, log RDP login attempts, and disable unused remote access/RDP ports.

Vulnerability and Configuration Management

Keep all operating systems, software, and firmware up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Organizations should prioritize patching of vulnerabilities on CISA’s Known Exploited Vulnerabilities catalog.
Disable unused ports.
Consider adding an email banner to emails received from outside your organization.
Disable hyperlinks in received emails.
Disable command-line and scripting activities and permissions. Privilege escalation and lateral movement often depend on software utilities running from the command line. If threat actors are not able to run these tools, they will have difficulty escalating privileges and/or moving laterally.
Ensure devices are properly configured and that security features are enabled.
Disable ports and protocols that are not being used for a business purpose (e.g., RDP Transmission Control Protocol Port 3389).
Restrict Server Message Block (SMB) Protocol within the network to only access servers that are necessary, and remove or disable outdated versions of SMB (i.e., SMB version 1). Threat actors use SMB to propagate malware across organizations.

REFERENCES

Stopransomware.gov is a whole-of-government approach that gives one central location for ransomware resources and alerts.
Resource to mitigate a ransomware attack: CISA-Multi-State Information Sharing and Analysis Center (MS-ISAC) Joint Ransomware Guide.
No-cost cyber hygiene services: Cyber Hygiene Services and Ransomware Readiness Assessment.

REPORTING

The FBI is seeking any information that can be shared, to include boundary logs showing communication to and from foreign IP addresses, a sample ransom note, communications with Vice Society actors, Bitcoin wallet information, decryptor files, and/or a benign sample of an encrypted file.

The FBI, CISA, and the MS-ISAC strongly discourage paying ransom as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, the FBI and CISA urge you to promptly report ransomware incidents to a local FBI Field Office, or to CISA at report@cisa.gov or (888) 282-0870. SLTT government entities can also report to the MS-ISAC (SOC@cisecurity.org or 866-787-4722).

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. The FBI, CISA, and the MS-ISAC do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by the FBI, CISA, or the MS-ISAC.

Revisions

September 6, 2022: Initial Version

Source :
https://www.cisa.gov/uscert/ncas/alerts/aa22-249a

Teaming in Azure Stack HCI

As we’re deprecating the vSwitch attached to an LBFO team, this article introduces a new tool for converting your LBFO team to a SET team. To download this tool, run the following command or see the end of this article.

Install-Module Convert-LBFO2SET

Windows Server currently has two inbox teaming mechanisms with two very different purposes. In this article, we’ll describe several reasons why you should use Switch Embedded Teaming (SET) for Azure Stack HCI scenarios and we’ll discuss several long-held teaming myths – We’d love to hear your feedback in the comments below. Let’s get started!

In Windows Server 2012 we released LBFO as an inbox teaming mechanism, with many customers leveraging this technology to provide load-balancing and fail-over between network adapters. Since then, the rise of software-defined storage and software defined networking has brought performance and compatibility challenges to the forefront (outlined in this article) with the LBFO architecture that required a change in direction.

This new direction is called Switch Embedded Teaming (SET) and was introduced in Windows Server 2016. SET is available when Hyper-V is installed on any Server OS (Windows Server 2016 and higher) and Windows 10 version 1809 (and higher). You’re not required to run virtual machines to use SET, but the Hyper-V role must be installed.

In summary, LBFO is our older teaming technology that will not see future investment, is not compatible with numerous advanced capabilities, and has been exceeded in both performance and stability by our new technology (SET). We’d like to discuss why you should move off LBFO for virtualized and cloud scenarios. Let’s dig into this paragraph a bit.

LBFO is our older teaming technology that will not see future investment

thumbnail image 1 of blog post titled

Teaming in Azure Stack HCI

With the intent to bring software-defined technologies like SDNv2 and containers to Windows Server, it became clear that we needed an alternative teaming solution and so we set off creating SET, circa 2014. Simultaneously reaching feature parity and stability with LBFO took time; several early adopters of SET will remember some of these pains. However, SET’s stability, performance, and features have now far surpassed LBFO.

All new features released since Windows Server 2016 (see below) were developed and tested with SET in mind – This includes all Azure Stack HCI solutions you may have purchased; Azure Stack HCI is not tested or certified with LBFO. This is largely due to development simplicity and testing; without driving too far into unimportant details, LBFO teams adapters inside NDIS which is a large and complex component – its roots date back to Windows 95 (of course updated considerably since then). If your system has a NIC, you’re using NDIS. In the picture shown above, each component below the vSwitch was part of NDIS.

The size and complexity of scenarios included in NDIS made for very complex testing requirements that were only compounded by virtualized and software-defined technologies that considerably hampered feature innovation. You might think that this is just a Microsoft problem, but really this affects NIC vendor driver development time and stability as well.

All-in-all, we’re not focusing on LBFO much these days, particularly as software-defined Windows Server networking scenarios become more exotic with the rise of containers, software-defined networking, and much more. There’s a faster, more stable, and performant teaming solution, called Switch Embedded Teaming.

LBFO is not compatible with several advanced capabilities

Here’s a smattering of scenarios and features that are supported with SET but NOT LBFO:

Windows Admin Center – WAC is the de facto management tool for Windows Server and Azure Stack HCI, with millions of nodes under management. You can create and manage a SET team for a single host, or deploy a SET team to multiple hosts with the new Cluster Creation UI we released to help you deploy Azure Stack HCI solutions at Microsoft Ignite this year (watch the session, try it out, and give us feedback).

LBFO is not available for configuration in Windows Admin Center.

RDMA Teaming – Only SET can team RDMA adapters. RDMA is used for example with Storage Spaces Direct (S2D) which requires a reliable high bandwidth, low latency network connection between each node. High-bandwidth? Low Latency? That’s RDMA’s bag so it is the recommended pattern with S2D. Reliability? That’s SET’s claim-to-fame so these two are a logical pairing.

Guest RDMA: SET supports RDMA into a virtual machine. This doesn’t work with LBFO for two reasons:

RDMA adapters cannot be teamed with LBFO both host adapters and virtual adapters.
RDMA uses SMB multichannel which requires multiple adapters to balance traffic across. Since you can’t assign a vNIC to pNIC affinity with LBFO, neither the SMB nor non-SMB traffic can be made highly available.

Guest Teaming is a strange one; you could add multiple virtual NICs to a Hyper-V VM; inside the VM, you could use LBFO to team the virtual NICs. However, you cannot affinitize a virtual NIC (vNIC) to a physical NIC (pNIC), so it’s possible that both vNICs added in the VM are sending and receiving traffic out of the same pNIC. If that pNIC fails, you lose both of your virtual NICs.

SET allows you to map each vNIC to a pNIC to ensure that they don’t overlap, ensuring that a Guest Team is able to survive an adapter outage.

Microsoft Software Defined Networking – (SDN) was first released in its modern form in Windows Server 2016 and requires a virtual switch extension called the Virtual Filtering Platform (VFP). VFP is the brains behind SDN, the same extension that runs our public cloud, Azure. VFP can only be added to a SET team.

This means that any of the SDN features (which are included with a Datacenter Edition license) like the Software Load Balancer, Gateways, Distributed Firewall (ACLs), and our modern network QoS capability are also unavailable if you’re using LBFO.

Container Networking – Containers relies on a service called the Host Network Service (HNS). HNS also leverages VFP and as mentioned in the SDN section, VFP can only be added to a Switch Embedded Team (SET). For more information on Container Networking, please see this link.

Virtual Machine Multi-Queues – VMMQ is a critical performance feature for Azure Stack HCI. VMMQ allows you to assign multiple VMQs to the same virtual NIC without which, you rely on expensive software spreading operations (the OS spreads packets across multiple CPUs without hardware (NIC) assistance) that greatly increases CPU utilization on the host, reducing the number of virtual machines you can run.

Moreover, if your vNIC doesn’t get a VMQ, all traffic is processed by the default queue. With SET you can assign multiple VMQs to the default queue which can be shared as needed by any vNIC allowing more VMs to get the bandwidth they need.

In this video, you can see the performance (throughput) benefits of Switch Embedded Teaming over that of LBFO. The video demonstrates a 2x throughput improvement with SET over LBFO, while consuming ~10% additional CPU (a result of double the throughput).

Dynamic VMMQ – d.VMMQ won’t work either. Dynamic VMMQ is an intelligent queue scheduling algorithm for VMMQ that recognizes when CPU cores are overworked by network traffic and reassigns that network traffic processing to other cores automatically so your workloads (e.g. VMs, applications, etc.) can run without competing for processor time.

Here’s an example of some of the benefits of Dynamic VMMQ. In the video, you can see the host, spending CPU resources processing packets for a specific virtual NIC. When a competing workload begins on the system (which would prevent the virtual NIC from reaching maximum performance), we automatically tune the system by moving one of the workloads to an available processor.

RSC in the vSwitch is an acceleration that coalesces segments destined for the same virtual NIC into a larger segment.

Outbound network traffic is slimmed to fit into the mtu size of the physical network (default of ~1500 bytes). However, inbound traffic can be coalesced into one big segment. That one big segment takes far less processing than multiple small segments, so once traffic is received by the host, we can combine them and deliver several segments to the vNIC all at once. SET was made aware of RSC coalescing and supports this acceleration as of Windows Server 2019.

We’re continuing to improve this feature for even better performance in the next version of Windows Server and Azure Stack HCI by enabling RSC in the vSwitch to extend over the VMBus. In the video below, we show one VM sending traffic to another VM with the improved acceleration disabled – This is using only the original Windows Server 2019, RSC in the vSwitch capabilities.

Next we enable the Windows Server vNext improvements; throughput is improved by ~17 Gbps while CPU resourcing is reduced by approximately 12% (20 cores on the system). This type of traffic pattern is specifically valuable for container scenarios that reside on the same host.

LBFO has been exceeded in both performance and stability by SET

Note: Guest RDMA, RSC in the vSwitch, VMMQ, and Dynamic VMMQ belong in this category as well.

Certified Azure Stack and Azure Stack HCI solutions test only SET

If all that wasn’t enough, both Microsoft and our partners validate and certify their solutions on SET, not LBFO. If you bought a certified Azure Stack HCI solution from one of our partners OR a standard or premium logo’d NIC, it was tested and validated with Switch Embedded Teaming. That means all certification tests where run with SET.

Link Aggregation Control Protocol (LACP)

thumbnail image 2 of blog post titled

Teaming in Azure Stack HCI

Ok, so this one is a little counter-intuitive. LACP, allows for port-channels or switch-dependent teams to send traffic to the host over more than one physical port simultaneously.

For native hosts this means that every port in the port-channel can send traffic simultaneously – for the system on the right with 2 x 50 Gbps NICs, it looks like one big pipe with a native host potentially receiving 100 Gbps. Naturally, you’d expect that this capability could extend to virtual NICs as well.

But things change with virtualization. When the traffic gets to the host, the NICs need to interrupt multiple, independent processors to exceed what a single CPU core can process – This is what VMMQ does, and as mentioned, VMMQ does not work with LBFO.

LBFO limits you to a single VMQ and despite having (in the picture) 100 Gbps of inbound bandwidth, you would only receive about 5 Gbps per virtual NIC (or up to ~20 Gbps per vNIC at the painful expense of OS-based software spreading that could be used for running virtual machine workloads).

thumbnail image 3 of blog post titled

Teaming in Azure Stack HCI

With SET, switch-independent teaming, and the hardware assistance of VMMQ and enough CPUs in the system, you could receive all 100 Gbps of data into the host.

In summary, LACP provides no throughput benefits for Azure Stack HCI scenarios, incurs higher CPU consumption, and cannot auto-tune the system to avoid competition between workloads for virtualized scenarios (Dynamic VMMQ).

Asymmetric Adapters

While we’re myth-busting, let’s talk about adapter symmetry which describes the length to which adapters have the same make, model, speed, and configuration – SET requires adapter symmetry for Microsoft support. Usually the easiest way to identify this symmetry is by the device Interface Description (with PowerShell, use Get-NetAdapter). If the interface description matches (with exception of the unique number given to each adapter e.g. Intel NIC #1, Intel NIC #2, etc.) then the adapters are symmetric.

Prior to Windows Server 2016, conventional wisdom stated that you should use different NICs with different drivers in a team. The thinking was that if one driver had an issue, another team member would survive, and the team would remain up. This is a common benefit customers cite in favor of LBFO: it supports asymmetric adapters.

However, two drivers mean twice as many things can go wrong in fact increasing the likelihood of a problem. Instead, a properly designed infrastructure with symmetric adapters are far more stable in our review of customer support cases. As a result, support for asymmetric teams are no longer a differentiator for LBFO nor do we recommend it for Azure Stack HCI scenarios where reliability is the #1 requirement.

LBFO for management adapters

Some customers I’ve worked with have asked if they should use LBFO for management adapters when the vSwitch is not attached – Our recommendation is to always use SET whenever available. A management adapter’s goal in life is to be stable and we see less support cases with SET.

To be clear, if the adapter is not attached to a virtual switch, LBFO is acceptable however, you should endeavor to use SET whenever possible due to the support reasons outlined in this article.

vSwitch on LBFO Deprecation Status

Recently, we publicly announced our plans to deprecate the use of LBFO with the Hyper-V virtual switch. Moving forward, and due to the various reasons outlined in this article, we have decided to block the binding of the vSwitch on LBFO.

Prior to upgrading from Windows Server 2019 to vNext or if you have a fresh install of vNext, you will need to convert any LBFO teams to a SET team if it’s attached to a Hyper-V virtual switch. To make this simpler, we’re releasing a tool (available on the PowerShell gallery) called Convert-LBFO2SET.

You can install this tool using the command:

Install-Module Convert-LBFO2SET

Or for disconnected systems:

Save-Module Convert-LBFO2SET -Path C:\SomeFolderPath

Please see the wiki for instructions on how to use the tool however here’s an example where we convert a system with 10 host vNICs, 10 generation 1 VMs, and 10 generation 2 VMs.

Summary

LBFO remains our teaming solution if you are running your workloads on bare metal servers. If however, you are running virtualized or cloud scenarios like Azure Stack HCI, you should give Switch Embedded Teaming serious consideration. As we’ve described in this article, SET has been the Microsoft recommended teaming solution and focus since Windows Server 2016 as it brings better performance, stability, and feature support compared to LBFO.

Are there other questions you have about SET and LBFO? Please submit your questions in the comments below!

Thanks for reading,

Dan “All SET for Azure Stack HCI” Cuomo

Source :
https://techcommunity.microsoft.com/t5/networking-blog/teaming-in-azure-stack-hci/ba-p/1070642

UniFi – Console and Gateway Recovery Mode

The Recovery Mode User Interface (UI) is a special interface for UniFi OS Consoles (UDMP, UNVR, etc.) and gateways used to recover from various failure modes (indicated on the LCM screen of that device). From the Recovery Mode, you can perform the following actions:

Reset to Factory Defaults: Completely reset the device. Note this will also wipe out any stored backup files.
Reboot: Restart the device and re-load the existing configuration.
Power-off: Initiate a software shutdown on the device, after which you can safely remove the power cable.
Check Filesystems: Check the integrity of the file system.
Firmware Update: Upload a previously downloaded firmware image (.bin) file in order to upgrade the firmware.

You should only resort to using recovery mode if you are prompted by the LCM screen found on your device.

Performing a Device Recovery

Download the most recent firmware for your device. You can find information on our latest releases here.
Completely power-off the UniFi device and unplug it from its power source.
Press and hold the reset button and then power on the device by connecting it to the power source once again.
Keep the reset button pressed for about 5 seconds. After some time the display (in supported models) will indicate that the gateway is in Recovery Mode.
Connect an Ethernet cable from your computer to the first LAN port (port 1) on the UniFi gateway.

Note: Port 1 is always the first one. Either the top port, or the top left corner one, depending on the layout of your device’s ports.
Configure a static IP address on your computer in the 192.168.1.0/24 range (for example 192.168.1.11). Windows ClientmacOS clientNote: If a wireless adapter is enabled and connected to another network it could conflict with the connection to the UniFi device. Disable the wireless adapter if necessary.
Open a compatible web browser navigate to http://192.168.1.30 to access the Recovery Mode UI.

Note: The Recovery Mode UI is accessible via HTTP only and not HTTPS. It is possible that your browser will automatically try to redirect your session to HTTPS. Make sure to navigate to the http://192.168.1.30 address and use a different browser if necessary.
Select Firmware Update > Choose and browse your computer for the previously download firmware (.bin) image file.
Wait for the upgrade process to complete and reboot the device afterwards.

Source :
https://help.ui.com/hc/en-us/articles/360043360253-UniFi-Console-and-Gateway-Recovery-Mode

UniFi – Login with SSH (Advanced)

We do not recommend using SSH unless instructed by one of our Support Engineers as part of advanced troubleshooting. Inexperienced users risk making changes that may degrade network performance, or even worse, completely break your deployment. Proceed with caution.

Requirements

1. You are connected to the same local network as the device/console you plan to connect with via SSH. This may consist of using a laptop connected to the same WiFi network, or hardwired directly to the device.

2. SSH is enabled. UniFi Network devices and UniFi OS Consoles have independent SSH settings.

UniFi OS Consoles – Following setup, SSH is automatically disabled. It must be enabled in your UniFi OS System Settings.
UniFi Network Devices – Following setup, SSH is automatically enabled. The credentials consist of a random string of characters.

3. The device you are using has a command line interface (CLI) capable of establishing a Secure Shell (SSH) connection. Linux and macOS devices can use their native terminal. Windows OS requires PowerShell or PuTTY.

Establishing an SSH Connection

The format of the command used to establish an SSH connection is as follows:

ssh <username>@<ip-address>

The <username> for UniFi OS Consoles (UDM Pro / UNVR / Cloud Key) and UniFi Gateways (UXG Pro) is always ‘root’. For example, a Dream Machine Pro (gateway) with an IP address of 192.168.1.1 can be accessed as follows:

ssh root@192.168.1.1

Note: The UXG will use <username> = ‘root’, but the <password> will be the shared password set in your UniFi Network Application.

Default Credentials

Prior to setup/adoption, devices have a set of default credentials.

UniFi OS Consoles – root / ubnt
UniFi Gateways – root / ubnt
UniFi Devices – ubnt / ubnt

Source :
https://help.ui.com/hc/en-us/articles/204909374-UniFi-Login-with-SSH-Advanced-

UniFi – Advanced Updating Techniques

We recommend that most users enable automatic updates. Doing so allows you to specify when your UniFi deployment automatically checks for and installs updates.

UniFi OS Console and application update preferences can be configured in your UniFi OS Settings. Please note, though, that self-hosted UniFi Network applications do not offer automatic updating.

UniFi Network device update preferences are set in your Network application’s System Settings. Devices managed by other UniFi applications are automatically updated within their respective applications.

Manually Update UniFi Devices via Web Application

Updating via the Device Property Panel

Use Case: You want to try Early Access firmware releases for specific devices, or you want to return to an official release after trying an EA release.

1. Copy the firmware release link from community.ui.com/releases.

2. Paste the link in the address bar found in the Settings tab of the device’s properties panel.

Updating via Your Network Cache

Use Case: You prefer to download and store updates in your Network application so they can be used by other devices, as opposed to downloading multiple, device-specific files from the internet. This is an ideal solution for reducing bandwidth within high-volume networks that host a large number of similar UniFi devices. It is also suitable for the advanced users who disable internet access on their UniFi device’s management network.

Device updates can be cached in your Network application’s System Settings. Once an update is cached, you can open to your UniFi Devices page and click Update Available.

Note: The Cache link will appear when you hover your cursor over an update.

Updating via SSH

Note: SSH updating is not a typical or recommended method. It is only prescribed to work around specific scenarios, such as when:

Prior traditional update attempts have failed. A successful SSH update will help verify if initial failures resulted from incorrect network configuration. For more details, see Troubleshooting Device Updates.
Your UniFi Network device is not being discovered or cannot be adopted because it has been preloaded with outdated firmware.
Your UniFI OS Console cannot be set up because it has been preloaded with an outdated version of UniFi OS.

UAP/USW (Internet)

Copy the update link from community.ui.com/releases.
SSH into your device.
Run the following command:upgrade paste_download_link_here Exupgrade https://dl.ui.com/unifi/firmware/UAL6/5.60.1.12923/BZ.mt7621_5.60.1+12923.210416.1641.bin

UAP/USW (No Internet)

Download the desired firmware update from community.ui.com/releases.
Use the following SCP command to copy the file into the /tmp folder of your device. This requires a compatible SCP application (e.g., Terminal on macOS and Linux, PuTTY/PowerShell on Windows).scp /folder_path/firmwarefile.bin <user>@<IP of device>:/tmp/fwupdate.binExscp /Users/alexpro/Desktop/BZ.mt7621_5.60.1+12923.210416.1641.bin Alex@192.168.1.219:/tmp/fwupdate.bin
Enter your SSH password when prompted.
Run the following command:syswrapper.sh upgrade2 &

UDM/UDM Pro/UXG Pro (Internet)

Copy the update link from community.ui.com/releases.
SSH into your device.
Run the following command:ubnt-upgrade paste_download_link_here Exubnt-upgrade https://fw-download.ubnt.com/data/udm/7675-udmpro-1.12.22-36b5213eaa2446aca8486f0b51e64cd3.bin

UDM/UDM Pro/UXG Pro (No Internet)

Download the desired firmware update from community.ui.com/releases.
Use the following SCP command to copy the file into the /mnt/data folder of your device. This requires a compatible SCP application (e.g., Terminal on macOS and Linux, PuTTY/PowerShell on Windows).scp /folder_path/firmwarefile.bin <user>@<IP of device>:/mnt/data/fwupdate.binExscp /Users/alexpro/Desktop/7675-udmpro-1.12.22-36b5213eaa2446aca8486f0b51e64cd3.bin Alex@192.168.1.219:/mnt/data/fwupdate.bin
Enter your SSH password when prompted.
Run the following command:ubnt-upgrade /mnt/data/fwupdate.bin

UCK G2, UCK G2 Plus, UDM SE, UDR, UDW, UNVR, UNVR Pro (Internet)

Copy the update link from community.ui.com/releases.
SSH into your device.
Run the following command:ubnt-systool fwupdate paste_download_link_here Exubnt-systool fwupdate https://fw-download.ubnt.com/data/unifi-dream/dd49-UDR-2.4.10-cd3afa000ebf4a4fb15374481539961c.bin

UCK G2, UCK G2 Plus, UDM SE, UDR, UDW, UNVR, UNVR Pro (No Internet)

Download the desired firmware update from community.ui.com/releases.
Use the following SCP command to copy the file into the /tmp folder of your device. This requires a compatible SCP application (e.g., Terminal on macOS and Linux, PuTTY/PowerShell on Windows).scp /folder_path/firmwarefile.bin <user>@<IP of device>:/tmp/fwupdate.binExscp /Users/alexpro/Desktop/dd49-UDR-2.4.10-cd3afa000ebf4a4fb15374481539961c.bin
Enter your SSH password when prompted.
Run the following command:ubnt-systool fwupdate /tmp/fwupdate.bin

USG (Internet)

Copy the update link from community.ui.com/releases.
SSH into your device.
Run the following command:upgrade paste_download_link_here Exupgrade https://dl.ui.com/unifi/firmware/UGW3/4.4.56.5449062/UGW3.v4.4.56.5449062.tar

USG (No Internet)

Download the desired firmware update from community.ui.com/releases.
Rename the file: upgrade.tar
Use the following SCP command to copy the file into the /home/<user> folder of your USG. This requires a compatible SCP application (e.g., Terminal on macOS and Linux, PuTTY/PowerShell on Windows).scp /folder_path/upgrade.tar <user>@<IP of device>:/home/<user>/upgrade.tarExscp /Users/alexpro/Desktop/upgrade.tar Alex@192.168.1.1:/home/Alex/upgrade.tar
Enter your SSH password when prompted.
SSH into your device.
Run the following command:sudo syswrapper.sh upgrade upgrade.tar

Manually Update the Network Application

Download the desired application update from community.ui.com/releases.
SSH into your device.
Run the following command (UDM/UDM Pro Only):unifi-os shell
Remove previously installed files:rm /tmp/unifi_sysvinit_all.deb &> /dev/null
Store the new application version on your device using the download link:curl -o “/tmp/unifi_sysvinit_all.deb” <network application link.deb>Excurl -o “/tmp/unifi_sysvinit_all.deb” https://dl.ui.com/unifi/6.2.26-a79cb15f05/unifi_sysvinit_all.deb
Once downloaded, install the new version:apt-get install -y /tmp/unifi_sysvinit_all.deb
Following installation, remove the downloaded file:rm /tmp/unifi_sysvinit_all.deb

Updating Devices in a Broken State

In rare occurrences, a device may stop functioning. UniFi APs may be updated using our TFTP Recovery. This should only be used if your AP completely stops functioning as a last resort prior to submitting an RMA. UniFi OS Consoles and gateways my be updated using Recovery Mode. This should only be used if prompted on your device’s LCM screen.

Source :
https://help.ui.com/hc/en-us/articles/204910064-UniFi-Advanced-Updating-Techniques

UniFi – Getting Support Files and Logs

It may be necessary to provide support files to our team when troubleshooting issues. These contain detailed logs and information about what is happening with your UniFi system. Although sensitive information is generally removed, we do not recommend sharing these publicly.

There are two support files to be aware of:

UniFi OS Support File: This contains logs related to your UniFi OS Console, the installed applications, your adopted UniFi devices, and the client devices connected.
Navigating to unifi.ui.com (or signing in locally via IP address) > select your UniFi OS Console > Console Settings > Download Support File. Note that it will have a *.tgz extension.
UniFi Network Support File: This only contains information about your UniFi Network application, your adopted UniFi Network devices, and the connected clients. This should only be used if you are self-hosting the UniFi Network application on a Windows, macOS or Linux machine.
Navigate to your UniFi Network Application > Settings > System > Download Network Support File. Note that it will have a *.supp extension.

Advanced

If the UOS Console or UniFi applications are inaccessible and you are not able to download the support file, you can download the logs by following these instructions. Please note, our support engineer will provide detailed information on which of the following will be required for troubleshooting.

1. SSH into the machine: ssh root@192.168.1.1

Note: If you need to change your SSH password, do so in the UniFi OS Settings, by navigating to unifi.ui.com (or signing in locally via IP address) > select your UniFi OS Console > Settings > System.

2. Create ZIP files for the logs. The commands’ format will be: tar -zcvf <file name> <folders path>.

UniFi OS logs: tar -zcvf unifi-core-logs.tar.gz /data/unifi-core/logs/
UniFi local portal (ULP) logs: tar -zcvf ulp-go-logs.tar.gz /data/ulp-go/log/
UniFi Network logs:
- For UniFi Dream Machine consoles:tar -zcvf unifi-logs.tar.gz /data/unifi/logs/
- For UniFi Cloud Key Gen2 consoles:tar -zcvf unifi-logs.tar.gz /usr/lib/unifi/logs
UniFi Protect logs:
- Without external disks: tar -zcvf unifi-protect-logs.tar.gz /data/unifi-protect/logs/
- With external disks: tar -zcvf unifi-protect-logs.tar.gz /srv/unifi-protect/logs/
UniFi Talk logs:
- tar -zcvf unifi-talk-logs.tar.gz /var/log/unifi-talk/
- tar -zcvf unifi-talk-base-logs.tar.gz /var/log/unifi-base/
- tar -zcvf unifi-talk-freeswitch-logs.tar.gz /var/log/freeswitch/
UniFi Connect logs: tar -zcvf unifi-connect-logs.tar.gz /data/unifi-connect/log/
System logs:
- ubnt-systool support /tmp/system
- tar zcvf system.tar.gz /tmp/system

3. Open a new terminal window and run the SCP command to copy the logs from the UniFi OS Console and onto your computer (or system).

Note: The period (.) in the path variable means it will be copied onto the currently opened directory in the terminal. And the asterisk (*) stands for “all”. So the following command will copy everything with the extension tar.gz (i.e. all the logs you prepared in Step 2).

scp root@192.168.1.1:/root/\*.gz .

4. Close both terminal windows to close the sessions.

If other logs are needed, our support agent will guide you and provide the necessary commands.

Source :
https://help.ui.com/hc/en-us/articles/360049956374-UniFi-Getting-Support-Files-and-Logs

UniFi Network – Updating Third-Party, non-Console UniFi Network Applications (Linux – Advanced)

This article provides the steps to update the UniFi Network application to the current stable release on a Debian or Ubuntu system via APT (Advanced Package Tool). If you run into issues following the process described in this article, please take a look at the scripts provided in this Community post that includes UniFi Network software installation on Ubuntu 18.04 and 16.04 and Debian 8/9.

Requirements

In order to update the UniFi Network application via APT, it is necessary to create source files or edit lines in an existing sources.list file with Linux text editors: vi or nano. The repo structure should be permanent, but if there are any changes they will be pointed out in the UniFi Network software version release posts, found in the Release section of the Community.

Before upgrading the UniFi Network application, make sure that you have backed up the UniFi Network Database. You will need to make sure that the user has sudo permissions. For more information about adding a user to sudo list, see this Debian article.

UniFi Network APT Steps

1. Install required packages before you begin with the following command:

sudo apt-get update && sudo apt-get install ca-certificates apt-transport-https

Click to copy

2. Use the following command to add a new source list:

echo 'deb https://www.ui.com/downloads/unifi/debian stable ubiquiti' | sudo tee /etc/apt/sources.list.d/100-ubnt-unifi.list

Click to copy

3. Add the GPG Keys. To add the GPG Keys use one of the two methods described below (Method A is recommended). When using the commands below, it is assumed you have sudo and wget installed, more information about sudo can be found here, and wget here.

User Tip: For Ubuntu 18.04, run the following commands before installing UniFi in step 4.

wget -qO - https://www.mongodb.org/static/pgp/server-3.4.asc | sudo apt-key add -
echo "deb https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list
sudo apt-get update

Click to copy

See an example of what scripts the Community is using to install the UniFi Network application on Ubuntu 16.04 and 18.04 in this Community post.

(Method A) Install the following trusted key into /etc/apt/trusted.gpg.d

sudo wget -O /etc/apt/trusted.gpg.d/unifi-repo.gpg https://dl.ui.com/unifi/unifi-repo.gpg

Click to copy

(Method B) Using apt-key.

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 06E85760C0A52C50

Click to copy

4. Install and upgrade the UniFi Network application.

Note: On some Distributions, it’s possible an incompatible Java release can be installed during this step. We recommend running the following command before proceeding with this step, to restrict Ubuntu from automatically installing Java 11. If you wish to undo this later, replace “hold” with “unhold”.

sudo apt-mark hold openjdk-11-*

Install and upgrade the UniFi Network application with the following command:

sudo apt-get update && sudo apt-get install unifi -y

Click to copy

5. This step may not be required, depending on the Linux distro you have. If your distro does not come with MongoDB, and it’s not available in their repo, then please see the MongoDB installation guide. You can find the latest installation guide for Ubuntu here, and Debian here. We recommend at least MongoDB 2.6.10. Some users have changed the backend to use MongoDB 3 successfully too.

6. The UniFi Network application should now be accessible at the computer’s configured local or public IP address, by typing that IP address in a browser’s navigation bar (Chrome is recommended). If it is not launching, use the following command: sudo service unifi start.

Other helpful commands are:

To stop the UniFi service: sudo service unifi stop
To restart the UniFi service: sudo service unifi restart
To see the status of UniFi service: sudo service unifi status

We strongly recommend staying with the stable release, but for those users who wish to do otherwise, click here to expand and see possible suite names, as well as code names in the table within.

Log Files Location

Log files will be essential for any troubleshooting you might perform. Find them here:

/usr/lib/unifi/logs/server.log
/usr/lib/unifi/logs/mongod.log

If your application is running on a Unix/Linux based system, then you will require superuser (sudo) privileges to access these log files.

User Notes & Tips

These notes have been added thanks to user collaboration. Click to expand.

Source :
https://help.ui.com/hc/en-us/articles/220066768-UniFi-Network-Updating-Third-Party-non-Console-UniFi-Network-Applications-Linux-Advanced-

UniFi Network – Updating Third-Party, non-Console UniFi Network Applications

We recommend hosting your Network Application on a UniFi OS Console for the most seamless updating experience. In addition to providing the ability to toggle automatic Network Application updates, you can also initiate manual updates through the GUI.

Updating the Network Application

Updating your Network Application is very similar to the initial setup. You can download the latest version here.

You will be required to close any running instances of the Network Application prior to the installation. Do not worry, your network will still continue to function as normal (devices will remain connected with internet access, and traffic will continue to be routed).

After executing the file, the setup wizard will guide you through the process of updating your application. We always recommend downloading a backup file, found in your System Settings.

Note: macOS users may be required to move the downloaded file into the Applications folder, or right-click > open the file in order to begin the installation.

(Advanced) Updating via CLI on Linux-hosted Applications

It is also possible to use APT for managing updates on Debian and Ubuntu based installations. You may refer to this article for more details. This should only be attempted by users with appropriate knowledge of Linux.

Source :
https://help.ui.com/hc/en-us/articles/6330410381335-UniFi-Network-Updating-Third-Party-non-Console-UniFi-Network-Applications

UniFi Network – Self-Hosting your UniFi Network Without a Console (Advanced)

We strongly recommend that users opt for a UniFi OS Console instead of self-hosting the Network Application on third-party operating systems.

Self-hosting the UniFi Network application on a home computer or 3rd party virtual machine (VM) requires extensive knowledge of computer engineering, networking, and security. Invalid host specifications or configurations may lead to system crashes, poor performance, and compromised network security.

A UniFi OS Console, on the other hand, takes all the guessing out of the picture as it is already optimized for running all of our UniFi Applications. It is also a significantly more secure solution for remote access, as this is hosted on your physical premises, as opposed to a third-party virtual machine in the cloud.

Note: Although a UI SSO account is required for remote access, it is possible to setup and use UniFi OS Consoles as local-only devices without the need for an SSO account.

For advanced users hoping for a scalable cloud-hosting approach, we also offer our own UniFi OS Cloud Console.

Configuration of third-party hosts is outside of Ubiquiti’s official support scope. If you still wish to self-host the UniFi Network Application, please be aware of the risks and proceed with caution.

Download and install the UniFi Network Application

The UniFi Network Application may be downloaded for Microsoft Windows, macOS, and Linux from this page. The Network application is provided as a simple installer for Microsoft Windows and macOS hosts.

For Linux, a .deb file is provided. This can be installed using the dpkg command on Debian or Ubuntu.

After installing the UniFi Network Application, you may launch it and follow the instructions to complete setup. You can access the configuration page by typing https://<IP_of_Network_Application_host>:8443 into the navigation bar of a browser while the application is running.

Frequently Asked Questions

What are the UniFi Network application system requirements?
At a bare-minimum, we recommend the following system requirements (make sure to read the Release Notes for more details about a particular version):

Operating system:
- Linux: Ubuntu Desktop / Server 16.04; Debian 9 “Stretch”
- Windows: Windows 10; Windows Server 2016
- macOS: Mavericks 10.9, 10.10 Yosemite, 10.11 El Capitan, 10.12 Sierra, 10.13 High Sierra, 10.14 Mojave, 10.15 Catalina.
CPU: x86-64 Processor (Intel / AMD x64 Processors)
RAM: 2GB
Network: 100Mbps Wired Ethernet
HDD: Minimum 10GB free (20GB or more preferred)
Java: Java Runtime Environment (JRE) 8
Web Browser: Google Chrome
MongoDB: version 3.2 or later. Mongo is offered bundled: default is 2.4.14 (for macOS and Windows only).

Note: You will need to continually increase your system specs as you begin to adopt and manage more devices.

Does the UniFi Network application have to run at all times?
Although this is not required, we strongly recommend running the UniFi Network Application at all times. This enables you to configure your system at all times. It is also a requirement for proper statistics and reporting.

I’m getting a Java-related error during setup, what do I do?
The UniFi Network application requires Java, so you’ll need to install Java 8 for your specific platform before re-running the installer.

The install is not finishing successfully, what could it be?
Make sure that all system requirements above are met and that all ports used by UniFi are opened.

I’m getting a “Your connection is not private” security warning when accessing the UniFi Network Application in my browser, should I be concerned?
No, there is nothing to worry about. Simply proceed to the next page by clicking Advanced > Proceed.

Source :
https://help.ui.com/hc/en-us/articles/360012282453-UniFi-Network-Self-Hosting-your-UniFi-Network-Without-a-Console-Advanced-

UniFi Network – Understanding and Implementing Minimum RSSI

This article explains what Minimum RSSI is and how to configure it in the UniFi Network application. We only recommend using this if you are familiar with basic RF theory as misconfiguration may result in performance degradation of your network.

How Minimum RSSI works

Received Signal Strength Indication (RSSI) is a value indicating the perceived signal level of a wireless client from the AP’s perspective. The Minimum RSSI value is set individually on each AP and indicates the minimum signal level required for a client to remain connected.

The main purpose of this is to assist with a client’s roaming between two nearby APs. It prevents a device getting “stuck” connected to the initial AP at a weaker signal strength as opposed to roaming to a new AP that may be more optimal. Once the signal drops below the Minimum RSSI value set, the initial AP will kick the client so that it can reconnect to the new AP.

Once an AP kicks a client (by sending a de-authentication packet), it is up to the client to find a better AP to connect to. It may connect back to the same AP, especially if it is the only one within range. Since the signal strength still does not meet the Minimum RSSI, it will again be booted. Improper tuning can thus result in network instability. For this reason, it is important to realize that there is no one size fits all and you should carefully test your configuration to avoid introducing connectivity problems.

How to determine and configure Minimum RSSI

Minimum RSSI is can be enabled within the UniFi Network Application by selecting an AP in UniFi Devices and then navigating to Settings in the side-panel of the selected device. Once enabled, this can be manually set for your 2G and 5G radios independently.

You can view the Signal Strength for your current wireless clients by clicking on a device in the Client Devices tab. The signal is measured in units of dbm (decibels per milliwatt). You will notice that this is a negative number because the power is less than 1 mW:

dbm = 10 log P₁/1mW
0 dBm = 1 mW
-10 dBm = 0.1 mW
-20 dBm = 0.01 mW, and so forth

A value close to 0 indicates high signal quality, whereas a larger negative value indicates poor signal quality. Remember, you need to granularly select the appropriate value for each AP and avoid using a single value everywhere.

Other Considerations

There are many factors that can affect the a client’s RSSI at the AP side including distance, building materials, objects, interference, etc. As much as we would love to give a recommendation, it really isn’t this simple. It’s safe to say -80dBm would be a starting point for standard home or office configurations, but there are too many environmental variables so you should have caution at all times.

The best method to determine appropriate Minimum RSSI values is to perform a site survey. This can be done by testing the signal strength of various wireless clients at different distances. Each device will have different antenna configurations and will thus perform differently in the same geographic location. You want to connect to an SSID, make it specific to that AP (an override on that SSID), and then roam to what you would consider the outer edge of the desired coverage area. Mark the client’s RSSI, and then take a couple more points. The more data you gather, the better idea you’ll get for the minimum RSSI value to use.

Source :
https://help.ui.com/hc/en-us/articles/221321728-UniFi-Network-Understanding-and-Implementing-Minimum-RSSI