A Windows NT Server 4.0 computer is the primary domain controller (PDC) and also runs SQL Server 2000. It has four processors and 1 GB of RAM. At morning logon time, 500 Windows Millennium Edition clients experience slow logons and occasional errors. System Monitor shows % Total Processor Time and % User Time averaging 90 percent, % Privileged Time averaging 20 percent, and Available Mbytes averaging 800 MB. You need to improve server performance for user logons without wasting memory. What should you do?

Introduction / Context:
Combining domain controller duties and SQL Server workloads on the same physical server can lead to resource contention, especially during peak logon times. In this scenario, CPU usage is very high while there is plenty of free memory, indicating that the bottleneck is the processors rather than RAM. SQL Server can be configured to use a subset of available CPUs, leaving one processor free primarily for the operating system and authentication services. This question asks which configuration change will best improve logon performance.

Given Data / Assumptions:

• The server has four processors and 1 GB of RAM.
• It is the primary domain controller and also runs SQL Server 2000.
• There are 500 Windows ME client computers on the network.
• During logon, % Total Processor Time and % User Time average 90 percent.
• % Privileged Time averages 20 percent, suggesting a mix of kernel and user work.
• Available Mbytes average 800 MB, so memory is not constrained.
• Users only complain about slow logons and occasional errors during peak authentication periods.

Concept / Approach:
Because CPU usage is high but memory usage is low, adding more memory is unlikely to help. The PDC must handle authentication and other domain services, which are critical during logon storms. SQL Server can consume significant CPU resources, potentially starving the domain controller functions. By configuring SQL Server to avoid using processor 0 (which the OS typically uses heavily), you can reserve one CPU mostly for the operating system and domain authentication. This is done using SQL Server's affinity mask or processor affinity settings.

Step-by-Step Solution:
1. Confirm from performance counters that CPU is the bottleneck and that memory is not under pressure. 2. Recognize that domain controller functions and authentication require CPU time, particularly on processor 0. 3. Open SQL Server configuration options and set processor affinity so that SQL Server uses only processors 1, 2 and 3. 4. Leave processor 0 unassigned to SQL Server so that the operating system and domain services can use it preferentially. 5. Monitor logon performance during the next peak period to confirm improved responsiveness on the domain controller.

Verification / Alternative check:
After applying the processor affinity change, use System Monitor again during morning logons. You should see CPU load distributed mainly across processors 1, 2 and 3 for SQL Server, while processor 0 is primarily serving system and authentication work. User reports of slow logons and errors should decrease. If necessary, further fine-tuning can be done by adjusting SQL Server max worker threads or planning to separate domain and SQL workloads in the longer term.

Why Other Options Are Wrong:
Option A, increasing physical RAM to 2 GB, does not address the fact that there is already 800 MB of free memory; CPU, not RAM, is the bottleneck. Option B, increasing virtual memory to 4 GB, likewise does not significantly help when memory is not exhausted and CPU is saturated. Option C configures SQL Server to use processors 0, 1 and 2, leaving processor 3 free; however, processor 0 is usually heavily used by the operating system, so giving it to SQL Server can worsen contention for logon processing. Option D correctly leaves processor 0 free for the OS and domain controller functions and is the best choice.

Common Pitfalls:
A common mistake is adding more memory automatically whenever performance issues arise, without checking whether memory is really the bottleneck. Another pitfall is running multiple critical server roles on the same machine without using processor affinity or resource controls, leading to unpredictable performance. In modern deployments, separating domain controller and database roles across different servers is recommended, but when that is not possible, careful tuning of CPU usage is important.

Final Answer:
You should configure SQL Server to use only processors 1, 2 and 3, leaving processor 0 available for the operating system and domain controller duties so that user logons are faster.