Windows system >> Computer software Tutorial >> Server technology >> Server synthesis

Solve Windows login performance issues in Active Directory environment

Windows Login Performance Factors

When looking for the cause of login performance issues, it is important to consider a number of factors. Some factors include:

The domain controller is too close to the user

Network connection and available bandwidth

Hardware resources on the data center ( X64 vs.x86, memory, etc.)

Group Policy (GPO, which directly affects bandwidth) applied to users and computers

Number of security groups where users and computers are located (also directly affects bandwidth)

GPOs that require additional processing time include settings such as loopback processing, WMI filters, and ACL filtering.

The heavy load domain controller is caused by the following factors: applications that require authentication Invalid LDAP query from user script or application, host other applications, such as Exchange, IIS, SQL Server, etc.

Client configuration: memory, disk, processor, etc., network interface (10, 100 or 1000), appropriate subnet mapping and DNS configuration to the site

Defining the scope

In order to define the actual scope of the problem, I usually spend time Ask a simple question. This requires some effort because these questions are usually defined by the user who complains about the problem. Here are some important questions to ask:

Is these questions defined as a single site, security group, OU, department, client type (notebook or desktop) or operating system?

Does the problem happen at some point of the day?

When you are in the office or cross-VPN connection, is there a problem?

Describe the symptoms: Does the delay occur at some point each time? (For example, on the login screen "On Network Settings"), before or after the login page?

When did it happen?

Tools and Data Collection

I use some basic tools to collect data. For performance issues, I like to spread the network and collect all the information that can be collected. See the example below:

Run Microsoft Product Support Report (MPSreports) on the client and their authentication data center. This is a commonly used tool that collects all event logs, MSINFO32, NetDiag, PConfig, drivers and hotfixes. Hewlett-Packard itself has a version called HPS Reports. In my opinion, it is more advanced than Microsoft tools. If you run it in a data center, you can collect specific Active Directory data. It also collects redundant information about the hardware, even HP hardware.

On the client side, use Microsoft KB article 221833 to set up lengthy logins for Winlogon system processes. This will provide precise details in the %Systemroot%\\Debug\\UserMode\\Userenv.log file. Note that this log does not include the data date, so you must:

Remove the existing userenv.log from the client
Start the verbose login for each KB 221833
Logout, log in and save userenv.log to a new location to restrict data collection during login

Note that userenv.log is very accurate in the following GPO and configuration files. And usually you can clearly see where the login delay has occurred.

Enable Net Logon login. The Netlogon log is located at %systemroot%\\debug and is empty if login is not enabled. For example, it shows which client in the subnet is not mapped to the site. This causes the client to authenticate outside of the data center and requires a longer login time than expected.

Run Process Monitor from Sysinternals. See the details in the Help section on the Enable Launch Log. You can capture process information during slow startup to see which processor is affecting performance.

Other tips for slow client login

You can also check the following to see if a login is caused by a known issue. performance.

First, check the GPResult.exe and LOGONSERVER environment variables on the client. MPSreports and HPS Reports will collect GPResults for logged in users. They do not collect LOGONSERVER variables that point to the authentication data center. . This is important because every time a user logs in, the GPO is downloaded to the client. SYSVOL (with GPO) is the DFS root and does not obey the client site warning. Instead, it collects the data center (host SYVOL DFS root) with random commands and can then download the GPO from the first data center in the list.

I have encountered a situation where the client at the primary service site will connect to the data center outside the slow WAN to get the GPO, resulting in a very slow login time. . Since this can happen on every login, this problem is intermittent.

Check the GPResult for the data center where the GPO is downloaded and see if the GPO is coming from outside the data center. Similarly, compare the LOGONSERVER variable to see if the client is validating outside the data center. With known slow or busy connections, the login delay can be interpreted as "normal" behavior.

Another good test is to use the network boot security mode to see if a delay has occurred. If not, then perform Net Start and list all started services. Then start and run Net Start in normal mode, listing all services again. This difference can prove which service is suspect, and eliminating one at a time can help you identify the problem. You can also try to disable the app that started when it starts, and see if the app is the cause.

The final technique is to use Netmon, Wireshark or another network capture tool for network tracing. Since you are trying to capture the login process, connect the dumb hub to the network cable, then connect the cable from the hub to the PC in question, then connect another cable to another PC or laptop with Netmon or WireShark installed. Run the capture tool in mixed mode and copy the login. This setup will ensure that the capture tool collects traffic inside and outside the client and eliminates network noise.

The above is the basis you need to master.