Check the Netlogon Log for Missing Subnets
The netlogon.log file contains valuable information about client site associations. Specifically, lines containing the phrase “no client site” indicate subnets that are not yet defined in Active Directory. These unidentified subnets might be the root cause of certain connectivity issues.
To review the log, open the netlogon.log file using your preferred method or PowerShell:
Get-Content C:\Windows\Debug\netlogon.log
Search for lines with “no client site” to identify any missing subnets.
Enable Debug Logging (If Necessary)
If your netlogon.log file is empty, debug logging might not be enabled. To enable it, follow these steps:
Open the Registry or PowerShell:
for Regedit : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Create or modify the DBFlag registry value with the following hexadecimal value: 2080FFFF
for Powershell :
nltest /DBFlag:2080FFFF
Restart the Netlogon service to apply the changes. You can do this via PowerShell:
Restart-Service Netlogon
Analyze the Debug Logs
After enabling debug logging and restarting the service, check the netlogon.log file again. Use PowerShell to monitor the log in real time:
Get-Content C:\Windows\Debug\netlogon.log -Wait
Look for entries with “no client site” to identify the subnets that need to be added to Active Directory.
Debug logging and the netlogon.log file are invaluable tools for identifying and resolving missing subnet configurations in Active Directory. By following these steps, you can easily pinpoint the subnets that require definition and ensure smoother network operations.
Managing an Active Directory (AD) environment requires a clear understanding of its configuration, including its network subnets. Knowing when specific subnets were added can provide valuable insights for audits, troubleshooting, and change tracking. However, this information is not readily visible in the default Active Directory tools. To address this, I created a script that retrieves and displays the creation dates of subnets in Active Directory.
In this article, I’ll share the purpose of this script, explain how it works, and provide usage instructions. If you’ve been looking for a way to streamline your subnet management tasks, this solution might be just what you need.
Subnet creation dates can be important for:
Auditing: Keeping a record of when changes were made.
Troubleshooting: Identifying if a recent subnet addition aligns with network changes.
Change Management: Ensuring compliance with organizational policies.
While the default AD tools allow you to manage subnets, they lack detailed tracking capabilities. This script bridges that gap by retrieving and displaying the creation timestamps.
The script leverages PowerShell and Active Directory cmdlets to query the CN=Subnets container. By parsing the whenCreated attribute of each subnet object, it provides a clear list of subnets along with their creation dates. Below is a summary of its functionality:
Connects to the Active Directory environment.
Queries the CN=Subnets container.
Retrieves the whenCreated attribute for each subnet.
Outputs the data in a readable format (e.g., table or CSV).
Before running the script, ensure the following:
You have administrative privileges to access the CN=Subnets container.
PowerShell 5.1 or later is installed on your machine.
The Active Directory module for Windows PowerShell is installed.
Write-Host "Error occurred: $_" -ForegroundColor Red
Write-Host "`nCheck if you have the following prerequisites:" -ForegroundColor Yellow
Write-Host "1. Running PowerShell as Administrator" -ForegroundColor Yellow
Write-Host "2. Domain Admin or appropriate permissions" -ForegroundColor Yellow
Write-Host "3. Active Directory PowerShell module is installed" -ForegroundColor Yellow
Write-Host "4. Running on a domain-joined machine" -ForegroundColor Yellow
}
While this script fulfills its primary purpose, there’s always room for improvement. Some potential enhancements include:
Adding filtering options to display subnets created within a specific timeframe.
Incorporating logging functionality for audit purposes.
Automating the script to run periodically and generate reports.
This script provides a straightforward way to retrieve subnet creation dates in Active Directory, making it easier to manage and audit your network environment. Feel free to try it out.
You can also check this article to check for missing subnets in your environment.
Server Message Block Version 1 (SMB1) is an older protocol that facilitates file and printer sharing over a network. Widely used in Windows systems, it allows devices on a network to share data with each other.
However, due to security vulnerabilities, more modern and secure alternatives are recommended.
Advantages:
Compatible with older hardware.
Simplifies file and printer sharing over a network.
Disadvantages:
Prone to security issues and more vulnerable to ransomware attacks.
May have lower performance.
Finding SMB1 Access on Domain Controllers
To locate SMB1 access on Domain Controller (DC) servers, the first step is to ensure that the Audit-SMB1Access feature is enabled. This feature collects SMB1 access control logs, making them available for analysis.
These logs focus on specific periods (e.g., the last 10 days).
SMBAnalysis
Enabling the Audit Feature To enable SMB1 access logging on Domain Controller servers, use the following PowerShell command:
# Get Domain Controllers
$DomainControllers = Get-ADDomainController -Filter * | Select-Object -ExpandProperty Name
Write-Host "Unique client entries (last 10 days) saved to: $OutputPath"
}
Addressing Security Concerns
Identify Security Vulnerabilities: SMB1 has inherent security vulnerabilities and, as an older protocol, is more susceptible to ransomware attacks and network threats. Analyze SMB1 logs to identify potential security risks and breaches.
Remediation and Updates: If critical security flaws are found in devices using SMB1, it is essential to update them with security patches. Additionally, consider disabling SMB1 or migrating these devices to a more secure SMB version (SMB2 or SMB3).
Protocol Transition and Reconfiguration
Transition from SMB1 to SMB2 or SMB3: To close security gaps associated with SMB1 and enhance overall network security, transition all devices from SMB1 to a more modern and secure SMB version (SMB2 or SMB3). This transition can also improve network performance.
Configuration Changes: Adjust Domain Controller settings to disable SMB1 access. This can be done via PowerShell or Group Policy.
Updating Network Security Policies
Firewall Rules: SMB1 should only be used on trusted networks, with firewall rules restricting SMB1 access. If necessary, SMB1 should not be accessible to the outside world.
Monitoring and Auditing: Continuously monitor and audit SMB1 access on all network devices to detect security breaches early. Regularly review audit logs and address any issues promptly.
User Awareness and Training
Limit SMB1 Usage: Educate users about the security risks associated with SMB1 and discourage its use. Provide guidance and training to migrate users to more secure alternatives like SMB2 or SMB3.
Documentation: Maintain detailed documentation on changes made and security measures taken. This will serve as a reference in case of similar situations in the future and can be used as a resource for network management.
Periodic Checks and Maintenance
Regular Checks: SMB1 usage and security audits should be performed regularly. Periodically check SMB1 logs and network security settings to enhance overall network security and quickly identify potential issues.
Security Updates and Patching: Regularly update devices with security patches to protect against new vulnerabilities. This is particularly critical for older hardware.
These steps summarize the fundamental processes needed to enhance your network’s security and resilience against potential threats.
If your Active Directory environment is large and distributed with numerous network blocks, it is essential to add these network blocks as subnets in Active Directory Sites and Services.
Failing to add these subnets can result in several disadvantages.
Disadvantages of Missing Subnet Definitions in Active Directory Environments
In an Active Directory (AD) environment, missing or incomplete subnet definitions can lead to various issues and inefficiencies. Especially in large and complex networks, correctly defining subnets is critical for AD to function properly. Below are the key disadvantages:
1. Site and Replication Issues
In AD, sites are used to optimize network traffic. Subnet definitions associate specific subnets with sites to direct traffic efficiently.
If subnets are missing, clients and servers might be associated with incorrect sites, leading to unnecessary WAN traffic and replication delays.
2. Delayed Authentication and Group Policy Application
Missing or incorrect subnet definitions may prevent clients from locating the nearest Domain Controller (DC). As a result, clients may attempt to authenticate with a DC in a remote location.
This can lead to longer login times and delayed Group Policy Object (GPO) applications.
3. Performance Degradation and Bandwidth Overuse
Without accurate subnet definitions, clients and servers may connect to DCs in distant sites, which can impact performance, especially in environments with slow WAN links.
Replication traffic between incorrectly associated sites may also increase WAN bandwidth usage unnecessarily.
4. Incorrect Site-Link Utilization
Sites and subnets are interconnected using site links. Missing subnet definitions can result in clients using inappropriate site links to access DCs or other AD services.
This can cause replication delays and incorrect DC selection.
5. DNS Resolution Issues
DNS is vital for authentication and replication processes in an AD environment. Missing subnet definitions may cause clients to use inappropriate DNS servers, resulting in delayed or failed DNS queries.
This can lead to slow AD services or failures in certain processes.
6. Complications in Log Analysis and Network Management
Missing subnet definitions complicate log analysis and network management. For instance, identifying which site specific IP ranges belong to becomes challenging.
Troubleshooting network-related issues becomes more complex and time-consuming.
Result
Properly defining subnets in an Active Directory environment is crucial for authentication, replication, and traffic management. Missing subnet definitions, particularly in large and distributed networks, can lead to performance bottlenecks and operational challenges. To avoid these problems, it is essential to define and regularly update subnet configurations for each location.
To avoid encountering these disadvantages, we need to use the Netlogon.log file to identify missing subnets. It is not necessary to enable Netlogon debug parameters to obtain information about missing subnets. By default, No_Client_Site entries can be found in the Netlogon file.
While detecting No_Client_Site information in the Netlogon file is relatively straightforward in environments with a single Domain Controller, it can become time-consuming in environments with multiple Domain Controllers, as you would need to search each Netlogon file individually.
For large and distributed environments, the following PowerShell script can be used to gather missing subnet information:
The script retrieves all Domain Controllers in the environment and categorizes them as accessible or inaccessible.
For accessible Domain Controllers, it accesses the Windows\debug directory, extracts the No_Client_Site entries from the Netlogon.log file, deduplicates the data, and exports the results.
<# This script analyzes missing subnets in an Active Directory environment. It uses the Get-ADDomainController parameter to retrieve all Domain Controller servers in the environment. The output is divided into two categories based on their accessibility. For accessible Domain Controllers, the script examines the lines from the netlogon.log file within the last day. Only unique entries are included in the output. If you want to analyze the netlogon.log file for the last 5 days instead, you can update the relevant line in the script: $lastFiveDays = (Get-Date).AddDays(-5) #>
#Active Directory Missing Subnet Analysis# # Output files $outputPathAccessible = "C:\script\MissingSubnet\Output\Accessible_DCs.txt" $outputPathInaccessible = "C:\script\MissingSubnet\Output\Inaccessible_DCs.txt" $outputPathNoClientSite = "C:\script\MissingSubnet\Output\Missing_Subnet.txt" # Clear or create the output files if (Test-Path $outputPathAccessible) { Clear-Content -Path $outputPathAccessible } else { New-Item -Path $outputPathAccessible -ItemType File } if (Test-Path $outputPathInaccessible) { Clear-Content -Path $outputPathInaccessible } else { New-Item -Path $outputPathInaccessible -ItemType File } if (Test-Path $outputPathNoClientSite) { Clear-Content -Path $outputPathNoClientSite } else { New-Item -Path $outputPathNoClientSite -ItemType File } # Add header rows Add-Content -Path $outputPathAccessible -Value "Accessible Domain Controllers" Add-Content -Path $outputPathInaccessible -Value "Inaccessible Domain Controllers" Add-Content -Path $outputPathNoClientSite -Value '"Domain Controller" | "Computer Name" | "IP Address"' # Get all Domain Controllers $servers = (Get-ADDomainController -Filter *).Hostname $uniqueEntries = @() # Temporary list to store unique entries $yesterday = (Get-Date).AddDays(-1) # Get the date for one day ago # Check if each Domain Controller is accessible foreach ($server in $servers) { $logPath = "\\$server\c$\Windows\debug\netlogon.log" # Check if the server is reachable by ping if (Test-Connection -ComputerName $server -Count 1 -Quiet) { # Write reachable servers to the file Add-Content -Path $outputPathAccessible -Value $server # Perform Netlogon processing if (Test-Path $logPath) { $lines = Get-Content -Path $logPath # Check each line in the log file foreach ($line in $lines) { # Extract date information from the line and compare with the last 1 day if ($line -match "^\d{2}/\d{2}") { $datePart = $line.Substring(0, 5) # Extract the date part (MM/dd format) $timePart = $line.Substring(6, 8) # Extract the time part # Combine date and time and convert to a DateTime object $entryDate = Get-Date -Month $datePart.Split("/")[0] -Day $datePart.Split("/")[1] -Hour $timePart.Split(":")[0] -Minute $timePart.Split(":")[1] -Second $timePart.Split(":")[2] # Process only if the entry is within the last 1 day if ($entryDate -ge $yesterday) { if ($line -match "NO_CLIENT_SITE") { # Extract client name and IP address $client = $line.Split(":")[4].Trim().Split(" ")[0] $ip = $line.Split(":")[4].Trim().Split(" ")[1] # Create the entry format $entry = "$server | $client | $ip" # Add to unique list (ignore duplicates) if ($uniqueEntries -notcontains $entry) { $uniqueEntries += $entry } } } } } } else { Write-Host "Log file not found: $logPath" } } else { # Write unreachable servers to the file Add-Content -Path $outputPathInaccessible -Value $server Write-Host "$server is not reachable." } } # Write unique entries to "No_client_site.txt" $uniqueEntries | ForEach-Object { Add-Content -Value $_ -Path $outputPathNoClientSite }
If you need to automatically delete files and folders when disk space on your drive falls below a certain threshold, you can use a PowerShell script to accomplish this task. Here’s how you can set it up.
PowerShell Script
This script will delete files and directories under a specified path when the available disk space is less than 5 GB.
# Define the path to the directory $directoryPath = "C:\DeleteFilesFolder\
# Set the threshold for disk space (in bytes) $threshold = 5GB
# Get the drive information $drive = Get-PSDrive -PSProvider FileSystem | Where-Object { $_.Root -eq "C:\" }
# Check the available free space on the drive if ($drive.Free -lt $threshold) { # Get all files in the specified directory and subdirectories $files = Get-ChildItem -Path $directoryPath -Recurse -File
# Loop through and delete each file foreach ($file in $files) { Remove-Item -Path $file.FullName -Force Write-Output "Deleted file: $($file.FullName)" }
# Get all directories in the specified directory and subdirectories $directories = Get-ChildItem -Path $directoryPath -Recurse -Directory | Sort-Object -Property FullName -Descending
# Loop through and delete each directory if it is empty foreach ($directory in $directories) { Remove-Item -Path $directory.FullName -Recurse -Force Write-Output "Deleted directory: $($directory.FullName)" }
Write-Output "All files and directories in $directoryPath and its subdirectories have been deleted due to low disk space." } else { Write-Output "Sufficient disk space available: $($drive.Free / 1GB) GB free." }
Explanation of the Script
$directoryPath: Specifies the directory path where files and folders will be deleted.
$threshold: Sets the disk space threshold to 5 GB.
$drive: Checks the free space available on the C: drive.
if ($drive.Free -lt $threshold): Checks if the available free space is less than 5 GB.
Get-ChildItem -Path $directoryPath -Recurse -File: Gets all files in the specified directory and subdirectories.
Remove-Item -Path $file.FullName -Force: Deletes each file without user interaction.
Get-ChildItem -Path $directoryPath -Recurse -Directory | Sort-Object -Property FullName -Descending: Gets all directories in descending order to ensure deletion from the deepest level first.
foreach ($directory in $directories): Deletes each directory and its contents without user interaction if it’s empty.
Running the Script Manually
Open PowerShell as Administrator.
Run the Script:
C:\Scripts\ClearIncomingQueue.ps1
Automating the Script with Task Scheduler
You can use Task Scheduler to automate the script.
Open Task Scheduler: Open it by typing taskschd.msc in the Run dialog.
Create a New Task:
Right-click and select “Create Task”.
General tab: Name your task (e.g., “Clear Files and Folders”).
Triggers tab: Click “New” and choose the schedule (e.g., daily).
Actions tab: Click “New” and select “Start a program”. Enter powershell.exe as the program/script.
In the “Add arguments (optional)” field, enter: -File "C:\Scripts\ClearIncomingQueue.ps1"
Conditions tab: Check “Start the task only if the computer is on AC power”.
Settings tab: Check “If the task fails, restart every” and set an interval.
This setup ensures that files and directories under the specified path are automatically deleted when the available disk space falls below 5 GB, without any user interaction.
Your infrastructure may have multiple locations and, depending on those locations, many network subnets. In some cases, you may choose to use multiple network subnets to separate services even within a single data centre.
If you are using Active Directory as the directory service in your infrastructure, you need to add these subnets to ‘Sites’ under "Active Directory Sites and Services" and ‘Subnets’ under that.
You can add subnets most simply with a few right clicks on the "Active Directory Sites and Services" console. This is usually the method that everyone uses.
This process also has an equivalent in the PowerShell world. Although it is generally not preferred by those who do not like to work with scripts, there is no better method than this when you want to do batch processing.
If you have hundreds of subnets that you need to define, you can do it in seconds with the following script.
You can use Microsoft’s free Multi-Factor Authentication (MFA) application to further increase the security of your Office 365 users in your organization. Of course, for this, your organization must have minimum Azure AD, Microsoft 365 and Microsoft 365 license types.
If you want to enable MFA for all or some of your users in your organization, you can follow the steps below; Method 1: You can access the MFA area via the console and take action for users. Login to Office 365 Admin Center –> Active Users –> Multi-factor authentication
Method 2: You can do it using Connect-MsolService cmdlet powershell commands. You can use three different methods, “EnablePerUserMFA”, “BulkImportEnable” and “EnableAllUserMFA”.
In cases where there are too many members in the group you want to change roles, it may not be efficient to do this from the management console, or you may not see the action taken.
For example to list servers without VMXNET3 adapters you can changing the -eq parameter; Get-Vm | Get-NetworkAdapter | Where-object {$_.Type -ne "Vmxnet3"} | Select @{N="VM";E={$_.Parent.Name}},Name,Type
If you want to export these lists into .csv file usage Export-Csv command; Export-Csv C:\VMXNET3_Adapter.csv -NoTypeInformation
I know it sounds like a very simple process.It is usually told that you can open the powershell application and access it with the “Connect-VIserver” command sets. This information is correct but incomplete because the need to required install the powershell module.
If you have installed the module, you can now connect to VMware vCenter via Powershell.
Connect-VIserver -Server vCenter -Port 443
If you get an error like the one below while connecting, you can use the command below to ignore the warning.
Error: Invalid server certificate. Use Set-PowerCLIConfiguration to set the value for the InvalidCertificateAction option to Prompt if you’d like to connect once or to add a permanent exception for this server. Additional Information: Could not establish trust relationship for the SSL/TLS secure channel with authority