Anyway, if you just have devices in UCRM there should be no hassle. Similarly, when you have devices in UCRM and in UNMS as well, and everything is configured correctly. Otherwise, there will be a migration wizard helping you solve the ambiguous items (for example: when a service device in UCRM is used as Site device in UNMS) - but if you don't have such "errors" in your current UCRM, UNMS, then the whole migration will be done in a single click.
Tuesday - last edited Tuesday
Are you suggesting I should stop adding a service device to a UCRM client if it's also a Site device in UNMS? As a general rule, our CPE's are just that, but at a number of sites, we offer service to the owner of the "grounds" and rather than do a wireless link up to the tower I just pull one ethernet port off one of the site routers.
I always assign 2 IP addresses to the site device then, one for management and one for the customer access. So I can track usage in UCRM and block access if they don't pay.
I can stop doing that and come up with a work around now but what about the setups out there already? You mention that this kind of deal is an "error" in UCRM/UNMS setup but the migration wizard will help me solve them. Does that mean the software will be able to conform to my network design or that the wizard will help me conform my network to the software design?
Either way I'm more than ready to try it out. If I need to conform my network, then I'd like to get started on that now in preparation.
- Of course, you can connect your clients via cable, no wireless needed.
- When you connect a client to the "Site Router" (as you named it), I assume you put this router under the Site (not under the Client)
- The client has their own device and this device should be marked as a client device (not that router)
Maybe I am missing something, but I don't understand why you need to consider the Site Router as the client's device. The client must use another device, connected to that router, right? Moreover, I assume the router is used to connect other clients, so obviously it can't be considered as "client's service device", it's site device.
Anyway, you can still use the migration but such client services will be skipped and you can later fix them manually. (Btw, there will be also a "force mode", which creates all the clients again in UNMS and creates the clients' devices or pulls the existing ones - even from existing Sites, but in your case, this is probably not what you want if most of your current UNMS data is ok)
Maybe I am missing something...
Yeah, sorry, you were missing something I forgot to add.
Unless a client specifically requests wired ports, our standard install is a single Unifi Mesh AP (the little outdoor one) inside the clients house. So most of our clients are CPE + Unifi, and then that leaves these wired clients in UNMS with nothing. Because they are wired into a "Site" device and UNMS doesn't see Unifi, at this point anyway.
What I can do, since these instances are few, is just create a pseudo device in UNMS until there is some Unifi recongition. I've done that before and it works well. We serve a business where we colocated our core gear in their rack, so again, we just gave them a demarc port on our core router. I created a pseudo router for their account and it makes it work nicely.
You answered my questions, thank you.
1. Router <-> 2. CPE in router mode? <-> 3. Unifi
1 should be under SIte
2 and 3 should be under Client
If the CPE is in router mode, this is the device which will be shaped or suspended
Site Router eth0 <-ethernet-> Client Unifi
Site Router eth1 <-ethernet-> Backhaul 1
Site Router eth2 <-ethernet-> Backhaul 2
Site Router eth3 <-ethernet-> Sector AP 1
Site Router eth4 <-ethernet-> Sector AP 2
Wednesday - last edited Wednesday
@UBNT-Petr To answer your question, we had to give up on UCRM because there was no solid integration working (UCRM + UNMS) to tie the customer account to the customer device. The traffic shaping and walled garden for nonpayment doesn't support DHCP addresses, so that major feature was unusable for us, which was the primary reason we wanted to use the tool. Also, the ever-changing roadmaps, with dates that weren't met didn't give us much confidence. I still remember seeing a roadmap that said UCRM+UNMS integration would be complete in October 2018. Also, changing or completely pulling roadmaps off the website when they aren't met lowered confidence further.
The priorities are changing as new devices are released and UNMS/UCRM needs to support them but we will do our best to improve this.
The integration will be released in Beta in a couple of days, so the suspension, shaping (along with DHCP), easy provisioning with auto-discovery - all of that will be there. Maybe someday, you can try it out.
You can also set the MAC address, which is used as the main identification key when it's defined in both UCRM and UNMS for the same device. Only if the MAC is not defined, the IP is used.