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

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:

Code View:

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:

Code View:

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.

-------------------
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.

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

windows 2008 Permissions more Explained

The default special permissions are further described in the following list.

Traverse Folder/Execute File

Traverse Folder allows you to access a folder nested within a tree even if parent folders in that tree deny a user access to the contents of those folders. Execute File allows you to run a program.

List Folder/Read Data

List Folder allows you to see file and folder names within a folder. Read Data allows you to open and view a file.

Read Attributes

Allows you to view basic attributes of an object (read-only, system, archive, and hidden).

Read Extended Attributes

Allows you to view the extended attributes of an object—for example, summary, author, title, and so on for a Word document. These attributes will vary from program to program.

Create Files/Write Data

Create Files allows you to create new objects within a folder; Write Data allows you to overwrite an existing file (this does not allow you to add data to existing objects in the folder).

Create Folders/Append Data

Create Folders allows you to nest folders. Append Data allows you to add data to an existing file, but not delete data within that file (a function based on file size), or delete the file itself.

Write Attributes

Allows you to change the basic attributes of a file.

Write Extended Attributes

Allows you to change the extended attributes of a file.

Delete Subfolders and Files

Allows you to delete the contents of a folder regardless of whether any individual file or folder within the folder in question explicitly grants or denies the Delete permission.

Delete

Allows you to delete a single file or folder, but not other files or folders within it.

Read Permissions

Allows you to view NTFS permissions on an object, but not to change them.

Change Permissions

Allows you to both view and change NTFS permissions on an object.

Take Ownership

Allows you to take ownership of a file or folder, which inherently allows the ability to change permissions on an object. This is granted to administrator-level users by default.

You also can create custom combinations of permissions, known as special permissions, other than those defined in Windows Server 2008 by default; I cover that procedure in detail later in this section.

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

Windows Server 2008 special permissions

Windows Server 2008 special permissions
Special permission	R	W	RX	L	M	FC
Traverse Folder/Execute File			X	X	X	X
List Folder/Read Data	X		X	X	X	X
Read Attributes	X		X	X	X	X
Read Extended Attributes	X		X	X	X	X
Create Files/Write Data		X			X	X
Create Folders/Append Data		X			X	X
Write Attributes		X			X	X
Write Extended Attributes		X			X	X
Delete Subfolders and Files						X
Delete					X	X
Read Permissions	X		X	X	X	X
Change Permissions						X
Take Ownership						X
Full Control	X	X	X	X	X	X

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

Complete WDS in 2008 Server

2.3. Deployment

The deployment story in Windows Server 2008 (and Windows Vista, for that matter) has radically changed. Windows Deployment Services (WDS) replaces the old Remote Installation Services (RIS) product that was included with Windows 2000 and Windows Server 2003. It has a number of enhancements, improvements, and new features, but perhaps the most important and the most useful of them is the ability for WDS to read, manage, and stream the new Windows Imaging Format (WIM). WIM support was first baked into Windows Vista and solves a number of problems that you may have stumbled on if you've worked with imaging products for Windows in the past. While WDS can still deploy what it calls "legacy" images—for example, Windows XP installations in the format you used to use in conjunction with Remote Installation Services—WDS shines when you set up different WIM files with boot and install images for different architectures and systems.

With some upfront grunt work (and that may be putting it mildly), you can significantly reduce the time it takes to achieve a complete deployment on machines that are of different types, architectures, and configurations. Let's take a look at some critical components of the deployment infrastructure under Windows Server 2008.

2.3.1. Windows Imaging Format

Windows Vista introduced the Windows Imaging Format, a hardware-independent format that stores images of the operating system. The premise of WIM is to make images many-to-one in nature; in other words, multiple images can be contained within one WIM file. Since Windows Vista was architected to be so modular, 95% of the base operating system can be replicated among any number of images; as a result, Microsoft itself can ship just one binary image for each processor architecture—x86 and x64—to everyone in the channel. Additionally, the sizes of each of the image files are reduced using single-instance storage techniques and enhanced compression. Further, you can create WIM files very easily for your own uses and modify them as well.

