Since the inception of network operating systems, the men and women who are responsible for administering and managing them have wanted an easy way to do so. Networks have gone through a natural evolution from peer-to-peer networks to directory-based networks. Directory-based networks have become the preferred type of network because they can ease an administrator’s workload. To address the needs of organizations, the Institute of Electrical and Electronics Engineers (IEEE) developed a set of recommendations that defined how a directory service should address the needs of administrators and efficiently allow management of network resources. These recommendations, known as the X.500 recommendations, were originally envisioned to include a large centralized directory that would encompass the entire world, divided by geopolitical boundaries. Even though X.500 was written to handle a very large amount of data, designers reviewing the drafts of these recommendations saw merit in the directory and soon the recommendations were adopted by several companies, including the two best known, Novell and Microsoft.

Active Directory is Microsoft’s version of the X.500 recommendations. Battles rage between directory services camps, each one touting its directory service as the most efficient one. Because some of the directory services, such as Novell Directory Services (NDS) and eDirectory, have been around longer than Active Directory, those that are familiar with NDS will attack Active Directory. Their attacks are usually focused on the idea that Active Directory does not perform functions the same way that NDS does.

When it is all said and done, companies that develop X.500-based directory services can interpret the recommendations and implement them to fit their design needs. Microsoft interpreted and employed the X.500 recommendations to effectively manage a Windows-based network. Novell did the same for a Novell-based network, and the two for years have been at odds over which is more efficient. All that notwithstanding, Microsoft has enjoyed great success with Active Directory. It has been adopted by thousands of organizations and will more than likely continue to be used for many years to come.

Source of Information : Sybex Mastering Active Directory for Windows Server 2008

Windows Server 2008 includes a new implementation (a complete redesign) of the original TCP/IP protocol stack called the Next Generation TCP/IP stack. This new framework is a total rewrite of TCP/IP functionality for both IPv4 and IPv6. It’s designed to better meet connectivity and performance needs in various networking environments using various networking technologies.

For the benefit of those stuck in a cave in Patagonia since the early 1980s, TCP/IP is the de facto standard network protocol stack for most server and workstation computers you’ll encounter, but it’s by no means the only one. It expands to Transmission Control Protocol/Internet Protocol and serves as the foundation for network traffic shuttled across the Internet. It’s become a nearly universal means for networked communications of all kinds.

The core network stack framework is improved and enhanced to increase existing functionality, complement it with supplementary performance enhancing functionality, and further expand that framework through additional features and components. The following are material that’s both directly and indirectly related to advances in the Next Generation TCP/IP network protocol stack in Windows Server 2008.


Receive window auto-tuning
In TCP, a receive window size defines the amount of data that a TCP receiver permits a TCP sender to push onto the network before requiring the sender to wait for acknowledgement of its receipt. Correctly determining the maximum receive window size for a connection is now automatically handled by receive window auto-tuning, which continuously determines the optimal window size on a per-connection basis using real-time bandwidth calculations.

Improved receive window throughput increases network bandwidth utilization during data transfers. If all receivers are optimized for TCP data, Quality of Service (QoS) can help reduce congestion for networks operating at or near capacity.

Quality of Service (abbreviated QoS) refers to the ability to shape and control the characteristics of ongoing network communications services. This idea operates on the notion that transmission and error rates (along with other traffic characteristics) can be measured, improved, and guaranteed — to some extent, anyway.


Compound TCP
The Next Generation TCP/IP network stack also treats connections with large receive window sizes and large bandwidth delays to Compound TCP (CTCP), a function that aggressively increases the amount of data sent in real-time by monitoring current traffic conditions.

CTCP also ensures that it doesn’t negatively impact other existing TCP connections and complements receive window auto-tuning support to provide substantial performance gains appreciable in any high-delay, high-throughput network environment.


Explicit Congestion Notification support
Lost TCP segments are assumed to be lost, probably owing to router congestion, which triggers a congestion control mechanism that dramatically reduces a TCP sender’s transmission rate. With Explicit Congestion Notification (ECN; see RFC 3168, which you can find at www.faqs.org/rfcs/rfc3168.html) support, both TCP peers and routers experiencing congestion accordingly mark packets they forward. On receipt of such packets, a TCP peer will scale back its transmission rate to ease congestion and reduce segment loss. Windows Server 2008 now includes core support for this protocol feature.


