Windows Server


Basic Troubleshooting steps    



Basic Troubleshooting steps


Basic Troubleshooting Steps

These are the basic troubleshooting steps that will come in handy for almost all of the relevant issues with in an Active Directory Domain Environment where in it needs troubleshooting.

These are some basics that need to be checked and done for troubleshooting.

You can follow and verify these steps for basic Windows Server Troubleshooting in almost any case it may be.

Please read through the following steps divided into sections, to help you guide through the troubleshooting for the most common and repeated issues that are seen while doing troubleshooting. It consists of network issues and issues that may cause slow system startup, slow user login/logon and group policy setting getting applied or not or slow group policy processing.

Please feel free to ask questions in the user forum.

You may also leave comments to this article below.


Technorati Tags: windows server 2008, windows server 2003, active directory domain service, Troubleshooting

Step 1:

Topics to focus :


TCP/IP Stack

Packet Fragmentation,

Ports and Firewall Issues

TCPIP Filtering - permit all

Name Resolution, Packet Fragmentation and Network Open Ports for connectivity


Please check that you have a healthy DNS server in the network with good records to work with.

In the TCP/IP stack check that you are pointing to the correct preferred DNS server for DNS name resolution.

Name Resolution is important for revealing the address of the target server on which to begin the communication with. For every service in the network that either has a Client - Server Architecture OR has a Server - Server Architecture it is necessary for one host / server to know the address of the target with whom it is communicating. Many services (almost all of them) depend on DNS Records for Resolving host names to IP addresses. It is critical to know: That it is easy to manage (create and remember) names in DNS FqDN format where in the names are written and mapped to an IP Address. There are specific DNS Records for these Host names that map them to a particular server using / by knowing its IP Address. DNS Resolution helps translate human readable names to computer IP Addresses. So if DNS Resolution is working fine then you are sure to get the correct address of the target system. If we know the correct address then only we can begin our communication else it will fail. So DNS name resolution is critical for network communication.

DNS holds the data that maps host names to IP Addresses. Name resolution helps clients to get the IP Addresses of the desired machine, if they know its DNS name; i.e. if they know what records to query for. The machines/systems are designed to hold names for machines with them. The process of name resolution is dynamic and it occurs at run-time. So it is critical for network communication as it is the way by which machines know the correct address of other machines.

Just make sure that DNS Server is healthy (i.e. the records that it hold are good) and the Clients that need DNS Name resolution for Active Directory in the Network point to the correct DNS Server. This setting can be checked in the Properties of the NIC Card under Network Connections window in Control Panel.

Hence it is critical to have a Healthy Good DNS Server in the Network for name resolution and also the DNS Server mentioned in the Preferred DNS Server section of the TCP/IP Stack for every client should be proper and point to the relevant /decided DNS Server; what it should be there.

Notice that the Server on which DNS Server is installed also has the DNS Client role for which it needs to make DNS queries; you should first design your strategy for DNS and then point this server to a relevant DNS Server for Name Resolution.

In case you need to open internet Access inside the Active Directory Domain, point every client to the internal DNS Server and then on the DNS server configure a forwarder to forward query requests to a public DNS Server. This public DNS server can be your ISP's DNS Server or a freely available DNS Server like mentioned here: List of public DNS Servers.

Once you are sure that DNS is working fine and we can rely on the current configuration; then move to the following step:

Disable TCPIP Filtering and set it to permit all.

Check packet fragmentation using the ping -f -l command line utility.

Check for (open) ports using the PortQryUI utility.

Whenever communication occurs in a network; the data being transferred is broken at several steps of the TCP/IP Model (OSI Model Layers). It finally travels in forms of packets of data being routed between machines with IP Addresses.

Each packet that is sent over a network can vary in size from network to network. This dependency on the Network is called in a value called as the MTU (Maximum Transmission Unit). This is the maximum working size of data that can be sent in a packet.

If the size is over flown, the packets start getting dropped in the network.

And if size is too low then the transmission of overall data over the network will take more time. So take the MTU seriously.

MTU size is critical for Optimum Network Performance.