Perhaps the best usability improvement of the WIM format is the ability to edit images offline using standard file management tools like Windows Explorer. You can add files and folder to an image; for instance, instead of the painful driver addition process in Remote Installation Services, you can simply drop drivers directly into a WIM-based image and have them automatically present for future deployments. Best of all, you don't need to create independent images for each edit you make—the additions, modifications, and deletions you make can coexist in one image, reducing management burden.

2.3.2. Windows PE

Windows Pre Environment, or Windows PE, is an execution environment designed to assist in installing and troubleshooting operating system installations. Rather than the old blue-background, text-based installation screen with previous versions of NT, Windows PE comes in graphical format and contains a full complement of tools to assist with getting Windows Server 2008 and Windows Vista installed on a drive.

The big win with Windows PE is that standard Windows network drivers work with it out of the box—no hunting for special NDIS drivers only for network deployment use. Additionally, it has a built-in firewall to protect the operating system in its most vulnerable state, when it is partially installed, and the ability to insert drivers from any sort of removable media into the session. You might recall the frustration of only being able to add a driver by hitting F6 at the right moment of Setup and then having the driver only on a floppy disk. Windows PE eliminates this annoyance.

2.3.3. Windows Deployment Services

Windows Deployment Services is the next generation of Windows 2000 and Windows Server 2003's RIS. It released with Windows Server 2003 Service Pack 2 and is the only supported method of deploying Windows Vista over the network, so if you want to stream Vista images to desktops and notebooks over the Net, you'll need to upgrade your RIS servers to that service pack level and then deploy WDS. WDS supports both x86 and x64 images as well.

Like RIS, WDS uses the Preboot Execution Environment (PXE) capabilities of most modern BIOSes and network interface cards to load a session of Windows PE. Windows PE then presents a menu to the user consisting of all the appropriate image and configuration options available on the WDS machine. The user selects a target, and the image—in WIM format, of course—is laid onto the disk of the target machine. It's all very elegant when you have configured it properly, and it makes it possible to reimage a system—in some cases, with applications and configurations as well—in less than 30 minutes. Imagine the boon to your support department: instead of wasting hours tracking down some obscure problem, you simply stream a new image to a machine while the user is out to lunch, and voilà! Problem solved. True, that's a rosy case, but it's possible and realistic with WDS and WIM.

What's changed from RIS? Here's a quick rundown, courtesy of Microsoft:

• The ability to deploy Windows Vista and Windows Server 2008 aside from simply Windows XP and the old NT-based operating systems

• Windows PE can be used as a boot operating system, allowing for both deployment and troubleshooting

• Support for WIM deployments

• Ability to transmit data and images using multicast functionality, which allows the performance of deployment services over the network to scale significantly better and more efficiently

• An enhanced PXE server stub

• A new, more user-friendly boot menu format that is both easier to use and easier to configure

• A new management console that helps you manage WDS servers on your networks, and the boot and install images contained thereon

There are two types of WDS servers that you can create: a transport server and a deployment server. The transport server only offers the core networking services; it doesn't give you all the functionality of WDS but is useful if you want to take advantage of the multicasting features in larger environments. A deployment server offers everything that WDS offers, including the transport components. For the purposes of this section of the chapter, we'll assume that we are working with a deployment server.

2.3.4. Installing and Configuring Windows Deployment Services

To install WDS, you need a Windows Server 2008 machine that is somehow joined to a domain. You'll also need DHCP working on your network, a valid DNS architecture, a partition formatted as NTFS, and a user account that is both a domain user and a local administrator on the server running WDS. If you meet all those requirements, you can install WDS by loading Server Manager, clicking Add Roles on the Roles Summary pane, and then selecting Windows Deployment Services.

Once you have added the role, it's time to configure the WDS server. There is a command-line utility, aptly named WDSUTIL, and there is the graphical component, which is an MMC snap-in. For this example, we'll walk through the graphical interface for WDS.

Your first steps should be as follows.

1. We'll need to create a shared folder that stores the necessary programs and supporting files to enable PXE-based networking booting, the files for Windows PE which each machine will store in a dynamic RAM disk, the boot images for Windows PE itself so that it can fully run on your client machines, and the install images for your operating systems (these are the actual WIM files themselves that are meant to be deployed to your target machines).