Quality of Service (QoS) support
Windows Server 2003 and Windows XP provide QoS functionality to applications through QoS APIs, which are leveraged to prioritize time-sensitive network data delivery functions. Windows Server 2008 and Windows Vista include new facilities for network traffic management on Windows networks so that high-priority traffic is handled first, which helps with streaming media, voice over IP, video conferencing, and other applications where quick response times are needed.

Policy-based QoS for enterprise networks allows IT staff to either prioritize or manage the send rate for outbound connections, which can be confined to applications, source/destination IPv4 or IPv6 addresses, and source/destination or a range of ports.


Enhancements for high-loss environments
The Next Generation TCP/IP stack also improves network conditions in highloss environments through several optimization features that include:

• (RFC 2582) The NewReno Modification to TCP’s Fast Recovery Algorithm: The NewReno algorithm provides faster throughput by changing the way a sender can increase its sending rate when multiple segments in a given window are lost, and the sender receives partial acknowledgement only for segments actually received.

• (RFC 2883) An Extension to Selective Acknowledgement (SACK) Option for TCP: SACK allows a receiver to determine when it has retransmitted a segment unnecessarily and adjust its behavior on-the-fly to prevent further unnecessary retransmissions. Fewer retransmissions result in more optimal overall delivery.

• (RFC 3517) A Conservative Selective Acknowledgement (SACK)-based Loss Recovery Algorithm for TCP: Windows Server 2003 and Windows XP use SACK information only to determine those TCP segments that have yet to arrive. Windows Server 2008 includes a method defined in
• RFC 3517 to use SACK information for loss recovery in the event duplicate acknowledgements are received, which is maintained on a perconnection basis by the Next Generation TCP/IP stack.

• (RFC 4138) Forward RTO-Recovery (F-RTO): Spurious retransmissions can occur as a result of increases in round trip time (RTT). The F-RTO algorithm prevents unnecessary retransmissions, particularly in wireless environments where client adapters may roam from point to point, to return quickly to normal send rates.

>>> Read more about Windows Server 2008 Enhances Networking - Offloading protocol processing < <<

Source of Information : For Dummies Windows Server 2008 For Dummies

A huge number of things are happening at any one time on a server: Users are logging in and accessing files, drives are spinning away, and processors are trying to make sense of it all. Each of these instances is considered an event. Being able to monitor these events and use them to interpret the health of your servers is an important aspect of administering a Windows Server 2008 network.

As its name suggests, the Event Viewer is used to view events. Although it is more of a passive tool (it doesn't supply you with the real-time data that you see in the Performance Monitor), it does give you access to a great deal of information.

You can view the events related to a particular role by selecting that role node in the Server Manager. For example, you can view the events related to file services on a file server by clicking the File Services node in the Server Manager node tree.

Although the Server Manager provides quick access to events related to a role, let's take a closer look at the Event Viewer, which can be opened as a separate snap-in. The Event Viewer accumulates events in a number of log files: Event Viewer can help you monitor hardware, application, service, and security issues.

The Event Viewer (Start, Administrative Tools, Event Viewer) provides two main categories of logs: Windows logs and Applications and Services logs. The Windows logs include the following:

• Application log— This log records events about the various applications running on the system. The developer typically presets these events in the software. The application log also records alerts configured in the System Monitor.

• Security log— This log records events related to the audit policies that you configure in Group Policy, "Deploying Group Policy and Network Access Protection"), such as the auditing of file access or the logon of a particular user or group of users. This log also tracks events related to resource use (such as files) on the network shares.

• Setup log— This log records events related to application installation and setup. This includes events regarding the adding or removal of server roles, information events when a role is added successfully, and warning events when a restart is necessary to finalize the addition of a role.

• System log— This log provides log entries based on a number of Windows Server 2008 presets. This includes information on things such as driver failures and services that fail to load. Anything to do with services or system resources can show up in this log.

A new set of logs, the Applications and Services logs, provide event logging for individual applications and server components. The default Application and Services logs include the Hardware Events (events related to hardware installation and failure), Internet Explorer (Internet Explorer–specific events) and Key Management Service (which is related to the use of encryption keys when sending and receiving data to other computers on the network). Other logs available in this category depend on the software and roles installed on the server.

A system of icons is used to classify the type of event that has been recorded in a particular event log. In the System log and the Application log, you can find the following event categories (each represented by a different icon in the Event Viewer):

