> [!Warning] > This is the biggest thing that I still have to understand about Ninja. # Policies We May Want - Windows Workstation Policy - MT Professional Workstation - Manufacturing Equipment? - MT Essentials Workstation - MT Unmanaged Workstation - MT Audit Only? # Policy Inheritance ![[Pasted image 20250527210023.png]]Policy is the engine that makes Ninja go. - What is a policy - What endpoint bahviors you monitor and alert (conditions & activities) - Patching (OS and 3rd-party), what gets approved. - Anti-virus - Ninja backups - Scheduled automations (scripted actions are also available with tasks) - Policy key points - Devices only ever adhere to a single policy. - Policies are assigned based on **device type** within an org or location. - Policies can be manually assigned to devices in app or through the API. - Policies are siloed by both OS and servers/workstations. - Policy inheritance - Policy inheritance allows for making wide sweeping changes without having to touch each policy. - Jeff recommended configuring all of your settings under the root policy for OS/device type then turning them on/off in the "operational parent policy" - In the top level everything is turned off, just configured. In the operational parent policy things are turned on/off. - The child policies are all applied to actual devices. Jeff's example was one child policy might have SentinelOne, another has BitDefender, etc. - You want as much in the top level policy as you can. You want to account for the edge cases but design for the 80%-90% of endpoints in your root policy then account for edge cases. - Think about the future when designing policies. - What if we acquire another msp? - An example for us would be the following - Root policy: Windows Server Policy /[Default] - Operational Policy: MT Professional Windows Server - Child Policy: MT Professional Server - Windows 2012 - Overrides - Any time you make an override it will break the inheritance chain. This has to be accounted for. Additional overrides will make things difficult to manage. - Overrides in the policy when possible, device level overrides are also possible. - example of device override: disable disk space notifications for a NVR server. - It seems like the best situation is when you are enabling/disabling with overrides, however tweaking policy settings is also possible. - Remove/edit things from upstream or add things only needed below. - You want to have it created top level then only applied when needed. - Changes made upstream will delete overrides. "any individual device overrides changes will remove overrides also if you change the policy applied to the device." - Overrides take precedence closer to the device they are. - Siloed policies![[Pasted image 20250528195953.png]] - Global Parent policies ![[Pasted image 20250528200337.png]] - Multi-Layer ![[Pasted image 20250528200426.png]] - Bringing it all together ![[Pasted image 20250528200742.png]]![[Pasted image 20250528200829.png]]![[Pasted image 20250528200920.png]]