<div dir="ltr">You are correct that the Device Mobility feature does not change the CMG for the roaming phone.  This is clearly documented in the Features and Services Guide.<div><br></div><div><i>"Cisco Unified Communications Manager always uses the Communications Manager Group setting from the phone record. The device always registers to its home location Cisco Unified Communications Manager server even when roaming."</i></div><div><br></div><div>Source: <a href="http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmfeat/CUCM_BK_F3AC1C0F_00_cucm-features-services-guide-100/CUCM_BK_F3AC1C0F_00_cucm-features-services-guide-100_chapter_010100.html#CUCM_RF_D5743F59_00__note149">http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmfeat/CUCM_BK_F3AC1C0F_00_cucm-features-services-guide-100/CUCM_BK_F3AC1C0F_00_cucm-features-services-guide-100_chapter_010100.html#CUCM_RF_D5743F59_00__note149</a></div><div><br></div><div>That was for others reading pleasure, as I'm sure you've already found that.</div><div><br></div><div>It would help to know your environment a little better in order to recommend a solution.  How many clusters, nodes, phones, branch sites, data centers, distribution of population, level of comfort with automation via AXL, etc.</div><div><br></div><div>But for the most part, I do believe the only way to balance device registrations is manually.  There are a lot of variables outside of phones, which could create an inbalance in your registration counts, to include: CTI Route Points, CTI Ports, Gateways, SIP Trunks, Route Lists, Hunt Lists, Shared Lines, Line Groups, etc.</div><div><br></div><div>Leaving it to a manual process avoids Cisco from designing a solution which may or may not crash your CUCM node, as things are being dynamically reassigned based on roaming users and the like.</div><div><br></div><div>I would personally just have this be a part of my regular maintenance plan (backups, patches, reboots, etc.) and any new branch office project.  I may always just account for a 20% overhead on any existing sites too, just so I'm not micro managing the environment evey time a phone is disconnected/connected to the network.</div><div><br></div><div>Lastly, I would also recommend not filling your nodes up to past 80% of their stated capacity.  There's always something we're not accounting for or have misunderstood, and leaving 20% resource capacity on the table should provide a nice safety net.  E.g., If you installed the 7,500 device OVA, only plan to register about 3,000 phones to it, so it can take on another 3,000 phones should its partner node* decide to fail and dump all of its phones on him.  That would be 6,000 total phones on your survived node, or 80% of 7,500.  This leaves room for all of those things stated above like Gateways, Trunks, Line Groups, etc.</div><div><br></div><div>*By partner node, I just mean another node in the same CMG.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 2:50 PM, Pawlowski, Adam <span dir="ltr"><<a href="mailto:ajp26@buffalo.edu" target="_blank">ajp26@buffalo.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good afternoon all,<br>
<br>
        I'm looking at using device pool mobility to try and balance out resource usage and routing between our campuses. I was hopeful that this functionality would also be useful for the callmanager group parameter, but, it appears this is not the case. Are there any thoughts or recommendations on issues relating to using mobility to divvy up items between locations? Any comment on an easier way to "balance" phones between call manager groups other than occasionally making sure we haven't assigned too many phones to one group to break failover/redundancy?<br>
<br>
        I was ultimately hoping that this would allow us to create 1 set of templates to deploy standard devices and not have to hose around with multiple templates to line up with different CMGroups.<br>
<span class="HOEnZb"><font color="#888888"><br>
Adam Pawlowski<br>
SUNYAB<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</font></span></blockquote></div><br></div>