Phil, I have attached below the final email we had on this subject as it might be useful to others.
Phil,
Sometimes it is hard to find time to explain some features. I have pasted another answer below that discusses open space phones and pseudo users that would be helpful.
[Tony] PCP is user oriented. Services belong to “users” and are managed that way. A user can be a real person, a place (lobby, elevator, conference room, manufacturing floor, etc.) or can be considered something like spares. An advantage to this is that it better aligns to Cisco’s UC services user centric mode and allows easier identification and selection of endpoints.
There are two types of LDAP environments for CUCM. There is the legacy environment which is pre 10.5(1) and the new model which is 10.5(1) and later. CUCM 9.1.2 operates in the legacy model. In this model AD integrated CUCM cannot deal with a userID that is not brought in from AD. In the later model non-AD users can exist in CUCM.
The definition of pseudo started with the older UPM product PCP is based on. The problem that caused the earlier UPM product to get the pseudo concept was that UPM needed userIDs to own phones and services but we could not push users into CUCM that did not already have a defined userID. Pseudo was then created to allow new users to be built in UPM that only existed in UPM. When the new pseudo user got a phone, UPM would provision the phone to the pseudo user in UPM but only push the phone to CUCM. Creating phones in CUCM presents no problem to CUCM. We don’t lose track of the user-less phones in CUCM when we do a reverse sync since the phone has a MAC and our pseudo user owns a phone with the same MAC. They match up. This system has been working for years since about UPM 2.0 and we have hundreds of customers using it.
How do you use pseudo? You will have to create a pseudo user for any non-AD entity (human or not) that you want to manage in PCP that does not exist in AD. While most real users own one to three endpoints, pseudo users typically own one to a hundred+ endpoints. If you have a conference room, you can name it iron_conf_room, for example, following some naming scheme for conference rooms. Once created with the pseudo role, you can add a speaker phone and maybe a wall phone. From this point forward iron_conf_room is tracked among other “users” in PCP.
The difference in management between PCP and CUCM is fairly clear. When there is a need to manage the speakerphone in the conference room, generally a person will call the help desk and report that the speaker phone in the iron conference room need some attention. The admin opens the user record for the iron_conf_room and selects the speaker phone (easy to tell which is the speakerphone from the picture of the phones in the conference room user record), then manages it. The admin can even send the person to the conference room and then call them on the wall phone because the iron_conf_room user record shows the other phone (in the case a wall phone for example)is in the same room. In the CUCM world, a user contacts the help desk and asks for the same help. The admin must send the person back to determine the MAC address of the speaker phone. Assuming the person figures out which of the tags on the bottom of the phone has the real number on it and copies it down accurately, the admin searches for it in the inventory and then acts on the phone. If the admin sends the user to the conference room and then needs to call them there is usually no way to know if there is another phone in the room or what the phone number is.
In PCP you can define telepresence rooms, conference rooms. Spare pools of phones, building 7 phones, lobby phones, etc. If you don’t want to name all the openspace phones or hallway phones in a building they can be grouped into OSPBuilding7 or hallphonesNYB7 or some other naming scheme. There is less granularity but still easy to figure out how to quickly find them. People don’t refer to open space phones by MAC address they typically tell you the physical location.
Here is a use case that might be interesting. Admin wants to change the device pools on all open space phones in building 7. Admin creates a new service area with a new device pool, or just picks a new device pool for an existing building 7 open space phone service area. Admin goes to the User Provisioning UI, looks up the OSPBuilding7 “user” and moves the user to the new or modified service area (can move a user to the same service area they are already in). In this case all open space phones in building 7 switch to the new device pool. Note that you don’t have to find and identify the MACs for the phones that need moving to a new device pool. None will be missed. If you have a cluster of 6 buildings at a location, you can pick all the open space users for the location in one quick selection and move them in one operation, changing just the open space phones at the location without affecting other phones.
One other thing that changes in a PCP managed network is that you may generally batch add bunches of new phones with lines and DNs, for example to a pseudo user that may be something like Fresno_spares . From this you can go to Fresno_spares and move a phone(s) to a real user at the Fresno site or a different pool of phones. In each case groups of phones can be managed together. New registered phones will be discovered during a reverse sync as they get added to the network. In this case we now have a UI for seeing these phones where you can select phones and assign them to real users or pools of pseudo users.
Hopefully this clarifies the hows and whys of the pseudo concept in PCP and how it can be used with open space phones. Starting in 11.0 PCP has an add room function which is a convenience feature used for open space, cubical, lobby, conf or TP rooms.
So how does this apply to the question?
We will order a phone for every cubicle/office when we convert an office to VoIP, unoccupied phones are set as open phones with no user assigned.
[Tony] This is where the phones are assigned to pseudo userIDs. A pseudo user such as floor_4_spares can be added for the open space phones on floor 4, for example. If there is an issue with licensing where you want to phones to not use a license when used as an open space phone vs. using a license when a human owns the phones, different templates can be applied that swap the settings and owner userID. So when the phone is initially added it needs to have the original phone template assigned that sets the desired settings for an open space phone and setting the owner UserID to anonymous. If the license consumption is not an issue, then just fully install the phones with services at install time and just move the ownership between the pseudo user or human user as needed. I would also suggest the device description be set to the actual cube number at add time so you can tell the physical location of the phones the pseudo user owns. It is common practice.
None of these appear to be showing up in Provisioning, same with conference phones.
[Tony] This is how it operates. These phones are called orphan phones from the PCP perspective. They can be synced in and there is a UI to see them and assign them to real users or pseudo users. If they are not assigned to a userID then they cannot be managed.
We need these phones to be functional where they are so a visiting user can sit in an open cube and have a functional phone,
[Tony] Setting the system up properly to start with allows the phones to work for visitors and owners and they can be easily moved from spares to people and back.
One workaround we have come up with is to potentially create an AD or local CUCM user that all the open phones get associated to and see if they sync into PCP. We will also need the field staff to be able to assign a phone to this user when someone leaves or moves to another office, not sure how we can do that if that unless we do a user account per domain
[Tony] This is an interesting idea but is covered in the earlier discussion.
Since I’m not sure they will see a user account or any devices that exist outside of the domain that they have privileges.
[Tony] there are probably several ways to address this, a couple below.
- One way is to put all the pseudo users (floor1_spares, floor2_spares, etc., or one pseudo user (all_spare_phones), in a separate Domain group and give all the admins access to that Domain group. So they will be able to only manage users in specific Domain groups they have access to plus the Domain group that holds all the spare phones. They can move phones back and forth between their Domain groups and the single spare phone Domain. This works if multiple Domain groups share a bunch of phones, probably in a single physical location.
- Another idea would be that when the phones are added, the ones in the Sacramento area are added to a pseudo user in the Sacramento Domain. As users join the company in Sacramento, they get the appropriate phone moved (change owner) from the spares pseudo user to the new human user. This works if all users and phones will exist in the same Domain group.
I hope this information provides some clarity on how PCP can be setup.
Regards
