Question 1

Windows 2000 Recovery Console on a mirrored volume: how can you install the Recovery Console now (for future troubleshooting) without breaking the mirror or reinstalling the operating system?

Accepted Answer

Introduction / Context:The Recovery Console is a minimal command-line environment used for system repair in Windows 2000. It can be installed post-setup, even on systems using software mirroring (dynamic disk mirror). Knowing the correct command avoids unnecessary mirror operations or a full reinstall.Given Data / Assumptions:Windows 2000 is already installed and running.The system volume is mirrored (software RAID 1).You want Recovery Console installed for future emergencies.Concept / Approach:Microsoft provides a supported method to install the Recovery Console from within Windows: run Setup in maintenance mode using the '/cmdcons' switch from the installation source. This adds a boot menu entry and copies the necessary files without altering the mirror.Step-by-Step Solution:Insert the Windows 2000 CD (assume it is drive X:).Open a command prompt and run: X:\i386\winnt32.exe /cmdconsConfirm the prompt to install the Recovery Console.Reboot to verify the Windows boot menu now includes 'Microsoft Windows 2000 Recovery Console.'Verification / Alternative check:After installation, check the root of the system drive for the 'CMDCONS' folder and the boot menu entry in boot.ini.Why Other Options Are Wrong:Reinstalling Windows is unnecessary.Breaking the mirror introduces risk and is not required.Add/Remove Programs does not provide a Recovery Console installer.None: A valid, supported method exists.Common Pitfalls:Running the command from the wrong path; assuming the mirror prevents RC installation; forgetting to keep the CD accessible for file copy.Final Answer:Run X:\i386\winnt32.exe /cmdcons

Question 2

IIS logging shows that requests between 7:00 PM and midnight are appearing in the following day’s log file. You need each day’s web activity to be recorded in that same day’s log. What should you change on the web site?

Accepted Answer

Introduction / Context:IIS (Internet Information Services) supports multiple log formats. The common W3C Extended Log File Format timestamps entries in Coordinated Universal Time (UTC) by default, and there is a separate option controlling when log files roll over and how they are named. If rollover uses UTC while you expect local time, evening requests may appear in the next day's log.Given Data / Assumptions:Web sites have logging enabled.Third-party reporting expects daily files aligned to local dates.Entries from 7:00 PM to midnight are shifted to the next day's file.Concept / Approach:Adjust the logging configuration so that IIS rolls logs based on local time. In IIS 5/Windows 2000, under the site's Logging Properties, choose 'Daily' rollover and enable 'Use local time for file naming and rollover.' This keeps timestamps consistent with reporting expectations without changing the server's system time zone.Step-by-Step Solution:Open Internet Services Manager → select the web site → Properties → Web Site tab → Enable logging → Properties.Select W3C Extended Log File Format (if desired), and set 'Log file rollover' to 'Daily.'Check 'Use local time for file naming and rollover.'Apply settings and verify that files now roll at local midnight.Verification / Alternative check:After one day, confirm that a new log starts exactly at local 00:00 and the previous day's late-evening entries remain in the correct file.Why Other Options Are Wrong:Changing the log format alone does not alter rollover timing.Changing the host time zone is unnecessary and may disrupt other services.Time service account context is unrelated to log rollover.None: There is a specific logging property that fixes the issue.Common Pitfalls:Confusing UTC timestamps in log lines with file naming/rollover time; forgetting to adjust each site if multiple exist.Final Answer:Change the log rollover property for the web site to roll over based on local time (daily)

Question 3

You installed a second hardware RAID-5 array to mirror an existing hardware RAID-5 array for complete data redundancy. In Disk Management, right-clicking free space on the new array shows no option to create a new or mirrored volume. What should you…

Accepted Answer

Introduction / Context:Windows 2000 supports software mirroring (RAID 1) only on dynamic disks. Even when underlying storage is hardware RAID, Windows still sees logical disks that must be dynamic if you want to create OS-level mirror sets across them. If the disks are basic, the mirror option will not appear in Disk Management.Given Data / Assumptions:Two hardware RAID-5 logical disks are presented to Windows.Goal: create a mirror of one array to the other at the Windows level.Current state: right-click shows no 'New Volume'/'Add Mirror' because disks are basic.Concept / Approach:Convert both logical disks from Basic to Dynamic using Disk Management. After conversion, you can add a mirror to an existing simple volume or create new mirrored volumes. Remember that mirroring a RAID-5 with another RAID-5 duplicates data at a higher level; ensure this is operationally justified given capacity and rebuild implications.Step-by-Step Solution:Open Disk Management → right-click each array → Convert to Dynamic Disk.If mirroring an existing simple volume, right-click that volume → Add Mirror → select the disk on the other array.Allow synchronization to complete; monitor for errors.Validate redundancy by temporarily taking one side offline in a maintenance window.Verification / Alternative check:Post-conversion, the 'Add Mirror' option becomes available for simple volumes, confirming dynamic disk status is required.Why Other Options Are Wrong:Creating/formatting partitions on Basic disks does not enable mirroring.Extended vs. primary partition choice is irrelevant without dynamic disks.None: The necessary prerequisite is to convert to dynamic.Common Pitfalls:Overlooking that hardware RAID does not replace Windows' requirement for dynamic disks when using software mirroring; forgetting to back up before disk conversions.Final Answer:Convert both arrays to dynamic disks