• The Information icon— Denotes the logging of successful system events and other processes

• The Warning icon— Shows a noncritical error on the system

• The Error icon— Indicates the failure of a major function (such as a driver failure)

To view a specific log in the Event Monitor, select the log's node in the node tree. The events recorded in that log appear in the Details pane.

Two additional icons are found in the Security log:
• The Success Audit icon— Shows that a security access event was successful (such as the access of a certain folder or file on the network)

• The Failure Audit icon— Shows that an audited security event failed (such as the failure of a user logon)

To view the properties of a particular event in a log, double-click on the event's icon in the Details pane. For example, you may want to see the details related to an Error event logged in the System log.

Microsoft now provides event-specific help for logged events. For more information on a logged event, click the Event Log Online Help link in the event's Properties dialog box. You are informed that the Event Viewer will send the information related to the event over the Internet. Click Yes to continue.

Internet Explorer opens and provides additional information on the event. This information includes an explanation of the event and possible actions to be taken to remedy the problem related to the event.

Source of Information : Sams Teach Yourself Windows Server 2008 in 24 Hours

The Reliability and Performance Monitor snap-in enables you to monitor server performance in real time. You can monitor hardware and application performance and create threshold alerts and performance reports. In terms of defining performance and reliability, performance describes how quickly the server completes the tasks it must accomplish. Reliability, on the other hand, is more a measure of how often the server performs exactly as you would expect in relation to its configuration.

The Reliability and Performance Monitor snap-in also provides access to the Performance Monitor, which was available in Windows Server 2003, and the new Reliability Monitor. The Performance Monitor enables you to add counters to quickly view real-time hardware information such as the percent processor time and also view information related to system services such as HTTP (on a web server).

The Reliability Monitor provides a System Stability chart that can be used to quickly view specific information about hardware, application, and Windows failures. You can click on a chart date, which runs along the x-axis of the chart and then view various system stability reports related to alerts and failures. The Reliability Monitor, which, in effect, provides some of the same type of information that you could glean from the Event Viewer, is discussed later in the hour.

Obviously, the Reliability and Performance Monitor provides a lot of potential information related to how a server is performing in terms of both hardware and software (including the operating system). What you are really trying to do when you monitor server performance is identify potential performance bottlenecks (say the CPU or the hard drive). When you measure reliability, you are looking for such things as device drivers that failed to initialize or services that had to stop and restart. Reliability often relates to the server configuration rather than hardware configuration, as performance does.

You can open the Reliability and Performance Monitor in the Server Manager (Start, Administrative Tools, Reliability and Performance Monitor). Expand the Diagnostic node and then select the Reliability and Performance node.

