As per your design requirement it would be better to have one Global policy (include all the necessary pages based on your SteelHead configuration like Simplified Routing, HTTP, SMB,etc.)
This Global policy shouldn't have inpath-rule page included.
So when you push Global Policy from SCC to multiple remote SteelHeads it will accept or update all the policies or pages that are part of this Global Policy and it wouldn't change in-path rules.
So this would be one time configuration of in-path rules on Local SteelHead and whenever required you can change, add or delete in-path rules directly onto that specific SteelHead.
Regarding SMB, there are some scenarios where you need to enable or disable some of the SMB settings. So to add this additional SMB commands you can insert CLI commands inside Global Policy page.
By this way you can also add CLI command to your policy.
Hope this approach helps.
I see what you are saying, but we were hoping to move away from the local "configure-one-appliance-at-the-time" approach just for in-path rules. Also thinking it would be beneficial to have policies ready(autoconfigure) for a new or replacement appliances if needed.
From experience we see that when doing some local config and at the same time use SCC policies it doesn't take to long before local config takes over. Admins don't want to spend time checking if the SCC-policies will overwrite local config.
I guess this is down to the human factor and procedures, but it is what is.
Sorry for the confusion, by SMB environment i meant small and medium-sized businesses (SMBs).
I will bring your suggestions to the table and we will look into this.