2. We then have to tell WDS how to answer PXE requests from the network, so that incoming client requests are answered or ignored depending on how security-conscious you want your deployment to be.

3. Next, your DHCP settings should be changed, whether your DHCP service is hosted on a Windows Server 2008 machine or provided by some other network device. Specifically, all DHCP broadcasts on UDP port 67 by client computers should be forwarded directly to both the DHCP server and the Windows Deployment Services PXE server. Also, all traffic to UDP port 4011 from the client computers to the Windows Deployment Services PXE server should be routed appropriately. The WDS Configuration Wizard will take care of this step in most environments.

The Windows Deployment Services Configuration Wizard will handle a lot of these tasks for you, so let's load it and run through the wizard to get a baseline configuration prepared. If you haven't already, install the WDS role by using the Add Roles Wizard, which you can enter from the appropriate link at the bottom of the Initial Configuration Tasks page. Then, from the Administrative Tools submenu off the Start menu, select Windows Deployment Services. In the left pane, expand the server list, right-click on the current server, and select Configure Server. The wizard launches.

1. On the Select Server Roles screen, shown in Figure 2-8, check the Windows Deployment Services box and click Next.

   Figure 2-8. The Select Server Roles screen

   

2. The Overview of Windows Deployment Services screen appears, as shown in Figure 2-9. Read the overview and listing of requirements, and then click Next when you finish.

   Figure 2-9. The Overview of Windows Deployment Services screen

   

3. The Select Role Services screen appears, depicted in Figure 2-10. Here, you select which of WDS's two roles you want to install, or you can opt for both. The Deployment Server role provides all of the functions and features of WDS and requires the components of the Transport Server role, which actually move the bits and bytes of your operating system images around the network. You can install the Transport Server role without the Deployment Server role, but you cannot have the Deployment Server role without the Transport Server role. Try it; the Add Roles Wizard will flash an error if you attempt the remove the latter and keep the former. For the purposes of our demonstration here, select both roles and click Next.

   Figure 2-10. The Select Role Services screen

   

4. The Confirm Installation Selections screen appears. Verify the settings you've chosen in the wizard and then click the Install button. You may need to restart the machine you are using.

Once the WDS roles are installed, it is time to run the configuration wizard. The Welcome Page appears, as shown in Figure 2-11. Read the introduction and then click Next.

Figure 2-11. The Welcome Page of the Windows Deployment Services Configuration Wizard

The Remote Installation Folder Location screen appears, as shown in Figure 2-12. Here, you tell WDS where to store images to stream to clients. This folder must reside on a volume formatted by NTFS. It's recommended that you choose a volume that doesn't contain the Windows system files for best performance, although you won't be prevented from selecting the system disk—simply acknowledge the warning that will appear. Choose a path, and then click Next.

Figure 2-12. The Remote Installation Folder Location screen

The PXE Server Initial Settings screen appears, depicted in Figure 2-13. Here, you can establish whether your WDS machines will respond to clients who aren't made known to WDS before you begin their deployment. If you want any computer to be able to stream an image to its drive (subject to that user having appropriate permissions), then choose "Respond to all known and unknown client computers." You can also elect to have unknown clients make a request that can subsequently be approved by an administrator. To require that clients be prestaged within WDS, choose the second option, and to turn off WDS network booting completely, choose the first option. Click Finish to complete the wizard.

Figure 2-13. The PXE Server Initial Settings screen

The wizard will trundle for a while, completing the initial configuration steps, and then you will see the Configuration Complete screen, shown in Figure 2-14.

Figure 2-14. The Configuration Complete screen

Next up, you need to add the boot images. These are the images that download over the PXE-based network connection and set up the Windows PE-based environment in which all of the deployment magic happens. Expand the server to which you want to add the boot images, right-click on the Boot Images folder, and select Add Boot Image. Then, insert the operating system media into the local CD or DVD drive, and browse to the BOOT.WIM file (on the Windows Server 2008 DVD, it is located in the \Sources directory off of the root of the CD). Click Open, and then enter a friendly image name and description, click Next, and wait as the images are copied to the WDS machine's shared folder that you established during the configuration wizard.

