by Dan DiNicolo
Welcome to article number 12 in my 70-240 in 15 minutes a week series. This week’s article is the final installment in the Windows 2000 Server portion of the series, and covers fault tolerance options as well as security configuration and analysis. The good news is that this week’s article is a little shorter than usual, since we’re just tying up loose ends. Next week we’ll begin our look at material relating to the Implementing and Administering Active Directory portion of the series, which should last approximately six to seven articles.
The material that this article will cover includes:
– Windows 2000 Fault Tolerance options
– Security Configuration and Analysis
– Security Template overview
– Introduction to IPSec and associated policies
Windows 2000 Fault Tolerance options
Windows 2000, like Windows NT 4.0, still supports what is commonly referred to as software RAID, or Redundant Array of Independent Disks. In software RAID, the OS handles all RAID functions, and the system does not require a separate RAID controller card. Although the software method is less expensive, it is certainly slower and less reliable than traditional hardware RAID. Windows 2000 supports three types of RAID as described below. Note that all RAID configuration is handled via the Disk Management MMC tool.
RAID 0 – now referred to as a ‘striped volume’, this is usually used to speed up access to data. In this configuration, which supports between 2 and 32 physical disks, data is striped evenly across the disks, which act as a single logical volume. Although the name suggests redundancy, there is in fact no redundancy in a RAID 0 configuration. Should a single volume in the striped volume fail, access to data on that volume will be lost. In Windows 2000, new striped volumes can only be created on dynamic disks, although existing stripe sets from NT 4.0 can continue to exist on basic disks in the case of an upgrade. Essentially that means you can have stripe sets if you upgraded, but cannot create new RAID 0 until you upgrade all hard disks that you wish to be part of the new configuration to dynamic disks. Note that neither the system nor boot partitions can reside on RAID 0 volumes.
RAID 1 – referred to as a ‘mirrored volume’, in this configuration data is mirrored between 2 physical hard disks for the purpose of redundancy. In this configuration (which is very popular for the system or boot partitions) everything written to the first volume in the mirror set is also written to the second by the fault tolerant driver ftdisk.sys. In the event that the first volume in the mirror should fail, the data will still be accessible via the second disk. As with RAID 0 in Windows 2000, new implementations can only be done on dynamic disks. However, mirror sets from NT 4.0 can exist and function (and be repaired) if you performed an upgrade to Windows 2000. RAID 1 implementations do have a cost associated with them, using up twice as much disk space as would normally be necessary.
RAID 5 – referred to as a RAID 5 volume in Windows 2000, it is also commonly known as a stripe set with parity. In this configuration, which can utilize between 3 and 32 physical disks, not only data but also associated parity information is striped across the disks. Data and its associated parity information are always stored on different disks, which ensures that data can be rebuilt (and thus still accessed) in the event of a single disk failure. Again, new RAID 5 volumes can only be created on dynamic disks, although NT 4 stripe sets with parity can continue to exist if you performed an upgrade. As with stripe sets, the system and boot partitions cannot reside on a RAID 5 volume. Also note that there is an overhead associated with RAID 5 volumes – 1/X of the disk space will be used by parity information, where X is the number of disks in the set.
Security Configuration and Analysis
Windows 2000 provides an MMC snap-in tool for analyzing the security configuration of a system. The Security Configuration and Analysis snap-in allows you to compare the current configuration of a system with settings found in security template files, pointing out inconsistencies between the two settings. Although a system can be configured using this tool, it is usually better to export settings to a template file, which can then be deployed to multiple systems using Group Policy in an Active Directory environment. However, settings can be configured on a system-by-system basis if required.
The Security Configuration and Analysis tool requires a working database in which to store system configuration information for the purpose of the comparison. This file has an .sdb extension, and must be opened (or created if starting from scratch) prior to importing a security template for the purpose of comparison. After the .sdb file has been created, one of the pre-defined security templates provided with Windows 2000 can be imported, as can any templates that you have created. Imagine that you wanted to check and see whether a certain system on your network met the requirements of your pre-defined enterprise-wide security settings that you have stored in a template. You could simply open a new .sdb file, and then import the template and compare the security settings to those on the system. The analysis will literally show which settings meet, do not meet, or are not defined in the template you imported. As shown below, the password policy on my system does not meet many of the requirements mapped out in a provided template called securews.inf (more on templates coming up).
Welcome to article number 12 in my 70-240 in 15 minutes a week series. This weeks article is the final installment in the Windows 2000 Server portion of the series, and covers fault tolerance options, security configuration and analysis, and IPSec and associated policies.