Question 4

Terminal Services for mixed legacy clients: you deploy a Windows 2000 Server (not a domain controller) in Application Server mode so Windows 3.1, Windows 95, and Windows 2000 Professional clients can run a 32-bit app. The IT team must be able to rem…

Accepted Answer

Introduction / Context:Windows 2000 Terminal Services supports 'remote control' (shadowing) of user sessions natively when the server runs in Application Server mode. Proper configuration is done in Terminal Services Configuration (tscc.msc) and/or per user account properties—no third-party software is necessary, and Remote Administration mode would limit concurrent sessions to administrative use only.Given Data / Assumptions:Server is in Application Server mode (multi-user app hosting).IT needs to shadow users' sessions for troubleshooting.The server is not a domain controller (not required).Concept / Approach:Enable remote control in Terminal Services Configuration under the RDP-Tcp connection properties (Permissions and Remote Control tabs), and/or set 'Remote control' on user accounts (allow, require user’s permission, view or interact). Additionally, grant the IT group the 'Full Control' permission on the RDP-Tcp connection and the 'Remote Control' user right via the Terminal Services permissions dialog—not by changing generic RDP object permissions or server mode.Step-by-Step Solution:Open Terminal Services Configuration (tscc.msc) → Connections → RDP-Tcp → Properties.On the Remote Control tab, enable remote control (choose 'Interact' and whether to require user consent).On the Permissions tab, add the IT group and grant 'Full Control' for the connection.Optionally, in each user's account properties, set remote control options.Verification / Alternative check:Use Shadow (or MMC tools) to attach to a live session; prompt and interaction confirm configuration.Why Other Options Are Wrong:Remote Administration mode disables multi-user app hosting and limits to 2 admin sessions.Granting Full Control on 'RDP protocol' generically is not how shadowing is enabled; it requires the remote control setting.Power Users membership does not grant shadow rights.Third-party tools are unnecessary because Windows provides native shadowing.Common Pitfalls:Misunderstanding server mode; not enabling Remote Control on the RDP-Tcp connection; forgetting user consent prompts block shadowing if not allowed.Final Answer:None of above

Question 5

You must deploy a custom registry setting to all users via Group Policy with minimal effort. Which method integrates the custom setting into a Group Policy Object (GPO) for centralized management?

Accepted Answer

Introduction / Context:Group Policy in Windows 2000 exposes registry-based policy settings via Administrative Template (ADM) files. If a required setting does not exist in the default templates, you can author a custom ADM that writes the necessary registry values under the policy-managed branches, and then link it in a GPO for consistent, centralized deployment to users or computers.Given Data / Assumptions:Need to configure a specific registry value for all users.Desire: leverage Group Policy, not per-machine scripting.Environment: Windows 2000 domain.Concept / Approach:ADM templates define UI elements in the Group Policy Editor and map them to registry locations. By writing a simple ADM with CATEGORY/POLICY/ACTIONLIST elements that set or remove the target keys, administrators can manage the setting with checkboxes and ensure it applies during policy refresh.Step-by-Step Solution:Author a .ADM file that targets HKCU or HKLM as appropriate and specifies the registry path/value.Open the target GPO → User Configuration → Administrative Templates → right-click → Add/Remove Templates → Add your ADM.Configure the new policy setting (Enable/Disable with desired registry data).Allow policy refresh or run 'gpupdate /force' (on later OS) or logoff/logon.Verification / Alternative check:Examine the registry on a client after policy application to confirm the value is present; RSoP can show that the GPO applied.Why Other Options Are Wrong:INF security templates focus on security settings, not arbitrary user registry preferences.MSI deployment is for applications, not raw registry keys (unless wrapped in a transform/custom action, which adds complexity).RIS is for operating system deployment, not ongoing policy enforcement.None: A direct ADM-based solution exists.Common Pitfalls:Placing settings outside the policy branches (which may not revert); forgetting to remove 'Only show policy settings that can be fully managed' when using custom ADM.Final Answer:Create a custom ADM template and add it to the GPO

Question 6

During RRAS setup at a branch, an incorrect modem driver was installed on a Windows 2000 Server. Removing the modem via Phone and Modem Options causes the system to hang each time. You must install the correct driver quickly. What should you do next?

Accepted Answer