Finally, you add the install images, which as you will recall are the actual target images streamed down over the network onto the machines on which you want an operating system installed. To get started, I recommend putting a default image of Windows Vista or Windows Server 2008 on your WDS machine. While this image won't come out of the box tweaked to your liking or with applications and settings preconfigured, I have found it useful to have the ability to install a vanilla Windows system over the network for other purposes as well. Additionally, you can start with these plain images, stream them to a system, customize them, capture the resulting image, and then re-upload it to the WDS machine, all without touching distribution media. To add a default install image of Windows Server 2008 onto your WDS machine:

1. Click on the server that will store the install image and expand it to expose the tree of folders beneath it.

2. Right-click on the Install Images folder in the left pane and select Add Install Image.

3. The Image Group screen appears, as shown in Figure 2-15. Type a name for this image group—groups are simply ways to organize collections of images. For example, type in Windows Server 2008 Installations into the group name box. You can then add more images later and store them in this group to make it easy to administer them from the WDS MMC snap-in. Click Next.

   Figure 2-15. The Image Group screen

   

4. The Image File screen appears. Browse the distribution media to find the INSTALL.WIM file located on the disc. For Windows Server 2008, you can find this image in the \Sources folder off the root of the media. Click Open.

5. The List of Available Images screen is next (see Figure 2-16). Here, you select which of the editions of the product you would like to make available to installation clients. Clear the checkboxes of images that you would like to exclude from the WDS server, and then click Next.

   Figure 2-16. The List of Available Images screen

   

6. The Summary screen shows Click Next to add the images to the store. This could take a while, as there is a lot to copy and manage.

Your boot and install images are now set up on the WDS server.

2.3.5. The Boot Menu

The Boot menu is a text-based screen that appears when WDS first begins loading after the PXE network environment has been established. The boot menu allows the user to choose between boot architectures—x86 clients can choose the right architecture, and there is a special boot version for x64 architectures as well—and further along in the process, it will dictate what choices appear in the installation menu.

WDS and 64-Bit Clients: A Quick Tip You might find that some of your x64-based hardware isn't being detected correctly by your hardware and/or the PXE software. In this case, you may want to explicitly instruct WDS to show both x64 and x86 options on the boot menu. The simplest way to do this is from the command line, as follows: WDSUTIL /Set-Server /Defaultx86x64ImageType:both

2.3.6. Creating and Modifying Images

Now that you have a sense of how to deploy WDS, and you have a few plain-vanilla install images on your server, you can set about creating custom images. You can create boot images and install images that are different from the defaults and suited to your requirements.

2.3.6.1. Creating and modifying boot images

You can create two different types of boot images for your needs: a capture image, which is what you boot a client computer into in order to capture an image of its hard drive for later deployment; and a discover image, which is used to install an operating system via WDS onto a computer that, for lack of hardware or software support, doesn't allow a PXE environment to be created.

Capture images automatically boot into the Windows Deployment Services Capture Utility in lieu of Setup. You use a capture image on a computer that is ready to be imaged, and once it is booted, a wizard creates an install image of the reference computer and saves it as a .wim file. You can then upload this WIM file onto your WDS server for deployment to other target machines. Alternatively, you can burn a CD or DVD that contains a capture image and the ImageX command-line utility. You can then boot the sourced system with the media, run ImageX to create the WIM-based image, and then connect over the network to a machine and upload that image for storage. I find it useful to have one of these capture image DVDs available, even if you choose not to make that method your standard way of capturing images.

To create a capture image:

1. Open the Windows Deployment Services MMC snap-in.

2. Expand Boot Images in the left pane.

3. Right-click on an image to use it as the foundation for your capture image, and select Create Capture Boot Image.

4. Enter a name, description, and the location to save the image.

5. Finish out the wizard and then right-click the boot image folder and select Add Boot Image from the resulting menu.

6. Browse to the new capture image you just created, and then click Next.

7. Finish the addition wizard and close out. Your capture image is now ready to be deployed.

