Deploying Microsoft Defender for Identity (MDI) requires more than just installing the sensor on a domain controller. MDI demands careful capacity planning to ensure reliable performance and accurate threat detection. Each MDI sensor analyses authentication traffic, monitors Active Directory activity, and reports telemetry to the MDI cloud service. If the underlying domain controller is undersized, this additional workload can lead to degraded performance or missed detections. In this post, we’ll walk through the key factors that influence sensor sizing — including CPU, memory, and network utilization — and show how to correctly assess whether your domain controllers can support MDI using Microsoft’s sizing guidance and tools.
If you deployed the precursor to MDI, Microsoft Advanced Threat Analytics (ATA), you be aware that you have to plan and size the ATA deployment. ATA and MDI share a common lineage, both were designed to detect suspicious activity and advanced attacks against Active Directory environments. However, their architectures differ fundamentally in deployment model, data flow, and management components.
ATA was an on-premises solution, which required servers and a database which was installed and managed entirely within customers' environment. MDI, by contrast, is a cloud-based service hosted within Microsoft 365 Defender. The on-premises component is a sensor installed directly on each domain controller, which communicates securely with the Defender for Identity cloud service. While the deployment is greatly simplified, you must still plan and size the sensor correctly.
This is where the TRI sizing tool comes in!
Note - do not run the tool just once and say we are golden! Run it multiple times on different days to abalyse peak load. You may also see that the load is spread onto different DCs depending on how the clients located a DC on a given day. You may also realise that the network team pinned all of their authentication traffic to a single DC and never told you...
Tool Download
Download and extract the sizing tool from GitHub.
The tool will be downloaded as a ZIP. Remove Mark of The Web, right click the ZIP and in properties unblock the file, then extract the files. You should see the below files in your extracted location:
NB - The EPPlus.dll must be in the same folder as TruSizingTool.exe.
Since we are using standard Windows protocols to retrive data from remote machines the aforementioned network ports must be open. If not the tool will fail.
Standard Execution
A simple, yest effective way, is just to run TriSizingTool.exe in an elevated cmd prompt with no options. That will query all domain controllers in the domain that the user is logged on to and by default will capture 24 hours worth of performance data. In many cases that is sufficient. For those situations where that is not the case, then look at the options below.
Note that this information is also captured in the log file that is created – see separate section below.
Time goes by, and we then see the tail end with the details noted below.
Writing final results to 'C:\Moveme\MDI-Sizing-Tool\Ext\TriSizingToolResults_20231119_2354.xlsx'...
Successfully wrote results to 'C:\Moveme\MDI-Sizing-Tool\Ext\TriSizingToolResults_20231119_2354.xlsx'.
Logged output can be found in 'C:\Users\Administrator\AppData\Local\Temp\TriSizingTool_9256.log'.
Command Line Options
Should you want to change the default duration, sample detection interval or limit which domain controllers to collect data from then you will need to crack out the options.
The screen shot below shows the options available with version 1.3.0.0 of the tool.
One feature I use heavily us the –GenerateDCListFile option. That generates a list of all DCs, and if there are DCs that I need to remove due to firewall or other issues they can be easily removed from the text file. Once the list has been edited and verified, then feed it to the –InputDCListFile paramater and the tool will only process those machines.
You may also want to use the –SampleSurationMinutes to increase or decrease the overall collection time. Within the collection period, the SampleRateSeconds and SlidingBusyPeriodMinutes can be used to adjust the sampling frequency and to set the busy period length.
Contents of the TriSizingTool Log File
This section contains the options shown when initially running the tool as that will have been lost in the screen buffer.
[2023-11-19 23:54:39.14] =====
[2023-11-19 23:54:39.16] Execution of TriSizingTool 1.3.0.0 started on 11/19/2023 11:54:39 PM UTC
[2023-11-19 23:54:39.16]
[2023-11-19 23:54:39.16]
[2023-11-19 23:54:39.16] Selected configuration:
[2023-11-19 23:54:39.16] Input source UseCurrent = 'UserDomain'.
[2023-11-19 23:54:39.16] Sample duration = 1,440 minutes (24 hours).
[2023-11-19 23:54:39.16] Sample rate = 5 seconds.
[2023-11-19 23:54:39.16] Sliding busy period = 900 seconds (15 minutes).
[2023-11-19 23:54:39.16] Output Excel file = 'C:\Moveme\MDI-Sizing-Tool\Ext\TriSizingToolResults_20231119_2354.xlsx'.
[2023-11-19 23:54:39.16] Active Directory counting of users & computers = Disabled
[2023-11-19 23:54:39.18] NICs with the following prefixes will be ignored:
Bluetooth Device
Local Area Connection
Microsoft Kernel Debug Network Adapter
Teredo Tunneling Pseudo-Interface
isatap.
IPHTTPSInterface
6TO4_Adapter
[2023-11-19 23:54:39.18] Fetching DC FQDNs...
[2023-11-19 23:54:39.18] Searching for DCs of domain wingtiptoys.ca...
[2023-11-19 23:54:40.08] Successfully fetched 3 DC names.
[2023-11-19 23:54:40.10]
[2023-11-19 23:54:40.10] Accessing performance counters on all selected DCs...
[2023-11-19 23:54:40.43] Attempting to enumerate NICs on all 3 servers...
[2023-11-19 23:54:41.99] Successfully enumerated 1 'Network Interface' Performance Counter Category instance
on server 2019-DC-1.wingtiptoys.ca. Query took 00:00:01.5559537.
[2023-11-19 23:54:46.44] Successfully enumerated 1 'Network Interface' Performance Counter Category instance
on server 2019-DC-2.wingtiptoys.ca. Query took 00:00:06.0071567.
[2023-11-19 23:54:54.88] Successfully enumerated 1 'Network Interface' Performance Counter Category instance
on server 2019-DC-3.wingtiptoys.ca. Query took 00:00:14.4449667.
[2023-11-19 23:54:54.88]
Successfully completed NIC enumeration requests on all 3 servers in 00:00:14.4610577.
Bootnote
Why is it called Tri Sizing ? Anything to do with someone’s favourite dinosaur?
The name “Tri Sizing” likely stems from the tool’s ability to evaluate three key dimensions:
1.Network Traffic Load – Measures packet throughput to determine if the sensor can handle the domain controller’s traffic.
2.CPU Availability – Assesses whether the domain controller has enough processing power.
3.Memory Availability – Evaluates RAM capacity to ensure smooth sensor operation.
These three factors are critical for determining whether a domain controller can support the MDI sensor without performance degradation.
Cheers,
Rhoderick