Introduction / Context:When a faulty or incompatible driver causes the system to hang during removal, the safest remediation is to take the hardware out of the equation so the operating system can boot cleanly and forget the device instance. Windows 2000 will then detect the modem as new hardware on the next insertion, allowing you to load the correct driver.Given Data / Assumptions:Modem driver is incorrect and removal attempts freeze the server.The device is on an expansion card (not integrated).Rapid recovery is required.Concept / Approach:Physical removal prevents the bad driver from initializing at boot. After booting without the device, Windows will drop the active device instance. Re-inserting the card triggers Plug and Play detection; you can then supply the correct driver package. This avoids risky registry edits and repeated system hangs.Step-by-Step Solution:Power down the server and remove the modem adapter.Boot the server; confirm stability and absence of the modem.Shut down and reinsert the modem card.Boot and install the correct driver when prompted by the Hardware Wizard.Verification / Alternative check:Device Manager should now show the modem correctly installed without exclamation marks, and RRAS should be able to use it for dial-up.Why Other Options Are Wrong:Software removal tools are already shown to hang; repeating with a different wizard may still fail.Manual registry deletion is dangerous and time-consuming.The Modem Troubleshooter relies on the same subsystems that are failing.None: There is a practical, low-risk physical removal path.Common Pitfalls:Forgetting to have the correct driver ready; not grounding yourself when handling hardware; reinserting in a different slot may change resource assignments—note the COM port/IRQ if relevant.Final Answer:Shut down, physically remove the modem card, restart, then shut down again and reinsert the card to install the correct driver

Question 7

Your server has two existing hard disks, and you add a third 100-GB hard disk to speed up a client–server application that is slow when returning query results. To maximize read/write throughput for this workload, which RAID level should you choose?

Accepted Answer

Introduction / Context:Disk I/O can bottleneck database-style client–server applications. RAID levels trade performance, capacity, and fault tolerance differently. When the explicit goal is the highest possible performance and no requirement for redundancy is stated, RAID 0 (striping) is the fastest option because it distributes reads and writes across multiple spindles without parity overhead.Given Data / Assumptions:Additional 100-GB disk is added to improve performance.Primary concern is speed, not resiliency.Typical workload: many reads and writes associated with query execution and temp files.Concept / Approach:RAID 0 splits data into stripes written across disks concurrently, increasing aggregate throughput and IOPS. RAID 1 mirrors data for redundancy but provides at best modest write performance improvements and halves usable capacity. RAID 5 adds parity for fault tolerance but incurs a write penalty (read-modify-write), which slows small random writes common in query workloads.Step-by-Step Solution:Evaluate workload: throughput and IOPS are priority.Choose the RAID level with no parity or mirroring overhead: RAID 0.Configure the array across at least two disks (three yields even more throughput).Place database temp/log files appropriately to exploit parallelism (if applicable).Verification / Alternative check:Benchmark before/after with representative queries to confirm lower latency and higher throughput on the striped volume.Why Other Options Are Wrong:RAID 1: Prioritizes availability; write performance gains are limited.RAID 5: Write penalty harms performance under frequent updates.RAID 2: Obsolete/not implemented in commodity controllers.None: A clear performance-maximizing choice exists.Common Pitfalls:Ignoring that RAID 0 has no fault tolerance—if any disk fails, the volume is lost. Use backups and consider RAID 10 if both speed and redundancy are required.Final Answer:RAID 0 (striping)

Question 8

Windows 2000 startup failure after repartitioning: The server now shows ‘‘Windows 2000 could not start because \system32 toskrnl.exe is missing or corrupt.’’ What change will correctly fix the boot path after adding a new partition?

Accepted Answer

Introduction / Context:After resizing or adding partitions with a third-party tool, Windows 2000 may fail to boot with an ntoskrnl.exe error. Frequently, the kernel file is intact; the real problem is that the ARC path in Boot.ini points to the wrong partition, so NTLDR looks in the wrong place for the Windows folder.Given Data / Assumptions:Single disk, originally a single NTFS partition.A new partition was added and the partition order changed.Error references \system32toskrnl.exe missing/corrupt immediately after POST.Concept / Approach:Boot.ini uses an ARC path like multi(0)disk(0)rdisk(0)partition(n)\WINNT. Adding a partition can increment the partition index for the Windows volume. Correcting the partition(n) value in Boot.ini restores the loader's ability to find ntoskrnl.exe.Step-by-Step Solution:Boot from Windows 2000 media and enter the Recovery Console.Log on to the installation and open C:\Boot.ini with the edit command (or use bootcfg where available).Adjust partition(n) so it points to the actual Windows folder's partition.Save changes, exit, and reboot to verify successful startup.Verification / Alternative check:From Recovery Console, list directories on candidate partitions (dir c:\, dir d:\winnt, etc.) to confirm where \WINNT resides before editing Boot.ini.Why Other Options Are Wrong:System File Checker requires a running OS; it does not fix ARC path issues.Emergency Repair for system files won't correct an incorrect Boot.ini partition pointer.Safe Mode cannot be reached because the loader fails before kernel initialization.Common Pitfalls:Confusing drive letters with ARC partition numbers; drive letters in Recovery Console may differ from those in Windows. Always confirm the actual Windows directory before editing.Final Answer:Start the computer by using the Recovery Console and modify the Partition parameter in the operating system path in C:\Boot.ini

