Rapid Search

Looks this site also good for rapid search http://www.filecrop.com
-------------------
Thanks,
Paddy

Administering Windows Server 2008 Server Core Machines

Administering Windows Server 2008 Server Core Machines

Now that your machine has been more or less configured and is ready to be deployed, it's time to discuss how you go about preparing the server for installation in different scenarios. As you know from earlier in this book, Windows Server 2008 offers groups of services, and the associated software, wrapped in "roles" that correspond to the likely environments in which you will deploy a machine. On a full installation of Windows Server 2008, these roles are installed using the Server Manager MMC console. On a Server Core machine, that is obviously not possible, as the graphical shell largely doesn't exist.

There is a command-line utility called oclist that allows you to view available roles to install on a machine with Windows Server 2008 Server Core. Once you have run oclist and identified any given role name, you can use that name in conjunction with the ocsetup utility to install or uninstall that server role or optional feature.

Some sample output from oclist

Note that the DHCPServerCore role is listed as not installed. Let's say that we wanted our Server Core machine deployed as a headless, GUI-less, stripped-down DHCP server for our enterprise. To prepare the machine, we need to install the DHCP Server role. Using the name we obtained from the oclist command output, we can start the role installation process with the ocsetup command, as follows:

ocsetup DHCPServerCore 

The system will trundle for a while, and the process should complete without errors. To verify that the role installation process is complete, run oclist again and then check to see whether the DHCPServerCore role is listed as "installed."

To uninstall a role, use the following command (in our case, should we want to uninstall the DHCP Server role):

ocsetup DHCPServerCore /uninstall 

Installing Active Directory Domain Services on Server Core

One role that you would likely want to install on a Server Core machine is the domain controller role. Installation of this role on a Server Core machine is a bit different, because installing the role using ocsetup has a large dependency on the graphical shell—meaning that using that method of setup can result in a very unstable Server Core machine that thinks it's a domain controller in some ways, but in other ways it doesn't.

The only supported way to install the domain controller role on a Server Core machine is to use the dcpromo utility in unattended mode. Using unattended mode requires setting up a simple text file with some parameters that will allow dcpromo to proceed without needing to prompt the user for any information, and ultimately you will be able to successfully promote a Server Core member server to a domain controller.

You need, at a minimum, the following nine parameters in a file called unattend.txt (or anything you want, as long as you remember the name):

[DCInstall] ReplicaOrNewDomain=Domain NewDomain=Forest NewDomainDNSName=hasselltech.local AutoConfigDNS=Yes DNSDelegation=Yes DNSDelegationUserName=username DNSDelegationPassword=password RebootOnSuccess=NoAndNoPromptEither SafeModeAdminPassword=breakincaseofemergency 

Then, to run the utility, just issue the following command:

dcpromo /unattend:unattend.txt 

Windows Remote Shell

Included with Windows Vista and full installations of Windows Server 2008 is the Windows Remote Shell, or WinRS. You'll also find WinRS on installations of Windows Server 2003 R2. WinRS consists of a listener portion that runs on the Server Core machine itself, and the client software on other machines. The client software sends commands addressed to specific machines to the listener port on that machine, and the WinRS software on the Server Core machine receives the command, executes, and transmits the output back to the originating client machine.

First, you'll need to activate the WinRS listener on the Server Core machine. Use the following command:

WinRM quickconfig 

 

Setting up the Windows Remote Shell listener on the Server Core machine

 

Once the listener is configured, you can simply go to any Windows Vista or Windows Server 2008 (full edition) machine, and funnel your Server Core-destined commands through winrs. For example, to see the results of the oclist command, issue the following at a command line on a Vista machine:

winrs -r:WS08-CORE-1 "oclist" 

Controlling Server Core Via Group Policy

Many administrators find setting up Server Core machines with a consistent configuration can be achieved most easily through the use of a targeted Group Policy attack. You can create a group policy object (GPO) that only applies to Server Core machines by limiting the application of the GPO's attributes via WMI to only machines operating with the Server Core SKU, or by creating an organizational unit (OU) within Active Directory Domain Services, placing only Server Core machines within that OU, and then linking the GPO to the newly created OU. I prefer the WMI method, as it doesn't force you to construct your AD hierarchy based on operating systems, although both methods ultimately work equally as well in terms of the desired effect.

