A university's ISE profiles laptops and printers well, but newly purchased VoIP phones show up as Unknown on day one. The team wants new models classified automatically as hardware ships, wants profiling policies left untouched, and still needs the probe data that authorization decisions rely on. Which profiling feature should they enable for the new VoIP models?

The Profiler Feed Service is the appropriate feature because it retrieves Cisco’s updated device signatures, allowing ISE to recognize newly supported phone models without waiting for the team to build or revise local profiling rules. Keeping DHCP and SNMP probes running preserves the observed attributes that existing profiling and authorization decisions depend on. Importing a VoIP profiling policy pack can provide model-specific rules and retain probe data, but it changes the profiling policies, contrary to the requirement that they remain untouched. Tuning DHCP profiling is a common way to classify phones from vendor-class and option attributes, and it can preserve the existing policies and SNMP collection; however, it depends on matching rules already covering the new model and does not automatically deliver Cisco’s newly published signatures as models ship. Switch Device Sensor can supply useful CDP and LLDP attributes to ISE while leaving policies and probes in place, but those observations alone do not provide the feed’s automatically updated model signatures, so an unrecognized new model may remain Unknown. Exam caveat: a feed supplies signatures, not a guarantee that every device will be identified if its traffic or attributes are unavailable or its signature is not yet published. Practical check: verify feed updates are reaching ISE, then confirm a newly supported phone is profiled while DHCP and SNMP probe collection remains enabled.