Question 9

Centralizing service-account local admin rights: You must ensure certain domain service accounts are members of the Local Administrators group on many Windows 2000 Professional computers. What is the best centralized approach?

Accepted Answer

Introduction / Context:Service accounts used by applications often need local administrative privileges on only a subset of machines. Manually adding them on each workstation is error-prone. Windows 2000 Group Policy provides a scalable way to enforce local group membership using the Restricted Groups setting.Given Data / Assumptions:Windows 2000 domain with many Windows 2000 Professional clients.Specific domain accounts must be Local Administrators on designated machines only.Computers can be organized into Organizational Units (OUs).Concept / Approach:Restricted Groups (Computer Configuration > Windows Settings > Security Settings > Restricted Groups) lets you define the exact membership of a local group on all computers within the scope of a GPO. Linking this GPO to the OU that contains only the target computers ensures scoped, centralized control without over-privileging.Step-by-Step Solution:Place the target computers into a dedicated OU.Create a GPO linked to that OU and configure Restricted Groups for ‘‘Administrators’’.Add the required domain service accounts (or a domain global group) as members.Force Group Policy update or wait for refresh; verify membership on clients.Verification / Alternative check:On a client, run ‘‘net localgroup administrators’’ to confirm the accounts were added, or use Resultant Set of Policy (RSoP) to validate application.Why Other Options Are Wrong:Adding to Domain Admins grants excessive rights everywhere.Local GPO per computer does not centralize management.A domain-level GPO would affect all domain computers, not just the intended subset.Common Pitfalls:Using the ‘‘Members of this group’’ list replaces existing members; include necessary defaults (e.g., Domain Admins) to avoid locking out support staff.Final Answer:Use an OU-linked Group Policy and configure Restricted Groups so the Local Administrators group on targeted computers contains the required service accounts

Question 10

Enabling DHCP across non–RFC 1542 router: Sales and Engineering are on separate subnets; Sales1 and Engineering1 run DHCP. The router cannot relay DHCP/BOOTP. How can you allow each DHCP server to support clients on the other subnet?

Accepted Answer

Introduction / Context:DHCP broadcast packets do not cross routers unless the router supports BOOTP/DHCP relay (RFC 1542). When a router lacks relay capability, a Windows server on each subnet can act as a relay agent to forward DHCP requests (broadcasts) to the appropriate DHCP servers via unicast.Given Data / Assumptions:Two subnets: Sales and Engineering.Sales1 and Engineering1 are DHCP servers; the router does not relay.Servers Engineering2 and Sales2 are available on each subnet.Concept / Approach:Deploy the DHCP Relay Agent (a Routing and Remote Access Service component) on one Windows server per subnet. Configure each relay to forward client broadcasts to the IP addresses of the DHCP servers. This enables cross-subnet leases without changing the router.Step-by-Step Solution:On Engineering2 and Sales2, install RRAS and add the DHCP Relay Agent.Specify the DHCP server IPs (Sales1 and Engineering1) as relay targets.Bind the relay to the local LAN interface on each subnet.Test client lease acquisition on both subnets.Verification / Alternative check:Monitor DHCP server logs for relayed requests from the other subnet and confirm clients obtain correct scopes and options.Why Other Options Are Wrong:Router option in scopes does not make the router a relay.RIP enables routing but does not translate/forward DHCP broadcasts.Running extra DHCP servers without scopes is ineffective and can cause conflicts.Common Pitfalls:Forgetting to add all DHCP server IPs in the relay agent or not binding the correct interface will prevent forwarding.Final Answer:Install and configure the DHCP Relay Agent service on Engineering2 and Sales2

Question 11

You must require strong passwords (complexity on) for local user accounts only, not domain accounts. Where should you configure Group Policy in a Windows 2000 domain with computers and users separated into OUs?

Accepted Answer

Introduction / Context:In Windows 2000, the domain password policy applies at the domain level to domain accounts. Local SAM accounts on member servers and workstations follow the effective Account Policies from the computer’s local security policy, which can be set via a GPO linked to the OU containing the computer.Given Data / Assumptions:Goal: enforce complexity only for local accounts, not all domain users.Computers and users are organized into separate OUs.Windows 2000 domain (mixed or native mode).Concept / Approach:Create or edit a GPO linked to the OU containing the target computers. Under Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy, enable ‘‘Passwords must meet complexity requirements.’’ This affects the local SAM on those computers and does not change the domain policy for domain accounts.Step-by-Step Solution:Identify the OU(s) with the computers whose local accounts require complexity.Create/link a GPO at those OU(s).Enable complexity and any other desired local Account Policy settings.Force policy update and verify via ‘‘secpol.msc’’ or ‘‘net accounts’’ on a member computer.Verification / Alternative check:Attempt to set a weak password for a local account; it should be rejected. Domain account policies remain governed by the domain's root GPO.Why Other Options Are Wrong:Domain-root policy would affect all domain accounts, not just local ones.User-OU GPO Account Policies do not apply to domain controller password policy nor to local SAMs on member computers.Configuring each local machine manually does not centralize enforcement.Common Pitfalls:Linking the policy to user OUs has no effect on local SAM account policies; ensure the scope targets computer objects.Final Answer:Link a GPO to the OUs that contain the computer accounts and enable ‘‘Passwords must meet complexity requirements’’