We can check packet fragmentation using the ping command in the following syntax:

Ping -f -l <size-in-bytes>

The best value for size-in-bytes is 1472.


Now once the MTU is set correctly.

Check what ports you need for connectivity between the host and the destination machines. These ports should be open on these machines for the connectivity to ever occur. Make a list of all the services running on the machines in Context. Then make sure what ports they (the machines) will be using for In-Bound and Out-Bound traffic, and then make rules specifically for these ports on the Machines firewall configuration; i.e. open the ports up.

PortqryUI is a handy nifty utility that might come handy in case you need to check open ports on the target from the host machine/workstation. You can get PortqryUI here: PortQryUI.


If packets are getting dropped somewhere in the network then use the following:

Registry key: MaxPacketSize
HKLM\System\CCS\Control\Lsa\ Kerberos\Parameters
DWORD MaxPacketSize Value = 1 Decimal


Win 2k3 uses Kerberos UDP by default:
How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000

You receive a "Directory Service failed to replicate the partition" error message when you try to promote a member server to a domain controller over a VPN connection

The function of the registry key MaxPacketSize is to allow kerberos to pass packets in TCP format inspite of UDP if the packet size exceeds 1 MB in size.

NOTE: Maxpacketsize and enable PMTUBHDetect are used in case of WAN and in a network where packets are getting fragmented

Kerberos uses UDP by default on port 88. UDP is a connectionless protocol. Meaning that the host will never get acknowledgement of the packet being received by the target. On the contrary TCP is a connection Oriented protocol, i.e. the host knows what data has been sent and received by the target destination computer machine. It verifies the receipt of the data on the target. So the host knows that what data has already been received by the target destination and what data still needs to be sent across the network. So if packets start getting dropped in the network then the host will never know about it is the transmission was done using UDP. So make this registry key on the host, so that if the packet data size is larger than 1 MB then it forces the host to use Kerberos over TCP/IP rather than UDP.

It is helpful because TCP is a connection oriented protocol however UDP is not.

So if there is an error in the transmission of packets then TCP detects it and resends the whole packet again making the transmission error free.


Step 3:

In case of black hole routers use the following registry keys:

Registry key:--> EnablePMTUBHDetect
Value Name: EnablePMTUBHDetect
0 = Disable
1 = Enable

// Network admins need to manually check the settings in the router configuration interface, if there is any less than 1472 MTU set.
How to Troubleshoot Black Hole Router Issues
#Method 3 is recommended

Recommended TCP/IP settings for WAN links with a MTU size of less than 576

Black hole Routers are those Routers which do not send an acknowledgement if any packet is dropped.
Part of a packet gets dropped due to packet fragmentation
So after enabling the EnablePMTUBHDetect key :
It starts negotiation with the Router starting from MTU (940+20=960) and then increases the packet size and decides the max. negotiation size at which the packets can be sent.

NOTE: Maxpacketsize and enable PMTUBHDetect are used in case of WAN and in a network where packets are getting fragmented


Black hole routers present an issue by not telling the host machine(s) about the event of a packet drop. They don't tell the machines of the packet they dropped. So the host never knows how and where the packet was dropped. That is why these routers are called Black Hole Routers. So that's why they are considered an issue to be resolved.

The registry key "EnablePMTUBHDetect" enables the host machines (windows workstation clients / member servers) to set the MTU size automatically to its optimum value by detecting the drop of packets in the network on its own.

It starts negotiating with the Router starting from MTU size 960 bytes(940+20=960) and then increases the packet size step by step, thereby reaching a value that can successfully pass through the Router and to the destination. Thus deciding the maximum negotiation size at which the packets can be sent over the network in case of a Black Hole Router.


Step 4:




Data type Range Default value

REG_DWORD 0 | 1 1

Value Meaning

0 : TCP uses an MTU of 576 bytes for all connections to computers outside the local subnet.

1 : TCP attempts to discover the MTU of the path to a remote host.

This key EnablePMTUDiscovery determines whether TCP uses a fixed, default maximum transmission unit (MTU) or attempts to detect the actual MTU.

