A hospital profiles IP cameras and VoIP phones with ISE. The camera profile currently matches only the HTTP user-agent, but the cameras stop sending HTTP after they are installed. Which profiling design keeps the assigned certainty factor reliable for these endpoints?
Select an answer to reveal the explanation.
Short Explanation
You’ll get a more reliable profile by adding DHCP and OUI conditions to the HTTP match, so their combined weight can clear the certainty factor. Think of DHCP and OUI as backup signals: even when the cameras stop sending HTTP, they can keep the evidence strong enough.
Full Explanation
Adding DHCP and OUI conditions to the HTTP match lets their configured weights contribute to the camera profile’s certainty factor. This is important because the HTTP user-agent may be observed during installation but is not a dependable continuing signal after the cameras stop sending HTTP. With suitable weights, DHCP and OUI evidence can bring the profile to its required certainty without later HTTP traffic; OUI is supporting evidence, not proof of a unique device type. Requiring a fresh DHCP exchange before assigning the profile makes assignment depend on an event that may not recur after installation, so it cannot reliably support already deployed endpoints. Using DHCP and DNS as weighted evidence while retaining HTTP as a required condition still makes HTTP a gate: once that observation stops, the profile cannot be assigned even if the other signals are available. Combining DHCP, OUI, and HTTP but making HTTP mandatory has the same flaw, since the other evidence cannot overcome the missing required match. Exam caveat: including a condition in a profile does not guarantee it contributes enough certainty; verify its configured weight and match logic. Practical check: review ISE live logs and endpoint details after installation to confirm DHCP and OUI probes arrive and the certainty factor reaches the required threshold without a new HTTP request.