Troubleshooting Device Adoption across Networks
Getting a UniFi device adopted is usually a plug-and-play job. You connect an AP, switch, or gateway, it gets an IP, the UniFi controller spots it, and with one click, you’re done. But when things don’t go smoothly, and they often don’t when dealing with remote sites, VLANs, or legacy gear, you need to dig deeper.
This guide breaks down the most common adoption problems and how to fix them. Whether you're setting up APs in a new branch office or helping someone adopt a switch from a remote home office, this is your roadmap to getting everything talking to the controller.
Let's dive in !!
Before we dive in, please don't self-host your UniFi Controller if you take care of client networks. Sooner or later this will cause issues! It's fine for home users, but definitely not recommended for IT service businesses and MSPs. If you want secure, reliable and a scalable hosting solution check out UniHosted.
why device adoption can go wrong
Device adoption is about trust. The device has to find the controller, accept its authority, and pull in the right config. That means discovery protocols, proper firmware, DNS resolution, SSH access, and often, clean networking.
Things go wrong when:
- The device can't find the controller
- Credentials mismatch
- Network firewalls block communication
- The device still remembers an old controller
- Firmware is too outdated
If any of those puzzle pieces are missing, adoption can hang, fail silently, or cause devices to endlessly cycle between “adopting” and “disconnected.”
symptom: device doesn’t appear in controller
Fix: check network basics first.
- Is the device plugged in?
- Is it receiving PoE (check LED lights)?
- Did it get an IP from DHCP?
Run a network scan (like arp-scan or a discovery tool) to confirm the device is actually online.
If it's a remote device, you'll need Layer 3 adoption, meaning the device and the controller are on different subnets or even separate networks.
Use this command via SSH:
set-inform http://<controller-ip>:8080/inform
Make sure that IP is publicly reachable or routed correctly across your VPN.
symptom: device appears, but won’t adopt
You’ll often get stuck in “Adopting...” status, or get repeated SSH credential prompts.
Here’s what to try:
-
Use default credentials:
ubnt / ubnt -
If those fail, reset the device with the button or SSH:
bash
syswrapper.sh restore-default -
Then SSH back in and use:
bash
set-inform http://<controller-ip>:8080/inform
Watch the logs in the controller. They’ll often tell you what’s failing, credentials, timeout, or incompatible firmware.
symptom: device reverts to old controller
This happens when:
- The device still has old inform settings from a previous network
- A DHCP Option 43 or DNS override keeps pointing it back
Here’s what to do:
- Factory reset the device
- Remove old DHCP settings (on router or firewall)
- Delete DNS entries pointing
UniFito an old IP - Run
set-informagain
Tip: Run set-inform twice. First time tells the device where to go, second time confirms and saves it.
symptom: adoption stuck in “adopting” or “updating”
This is often a firewall issue.
UniFi devices talk over:
- TCP 8080 (controller communication)
- TCP 8443 (HTTPS controller UI)
- UDP 10001 (discovery)
- TCP 22 (SSH)
Make sure all of these are open and not blocked by an edge firewall or router. Also check that no deep packet inspection (DPI) features are interfering, some ISPs or firewalls do that silently.
If you're using a VPN to connect remote sites, test direct connectivity to the controller with a simple ping or curl command from the remote subnet.
when adoption fails silently
Sometimes devices just don’t respond, no error, no adoption, no logs.
This usually points to:
- Corrupt firmware: try updating manually via TFTP or SSH
- Bad flash memory: in which case, you might need to RMA
- Multiple DHCP servers: the device got an IP, but on the wrong network
Use a packet sniffer like Wireshark on your controller’s interface. Look for inform requests (/inform on TCP 8080) and see where they’re going.
building adoption-friendly networks
If you’re working in environments where devices might be moved around, branch offices, home users, new site rollouts, it helps to build adoption into the process.
Here’s what works:
use DHCP Option 43
Set it to your controller’s IP so every UniFi device on that subnet knows where to go.
use DNS alias
Create a DNS A-record called UniFi that points to your controller’s IP. That’s what UniFi devices use by default.
use a hosted UniFi Controller
A cloud-based controller makes adoption easier across locations. Devices can adopt from anywhere with internet. That’s what we handle at UniHosted, devices plug in, show up, and you click “Adopt.”
automation and tools
For larger rollouts:
- UniFi Network App – lets you adopt from mobile
- UniFi Site Manager – great for MSPs or multi-location
- set-inform scripts – useful when deploying batches of APs
You can even bake set-inform into your imaging scripts if you’re deploying dozens of devices to new locations.
adoption case: remote employee Wi-Fi
A client shipped a U6-Lite to an employee’s home. It never adopted.
They plugged it in. Device had power, was online, but didn’t appear in controller.
Turns out:
- The device got an IP, but the home router blocked outbound TCP 8080.
- Once they added a firewall rule to allow 8080 out, adoption completed.
- After that, policies and Wi-Fi settings were pushed without a hitch.
worst case: firmware mismatch
Some older devices (like UAP-AC-Lite) ship with very old firmware. That version can’t talk to modern controllers.
If adoption always fails and you’re sure everything else is good, SSH in and run:
info
Check the firmware version. If it’s older than 3.x, download the latest .bin and use:
upgrade http://<your-server>/firmware.bin
Once updated, reset again and re-attempt adoption.
future-proofing adoption
If you want a setup that just works:
- Use UniFi Dream Machines at satellite sites
- Keep one hosted controller to adopt all gear
- Assign static IPs to gateways or key switches
- Document MAC addresses and deployment dates
- Use DNS or DHCP options to centralize adoption
This setup makes scaling painless. You’ll plug in a new AP, wait 60 seconds, and see it appear in your dashboard—ready to go.
conclusion
Device adoption problems happen. But with the right tools and a repeatable approach, they stop being frustrating and start being just another quick fix.
If you’re managing multiple sites, or shipping APs to remote staff, hosted controllers save you tons of time. We do this at Unihosted all day, adopting remote APs, fixing inform issues, and automating network onboarding.