The second type of boot image you can create, a discover image, forces Setup.exe to launch in Windows Deployment Services mode and then ping around the network to find an active WDS machine. You can use these images on a CD or DVD to allow WDS to stream deployments to machines that don't or won't support PXE. To create a discover image, use the following procedure:

1. Open the Windows Deployment Services MMC snap-in.

2. Expand Boot Images in the left pane.

3. Right-click on an image to use it as the foundation for your discover image, and select Create Discover Boot Image.

4. Enter a name, description, and the location to save the image.

5. Finish out the wizard and then right-click the boot image folder and select Add Boot Image from the resulting menu.

6. Browse to the new discover image you just created, and then click Next.

7. Finish the addition wizard and close out. Your discover image is now ready to be deployed.

If you are interested in creating hard media, such as a CD or DVD, to contain your discover image, you can download the Windows Automated Installation Kit from the Microsoft web site and install it. From that point, open a command prompt to the C:\Program Files\Windows AIK\Tools\PETools folder and commence the following procedure:

1. Create a Windows PE build environment by entering CopyPE {arch} c:\WinPE, replacing the architecture of the boot image you'd like when issuing the command.

2. Copy the discover image to a target directory using the following command:

   copy /y c:\boot.wim c:\winpe\iso\sources 

   
   

3. Go back to the PETools folder in step one, and create the bootable ISO image using the OSCDIMG utility that is bundled in the Windows Automated Installation Kit. Type the following:

   oscdimg -b -bc:\winpe\ISO\boot\etfsboot.com c:\windpe\ISO c:\winpe.sio 

   
   

4. Burn the resulting c:\winpe.iso file to a CD or DVD using your preferred burning and mastering software.

2.3.6.2. Creating install images

You can build custom install images (the images that consist of the actual operating system and any changes you want to bake into the package) from prepared computers and upload them for deployment to target machines. Generally, you boot the source computer normally, run the sysprep utility in most cases to strip out physical machine-specific information and security identifiers, then reboot into a WDS-based capture image, take a WIM-formatted image of the client, upload it somewhere else, and then reboot.

Specifically, after you have finished configuring the source (or reference, as Microsoft refers to it) computer the way you'd like it to be imaged, run the following from the command line:

sysprep /oobe /generalize /reboot 

After the utility has finished and the computer has restarted, press F12 and select the capture image from the boot menu that will be displayed. Choose the drive that contains the operating system on which you just ran SYSPREP, provide a name and description for the image, and click Next to continue. Then browse to a location on the machine where you can store the resulting .WIM file, enter a name of the image file, and then click Save. Finally, click "Upload image to WDS Server," enter the name of your WDS machine, and click Connect, entering credentials if prompted or necessary. (Choose the correct image group along the way if you are so prompted.)

Click Finish, and your image will be created, prepared, and uploaded, and will be ready for deployment to your target machines.

2.3.6.3. Sysprep: the system preparation tool

The most common catch to any imaging solution is the need to identify and scrub security identifier (SID) information from your image. Deploying an image onto multiple computers, all with the same SID information, is an invitation to disaster. Sysprep is the answer to this problem.

Sysprep will not reimage a domain controller, a member of any cluster, or a machine functioning as a certificate server because of the inherent machine-specific characteristics of those services. However, after Sysprep has completed, these services are certainly supported and available to be installed.

Here's an overview of how Sysprep works:

1. You generate a prototype image and configure everything on that system as needed.

2. You then copy the profile of the account that has the settings and customizations you've been performing to the Default User profile, so that all future users of the system get those tweaks.

3. Then you run Sysprep. This scrubs SIDs and personal information from your prototype and shuts down the machine.

4. Next, you boot the computer from your WDS capture image and generate the WIM file. You can optionally upload that image as well.

5. Finally, you reboot the computer without the floppy, and proceed through mini-Setup again so that all personal information can be restored and new SIDs can be generated. (You can script this process so that a mini-unattended installation is performed.)

2.3.7. Configuring and Performing Unattended Installations with Scripts