To use the WMI method, filter the OperatingSystemSKU property under the Win32_OperatingSystem class. The applicable values are as follow: 12 represents the Datacenter Server Core edition, 13 represents the Standard Server Core edition, and 14 represents the Enterprise Server Core edition.
-------------------
Thanks,
Paddy

Available roles and features on Windows Server 2008 Server Core machines

Available roles and features on Windows Server 2008 Server Core machines
Roles available in Server Core	Features available in Server Core
Active Directory and Active Directory Lightweight Domain Services (LDS)	BitLocker Drive Encryption
DHCP Server	Failover Clustering
DNS Server	Multipath I/O
File Services (including DFSR and NFS)	Removable Storage Management
Print Services	SNMP Services
Streaming Media Services	Subsystem for Unix-based Applications
Windows Server Virtualization	Telnet Client
	Windows Server Backup
	WINS Server

-------------------
Thanks,
Paddy

Here are some other things you don't get with Windows Server 2008 Server Core:

Here are some other things you don't get with Windows Server 2008 Server Core:

• No .NET Framework, or even the common language runtime (CLR)

• No Microsoft Management Console, and no related snap-ins

• The vast majority of Control Panel applets are not present

• No Run box, and no Start menu to go with it

-------------------
Thanks,
Paddy

The New Architecture in IIS 7

The New Architecture in IIS 7

Modularity is the key word and was the ultimate design concept surrounding the complete redevelopment of the request processing pipeline in IIS 7.

There are 40 different modules that make up the feature set of IIS, divided into eight categories. These modules are individually listed here, so you can see how different modules make up the functional stack that is IIS 7.

Common HTTP Web Server Components

• StaticFileModule

• DefaultDocumentModule

• DirectoryListingModule

• HttpRedirect

• CustomErrorModule

Windows Process Activation Service

• ProcessModel

• NetFxEnvironment

• ConfigurationAPI

Security

• BasicAuthModule

• DigestAuthModule

• WindowsAuthModule

• CertificateAuthModule

• AnonymousAuthModule

• IPSecurityModule

• UrlAuthorizationModule

• RequestFilteringModule

Health and Diagnostics

• HttpLoggingModule

• CustomLoggingModule

• RequestMonitorModule

• HTTPTracingModule

• ODBCLogging

• LoggingLibraries

Performance

• HTTPStaticCompression

• HTTPDynamicCompression

Management

• ManagementConsole

• ManagementScripting

• ManagementService

• Metabase

• WMICompatibility

• LegacyScripts

• LegacySnap-in

Application Development

• NetFxExtensibility

• ISAPIModule

• ISAPIFilterModule

• CGIModule

• ServerSideIncludeModule

• ASP

• ASP.NET

FTP Publishing

• FTPServer

• FTPManagement

New: The Windows Process Activation Service

All installations of IIS 7 require a service new to Windows Server 2008, known as the Windows Process Activation Service, or WPAS. WPAS essentially maintains and administers all worker processes and application pools for IIS on any given machine, listening for new requests and either assigning them to existing processes or starting new work processes and marshalling the request to that process. WPAS also acts as a clearinghouse for configuration information for sites, application pools, and overarching web applications running on the machine.

-------------------
Thanks,
Paddy

Group Policy Management Tools

Group Policy Management Tools

It's important to note that there are several paid third-party tools available to help you manage GPOs, their scope and effect, and their application, including the following:

FAZAM

FAZAM tracks changes to GPOs, provides version control for GPOs, allows new or changed GPOs to move into production only after being tested and approved, eliminates the risk of making changes to a live production environment, handles multiple users making simultaneous changes, and enhances GPO administration delegation. However, there are reports that this tool does not work well with Windows 2000 and is fully functional only on Windows Server 2003 and later. FAZAM is available at http://www2.fullarmor.com/solutions/group.

NetIQ Group Policy Administrator

NetIQ Group Policy Administrator handles change and release management to keep better track of GPO modification, creation, and deletion, and enhances change simulation and analysis of hypothetical GPO deployments above and beyond what Windows Server 2008 provides. NetIQ Group Policy Administrator is available at http://www.netiq.com/products/gpa/default.asp.

Quest ActiveRoles