You can also run the Reliability and Performance Monitor snap-in in the MMC (Start, Administrative Tools, Reliability and Performance Monitor

The Resource View pane of the Reliability and Performance Monitor provides you with a quick look at CPU, Disk, Network, and Memory usage on the server. Real-time counters at the top of the window show you how each of these resources is currently affected by demand on the server from such things as user access, resources served to users, and other processes running on the server that are related to the various roles you have assigned the server.

Below the Resource View graphs is the Resource View details area. By default, all the Resource details are closed and show a counter that provides the running data points that are shown in the associated graph.

You can expand each of the Resource views to view the details related to a particular resource such as the CPU resource, which measures the total percentage of CPU capacity currently in use. When you expand the CPU resource, you are in the Resource Overview details (for CPU capacity), which provides a detail table.

Let's look at each of the resources measured in the Reliability and Performance Monitor and what kind of details are provided when you look at the expanded view details for a particular resource. The Resource view provides the following information:

• CPU— The total percentage of CPU use is displayed in green. The CPU Maximum Frequency is displayed in blue. The details table contains the following:
Image— Application using the CPU
PID— The application instance's process ID
Description— The application name
Threads— Active threads from the application instance
CPU— CPU cycles active from the application instance
Average CPU— Average CPU load (over the last 60 seconds) from the application instance

The PID or process identifier is the unique number the operating system assigns to a process. A thread is part of an application that can execute independently.

• Disk— The total input/output (current) is displayed in green. The percentage for the highest active time is displayed in blue. The details table contains the following:
Image— Application using the disk
PID— The application instance's process ID
File— The file read/written by an application
Read— The current read speed (in bytes/minute) for the data by an application
Write— The speed (bytes/minute) at which the application is writing data
IO Priority— The I/O task priority for the application
Response Time— Disk response time in milliseconds

• Network— Displays the total network traffic (Kbps) in green and the network capacity percentage currently in use in blue. The details table contains the following:
Image— Application using the network resources
PID— The application instance's process ID
Description— The application name
Address— The network address (IP address, FQDN name, or computer name) with which the local computer is exchanging information
Send— The data currently being sent from the local computer (as sent by the application named in the Image line)
Receive— The amount of data currently being received (bytes/minute)
Total— Total bandwidth used (that is, sent and received) in bytes/minute by the application

• Memory— Displays the hard faults per second in green and the physical memory currently in use percentage in blue. The details table contains the following:

A hard fault or page fault is basically when data requested by the application instance is not in real memory and so must be retrieved from the paging file and loaded into memory.

Image— Application using the network resources
PID— The application instance's process ID
Description— The application name
Hard Faults/Min— Hard faults (per minute) resulting from the application instance; a lot of hard faults would indicate that your server's memory is becoming a performance bottleneck
Working Set (KB)— The amount of memory (in kilobytes) currently being used by the application instance
Shareable (KB)— The amount of memory in the working set that may be available to other applications.
Private (KB)— The amount of memory in the working set reserved for the application instance

Obviously, the Resource view details provide a lot of information. But the key to using this information really lies in the fact that server performance can be affected in a negative way by two things: hardware problems and software problems.

The typical hardware bottlenecks for a server are the CPU, disks, network adapter (or adapters), and memory. The Reliability and Performance Monitor provides graphs for these hardware components because they can often be the reason the server is underperforming.

If the problem isn't directly related to a hardware malfunction, the problem can be a software issue that is monopolizing one of the key server hardware components, such as the CPU or the network adapter. Having quick access to the information related to the application instance enables you to potentially identify a malfunctioning software entity. So, although you can gain more specific real-time data using the various counters available in the Performance Monitor and more details related to server hardware and software events that are logged in the Event Viewer, the Reliability and Performance Monitor is definitely a quick way to survey a server's health.

The Reliability Monitor, a new tool provided by the Reliability and Performance Monitor snap-in, provides a system stability chart that enables you to view events related to software, application, and hardware failures. It provides quick access to "bad" events in a timeline, making it a useful addition to server troubleshooting, particularly when used with Event Viewer data.

Using GP, you can assign scripts to entire domains, organizational units, sites, and groups instead of repeatedly entering the same login script into multiple users' profiles. You can launch four types of scripts using a GPO: logon and logoff scripts, which apply to users, and startup and shutdown scripts, which apply to computers. Startup scripts are executed before logon scripts, and logoff scripts are executed before shutdown scripts.

You can write scripts in any number of languages. Windows Server 2008 is prepared to accept Jscript (.JS) and Visual Basic Scripting Edition (.VBS) files in addition to batch (.BAT), compiled command scripts (.COM), and application executables (.EXE). Scripts to be run through GP are stored on domain controllers in %SystemRoot%\SYSVOL\yourdomain.com\Policies\scripts, with yourdomain.com replaced with your fully qualified domain name.

You can assign startup and shutdown scripts in GP using the following procedure:

1. In the Group Policy Object Editor, navigate in the lefthand pane through Computer Configuration, Policies, Windows Settings, and Scripts (Startup/Shutdown).

2. In the righthand pane, click Startup and Shutdown to modify the scripts assigned to each.

You can assign logon and logoff scripts in GP using the following procedure:

1. In the Group Policy Object Editor, navigate in the lefthand pane through User Configuration, Policies, Windows Settings, and Scripts (Logon/Logoff).

2. In the righthand pane, click Logon and Logoff to modify the scripts assigned to each.

You can further define properties for these scripts under the Computer Configuration/Policies/Administrative Templates/System/Scripts and User Configuration/Administrative Templates/System/Scripts nodes in the Group Policy Object Editor. For users running scripts, you have the following options :

"Run legacy logon scripts hidden" tells Windows not to display the DOS window when using a .COM or .BAT logon or logoff script.

"Run logoff scripts visible" indicates whether the actions and results of the logoff script's execution should be displayed to the user.

"Run logon scripts synchronously" allows you to specify multiple scripts and have them run at the same time rather than in sequence as the default dictates.

"Run logon scripts visible" indicates whether the actions and results of the logon script's execution should be displayed to the user.

For computers running scripts, you can configure the following options:

"Allow logon scripts when NetBIOS or WINS is disabled" instructs Windows to either run or ignore logon scripts depending on where you have enabled the old legacy-compatible NetBIOS and WINS naming schemes.

"Maximum wait time for Group Policy scripts" sets a cutoff time for the execution of scripts specified in GP before Windows simply cuts them off and continues with the process at hand.

"Run logon scripts synchronously" allows you to specify multiple scripts and have them run at the same time, rather than in sequence as the default dictates, on a per-computer rather than a per-user basis.

"Run shutdown scripts visible" indicates whether the actions and results of the shutdown script's execution should be displayed to the user.

"Run startup scripts asynchronously" allows to you to specify multiple scripts and have them run in sequence, rather than at the same time, as the default dictates.

"Run startup scripts visible" indicates whether the actions and results of the startup script's execution should be displayed to the user.

*.* Source of Information : O'Reilly Windows Server 2008: The Definitive Guide

Software Restriction Policies allow you to control the execution of certain programs. It's an excellent feature to use on terminal servers or machines serving as a public kiosk, so users are locked into one specific function and can't mess with administrative tools or Internet applications and utilities.

Windows can identify software to either restrict or allow in several different ways. For one, it can use hash rules, which are made by identifying characteristics of files and executables that come with a program and generating an algorithmic hash from them. Hashes are great for identifying specific versions of programs because the hash value would change when different files are used to compute the hash (which is a near certainty with newer version of a program). Certificate rules can identify software via a digital signature, which is a useful method to secure authorized scripts. Windows also can identify software via its path and the Internet zone (inside Internet Explorer) from which a particular piece of software is downloaded. Finally, Windows can create a rule that catches any software not explicitly identified either in a list or by any other rule. (Control for programs executed within a browser is lacking from the GP standpoint, but improvements to Internet Explorer in Windows XP Service Pack 2 pick up a bit of this slack.) Windows matches programs to rules in the order in which they're listed in the software restriction GPO, and if more than one rule identifies the same program, the rule that catches the program most specifically will trump any other rule.

You might be tempted to create a rule that disallows programs from running by default aside from those explicitly placed in an exception list. This seems like an easy way out, but it really can lobotomize a system unless you take great care to create an exception for every Windows executable a user might need, including his application programs. It can also step on the toes of any user logon scripts that might be necessary to create a secure environment. If you decide to go this route, it's imperative that you extensively test any restriction policies and exception lists in a lab. Also, when you do create the actual software restriction GPO, make sure to add the Domain Administrators group to the GPO's ACL and explicitly deny the Apply Group Policy permission to the GPO—this will enable an administrator to reverse the policy and not lock himself out.

Once you're ready to create the policy, follow this procedure:

1. Create a new GPO for each restriction policy. This makes it easier to disable a policy that might be overly restrictive.

2. Choose Computer Configuration or User Configuration to apply the restrictions to machines or users, and then navigate through Policies à Windows Settings à Security Settings à Software Restriction Policies.

3. Right-click Software Restriction Policies and choose New Software Restriction Policy from the context menu.

4. Set a default identifier rule: in the left pane, click Security Levels, and then right-click a specific security level and choose Set as Default from the pop-up context menu.

5. Now, create the actual rules that will catch software on which to enforce a restriction. Right-click Additional Rules in the lefthand pane. Choose New Certificate Rule and select the certificate to require or block, New Hash Rule and the file to allow or block, New Internet Zone Rule and the zone from which to allow or block programs, or New Path Rule and the file or Registry key to allow or restrict.

6. In the righthand pane, double-click Enforcement. Here, indicate how these restrictions should be enforced. Use of the following options is recommended:

"All software files except libraries" will help you avoid blocking critical system and application function files.

"All users except local administrators" indicates that Windows should enforce the policy for everyone except those in the local administrator group.

7. Next, in the righthand pane, double-click Designated File Types. On this sheet, review and add file extensions associated with applications included in the software restriction policies. The list should be fairly complete, but ensure that any scripting languages you use in your organization have their associated file extensions included.

8. Finally, in the righthand pane, double-click Trusted Publishers. Here you can specify whether normal users, local administrators, or enterprise administrators are allowed to decide what certificates to trust when opening digitally signed programs and controls.

*.* Source of Information : O'Reilly Windows Server 2008: The Definitive Guide