A retail bank changes the boot order on a service profile template, and the profiles already created from it do not change. The template type is initial. Why do those profiles keep the old boot order?
Select an answer to reveal the explanation.
Short Explanation
An initial template is a rubber stamp, not a subscription. You stamped these profiles when they were born, and later edits to the stamp do not rewrite them. If you wanted the boot-order change to follow the profiles, you needed an updating template.
Full Explanation
UCS service profile templates come in two types. An initial template applies its configuration when the profile is created and then leaves that profile alone. Later edits, including a new boot order, do not propagate, so the bank's existing profiles keep the previous order. An updating template is the opposite: bound profiles receive subsequent changes. The claim that these profiles are bound to an updating template, and that an updating template ignores later edits, reverses both the stem and the behavior. Boot order lives in the boot policy associated with the profile or template. A UUID pool supplies an identity and does not store the boot device list. Fabric interconnect reloads are not the trigger that applies template edits. An updating template pushes changes without requiring both interconnects to reboot, and an initial template will not start pushing just because they did. Caveat: unbinding a profile from an initial template does not by itself rewrite the boot order. You change the profile or recreate it from an updating template. Operational check: confirm the template type is initial, then either update each affected profile's boot policy or move new profiles to an updating template and verify one test blade shows the new order.