26 December 2009
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
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
-------------------
Thanks,
Paddy
Available roles and features on Windows Server 2008 Server Core machines
-------------------
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
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
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.
-
-
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
-
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
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.
-
-
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
-
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