> [!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]]