26 December 2009

Rapid Search

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

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

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

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

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

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

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

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

Windows DNS Command-Line Utilities

DNS Command-Line Utilities

In this section, I'll describe some useful programs designed to run from a command line that you can use to automate your DNS setup and configuration processes.

 DNSCmd

The Windows Server 2008 Support Tools collection, described earlier in the book, contains the DNSCmd utility, which is a great way to access some command DNS configuration-related functions through the power and speed of the command prompt. To get to DNSCmd, look in the Support\Tools directory on the Windows Server 2008 distribution CD for the file support.cab. Inside, copy and paste DNSCmd to a convenient location.

DNSCmd displays and changes the properties of DNS servers, zones, and resource records. Some operations of this tool work at the DNS server level while others work at the zone level. You can use DNSCmd on any Windows 2000 or XP computer, as long as the user that is running the application is a member in the Administrators or Server Operators group on the target computer. Both the user account and the server computer must be members of the same domain or reside within trusted domains.

DNSCmd can be used in any of the following situations, in which you want to:

  • Retrieve information about a DNS server

  • Begin the scavenging process

  • View information and contents of a DNS zone

  • Create, remove, or "pause" zones

  • Change the properties of a zone

  • Add, delete, and enumerate records in a zone

You use DNSCmd simply by specifying attributes and their values as part of a command. For example, to create a new standard primary zone called corp.hasselltech.local on a server named dc1.corp.hasselltech.local and stored in corp.hasselltech.local.dns files, use the following syntax:

dnscmd dc1.corp.hasselltech.local /ZoneAdd corp.hasselltech.local /Primary /file corp.hasselltech.local.dns   					  

I could have also chosen to make corp.hasselltech.local a secondary zone by replacing the /Primary switch with /Secondary.

To create a new A record, I could issue the following command, which adds a record for a machine named www to the zone with an IP address of 192.168.1.23 to the same DNS server as in the previous example:

Dnscmd dc1.corp.hasselltech.local /RecordAdd corp.hasselltech.local www A 192.168.1.23   					  

You can see all of the zones on a target server by entering the following command:

dnscmd dc1.corp.hasselltech.local /enumzones 

If you're experiencing some problems with replication and want to trigger the process manually, you can start it with the following command (assuming you want to use the same server to begin the process as in the previous examples):

Dnscmd dc1.corp.hasselltech.local /ZoneRefresh corp.hasselltech.local 

Likewise, you might find yourself needing to manually age all of the records on a particular machine. You can easily do so through DNSCmd using the following:

dnscmd corp.hasselltech.local /ageallrecords dc1.corp.hasselltech.local 

You'll need to confirm your choice, and then the current time will be applied to all records on that machine.

You might also need to clear the DNS cache on a target server, which can be done using this command:

Dnscmd dc1.corp.hasselltech.local /clearcache 

To quickly stop and start the DNS process on the target computer, use the following command:

Dnscmd dc1.corp.hasselltech.local /restart 

If you want to export a particular zone to a file, you can issue the following command:

dnscmd /zoneexport corp.hasselltech.local corp.hasselltech.local.dns 

And finally, to delete a zone from a target server, use the following command:

dnscmd dc1.corp.hasselltech.local /zonedelete corp.hasselltech.local 

DNSLint

DNSLint is also on the distribution CD in support tools. DNSLint is a utility born out of the desire to automate the process of troubleshooting lame delegation issues and problems with AD replication because of faulty DNS records. DNSLint is a great tool to make sure that every DNS server that has records on your services has correct records and that there are no issues with those DNS servers' data. (And in case you're wondering, the name DNSLint comes from the idea that lint is something you find in your blue jeans after they come out of the dryer. When you find lint, it is useless and perhaps even embarrassing, meaning you probably quickly discard it. You should do the same with outdated or inaccurate DNS records for critical machines on your network.)

The best thing to do from the start is to create a standard report on any given DNS domain, using the following:

dnslint /d hasselltech.local /v 

DNSLint produces an HTML-based report and then starts Internet Explorer to display the result. The results are color-coded with warnings in amber and errors in red for easy scanning. (You can elect to get a text-based report, if you prefer.) The report generated by the previous command will show a detailed listing of each DNS server for the corp.hasselltech.local domain and indicate whether the server responds to a query on port 53, which is the standard DNS port. It will tell you how it found each server, and it will also list each server that reports authoritatively. You will also see Mail Exchanger records in the zone, which is useful for troubleshooting SMTP routing problems.