Quest ActiveRoles allows junior-level administrators to securely make changes to important elements of Active Directory, including GP. Quest ActiveRoles is available at http://www.quest.com/fastlane/activeroles/.

-------------------
Thanks,
Paddy

Read-Only Domain Controllers: windows 2008 RODC

Read-Only Domain Controllers

Think back to the days of Windows NT 4.0, when there was one king of the hill, the primary domain controller (PDC), and then any number of subservient princes below that king on the same hill—the backup domain controllers, or BDCs. It was easy to see the flow of information—changes were made to the master copy of the domain security information on the PDC, and from there it flowed outward, unidirectionally, to the BDCs. When AD DS came around, however, this distinction was eliminated, and in practice a domain controller became equal to any other domain controller, without any designation of primary, backup, or so on. (Well, in actuality, some DCs are a little more equal than others when you factor operations master roles into the equation, but that's not relevant to this discussion.) While this new design increased the fault tolerance and distributed deployment capabilities of the operating system, it's somewhat of an issue if a domain controller anywhere on the network pushes corrupt or otherwise incorrect data to other DCs; how would you prevent that? In branch office scenarios, this issue is particularly serious, since the designated administrator in a branch office needs Domain Admin credentials to administer the DC in her office; this actually gives her the right to administer any DC, not just the one she's responsible for looking after. It's not the best security situation.

While this equality of domain controllers is still the case in Windows Server 2008's AD DS implementation, there is now the concept of a read-only domain controller. A read-only domain controller (RODC) is just that—it receives information replicated to it from full domain controllers, but it doesn't permit any changes to be made to its own copy of the directory database, and thus no information can be replicated back to the full DCs in the domain of which it's a member. This is a great win for branch offices whose companies are large enough to have a comprehensive AD DS structure. Now, you don't have to deploy a full-blown domain controller to your remote locations—you can simply place a RODC there. The benefits are significant and include the following:

• You reduce the risk of someone attacking a branch office location and sending poisoned data throughout the entire AD DS database.

• The RODC caches only the credentials of users and computers who have authenticated to the RODC and whom the Password Replication Policy allows to have credentials cached, which reduces the possibility that accounts can be cracked from a stolen branch office domain controller.

• By default, the RODC does not cache domain administrator credentials, so the keys to the kingdom are more fully protected.

• The Kerberos authentication tickets issued by the RODC will only be valid for systems within its scope, so it can't issue falsified tokens to get nefarious users onto the full network.

• The RODC is a Server Core-designated role, which means there's hardly any need for administration locally. No GUI also means a smaller attack surface. To set up a read-only domain controller, run DCPROMO and select the option on the Additional Domain Controller Options screen to make your new domain controller a read-only domain controller.

DNS considerations for read-only domain controllers

During the Active Directory Domain Services Installation Wizard, when you're first deploying a RODC, DCPROMO recommends that you install a DNS server locally on the RODC. That server is fed zones from the AD DS infrastructure, and the process will add the RODC's local IP address to the RODC's local DNS client properties, so queries will be directed automatically to the AD-integrated zone on the machine itself.

However, for maximum fault tolerance, if there is only one DNS server and RODC (for instance, if the two services are running on the same machine) at a branch office, Microsoft recommends using the options in your DHCP scope—assuming you are using dynamic IP addresses at your branch office—to include not only the local RODC-based DNS server, but also a DNS server at the main office, where your other AD servers are centrally located. Make sure the local RODC-based DNS server is first on the list, so that only queries that fail to get a response from your local server are directed over the wire to your hub site.

If you have a larger branch office contingent, and you have multiple RODCs deployed at one branch office, you can install a DNS server instance on each RODC. Remember that since RODCs are indeed read-only, any dynamic update requests from your clients have to go directly to a writeable domain controller at your central office. The DNS server instances on RODCs will not attempt to replicate with one another; rather, they will receive all updates directly from the central AD DS infrastructure, so there may indeed be certain times wherein one local RODC has received an updated DNS entry for a client, but another has not. This issue resolves itself (no pun intended) within a replication cycle, but to avoid it, make sure the clients themselves have identical DNS server lists—use DHCP options to assist with this—and only install one DNS server instance per site.

-------------------
Thanks,
Paddy