Question 12

Windows 2000 and Windows NT trust relationships are in place, but a Windows 2000 domain controller (DC1) using a highly secure security template is blocking access from Windows NT domain users. To restore access while keeping the trusts intact, what…

Accepted Answer

Introduction / Context: Windows 2000 introduced security templates that can harden domain controllers substantially (for example, restricting LM/NTLM, enforcing SMB signing, tightening cipher suites). When a Windows 2000 DC is locked down with an aggressive template, legacy Windows NT 4.0 clients and trusted domains may fail authentication or resource access even though two-way trusts exist. This scenario tests your understanding of interoperability between mixed-generation domains and the impact of security templates on legacy access.Given Data / Assumptions:Two Windows NT domains and a Windows 2000 domain have mutual trusts.DC1 (a Windows 2000 domain controller) uses a highly secure template.Users from the NT domain cannot access resources on DC1, but trusts themselves are configured.Goal: allow NT users to access DC1 while keeping the domain topology unchanged.Concept / Approach: Highly secure DC templates often disable or restrict down-level protocols (e.g., NTLMv1, unsigned SMB). NT 4.0 domains may still rely on these legacy mechanisms. The most direct, least disruptive fix is to adjust the security template applied to DC1 to a less restrictive custom profile that explicitly allows necessary down-level compatibility (e.g., permit NTLM where required, relax SMB signing requirements if appropriate). Changing domain mixed/native mode does not address authentication protocol mismatches and would not by itself re-enable access for NT clients.Step-by-Step Solution:Confirm the failure correlates with DC1’s hardening (event logs, security options).Duplicate the existing template and create a more compatible custom template.Lower specific settings (e.g., LAN Manager auth level, SMB signing) to permit NT access.Reapply the adjusted template to DC1 and test NT domain user access.Verification / Alternative check: After applying the less restrictive template, verify successful NT user authentication, access to shared resources, and absence of related security failures in the DC’s event logs. Ensure that you only relax the minimum settings required.Why Other Options Are Wrong:Apply a less restrictive policy to NT DCs: the access problem originates on DC1’s restrictions.Mixed/native mode changes: domain functional level does not directly fix protocol-level blocks from hardening.None of above: incorrect because template relaxation on DC1 is appropriate.Common Pitfalls: Over-relaxing unrelated settings; changing domain mode unnecessarily; assuming trusts alone guarantee interoperability without ensuring protocol compatibility.Final Answer: Apply a less restrictive custom security template to DC1.

Question 13

A third-party 32-bit app on Windows 2000 Server stops responding; CPU remains at 100% even after ending the app. Task Manager shows no apps and the process Application.exe is gone. To restore CPU usage to normal, what should you do next?

Accepted Answer

Introduction / Context: Sometimes a GUI task crashes, but helper components, services, or child processes that it spawned continue to consume CPU. On Windows 2000 Server, the Applications tab may be empty after ending the app, yet a background process can still peg a CPU. This question tests post-crash remediation: finding and terminating associated processes that persist after the visible program closes.Given Data / Assumptions:Application.exe has been ended; CPU stays at 100%.No other “applications” are visible, but background processes can remain.The goal is to return CPU to the normal 20–30% range without rebooting.Concept / Approach: Switch from the Applications tab to the Processes tab and sort by CPU usage. Identify any processes tied to the problematic application (e.g., helper EXEs, service-hosting processes if the app registered components) and terminate them in a controlled fashion. If the app used sub-processes, they may continue to run even when the parent exits. Stopping unrelated services like Server or Workstation does not address runaway CPU from an app component; restarting Explorer.exe is only relevant if Explorer is the offender.Step-by-Step Solution:Open Task Manager → Processes; enable columns for CPU and CPU Time.Sort by CPU to find the process consuming 100%.Correlate the high-CPU process with the failed app (name, path, user, description).Use End Process (or kill via tlist/kill if installed) to terminate the child.Reassess CPU usage; if stable, investigate root cause (patch or vendor update).Verification / Alternative check: After termination, CPU should return to baseline. Review Event Viewer and application logs to confirm no system service is looping due to the app crash.Why Other Options Are Wrong:Restart Server/Workstation services: not targeted; unnecessary service disruption.Restart Explorer.exe: helps only if Explorer is at fault; not indicated here.None of above: incorrect; ending remaining child/background processes is appropriate.Common Pitfalls: Looking only at the Applications tab; failing to sort by CPU; terminating critical system processes instead of the offending child; ignoring service-hosted components that need a service restart or server reboot if they cannot be cleanly ended.Final Answer: Use Task Manager to end any related child processes.

Question 14

You must preinstall, configure, and test Windows 2000 Server on 15 computers, then ship them so branch users can enter each computer’s name and product key on first boot. Which deployment method best meets this requirement?

Accepted Answer

Introduction / Context: Windows 2000 supports two primary automated deployment paths: unattended setup (using Unattend.txt and optional UDF files) and disk imaging with Sysprep (using sysprep.inf and Mini-Setup on first boot). When you need to fully preinstall and test systems in a lab, then hand off last-mile identity details—like product key and computer name—to remote users, Sysprep with Mini-Setup is the right tool.Given Data / Assumptions:All 15 machines will be installed, configured, and tested before shipping.Branch users will enter the computer name and product key upon first startup.Desire: identical image with per-machine identity finalized at Mini-Setup.Concept / Approach: Sysprep generalizes an installation and prepares it for imaging. A sysprep.inf file controls Mini-Setup prompts. If you omit ProductKey and ComputerName (or use prompts), Mini-Setup will ask the receiving user for those values. While the -noidgen switch is not generally recommended for mass deployment (unique SIDs are preferred), classic exam practice associated the combination “Sysprep + sysprep.inf + prompt for identity on first boot” with this choice. Unattended setup with Unattend.txt and UDF is better when you are installing fresh at the remote site, not when shipping preinstalled, tested images.Step-by-Step Solution:Build and configure a reference Windows 2000 Server.Use Setup Manager to create sysprep.inf; leave ProductKey and ComputerName to prompt.Run Sysprep to generalize; capture and deploy the image to the 15 PCs.At first boot in each branch, users supply the product key and computer name.Verification / Alternative check: Confirm that Mini-Setup runs on first boot and prompts for values. Validate that the deployed machines join the intended workgroup/domain configuration as required afterward.Why Other Options Are Wrong:Unattend.txt is used for fresh installs, not for preinstalled images.Hard-coding names does not meet the requirement for users to enter names/keys.None of above is incorrect because Sysprep with sysprep.inf fits the scenario.Common Pitfalls: Confusing Unattend.txt with sysprep.inf; forgetting to test Mini-Setup prompts; duplicating SIDs if improper Sysprep usage is chosen (ensure best practices in real deployments).Final Answer: Install Windows 2000 Server; use Setup Manager to create sysprep.inf for Sysprep and run sysprep -noidgen.

Question 15

A Windows 2000 Server configured to audit file access crashes with Stop C0000244 (Audit Failed) due to security audit generation failure. You need to keep auditing file access but prevent the crash from reoccurring. What is the best corrective actio…

Accepted Answer

Introduction / Context: Stop C0000244 (Audit Failed) indicates that Windows could not generate a required security audit event, commonly because the Security log was full and the system was configured to crash when auditing cannot continue (CrashOnAuditFail). For servers auditing every file access, log growth is significant. The solution should both preserve ongoing auditing and avoid another crash.Given Data / Assumptions:File access auditing is enabled and must remain enabled.Security log filled up, causing audit generation failure and a system stop.We need a durable configuration change to prevent recurrence.Concept / Approach: Configure the Security log policy to Overwrite events as needed. This ensures that when the log becomes full, oldest entries are recycled, allowing new audit events to be written and preventing audit failure stops. While increasing log size or periodically clearing the log can help, they do not guarantee continuity under sustained auditing. Setting CrashOnAuditFail to 0 prevents a crash but risks silently losing required auditing if the log is full and overwriting is not enabled. Therefore, enabling overwriting is the most direct, resilient fix compatible with continued auditing.Step-by-Step Solution:Open Event Viewer → Security log → Properties.Select “Overwrite events as needed.”Optionally increase maximum log size to extend retention.Implement regular archival (script log save + clear) to keep historical records.Verification / Alternative check: Monitor Security log behavior over a week of typical load. Confirm that events continue to be recorded and the system does not halt due to full logs.Why Other Options Are Wrong:CrashonAuditFail=0: avoids crash but can mask the underlying issue and still block event writes.Increase size: delays fullness but does not prevent it under sustained auditing.Daily save/clear: helpful, yet a spike between jobs can still fill the log.Delete License Trial key: irrelevant.Common Pitfalls: Forgetting compliance requirements for retention; failing to pair overwrite with archival; assuming a larger log is a permanent fix.Final Answer: Set the Security Log to overwrite events as needed.

Question 16

You added a second hardware RAID-5 array and want to mirror the original RAID-5 volume for full redundancy in Windows. The option to create a mirrored volume is unavailable on the new array. What must you do first?

Accepted Answer