If you are specifically having email difficulties, you can use DNSLint to determine whether a designated email server listens on the correct port. Use the following command:

  dnslint /d domainname.tld /c 

The report generated by that command lists whether a server indicated in an MX record is listening for SMTP, POP3, and IMAP4 requests, and will also show the SMTP header returned by the server to help in diagnostics.

To assist in troubleshooting, the following functions are available in DNSLint:


dnslint /d domainname

This diagnoses potential causes of "lame delegation," covered earlier in this chapter, and other related DNS problems. You'll receive an HTML-based report once the checking diagnosis is complete. Add /v for more information about how the DNS servers listed in the report were found. If you get errors saying that the domain specified is not listed with InterNIC, simply add the /s option.


dnslint /ql mylist.txt

This verifies a user-defined set of DNS records on multiple DNS servers. You can specify in a simple text file the sets of records you'd like to test. For example, the following tests A, PTR, CNAME, and MX records for the domain name and IP address of a fairly well-known company:

microsoft.com,a,r       ;A record 207.46.197.100,ptr,r    ;PTR record microsoft.com,cname,r   ;CNAME record microsoft.com,mx,r      ;MX record 


dnslint /ad localhost

This verifies the DNS records on a specific host (in this case, the current machine) specifically used for Active Directory replication. If you get errors saying that the domain specified is not listed with InterNIC, simply add the /s option.

Previous Page Next Page

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

Windows DNS Command-Line Utilities

DNS Command-Line Utilities

In this section, I'll describe some useful programs designed to run from a command line that you can use to automate your DNS setup and configuration processes.

 DNSCmd

The Windows Server 2008 Support Tools collection, described earlier in the book, contains the DNSCmd utility, which is a great way to access some command DNS configuration-related functions through the power and speed of the command prompt. To get to DNSCmd, look in the Support\Tools directory on the Windows Server 2008 distribution CD for the file support.cab. Inside, copy and paste DNSCmd to a convenient location.

DNSCmd displays and changes the properties of DNS servers, zones, and resource records. Some operations of this tool work at the DNS server level while others work at the zone level. You can use DNSCmd on any Windows 2000 or XP computer, as long as the user that is running the application is a member in the Administrators or Server Operators group on the target computer. Both the user account and the server computer must be members of the same domain or reside within trusted domains.

DNSCmd can be used in any of the following situations, in which you want to:

  • Retrieve information about a DNS server

  • Begin the scavenging process

  • View information and contents of a DNS zone

  • Create, remove, or "pause" zones

  • Change the properties of a zone

  • Add, delete, and enumerate records in a zone

You use DNSCmd simply by specifying attributes and their values as part of a command. For example, to create a new standard primary zone called corp.hasselltech.local on a server named dc1.corp.hasselltech.local and stored in corp.hasselltech.local.dns files, use the following syntax:

dnscmd dc1.corp.hasselltech.local /ZoneAdd corp.hasselltech.local /Primary /file corp.hasselltech.local.dns   					  

I could have also chosen to make corp.hasselltech.local a secondary zone by replacing the /Primary switch with /Secondary.

To create a new A record, I could issue the following command, which adds a record for a machine named www to the zone with an IP address of 192.168.1.23 to the same DNS server as in the previous example:

Dnscmd dc1.corp.hasselltech.local /RecordAdd corp.hasselltech.local www A 192.168.1.23   					  

You can see all of the zones on a target server by entering the following command:

dnscmd dc1.corp.hasselltech.local /enumzones 

If you're experiencing some problems with replication and want to trigger the process manually, you can start it with the following command (assuming you want to use the same server to begin the process as in the previous examples):

Dnscmd dc1.corp.hasselltech.local /ZoneRefresh corp.hasselltech.local 

Likewise, you might find yourself needing to manually age all of the records on a particular machine. You can easily do so through DNSCmd using the following:

dnscmd corp.hasselltech.local /ageallrecords dc1.corp.hasselltech.local 

You'll need to confirm your choice, and then the current time will be applied to all records on that machine.

You might also need to clear the DNS cache on a target server, which can be done using this command:

Dnscmd dc1.corp.hasselltech.local /clearcache 

To quickly stop and start the DNS process on the target computer, use the following command:

Dnscmd dc1.corp.hasselltech.local /restart 

If you want to export a particular zone to a file, you can issue the following command:

