Im struggling with Owner User ID and Extension mobility.
It seems to me that unless we set Owner user ID on every single hardware phone, it uses an extra license. Why would you set owner user ID when you are using extension mobility? The whole point of extension mobility is that a phone has no owner, they can use any phone.
The problem is, if you set owner user ID on every phone, users get an EXTRA phone appear in their UCM user options (https://callamanger/ucmuser) that has nothing to do with them.
So for example, john smith may have an iPhone jabber, a CSF jabber, and an EM user device profile. If you set a desk phone to be owner by him, he sees four devices under his UCMUser, even though he only ever uses three.
This causes complaints and confusion for users. The only option I see is just to not set owner user ID for the physical desk phones, but this results in using twice as many licenses as we should.
Am I missing something here?
From CUCM version 9.1(1a) , EM has been removed as a licensed user feature.
A device requires a licnese when it is added to CUCM based on device type/model.After that device is mapped to a user by setting the owner userID.Thereafter,licensing comes.
A user is associated to device when useid is entered in Owner USerId option of teh device.when associated, user and device share the licnese.
with essential /Basic/Enhanced UCL, we can have one device while with Enhanced Plus/CUWL Std/Professional, we can have more than 2 devices associated per user.
Thats exactly my point.
Why are we assigning an owner to a hardware phone, when we are using a feature (Extension mobility) that is designed to allow people to log in to ANY hardware phone (So phones do not have "owners)
If we assign an owner to a phone, that hardware phone appears in the users user options web page - The self care portal. This is silly.
If you are using extension mobility then phones do not have owners, people merely have device profiles that are used on ANY phone and ANY hpone can be owned by ANY user. Why are we statically assigning an owner User ID for a desk phone when the User is inherantly mobile and not static?
I have two choices, do not statically assign phones, and use twice as many licenses. Or statically assign a phone, and the user has the option to administer a phone (in their CM user options) that they may never sit at; And certainly never NEED to administer, because all of the settings are under their device profile, and NOT the desk phone because the user uses extension mobility.
Can you see my point?
Can't you just set the owner option to Anonymous (Public/Shared Space)?
EDIT: Yes you can, I just did it.
Screenshot of the seciton I'm referring to:
But doesnt that then use more of a differnet type of license?
AFAIK public space devices are licensed differently, I may be wrong though?
I'm not sure, as I haven't had a chance to learn ELM/PLM yet, but that's not the point.
Your point of:
"If we assign an owner to a phone, that hardware phone appears in the users user options web page - The self care portal. This is silly."
Is now addressed with the Anonymous setting. How you pay Cisco for using their products is a different matter.
Sorry if that sounds blunt, but I'm never one to arguing over software licensing. It sucks and we have to play by their rules. At least now your users don't see desk phones in the Self Care Portal.
It doesn't use a different type of license really. It will borrow from your CUWL/UCL licensing. User-based licensing allows users to have multiple devices with a single license. Setting everything as a public space phone will use a user license for each phone which can be a pain. You may end up needing extra licenses if each user also has a Jabber device or a Remote Destination Profile. For Extension Mobility deployments, I have heard of account managers recently giving out additional licensing to cover these kinds of scenarios.
There isnt really a work around... its just the way that Cisco think it should be!!!
There is no real solution for it im afraid. you either have to assign your phones to your users (Even though they are in an EM deployment) or you can possibly create a new user, and assign all phones to that user.
What you will find then though is that the new user you have created will consume quite a few licenses (from memory I think you can have up to 10 devices for each "CUWL Pro" user type)
So a dummy user with 100 phones assigned might then use 10 CUWL pro licenses according to the ELM. You can then fight with your Cisco account manager to get them to supply 10 extra licenses FOC because of this stupid problem; They may or may not relent; I have not tried this. In my deployment we have a surplus of licenses so it wasnt a problem.
I feel your pain. I'm facing exactly the same dilemma as you and realising the same outcome. we've also made extensive use of extension mobility.
If I understand the thread correctly, even if I review each of my 3500 EM users, look at which device they are currently logged in on and associate that device to the user, the minute they have an office shuffle or hot desk and log into another IP phone, PLM potentially then goes into "overage mode" or dips into the spares pool until I update the device associations?
That is absolutely bonkers. To my mind EM then becomes a licensable service, it is just done by stealth rather than up front.
Actually no, thankfully your comments on users signing into another device are not the case.
The simple explanation is this:
1 phone uses one license
1 user with at least one device assigned uses one license
1 user can "own" at least 1 device
If you do not set an "owner" for a device, it uses a license. If a user has a device profile associated with their account, this also uses a license. So in theory, a user could use a license, and log into an IP Phone that is also using a second license.
In the above example, two licenses would be consumed.
If you set the device to be OWNED by the user above, only one license is consumed.
The problem comes in that
a) You have to do a 1:1 association of users to devices to get your license counts right
b) Once these devices are assigned, the user can then administer the device you assigned to be owned by them in their user options web page (Causing confusion, since they will never actually see the settings of the base device because they are logged in)
c) If user A is owner of phone A, and user B is owner of phone B, and user and and user B swap desks, User A can still administer phone A even though they are sitting at phone B, and vice versa. Albeit it the settings will never take effect anywhere, since everyone is logged in. This leads to confusion amongst users as to which device they should be adding speed dials to etc.
People logging in here there and everywhere has NO effect on license counts. It is based purely on:
Number of devices assigned to each user (to determine license type required by that user; Basic/Enhanced/UWL See http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-communications-licensing/product_solution_overview0900aecd806cc7a4.html for details)
Number of physical, SEP Devices configured in combination with who the owners are (To determine how many licenses are required)
Have a look at Cisco Device Assignment Tool. It helps to do the association, but unfortunately doesn't alleviate the sillyness with user options.
In my opinion the fix to this is to have a check box on the admin page for each IP phone or under a common phone profile setting "Display device in Unified CM User Options"
The default should be set to no if the phone has extension mobility enabled, and yes if it does not.
We could even go one further and implement some logic:
if phone is logged into by a user, assign it to that user for licensing purposes until either:
Phone is logged into by another user
Phone remains registered but logged out for 30 days
In conjunction with the above setting, it would take a lot of the pain out of the current licensing system.
Wow - thanks for the explanation. So not as bad as I thought!
I concur that applying your suggested logic would take out a lot of the pain and offer an optimal solution. In fact it begs the question, why didn't Cisco think of that?
There is a solution for this and that solution is to contact Cisco license. We have recently discussed this with cisco and they realise it's a problem they created. When you email cisco they will give you a temporary license that will automatically expire when they fix this at some point in the future.