Introduction / Context: Windows 2000 and later can provide software fault tolerance by mirroring (RAID-1) at the volume level. However, the ability to create mirrored volumes requires the disks to use the dynamic disk type (managed by the Logical Disk Manager), not basic disks. When underlying storage is already hardware RAID, Windows sees each array as a single disk; you can still mirror volumes between them using dynamic disks.Given Data / Assumptions:Two separate hardware RAID-5 arrays are visible as two disks in Windows.You want to mirror the volume on the original array to the new array.Disk Management does not show the mirror option for basic disks.Concept / Approach: Convert both disks from basic to dynamic using Disk Management. Only dynamic disks support creating mirrored volumes (and other dynamic volume types). Once converted, you can add a mirror to the existing simple volume (which sits atop the hardware RAID) so Windows keeps an identical copy on the second array. Partitioning or formatting steps on the new array are not prerequisites for enabling the Add Mirror function.Step-by-Step Solution:Open Disk Management; right-click each disk → “Convert to Dynamic Disk.”Right-click the existing simple volume → “Add Mirror…”Select the new dynamic disk (the second array) as the mirror target.Allow resynchronization to complete; verify redundancy and health.Verification / Alternative check: After conversion and mirror creation, Disk Management should display the volume as “Mirrored” with both plexes healthy. Test by temporarily taking one array offline (in a controlled maintenance window) and verifying continuity.Why Other Options Are Wrong:Create partitions/format: not required to expose the mirror option.Extended/logical: layout choice does not enable mirroring on basic disks.Common Pitfalls: Confusing hardware RAID with Windows dynamic disk mirroring; attempting to mirror while disks remain basic; overlooking backups before conversion (conversion is nondestructive but precautions are recommended).Final Answer: Convert both to dynamic disks.

Question 17

You installed Network Monitor on a dedicated Windows NT system (Monitor 2) to observe traffic from an application server. With only base OS on servers Monitor 1 and Monitor 2, what is the correct way to monitor the application server’s traffic remot…

Accepted Answer

Introduction / Context: Microsoft Network Monitor can capture traffic locally or remotely. For remote capture on Windows NT/2000, you pair a capture station with the target by installing and configuring the Network Monitor agent on the target, then authorize the capture station. This question checks knowledge of the remote capture pairing rather than arbitrary port configuration or installing the full analyzer everywhere.Given Data / Assumptions:Monitor 2 already has Network Monitor installed.The application server needs to be monitored; minimal additional software is acceptable.Goal: capture traffic from the application server without turning it into a full analyzer console.Concept / Approach: On the application server, install the Network Monitor Agent component and configure it to allow remote captures from the authorized capture computer (Monitor 2). This creates a “monitoring partners” relationship—Monitor 2 can initiate and control captures on the application server through the agent. Arbitrary “ECP/EDP ports” are not relevant settings, and installing the full analyzer on another box (Monitor 1) does not help capture the application server unless that is where you run the agent or the analyzer locally.Step-by-Step Solution:Install Network Monitor Agent on the application server via Add/Remove Programs → Networking.On Monitor 2, connect to the remote agent and set capture permissions.Start a remote capture; reproduce workload; stop and analyze the trace on Monitor 2.Optionally set capture filters to focus on the app’s ports or hosts.Verification / Alternative check: Confirm packets are captured when traffic is generated, and that capture files reflect the application server’s interfaces. Validate that only authorized stations can request captures from the agent.Why Other Options Are Wrong:Install Network Monitor on Monitor 1: irrelevant to monitoring the target.Install Network Monitor on the application server: full console not required; the agent suffices.ECP/EDP port settings: not a real configuration for Network Monitor.Common Pitfalls: Forgetting to install the agent on the target; lacking permissions from the capture station; attempting to mirror switch ports without SPAN/RSPAN when needed on switched networks.Final Answer: Configure Monitor 2 and the application server as monitoring partners to enable remote capture.

Question 18

You must ensure Group Policy changes apply to computers in the Finance OU within 15 minutes while users are logged on. Which setting should you configure to shorten the refresh cycle?

Accepted Answer

Introduction / Context: By default, Windows 2000 clients process Group Policy at startup and periodically in the background (every 90 minutes with a random offset). If you require rapid propagation—such as within 15 minutes—you must explicitly configure the computer refresh interval in policy. This question distinguishes between DC refresh (for policy on controllers) and client computer refresh (which affects the targeted OU’s machines).Given Data / Assumptions:Computers reside in the Finance OU.Users may remain logged on; background refresh must pick up changes.Desired maximum delay: 15 minutes.Concept / Approach: Edit the applicable Group Policy Object and set Computer Configuration → Administrative Templates → System → Group Policy → Group Policy refresh interval for computers. Specify 15 minutes (and optionally a small random offset). This ensures computers in scope will reapply policy at the new interval even while logged on. Domain controller refresh interval does not apply to client computers in the OU; “asynchronous application” impacts processing behavior, not interval length.Step-by-Step Solution:Open GPMC/Group Policy Editor on the Finance OU’s GPO.Navigate to the computer refresh interval setting and enable it.Set the interval to 15 minutes and choose a small random offset.Force a gpupdate /target:computer if using later OS, or wait for interval on Windows 2000.Verification / Alternative check: Check the event logs or use Resultant Set of Policy (RSoP) to confirm the setting is applied; observe that changes appear within the expected 15-minute window thereafter.Why Other Options Are Wrong:Default background refresh: remains at 90 minutes by default.Asynchronous settings: do not reduce the interval.Domain controller refresh: affects DCs only, not clients in Finance OU.None of above: incorrect because configuring the computer refresh interval is correct.Common Pitfalls: Editing the wrong GPO scope; setting the user refresh interval instead of computer; forgetting that Windows 2000 lacks gpupdate and relies on background refresh or reboot/logon for immediate enforcement.Final Answer: Enable and configure the Group Policy refresh interval for computers.

Question 19

On a Windows 2000 file server using NTFS quotas with a 100 MB default limit (deny disk space when exceeded), a user receives “The disk is full or too many files are open” when saving to her home folder. The IN_PROGRESS share is on the same NTFS volu…

Accepted Answer

Introduction / Context: Windows 2000 NTFS quotas can enforce per-user storage limits and deny additional disk space when users exceed their thresholds. When a user hits the hard quota limit, write operations fail with “disk is full” errors even though the physical disk may have free space. Understanding how quotas are measured and enforced is key to resolving the error quickly.Given Data / Assumptions:Default quota limit: 100 MB with “Deny disk space” enabled.User’s home folder and the IN_PROGRESS share reside on the same NTFS volume.Quota accounting is per user per volume.Concept / Approach: To resume saving, the user must reduce her quota consumption on that volume. Moving files to another folder on the same volume does not change her quota usage. NTFS quotas in Windows 2000 calculate usage by file ownership and logical size; compression does not necessarily reduce counted usage for quota purposes. Changing ACLs to give other users control does not transfer ownership automatically and is inappropriate. The practical fix is to delete or archive files off the volume (or to another volume) so that her usage drops below 100 MB.Step-by-Step Solution:Check current quota usage via the Quota tab or command-line tools.Identify large files in the home folder that can be archived or deleted.Move files to a different volume (if available) or remove unneeded files.Attempt the save again once usage is under 100 MB.Verification / Alternative check: After cleanup, the save should succeed; confirm quota usage is below the threshold. Administrators may grant a higher limit or create per-user exceptions if justified.Why Other Options Are Wrong:Compress files: quota typically counts logical size; compression may not help.Change security: does not affect ownership or quota accounting meaningfully.Move to IN_PROGRESS: same volume, same quota usage.None of above: incorrect because removing/reducing files below 100 MB is the fix.Common Pitfalls: Assuming any free disk space equals quota availability; moving files within the same volume; expecting compression to lower quota usage when quotas count uncompressed logical size.Final Answer: Remove files from her home folder until the total uncompressed file size is less than 100 MB.

Question 20

You want all Windows 2000 Professional clients to receive the latest Windows 2000 service pack automatically when they log on to the domain. What is the correct enterprise deployment approach?

Accepted Answer

Introduction / Context: In Windows 2000 Active Directory environments, software distribution to clients is commonly done using Group Policy Software Installation (GPSI) with Windows Installer packages (.msi). To ensure that every Windows 2000 Professional computer receives a service pack automatically at logon, you must integrate the package into a domain-based Group Policy Object applied to the target computers or users.Given Data / Assumptions:Clients are Windows 2000 Professional joined to the domain.Goal: automatic service pack delivery at logon.Centralized, AD-based deployment is preferred over manual updates.Concept / Approach: Build or obtain a Windows Installer package that wraps the service pack deployment and supports silent installation. Then use a GPO linked to the OU containing the clients to assign (to computers) or publish (to users, if appropriate). RIS is for OS deployment, not service pack rollout. Local Computer Policy affects only a single machine and does not scale. DFS provides distribution paths but does not automate installation by itself.Step-by-Step Solution:Prepare a tested MSI (or ZAP where MSI is unavailable) for the service pack.Create or edit a domain GPO → Software Installation.Assign to computers in the relevant OU so installation occurs at startup/logon.Test with pilot clients, then broaden deployment.Verification / Alternative check: Review client event logs for software installation entries; confirm the service pack level post-reboot. Ensure proper permissions to the distribution share and that the package supports silent parameters.Why Other Options Are Wrong:RIS: OS provisioning tool; not intended for service packs on existing installs.Local policy: non-scalable and not domain-wide.DFS: storage/namespace only; no install automation.None of above: incorrect because a GPO-based MSI deployment is correct.Common Pitfalls: Deploying via user assignment when computer assignment is required; neglecting reboot requirements; not testing transforms/customizations before broad rollout.Final Answer: Create a Windows Installer package for the service pack and assign/publish it via Group Policy.

Windows 2000 Server Questions

Questions

Practice smarter