Re: Iso Windows Server 2012 R2 Foundation
Denna Repaci
As with previous Windows versions, your hardware must meet certain requirements for Windows Server 2012 R2 to function properly. First of all, Windows Server 2012 R2 requires a 64-bit processor; Microsoft has discontinued 32-bit software with this release of Windows Server. Table 2-2 outlines the minimum and recommended hardware requirements for Windows Server 2012 R2 as provided by Microsoft:
In addition, you must have the usual I/O peripherals, including a keyboard and mouse or compatible pointing device and a wired or wireless network interface card (NIC). If you can connect to a network location on which you have copied the contents of the Windows Server 2012 R2 DVD-ROM, you are not required to have a DVD-ROM drive on your computer. As with any other operating system installation, you will receive improved performance if you have a faster processor and additional memory on your system.
Further, when you install Windows Server 2012 R2 on an Itanium-based computer, you must have an Intel Itanium 2 processor and additional hard disk space. Computers with more than 16 GB RAM require additional disk space for paging, hibernation, and dump files. With disk space at an all-time minimum cost, it is easy to acquire a high-capacity hard disk. You will certainly need plenty of disk space on a server that will be a domain controller in a large domain.
As explained in Chapter 1, Windows Server Core includes a minimal version of the server software without the GUI; you perform all configuration tasks from the command prompt. Follow this procedure to install Windows Server Core and perform initial configuration tasks:
You receive the options shown in Figure 2-4 to upgrade or install a clean copy of Windows Server 2012 R2. Select Custom (advanced) to install a clean copy of Windows Server 2012 R2. The upgrade option is available only if you have started the installation from within Windows Server 2008, Windows Server 2008 R2, or the original version of Windows Server 2012.
Take a coffee break while the installation proceeds. This takes some time (particularly when installing on a virtual machine), and the computer restarts several times. As shown in Figure 2-5, Setup charts the progress of installation.
Type and confirm a strong password. When informed that the password is changed, click OK. After a minute or so, the desktop appears, containing a command window but no Start screen or desktop icons (see Figure 2-6). This is the standard Windows Server Core interface.
All configuration, management, and troubleshooting of Windows Server Core is done from the command line. Available utilities enable you to perform almost all regular configuration tasks in this fashion. In Windows Server 2012 and 2012 R2, many of the commands used with Server Core in Windows Server 2008 have been replaced by PowerShell cmdlets. Table 2-3 describes some of the more useful available commands.
Available commands also include most commands formerly used with MS-DOS and previous Windows versions. We discuss many Server Core commands and PowerShell cmdlets in various chapters of this book and other Cert Guide books in this series.
When you shut down a Windows Server 2012 R2 computer, it displays the Shutdown Event Tracker dialog box, which asks you for a reason for shutting down the server. For learning purposes, it is helpful to disable this item. You can do so by typing gpedit.msc to open the Local Group Policy Object Editor. Navigate to Computer Configuration\Administrative Templates\System, right-click the Display Shutdown Event Tracker policy, and click Properties. On the dialog box that appears, click Disabled and then click OK.
You can upgrade a computer running Windows Server 2008 R2 with Service Pack 1 (SP1) or later to Windows Server 2012 R2, provided that the computer meets the hardware requirements for Windows Server 2012 R2. You cannot upgrade a Windows Server 2003 or older computer or a computer running any client version of Windows to Windows Server 2012 R2.
You can convert the full GUI version of Windows Server 2012 R2 to Server Core or vice versa at any time; further, you can interconvert the GUI version between any of the three options described in Chapter 1.
If you are converting a server that was originally installed in GUI mode back to GUI from Server Core, the procedure is slightly simpler. Use the following PowerShell command in place of those given in steps 2 and 3:
To install the complete desktop experience on your server (including access to Windows Store apps as in Windows 8 or Windows 8.1), use the following PowerShell command and then restart your computer. This mode adds a link to Windows Store on the Start screen, as shown in Figure 2-9:
Installing the minimal server interface on your server requires you to remove the Start screen shell. Use the following PowerShell command and then restart your computer. You receive a command prompt window and the Server Manager console as previously shown in Figure 2-8.
As an organization grows, administration of servers can become become quite overwhelming to manage. To help balance the workload and create a smooth support process, a delegation model should be implemented. Implementing a delegation model involves the following:
Preparing for a delegation model requires some planning up front. Deciding how to manage your systems administration can be a frustrating task. The key to success is to define a model that best works for your situation, agree upon the long-term strategy, and discipline those involved to stick with the model. There are three basic strategies to select from when deciding how to manage your environment:
For example, the main office might contain the majority of the systems. These systems are managed by senior administrators or an enterprise admin group. Branch sites might contain locally significant servers such as file servers that are managed by site admins and/or the enterprise admin group. Desktop engineers might be delegated administrative access to all desktops but might escalate issues to site admins or even enterprise admins if necessary.
Once a delegation model has been selected, the next step is to decide how to delegate access. Depending on the server, installed roles, and applications installed, there are different ways to delegate access. In some cases, applications or roles include an interface where elevated access is granted. In most other situations, local built-in groups can be used to grant different access to different delegates depending on their function.
When delegating administrative tasks, it is a good practice to create separate delegate accounts for users. The idea is to operate on the principle of least privilege, meaning for normal operations you would use a standard user account with enough access to perform your job. When elevated privileges are required, invoke the run as function or log in with your delegate account. This reduces the risk of unintentional changes that could make for an unpleasant day for the admin.
One of the major benefits of Active Directory is that you can split up administrative tasks among various individuals using the AD DS Delegation of Control Wizard. You can assign different sets of administrative responsibility to different users, and these can include segments of the directory structure such as OUs or sites. The following are several benefits of delegating administrative control:
When designing your AD DS forest structure, you should keep in mind the administrative requirements of each domain. Each domain has the capability to contain a different OU hierarchy. The forest administrators, who are members of the Enterprise Admins group, are automatically granted the ability to create an OU hierarchy in any domain within the entire forest. Domain administrators, who are members of the Domain Admins group in each separate domain, by default are granted the right to create an OU hierarchy within their own domain.
When you initially create your OU design, you should do so to enable administration. After that, you should create any additional OUs required for the application of Group Policy and management of computers. Delegation of Control and management of AD DS are discussed in more detail later.
Before using administrative tools, you must first ensure that the necessary access rights have been granted and that you have addressed any prerequisites, such as .Net Framework 4.5, Windows Management Framework 4.0, or Firewall configurations.
As mentioned previously, Windows PowerShell Desired State Configuration (DSC) was designed to enhance the levels of automation through the use of PowerShell 4.0. It helps administrators cut down on repetitive tasks by defining prebuilt configurations that accompany PowerShell 4.0 cmdlets. Configuration parameters are saved in a Managed Object File (MOF) and can be used as a baseline for comparison or as a template for new deployments. DSC is often used in the following situations:
DSC works through the basis of defining configurations within scripts. Using Notepad, you can build a custom DSC configuration. Configurations contain several components, all of which are organized within a configuration block. The keyword Configuration tells PowerShell that a specific configuration is to follow. The use of braces identify the start and end of the configuration. Together, both of these items create the foundation of a configuration block. The basic structure of a configuration block is
Inside the configuration block, node blocks are identified. A node represents a computer in the environment. Nodes are used when you need to apply a configuration block to a specific computer or computers. Like configuration blocks, node blocks start and end with a brace . Multiple node blocks can be created within a configuration block, although a configuration block does not have to contain any node blocks. Depending on the requirements, you might need to use node blocks.
d3342ee215