dnscmd /zoneexport corp.hasselltech.local corp.hasselltech.local.dns 

And finally, to delete a zone from a target server, use the following command:

dnscmd dc1.corp.hasselltech.local /zonedelete corp.hasselltech.local 

DNSLint

DNSLint is also on the distribution CD in support tools. DNSLint is a utility born out of the desire to automate the process of troubleshooting lame delegation issues and problems with AD replication because of faulty DNS records. DNSLint is a great tool to make sure that every DNS server that has records on your services has correct records and that there are no issues with those DNS servers' data. (And in case you're wondering, the name DNSLint comes from the idea that lint is something you find in your blue jeans after they come out of the dryer. When you find lint, it is useless and perhaps even embarrassing, meaning you probably quickly discard it. You should do the same with outdated or inaccurate DNS records for critical machines on your network.)

The best thing to do from the start is to create a standard report on any given DNS domain, using the following:

dnslint /d hasselltech.local /v 

DNSLint produces an HTML-based report and then starts Internet Explorer to display the result. The results are color-coded with warnings in amber and errors in red for easy scanning. (You can elect to get a text-based report, if you prefer.) The report generated by the previous command will show a detailed listing of each DNS server for the corp.hasselltech.local domain and indicate whether the server responds to a query on port 53, which is the standard DNS port. It will tell you how it found each server, and it will also list each server that reports authoritatively. You will also see Mail Exchanger records in the zone, which is useful for troubleshooting SMTP routing problems.

If you are specifically having email difficulties, you can use DNSLint to determine whether a designated email server listens on the correct port. Use the following command:

  dnslint /d domainname.tld /c 

The report generated by that command lists whether a server indicated in an MX record is listening for SMTP, POP3, and IMAP4 requests, and will also show the SMTP header returned by the server to help in diagnostics.

To assist in troubleshooting, the following functions are available in DNSLint:


dnslint /d domainname

This diagnoses potential causes of "lame delegation," covered earlier in this chapter, and other related DNS problems. You'll receive an HTML-based report once the checking diagnosis is complete. Add /v for more information about how the DNS servers listed in the report were found. If you get errors saying that the domain specified is not listed with InterNIC, simply add the /s option.


dnslint /ql mylist.txt

This verifies a user-defined set of DNS records on multiple DNS servers. You can specify in a simple text file the sets of records you'd like to test. For example, the following tests A, PTR, CNAME, and MX records for the domain name and IP address of a fairly well-known company:

microsoft.com,a,r       ;A record 207.46.197.100,ptr,r    ;PTR record microsoft.com,cname,r   ;CNAME record microsoft.com,mx,r      ;MX record 


dnslint /ad localhost

This verifies the DNS records on a specific host (in this case, the current machine) specifically used for Active Directory replication. If you get errors saying that the domain specified is not listed with InterNIC, simply add the /s option.

Previous Page Next Page

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

Windows 2008 Command-Line Utilities

Command-Line Utilities

In this section, I'll look at several ways you can manage file, print, and user services from the command line.

Using Shares

Sometimes it's inconvenient to use the Windows GUI to map a drive—this is a problem particularly in logon scripts. How do you use a batch file to tell the mouse pointer to move over to My Network Places? There's a better way. The net use command enables you to map any drive to any server on your network, and in some cases, outside networks, too. The syntax is:

net use drive \\server\share 

Here are some common examples that you should find useful.

To map drive H: to Lisa Johnson's home directory on server MERCURY:

net use H: \\mercury\users\lmjohnson 

To map the first available drive letter to the same directory:

net use * \\mercury\users\lmjohnson 

Sometimes you might need to connect to a share on a domain that isn't trusted by your home domain. If you have an account on that domain, you can use it to connect, like so:

net use H: \\foreignmachine\sharename /user:foreigndomain\username 