If you are interested in further automating the deployment of operating systems using WDS, look into using unattended installation scripts: not only can you kick off an OS deployment over the network, but you can customize the responses to setup prompts, installed programs, product keys that are configured, and more, so that even if you aren't using an imaged system, you achieve a consistent setup on all machines you roll out.

In Windows Server 2008 and Windows Deployment Services, there are essentially two different unattend files: a WDS client unattend file, which resides on the WDS server and directs the WDS client interface to install the right image and partition disks correctly; and the actual unattend file for the image itself, which is the type of unattend file with which you may be more familiar. This is stored in the $OEM$ structure common in the Windows 2000 and Windows Server 2003 days, or in the \Unattend directory in the image, and automates the remainder of the Setup process that the WDS unattend file can't address.

You'll find the Windows Automated Installation Kit will come in handy if you are creating more than the simplest unattend files—in particular, the Windows System Image Manager can walk you through creating an unattend file, which can then be assigned (associated, in effect) either to clients hitting a specific server or specific clients themselves, as well as different machines based on x86 and x64 architectures.

The format of the WDS client unattend file is easy to read, as it's in XML, which has a familiar syntax and structure. A sample follows.

Code View:

<?xml version="1.0" ?> <unattend xmlns="urn:schemas-microsoft-com:unattend">    <settings pass="windowsPE">       <component name="Microsoft-Windows-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86">          <WindowsDeploymentServices>             <Login>                <WillShowUI>OnError</WillShowUI>                <Credentials>                      <Username>username</Username>                      <Domain>domain</Domain>                      <Password>password</Password>                   </Credentials>                </Login>             <ImageSelection>                <WillShowUI>OnError</WillShowUI>                <InstallImage>                   <ImageName>Windows Vista x86</ImageName>                   <ImageGroup>Windows Vista</ImageGroup>                   <Filename>Install.wim</Filename>                </InstallImage>                   <InstallTo>                   <DiskID>0</DiskID>                   <PartitionID>1</PartitionID>                </InstallTo>             </ImageSelection>          </WindowsDeploymentServices>          <DiskConfiguration>             <WillShowUI>OnError</WillShowUI>                <Disk>                   <DiskID>0</DiskID>                   <WillWipeDisk>false</WillWipeDisk>                   <ModifyPartitions>                      <ModifyPartition>                         <Order>1</Order>                         <PartitionID>1</PartitionID>                         <Letter>C</Letter>                         <Label>CLIENTMACHINE</Label>                         <Format>NTFS</Format>                         <Active>true</Active>                         <Extend>false</Extend>                      </ModifyPartition>                   </ModifyPartitions>             </Disk>          </DiskConfiguration>       </component>       <component name="Microsoft-Windows-International-Core-WinPE" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86">          <SetupUILanguage>             <WillShowUI>OnError</WillShowUI>             <UILanguage>en-US</UILanguage>          </SetupUILanguage>          <UILanguage>en-US</UILanguage>       </component>    </settings> </unattend>   					  

Here's the process to integrate unattend files with your WDS deployment. Start by associating the WDS unattend file to the appropriate image.

1. Create your unattend.xml file for the WDS client. I suggest using the Windows System Image Manager, part of the Windows Automated Installation Kit.

2. Once you've created the unattend.xml file, upload it to your WDS server at the \RemoteInstall\WDSClient\Unattend folder.

3. Open Windows Deployment Services Manager.

4. Right-click the WDS server that is hosting the image to which your new unattend file should be assigned, and click Properties.

5. Navigate to the Client tab.

6. Check the "Enable unattended installation" box, browse to your unattend file at \RemoteInstall\WDSClient\Unattend folder (use the full network path—don't go through the WDS server's local C: drive), and click Open.

7. Click OK.

Next, you can associate the Windows Setup unattended file to the image for a full hands-off deployment. To do so:

1. Open Windows Deployment Services Manager.

2. Expand the image group that contains the image you want to use.

3. Right-click the specific image and select Properties.

4. Navigate to the General tab.

5. Click "Allow image to install in unattend mode," and then click the Select file and browse to your Windows Setup unattend file. Click OK.

6. Click OK to close out of the Properties sheet.