By discovering the Path MTU and limiting TCP segments to this size, TCP can eliminate fragmentation at routers connecting networks with different MTUs. Fragmentation reduces TCP throughput and increases network congestion.

By default, this entry applies to all interfaces. However, the MTU can be reduced for any particular interface by changing the default value of the MTU entry in the subkey for that interface.

EnablePMTUDiscovery is a registry key that can enable the windows operating system to discover the working MTU size in effect itself by sending packets of variable size to the destination. By sending packets of data in variable sizes the Windows Operating System can determine what MTU size will be set for future data transfers so that the packets do reach the destination successfully and not drop in the middle of the path; EnablePMTUDiscovery enabled the Windows OS to discover the Packet Maximum Transfer Unit that will work in the network for flawless network communication.


Step 5: (optional)

For Windows server 2003 SP2 onwards

TCP Off-Load
Win 2k3 SP2 +
For any Network Issues, Disable the below three keys:

Values: 1 (enabled) 0 (disabled))

Values: 1 (enabled) 0 (disabled))

Values: 1 (enabled) 0 (disabled))
} Change them to '0' and REBOOT
} //these three Reg. Keys act as a Firewall. OR they create a Blockage at the NIC .
The Microsoft Windows Server 2003 Scalable Networking Pack release


These are some advanced options as available in Windows Server 2003 SP2 onwards. Sometimes they may cause network issues. We suggest that you disable them unless you are using them specifically. The above mentioned registry keys are as suggested with values to disable these features on a Windows Server 2003 SP2.


These set of features are as available on Windows Servers starting Windows Server 2003 SP2 onwards. We do not recommend that you disable them on a Windows 2008 or onwards server. And hence you should not disable them on a Windows Server Running Windows Server 2008 Onwards Operating System.

Only disabling them is recommended on Windows Server 2003 SP2 Operating System and not on a Windows Server 2008 Operating System. The reason being that Windows Server 2008 Operating System understands them better and works smoothly with these new features. However, the Windows Server 2003 SP2 might sometimes screw it together with the old settings, so for compatibility sake you can/may disable them on Windows Server 2003 SP2 Operating System.


Step 6:

Group Policy:



Comp Conf. > Administrative Templates > System > Logon > "Always WAIT FOR NETWORK AT START-UP AND LOGON"



# NOTE :--> never use this over a VPN


When this group policy setting is used, the client computer on which the Group Policy is applied always waits for the Network Server / the Domain Controller to be available for accessing the SYSVOL and NETLOGON shares, before allowing the user to login to the desktop. So if this policy is in effect then the client workstation will show a large delay in user logon if the Network is not optimized well OR if the user is logging-in to the Active Directory through a VPN where the speed is very slow.


Make sure that you do not apply this policy setting on machines that are supposed to be used over a VPN Connection.


Whenever your clients are experiencing long delays in system reboot / System Logon, then it is a good practice to verify this Group Policy Setting for that OU in which the Computer and/or the user logging-in reside. If this setting is in effect then the machine is sure to apply the latest Group Policies and not jump to the login screen OR Desktop by a request time-out in the network.


NOTE: This Group Policy can be applied at any level of OU.


Step 7:


Group Policy:



COMPUTER POLICY + USER POLICY > Administrative Templates > System > Group Policy > "GROUP POLICY SLOW LINK DETECTION"


                >= 500 Kbps


By default the value for a slow link is something that is less than 500 Kbps, otherwise what value you specify in this Group Policy setting will come into effect. Whenever GROUP POLICY SLOW LINK DETECTION Group Policy comes into effect and it detects a slow link, it will not update the Group Policies on the client workstation to the latest available policies; rather it will bypass and apply the old group policies from the cache.


NOTE: This Group Policy can be applied at any level of OU.


It is a good practice to check this Group Policy setting if you are experiencing issues with "Group Policy not getting applied".


More on this Group Policy:

·        Group Policy slow link detection


Step 8:




To turn off Fast Logon Optimization, you can use the following policy setting:

Computer Configuration\Administrative Templates\System\Logon\ Always wait for the network at computer startup and logon

When this policy is enabled, a Windows XP client behaves in the same manner as a Windows 2000 client at both system startup and at user logon.



Description of the Windows XP Professional Fast Logon Optimization feature






This is a policy setting that optimizes the availability of Desktop to the end -user.

To optimize system performance you may enable this policy.

When troubleshooting if this policy is enabled then that helps the user to get to his/her Desktop readily.


Step 9:


SMB                    [ NO REBOOT REQUIRED ]


a) Registry:

HKLM\SYSTEM\CCS\Services\{Lanmanserver OR LanmanWorkstation}\Parameters


Enable Security Signature    =    1

Require Security Signature    =    0




CrashOnAuditFail    =    0



b) Policy:    [Default DC Policy]

COMPUTER > WINDOWS > Security > Local Policy > Security Options > Microsoft Network (Client/Server): [ __/-- ]


For both 'Microsoft N.S'    and    Domain Member: Digitally Sign Communication (Always) : Disabled }



Prevents SMB Packet Signing.

Prevents Secure Channel Signing.



This Policy (OR Registry) is used to declare policy for SMB Signing and Secure Channel Signing.

If enabled, then Signing is used when available for the machines.

If set to required, then Signing is made mandatory and those machines on which it is not enabled are not communicated with at all.


If you are experiencing Network issues, then do check these settings. The best value for these settings is to enable them, as it will allow network connectivity with both machine: One on which signing is available and other on which it is not.

For those machines on which signing is set to required (this means that signing is enabled and must be used) will only talk to those machines on which signing is available (machines, those on which it is enabled and on those on which it is required both fall in this category).


Step 10:



This Registry Setting "Crashonauditfail" if enabled will cause the Domain Controller server to reboot when the size of Audit Logs is to full capacity and there is no more space to write Audit Event Logs without overwriting the old logs. This registry is made to ensure that as the Audit Event Logs are full the system then reboots itself and will deny any machines to log-in into the domain and even non-Administrators to login into the Domain Controller.

The System Administrator must take a back-up of the Audit Event Logs and then clear the logs for the Domain Controller to function properly again.

This setting was designed to prevent any loss or Any Audit Event Log getting lost.

We recommend that you take a backup of the Audit Event Log before clearing it out for further use.


This setting ensures that no logs are lost from being seen by the System Administrator.


Sometimes if you are experiencing issues in which the Domain Controller is Rebooting again and again then it is a good idea to look at this setting and the issues caused by it, to troubleshoot further on the case.




Data type


Default value


0 | 1 | 2






The feature is off. The system does not halt, even when it cannot record events in the Security Log.


The feature is on. The system halts when it cannot record an event in the Security Log.


The feature is on and has been triggered. The system halted because it could not record an auditable event in the Security Log. Only members of the Administrators group can log on.



This problem occurred because the crashonauditfail policy was enabled on the DC and it rebooted due to security log problem. This causes the crashonauditfail registry value to be set to 2 and will not allow accounts that are not in the administrators group to logon to the DC in any way. Replication, DNS and FRS all run under the system account and fail logon attempt.


Setting crashonauditfail to value 1 and rebooting the DC will fix.


As a workaround, any machine account that requires access to the DC can be added into the administrators group to allow access until the crashonauditfail key can be changed and the DC rebooted.




No TrackBacks

TrackBack URL: http://www.skar.us/site/mt-tb.cgi/2795

Leave a comment


Author Bio          ★★★★★

Author Name:         administrator
Author Location:    India
Author Rank:          Writer
Author Status:        
The Green leave stands!!



  • eBooks
  • Games
  • Softwares
  • Tools
  • Tweaks
  • Wallpapers
  • Warez
  • Games
  • Tools
  • Wallpapers
    System Administration
  • dll Center
  • Scripts
  • Tools
  • .extensions database
  • Write-up
  • Download Database
  • Jobs
  • Lists
  • Polls
  • Glossary

01000011 01110010 01100001 01100011 01101011 01111010 01101000 01100001 01100011 01101011