CSS Dependancy on Device Profile

[louis.engelbrecht]

HI have a strange issue where the dependancy records on a CSS that i want to delete shows that a Device Profile is dependant on the CSS.

I can confirm that neither the device profile or any of the lines have this CSS configured.

I have logged out those users from their phones but the issue still persist.

i also have the same issue with a devicepool that has a udp dependancy. but the user is not logged into any phone so that association should dissapear.

Any Ideas?

[Marwan ALshawi]

have a look at route plan report and see whats still linked

[louis.engelbrecht]

Route Plan report doesnt show the devicepool or CSS of the DN.

I have however run a sql query on the numplan table.

select fkCallingsearchspace from device where name = '4476293' the fkcallingsearch space references the CSS that i want to delete.

but how do i update this via ccmadmin. There are no fields that reference the udp to a CSS.

although when i run the same query against my own udp then fkcallingsearchspace is empty.

[Rob Huffman]

Hi Louis,

There is a relationship between the Lines inserted with the UDP and CSS. If you were to delete the UDP for 4476293 this would free you up to remove the CSS in question. Then create a new UDP for 4476293 :)

Hope this helps!

Rob

[louis.engelbrecht]

Thanks Rob.

This is a workarround that works, but unfortunately not a viable solution for me as i have other css' that is in use by 250+ udp's.

Please note that i am not refering to the lines on the udp. the udp is a device entry in itself and this is where the css is configured. (just like you have a css on a physical phone device)

I dont particularly want to recreate all of these udps manually, or even using bat...the risk is to high in the production environment.

Does anyone know what process adds the fkcallingsearchspace field to the udp device entry? and why does this field exist only for certain udp's?

I have found that this is only populated for a third my udp's. (i have over 3000 udps)

Could it be that this is historic from previous versions? or from the migration process to extension mobility?