Deploying Windows Server 2012 (part 2) - Installing Windows Server 2012 - Planning partitions, Naming computers, Network and domain membership options

When you are working with Windows Server 2012 on BIOS-based systems, you should be aware of the special types of drive sections used by the operating system:

Although these volumes or partitions can be the same, they are required nonetheless. When you install Windows Server 2012, the Setup program assesses all hard-disk-drive resources available. Typically, Windows Server 2012 puts the boot and system volumes on the same drive and partition and marks this partition as the active partition. The advantage of this configuration is that you don’t need multiple drives for the operating system and can use an additional drive as a mirror of the operating system partitions.

A GUID partition table (GPT)–based disk has two required partitions and one or more optional (original equipment manufacturer [OEM] or data) partitions (up to 128 total):

Although EFI-based computers can have both GPT and MBR disks, the computer must have at least one GPT disk for booting.

Now that you know how Windows Server 2012 uses disks on both BIOS-based and EFI-based computers, consider carefully how you want to partition the hard disk drives. The boot and system files require about 10 GBs of space. To allow for flexibility, you should create a partition for the operating system with at least 40 GBs. This allows for the addition of service packs and other system files later. Don’t forget that you should also have enough disk space for the pagefile and crash dump; I recommend reserving additional disk space equivalent to twice the installed RAM for this purpose.

Although a server could have a single hard disk with a single partition, it sometimes is better to have multiple partitions, even if the computer has only one drive. By using multiple partitions, you can separate operating system files from application data as might be a recommended best practice for the application. Although this permits the use of services that require installation on nonsystem partitions, it could make migrating to a future operating system more difficult.

For systems with multiple disks, this is a good time to think about whether you want to use a redundant array of independent disks (RAID) to add fault tolerance for the operating system. RAID can be performed at the hardware level or at the operating system level. You will find that the hardware-based RAID provides the best performance and is the easiest solution.

Increasingly, enterprises are using storage arrays. If your servers are allocated storage from storage arrays, keep in mind that each logical unit number, or LUN, assigned is a virtual disk and that the virtual disk likely is spread across multiple physical disks (also called spindles). Here, hardware RAID is configured within the storage array and you might not need additional software-based RAID. That said, several software RAID options are available and administrators often will want to implement one of these options as an additional safeguard, including

RAID options include the following:

Software-based RAID is implemented by using dynamic disks. For a bare-metal installation, the disks on the computer should be formatted as basic disks, and then after installation, you could upgrade to dynamic disks so that you can implement software-based RAID. On existing installations, the computer might already have dynamic disks, which could be the case if a computer is currently using Microsoft Windows Server and you are performing a new installation of Windows Server 2012. Keep in mind, however, that dynamic disks are deprecated for all usages except mirrored boot volumes. If you want to mirror the volume that hosts the operating system, you might want to use dynamic disks because this is one of the best approaches.

For resilience, virtual disks that you create as part of a server’s Storage Spaces can use mirroring or parity as well. As part of software configuration, you cannot use RAID 0 with system or boot volumes. More typically, operating system files are mirrored, and application data is striped with parity. If you plan to mirror the operating system, you will need two disks. If you plan to create a RAID-5 volume for your data, you’ll need at least three disks.

It is surprising how few organizations take the time to plan out the names they’re going to use for their computers. Sure, it is fun to have servers named Lefty, Curly, Moe, Ducky, Ruddy, and Aardvark, but just what do the names say about the role and location of those servers? You guessed it—nothing, which can make it difficult for users and even other administrators to find resources they need. Not to mention the management nightmare that happens when your six cutely named servers grow to number 50 or 500.

Rather than using names that are cute or arbitrary, decide on a naming scheme that is meaningful to both administrators and users—and this doesn’t mean naming servers after the seven dwarfs or Lord of the Rings characters. OK, it might be cool—way cool—to have servers named Bilbo, Gandalf, Frodo, and Gollum. But pretty soon you’d have Galadriel, Boromir, Theoden, Eowyn, and all the rest of the cast. And at that point, you’d better be ready to field lots of questions, such as, “How do you spell Aeyowin, anyway?” or “What’s Thedding, and where is it again?”

To help users and ease the administrative burden, you might decide to use a naming scheme that helps identify what the computer does and where it is located. For example, you could name the first server in the Engineering department EngServer01 and the first server in the Technical Services department TechServer01. These names identify the computers as servers and specify the departments in which they are located. You might also have servers named CorpMail01 and CorpIntranet01, which identify the corporate mail and intranet servers, respectively.

Although naming conventions can be helpful, don’t go overboard. The names EngServer01, TechServer01, CorpMail01, and CorpIntranet01 help identify computers by role and location, but they aren’t overly complex. Keeping things simple should help ensure that the computer names are easy to remember and easy to work with. Stay away from overly complex names, such as SeattleSrvBldg48DC17 or SvrSeaB48F15-05, if at all possible. Overly complex names are unnecessary in most instances and probably contain information that most users don’t need. For example, users won’t care that a server is in building 48 or that it is on floor 15. In fact, that information might be too specific and could actually help someone who wants to break into or sabotage the corporate network. Instead of putting exact mapping information in the computer name, keep a spreadsheet that maps computer locations for administrative use, and include only general information about the location or department in the computer name.

While we’re talking about security, keep in mind that some organizations use server names with arbitrary character strings on purpose. They want to make the network infrastructure difficult to discover and navigate for anyone trying to gain unauthorized access. Thus, they might use computer names like Srv4Wg8th3kb12a or Tkl82jeb4j2e9pz. Here, the organization is using random 15-character strings as computer names but giving up ease of use and reference with the goal of enhancing overall security.

Finally, keep in mind that computer names must be unique in the domain and must be 64 characters or less in length. The first 15 characters of the computer name are used as the pre–Windows 2000 computer name for Network Basic Input/Output System (NetBIOS) communications and must be unique in the domain as well. Further, for Domain Name System (DNS) compatibility, the name should consist of only alphanumeric characters (A–Z, a–z, and 0–9) and the hyphen.

During installation, you must decide on several important network and domain membership options, such as the following: