The remainder of this chapter provides some quick tips for NT admins transitioning to WS2003. These are listed in alphabetical order rather than order of importance. This list is by no means exhaustive in coverage; for detailed information about common WS2003 administrative tasks, see the Task Map in Chapter 3 and the cross references listed here to various topics in Chapter 4 and Chapter 5.
Configuring account policy—password and account lockout restrictions—was relatively easy in Windows NT using User Manager for Domains. In WS2003, you have to use Group Policy if you are in a domain environment, and you need a good understanding of Group Policy before attempting this. In a simple workgroup environment with standalone servers, you can edit the local security policy directly instead, which is simpler. Either way, see Group Policy in Chapter 4 before you try experimenting with configuring account policy. If you want to dive in right away, you can find the account policy settings in either:
Security Settings → Account Policies
Computer Configuration → Windows Settings → Security Settings → Account Policies
If you’ve tried installing WS2003, you’ve already been prompted to activate your product, unless you’re an enterprise client with a bulk volume licensing agreement with Microsoft. Activation is an antipiracy measure implemented by Microsoft on Windows XP and later; see Installation in Chapter 4 for more information.
Implementing Active Directory (AD) for an enterprise is not a trivial task. You can find information about administering various aspects of Active Directory in the topics Active Directory, Domain, Domain Controller, Forest, OU, Site, and Trusts in Chapter 4. You’ll also find some tips on planning AD implementation scattered among these topics, but for a more thorough and systematic treatment of planning AD implementation, see Active Directory by Robbie Allen (O’Reilly).
Instead of walking over to a domain controller to run Active Directory Users and Computers from the local console, you can install a complete set of WS2003 administration tools on a Windows XP Professional workstation and then use that as your main administrator workstation. Note that you must have Windows XP Service Pack 1 or later installed before installing these tools on your workstation. To install the Windows Server 2003 Administration Tools Pack, double-click on Adminpak.msi in the \i386 folder on your WS2003 product CD.
If you’re just starting out with WS2003, the two most important administrative tools you need to become familiar with here are:
Manages disks, shares, event logs, performance logs, services, and devices on a computer. You can use Computer Management to administer these things on either the local computer or on a remote computer—except that you can’t update device drivers or uninstall devices on remote computers. (Device Manager operates in read-only mode when connected to a remote computer.)
For more information on these two tools, see Administrative Tools in Chapter 4. These two tools, and most administrative tools in WS2003, are implemented with the Microsoft Management Console (MMC), a management framework that uses snap-ins to create administrative tools with a common look and feel. The MMC can also build your own customized administrative tools, which can then be distributed to administrators by email or shared over the network; see Microsoft Management Console in Chapter 4 for more information.
Configuring an audit policy was relatively easy in Windows NT using User Manager for Domains. In WS2003, you have to use Group Policy if you are in a domain environment, and you need a good understanding of Group Policy before you attempt this. In a simple workgroup environment with standalone servers, you can edit the Local Security Policy directly instead, which is simpler. Either way, see Group Policy in Chapter 4 before you try experimenting with configuring audit policy. If you want to dive in right away, you can find the audit policy settings in either:
Security Settings → Local Policies → Audit Policy
Computer Configuration → Windows Settings → Security Settings → Local Policies → Audit Policy
Microsoft Internet Explorer’s Enhanced Security Configuration is currently configured on your server. This enhanced level of security reduces the risk of attack from Web-based content that is not secure, but may also prevent web sites from displaying correctly and restrict access to network resources.
This feature is one of the “secure out-of-the-box” enhancements of WS2003, which installs in a more-or-less locked-down state as opposed to NT which installs in a more-or-less wide-open state. In effect, this means that the security setting for the Internet zone is set to High, so if you want to browse a relatively benign site such as Google, you have a few choices:
Add google.com to your Trusted Sites zone by entering the URL and then:
|File → Add this site to → Trusted Sites Zone|
Change the setting for the Internet zone to Medium so you can browse any Internet site:
|Internet Explorer → Tools → Internet Options → Security → Internet → Medium|
Disable the Internet Explorer Enhanced Security Configuration feature entirely:
|Control Panel → Add or Remove Programs → Add/Remove Windows Components → clear checkbox for Internet Explorer Enhanced Security Configuration|
The best solution is the first one. In general, you shouldn’t be browsing the Web on a server anyway; use a workstation instead to download drivers and perform similar tasks.
If you expect to have both Windows NT and WS2003 coexist for a while on your network, select NetBIOS computer names that will be compatible with both platforms (maximum 15 characters). Also, since WS2003 uses DNS as its name-resolution service when Active Directory is deployed, make sure your computer names are DNS-compatible as well (this means no underscores, periods, or spaces—only letters, numbers, and dashes).
Speaking of computer names, there is also the issue of share names to consider. When naming a shared folder or printer, it’s a good idea to avoid using spaces or special characters if your network contains a mix of WS2003 and other computers (such as Windows NT, Unix, and so on). Otherwise, some clients might have difficulty connecting to your WS2003 shares.
By the way, if you change the name of a domain or domain controller using the rendom utility on the WS2003 product CD, this can cause problems if you have downlevel Windows NT servers on your network and are using WINS for name resolution for these servers. This is because the WINS databases maintains the former name of your domain controller for a period of time, which can cause name-resolution problems for clients unless the offending records are flushed from the database.
Delegation is a powerful feature of WS2003 that helps administrators shuffle off some of their administrative responsibility to other trusted (trustworthy) users before overwork causes them to “shuffle off this mortal coil.” For more information see Delegation in Chapter 4.
One of the first things an NT admin will notice regarding the WS2003 desktop is that the standard NT desktop icons of My Computer, Network Neighborhood, Inbox, Internet Explorer, and My Briefcase are missing (only Recycle Bin is present). To get them back, do this:
|Right-click on desktop → Properties → Desktop → Customize Desktop → General → select the icons you want to appear on the desktop|
|Right-click on desktop → Arrange Icons By → Show Desktop Icons|
The desktop for WS2003 is basically that of Windows XP, so if you’re familiar with XP you should have no trouble with the basic desktop and navigation features of WS2003. For example, to select the Luna theme used by XP, first start the Theme service:
|Administrative Tools → Services → double-click on Themes → Startup Type → Automatic → Apply → Start|
Now enable the Luna theme:
|Right-click on desktop → Properties → Themes → Theme → Browse → C:\Windows\Resources\Themes → Luna.theme → Open → Apply|
For more information on desktop stuff like this, see Windows XP in a Nutshell by David Korp, Tim O’Reilly, and Troy Mott (O’Reilly).
If you are going to deploy and manage IP addressing on WS2003 using DHCP, you may want to disable the Automatic Private IP Addressing (APIPA) feature on your machines. If a system is configured for DHCP but is unable to contact a DHCP server when it first starts up, APIPA automatically assigns it an IP address from the reserved address range, 169.254.0.1 through 169.254.255.254. No warning message appears to say that the system has used APIPA instead of DHCP to obtain its address. The effects can be nasty, resulting in an inability to access other machines on the network because they are on a different subnet. Chapter 4 includes more details on DHCP and APIPA; see DHCP for DHCP issues and for APIPA, see TCP/IP.
Microsoft has borrowed the concept of mounted volumes from Unix and implemented the ability to mount a volume in an empty folder on an NTFS volume in WS2003. This feature helps you get beyond the 24-letter limit for mapped drives in Windows NT (see Disks in Chapter 4 for details). Note that, if used carelessly, this feature can cause problems; nothing prevents you from mounting a volume in a folder on a mounted volume, or even mounting a volume in a folder on itself!
A good tip when implementing disk quotas is to configure global quotas only and not quotas for individual users. Not following this recommendation can make quota administration a real headache.
DNS is used as the name-locator service for Active Directory in WS2003. This means you must have DNS servers implemented on your network if you want to connect to resources without specifying their IP address. For more information see Active Directory and DNS in Chapter 4.
NetBIOS is still an option for name resolution, however, and NetBIOS over TCP/IP is enabled by default (even in WS2003 functional-level domains) so downlevel (Windows NT/9x) computer names can be resolved if such systems are present. You can disable NetBIOS over TCP/IP using the Advanced TCP/IP settings box (see TCP/IP in Chapter 4). Note that, if you disable NetBIOS over TCP/IP, you can’t restrict a user’s access to specific workstations using the Account tab of the user account’s property sheet because this feature requires NetBIOS over TCP/IP in order to work.
WS2003 domains are quite different from NT domains (see Active Directory, Domain, and Forest in Chapter 4 for details). For example, you no longer need to separate master (account) domains from slave (resource) domains or manually establish trusts between domains. New domains are created by promoting standalone or member servers to the role of domain controller using Manage Your Server, which is accessible directly from the Start menu. You can create three kinds of domains this way:
The first domain controller of the root domain of the first tree in a new forest— in other words, the very first WS2003 domain controller on your network
The first domain controller of a new root domain, creating a new tree in an existing forest, with a two-way transitive trust created automatically between the new root domain and the root domains of existing trees in the forest
The first domain controller of a new child domain under an existing parent domain, with a two-way transitive trust created automatically between the parent and child domains
In Windows NT, one domain controller in each domain—the primary domain controller (PDC)—was special. The PDC was the only domain controller with a writable copy of the domain directory database, and all changes made to user, group, or computer accounts in the domain had to be made on the PDC. (If the PDC was unavailable, those changes could not be made.) All other domain controllers in the domain were backup domain controllers (BDCs), which contained read-only versions of the domain directory database.
With WS2003, domain controllers are all peers, and each domain controller contains a full writable copy of the Active Directory database. Replication between domain controllers follows a method called multimaster replication in which there is no single master domain controller. If you look under the surface, you find out that this is not quite the case. There are actually five special domain controller roles called flexible single master of operations roles or FSMO roles, which are found only on certain domain controllers in an enterprise. For information on these special roles, see Domain Controller in Chapter 4.
Speaking of PDCs and BDCs, the usual way to upgrade a Windows NT domain to WS2003 is to upgrade the PDC first, then the BDCs. The hitch is to make sure the former PDC is available on the network when you are upgrading the BDCs. If it isn’t, the first BDC you upgrade will think it’s the first domain controller in the domain and assume some of the operations master roles discussed earlier. Then when the former PDC comes back online, you will have a serious conflict between them, and the only way to resolve it is to wipe your former BDC and reinstall it from scratch.
I don’t recommend dual-boot configurations except for playing around at home, and you should know that volumes formatted with the version of NTFS on WS2003 (called NTFS5) support dual boots only on Windows NT 4.0 with Service Pack 4 or higher. If you are using an earlier version of NT and want to maintain it on a dual-boot configuration, you will be unable to use advanced features of WS2003’s NTFS, such as disk quotas and the Encrypting File System (EFS). Speaking of EFS, just because you encrypt a file or folder using EFS doesn’t mean you can’t accidentally delete it!
There’s no more ERD in WS2003. Instead, you can try Last Known Good Configuration, Safe Mode, the Recovery Console, and Automated System Recovery (pretty much in that order) if you have problems booting your system. See Advanced Options Menu, Backup, and Recovery Console in Chapter 4 for more information.
Event logs are pretty much the same as they were in Windows NT, although there are more of them on domain controllers and DNS servers, and an MMC console (Event Viewer) now manages them. If you run a high-security networking environment, you can configure a WS2003 system to halt when the event log becomes full. You need to configure a registry setting to do this; see Event Logs in Chapter 4 for more information. Also, when you install or upgrade a machine to WS2003, configure your event log size and wraparound settings immediately so you won’t lose valuable data that might be useful for troubleshooting later on.
WS2003 is forgiving of problems created when you update devices with incorrect or corrupt drivers. Such updates can sometimes prevent the system from booting to the point you can log on. If this is the case, simply press the F8 function key when the boot-loader menu prompts you to select an operating system to boot. This causes the Advanced Startup Options menu to appear. One of the menu items is the familiar Last Known Good Configuration, which restores the system to the state in which it last booted successfully. If this fails, you can select the Safe Mode option to boot using a minimal set of device drivers. For more information, see Advanced Options Menu in Chapter 4.
Speaking of the boot menu, in a normal Windows NT installation this menu displayed two options: Normal Boot and VGA Mode Boot. In WS2003, however, there is only one boot option: Normal Boot (there is no VGA Mode Boot menu option because safe mode takes care of this). As a result, in a normal WS2003 installation with only one operating system installed, the boot menu doesn’t appear at all. In this case, to open the Advanced Startup Options menu, just press F8 while it says “Starting Windows” at the bottom of the screen. If the Recovery Console is installed on a machine, however, the boot menu does appear because the Recovery Console is essentially a different operating system (a command-line version of WS2003). See Recovery Console in Chapter 4 for details.
For general information about managing hardware devices and device drivers, see Devices in Chapter 4.
The Setup Manager wizard-based tool can perform unattended installations of WS2003; it’s included in the \SUPPORT\TOOLS folder on your WS2003 product CD. It walks you through the process of creating an answer file; see Installation in Chapter 4 for more information.
If you plan to upgrade NT machines to WS2003, make sure their hardware supports it. Most shops will likely elect to install WS2003 on fresh machines instead and put their old NT boxes out to pasture afterward.
With Windows NT, some administrators chose to designate their boot partition as FAT while using NTFS to secure their data partitions. This enabled them to repair missing or corrupt system or driver files by booting from a DOS disk when these missing or corrupt files prevent successfully booting the system. This hack is no longer necessary with WS2003 because of Safe Mode and the Recovery Console, so the bottom line is that you should use only NTFS for your WS2003 boot volume because it is more secure than FAT or FAT32.
IntelliMirror is simply a buzzword for a hodge-podge of WS2003 features that enable users to access their desktops and data conveniently from any computer on (or off) the network. See Files and Folders, Group Policy, and Users in Chapter 4 for more information about offline folders, folder redirection, roaming user profiles, and other IntelliMirror technologies.
Like Windows NT, WS2003 provides two sets of permissions for access to files and folders: NTFS permissions and shared-folder permissions. The basic approach for secure shared resources is the same as with NT, but NTFS permissions require some relearning in WS2003 because they are more complex than they were in NT. See Permissions in Chapter 4 for more information.
One new feature of WS2003 is remote management of printers across a network (or over the Internet) using a web browser; see Printing in Chapter 4 for more information. Otherwise, printing is much the same in WS2003 as it was in NT. By the way, always let WS2003 detect Plug and Play printers and install drivers for them automatically; if you install the driver manually and reboot your machine, you may end up with two printers for the same print device! Also, specify a location for your printer when you create it using the Add Printer Wizard. Users will then be able to search for printers by location when they search Active Directory using Start → Search.
If you have migrated a Windows NT domain to WS2003 but still have Windows NT member servers running RAS (or RRAS) on your network, note that they will be unable to communicate with Active Directory to authenticate users trying to initiate RAS sessions. Either upgrade the RAS servers to domain controllers, or weaken RAS permissions for your WS2003 domain by adding the Everyone built-in special identity to the Pre-Windows 2000 Compatible Access built-in group; this allows the RAS server to use NTLM for authenticating RAS users. For general information on remote access in WS2003, see Routing and Remote Access in Chapter 4.
Configuring user rights was relatively easy in Windows NT using User Manager for Domains. In WS2003 you have to use Group Policy if you are in a domain environment, and you need a good understanding of Group Policy before you attempt this. In a simple workgroup environment with standalone servers, you can edit the Local Security Policy directly instead, which is simpler. Either way, see Group Policy in Chapter 4 before you try experimenting with configuring user rights. If you want to dive in right away, you can find the user rights settings in either:
Security Settings → Local Policies → User Rights Assignment
Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment
Although the Windows NT 4.0 Server Resource Kit included a GUI
utility to complement the
scheduling tool, WS2003 carries this further with
Scheduler, a wizard for scheduling tasks to be run (see
Tasks in Chapter 4 for more information). The
at command is still available for batch scripting
purposes, but it is best not to use it because of compatibility
issues between it and Task Manager. Instead, use the new
schtasks command, which is covered in Chapter 5.
An ordinary user account for browsing the Web, checking email, and doing other mundane stuff
A Domain Admins account for performing administrative tasks
In Windows NT, if an administrator was logged on with her ordinary account and had to perform an administrative task, she had to log off, log on with her admin account, perform the task, log off, and log back on with her ordinary user account. WS2003 makes this easier with Secondary Logon, a way of performing a task with different credentials than those used for the current logon session.
To illustrate, say you are logged on with your ordinary user account and want to run some command-line scripts using Administrator credentials. First open a command-prompt window by:
|Start → Command Prompt|
username is your Administrator
be prompted to enter your password, after which a second
command-prompt window opens up on top of the first that lets you
execute commands using your Administrator credentials. The current
directory of this new command prompt window is set to
%SystemRoot%\System32, which is where most
administrative tools (MMC consoles saved as .msc
files) are located. For example, to open the Computer Management
console as Administrator, type the following in the new window:
Alternatively, you can type the following instead in your original window:
You can also find the icon for the file compmgmt.msc in C:\Windows\system32 using Windows Explorer, right-click on it, and select Runas from the shortcut menu. For more information on Secondary Logon, see runas in Chapter 5.
In NT you could use Server Manager to send a console message to connected users before unsharing a shared folder or rebooting a server. In WS2003 you can use Computer Management to do the same; see Shared Folders in Chapter 4 for more information.
Use the Distributed File System (DFS) to combine your shared folders into one or more DFS trees. Users just connect to a DFS tree and browse the tree for the share they need, and they don’t need to know the name of the file server on which the share is located. See DFS in Chapter 4 for more information.
Publish the shares in Active Directory so users can search for them by location and by using friendly names. In this way users don’t need to know the names of the file servers hosting the shares. You can also configure permissions on the shared folder object you publish to Active Directory—not to control access to the share but to control who can find and view the information you have published to Active Directory about the share. See Active Directory in Chapter 4 for more information.
For general information about how to manage shared folders, see Shared Folders in Chapter 4.
Managing directory replication between Windows NT domain controllers and sites connected by slow WAN links was a hit-and-miss procedure of juggling various registry entries such as ChangeLogSize, ReplicationGovernor, and so on. Things are simpler in WS2003: use Active Directory Sites and Service to create sites that map to the physical (geographical) topology of your network, map well-connected subnets to each site, and create and configure site links to join sites together and control directory replication between them. See Site in Chapter 4 for more information.
If you have an NT network with System Policy implemented for locking down client desktops and other features, you should be aware that, when you upgrade your network to WS2003, these System Policies will not be upgraded to Group Policies. The reason is that Group Policy modifies special areas of the registry rather than the actual registry entries of the settings managed, whereas System Policy directly modifies the registry settings involved.
Likewise, if you migrate a portion of your network to WS2003, be aware that any Group Policies you configure will have no effect on your remaining NT machines. Therefore, you may want to continue using the NT System Policy Editor (poledit.exe) to create and manage System Policy on your downlevel machines (place the Ntconfig.pol file in the sysvol folder on your WS2003 domain controller for it to be applied). For more information, see Group Policy in Chapter 4.
used for running applications from a central terminal server and requiring special licensing
used for remote administration of WS2003 machines and supporting up to two concurrent connections
Administrators familiar with the Terminal Services Edition of NT will see many enhancements in WS2003, including improved display and sound capability.
WS2003 domains are simpler to manage than NT domains because two-way transitive trusts are automatically established between parent and child domains in a domain tree and between the root domains of trees in a forest. However, the fine print is that these trusts are transitive only after you convert your domains to Windows 2000 native functional level—in other words, when you no longer have any remaining BDCs in your NT domains. For more information on functional levels, see Domain and Forest in Chapter 4.
What NT called global
users are called domain users in WS2003
(see Users in Chapter 4 for
more information). Domain user accounts are created and managed using
the Active Directory Users and Computers console, which is quite
different from the old User Manager for Domains tool in NT. You can
also use two command-line tools,
ldifde, to simplify administration of large
numbers of accounts through batch operations (see these topics in
Chapter 5 for more info).
Global groups (similar to global groups in NT)
Domain local groups (similar to local groups in NT)
Universal groups (not found in NT)
The new universal groups and the enhanced nesting functionality of domain local and global groups is available only for WS2003 domains running in Windows 2000 native or WS2003 functional level. For more information about functional levels and groups, see Domain and Groups in Chapter 4.
Upgrading your NT servers to WS2003 has clear advantages for enterprises, the most obvious being the improved scalability and manageability associated with Active Directory. But what about upgrading your desktop machines to Windows XP Professional? This is bound to be a costly exercise because hardware on existing machines will have to be beefed up or replaced entirely. Is it worth it? Probably, for several reasons:
Remote management of XP Professional computers is a breeze using the Computer Management console, and it’s bound to reduce your help-desk costs significantly.
Group Policy enables enterprise-wide management of desktop settings, software installation, roving desktops, and other useful features.
Costs for training users will be minimal if users are already familiar with the desktop features of Windows 95/98 and Windows NT 4.0.
I’ll stop there lest I sound like an ad for Microsoft, but the fact is that there are compelling reasons why migrating desktop computers to XP Professional makes sense.