(If you need to use a password, you'll be prompted for it.)

If you need to terminate a connection or map to a server, use the /d switch:

  net use \\mercury\users\lmjohnson /d 

To disconnect all drive mappings on the local machinemaps:

net use * /d 

To connect to a foreign machine (152.1.171.133, in this example) over the Internet or an intranet without relying on name resolution:

net use H: \\152.1.171.133\c$ 

You also can use a different account with the IP address:

net use H: \\152.1.171.133\c$ /user:hasselltech\hassell 

And you can specify that this mapping is for the current session only and should not be restored upon logon. This is a feature that I call map persistency—keeping the same mappings across login sessions, a big timesaver for your users. To do so:

net use H: \\152.1.171.133\c$ /persistent:no 

FSUTIL

To set up default quotas and modify them using the command line, type the following at the prompt:

fsutil quota modify [VolumeOrDrive] [warninglevel] [hardquota] [username] 

replacing the text in brackets with the appropriate information as specified in the following list:


VolumeOrDrive

The drive letter or volume name of the disk on which you want to modify a quota. Volume names are tricky to specify because you must do so using the globally unique identifier (GUID), which can be a long string of seemingly random numbers.


warninglevel

The amount of space at which warnings will be recorded in the system event log.


hardquota

The amount of space at which users will reach their maximum allowed disk space.


username

The user to which this quota specification applies.

Using fsutil.exe, you can create scripts to automatically set quota entries upon new-user creation to work around the limitation of assigning quotas to groups, as described earlier in this chapter. fsutil.exe can help you access functionality more quickly and efficiently than you can by using the GUI interface. The following examples, designed to run from a command line, illustrate the quota functionality available through fsutil.exe.

To disable quota support on drive C:

fsutil quota disable C: 

To enable quota support on drive E:

fsutil quota enforce E: 

To set a 250 MB quota for Lisa Johnson (user ID lmjohnson) on drive C:

fsutil quota modify C: 250000000 lmjohnson 

To list the current quotas set on drive D:

fsutil quota query D: 

To track the disk usage—in other words, to list which users are taking up what amount or portion of space—on drive F:

fsutil quota track F: 

To list all users over quota on any volume on the server:

fsutil quota violations 

Managing Offline Folders

To make a share's contents available offline from the command line, at a prompt, type:

net share nameofshare /CACHE:[manual | documents | programs | none] 

/CACHE:manual enables manual client caching of programs and documents from this share. /CACHE: documents enables automatic caching of documents from this share. /CACHE:programs enables automatic caching of documents and programs (distinguished by their file extension) from this share. /CACHE:none disables caching from this share.

VSSADMIN

The GUI for managing shadow copies is somewhat complete; however, it lacks the ability to specify on which disk or volume shadow copies are stored. Also, an administrator cannot delete specific shadow copy files using the GUI. This might be needed if a user creates an incorrect version of a file, then leaves and another worker comes back the next day. An administrator might need to delete the previous version as soon as possible so that the new user doesn't inadvertently work from the incorrect version.

The vssadmin.exe command-line utility was created to offer administrators the ability to control these factors. I'll now walk through several examples.

vssadmin Add ShadowStorage /For=C: /On=D: /MaxSize=150MB 

This command specifies that storage for shadow copies (known as an association) of drive C: will be stored on drive D:. If a value is not specified, there is no limit to the amount of space shadow copies can use. Shadow copies require at least 100 MB of space, and you can specify the maximum amount in KB, MB, GB, TB, PB, and EB, although it's assumed if you don't use a suffix, the value is in bytes.

vssadmin Create Shadow /For=E: /AutoRetry=2 

This command creates a new shadow copy of drive E:. The /AutoRetry switch dictates that if another process is attempting to make shadow copies at the same time vssadmin is attempting to make them, the utility will keep trying for two minutes.

vssadmin Delete Shadows /For=C: /Oldest 

This command deletes the oldest shadow copy on drive C:. You can use the /all switch to instead delete all shadow copies that can be deleted. You also can specify a specific shadow copy to delete by using /Shadow=ID, where ID is the hexadecimal number you obtain through the List Shadows command, covered later in this section.

vssadmin Delete ShadowStorage /For=C: /On=D: 

This command deletes the storage space on drive D: that is used to store shadow copies of drive C:. If you leave off the /On switch, all shadow copy storage associations for drive C: will be deleted.

vssadmin Resize ShadowStorage /For=C: /On=D: /MaxSize=150MB 

This command modifies the maximum size for a shadow copy storage association between drives C: and D:. Again, the maximum size has to be 100 MB or more. If you decrease the maximum size, older shadow copies can be deleted to make room for more recent shadow copies.

Other useful commands:


vssadmin List Providers

This command lists registered volume shadow copy providers.


vssadmin List Shadows

This command lists existing volume shadow copies and their ID numbers, for use with the Delete Shadows command.


vssadmin List ShadowStorage

This command shows the disks eligible to support shadow copy functionality.

Previous Page Next Page

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