The Windows Server 2008 team has made a special effort at improving network performance and efficiency. For the first time, there is a dual-IP layer architecture for native IPv4 and IPv6 support together, simultaneously. (If you've ever configured IPv4 and IPv6 on a Windows Server 2003 machine, you'll know what a pain it is to get them to interoperate without falling all over each other.) Communications security is enhanced through better IPsec integration throughout the various pieces of the TCP/IP stack. Hardware is used more efficiently and robustly to speed up performance of network transmissions, intelligent tuning and optimization algorithms run regularly to ensure efficient communication, and APIs to the network stack are more directly exposed, making it easier for developers to interact with the stack. Let's take a look at some of the improvements in what the team is calling Next Generation Networking.
TCP/IP Stack Enhancements
As I alluded to earlier, many changes in Windows Server 2008 were made to the TCP/IP stack itself. One such improvement is the auto-tuning TCP window size: Windows Server 2008 can automatically tune the size of the receive window by each individual connection, increasing the efficiency of large data transfers between machines on the same network. Microsoft quotes the following example: " ... on a 10 Gigabit Ethernet network, packet size can be negotiated up to 6 Megabytes in size."
The dead gateway detection algorithm present in Windows Server 2003 has been slightly improved: Windows Server 2008 now tries every so often to send TCP traffic through what it thinks to be a dead gateway. If the transmission doesn't error out, then Windows automatically changes the default gateway to the previously detected dead gateway, which is now live. And Windows Server 2008 supports offloading network processing functions from the CPU itself to the processing circuitry on the network interface card, freeing up the CPU to manage other processes.
There are also improvements to network scaling. For example, in previous versions of Windows Server, one NIC was associated with one single, physical processor. However, with the right network card, Windows Server 2008 supports scaling NICs and their associated traffic among multiple CPUs (a feature called receive-side scaling), permitting much higher amounts of traffic to be received by one NIC on a highly loaded server. This particularly benefits multiprocessor servers, since more scale can be added simply by adding processors or NICs and not by adding entirely new servers.
Changes to Terminal Services
Network applications are growing in popularity with each passing week. Windows Server 2008 sees more work in the Terminal Services/Remote Desktop area than might have been expected, and some of the new capabilities are very welcome improvements. Aside from the three new features, the team worked on improving the core processes that make TS tick, including single sign-on to Terminal Services sessions, monitor spanning and high-resolution support for sessions, integration with the Windows System Resource Manager to better monitor performance and resource usage, and themes that make TS sessions seamless to the client.
There are three key new features added in the Windows Server 2008 release. The first is Terminal Services RemoteApp. Like the functionality offered by Citrix MetaFrame years ago, Windows Server 2008 will support—out of the box—the ability to define programs to be run directly from a TS-enabled server but be integrated within the local copy of Windows, adding independent taskbar buttons, resizable application window areas, Alt-Tab switching functionality, remote population of system tray icons, and more. Users will have no idea that their application is hosted elsewhere, except for the occasional slow response because of network latency or server overload. It's also simple to enable this functionality: administrators create .RDP files, which are essentially text-based profiles of a Terminal Services connection that the client reads and uses to configure an RDP session for that particular program. They can also create .MSI files that can populate profiles; the main advantage here is that .MSI files are traditionally very easy to deploy via automated system management methods like Systems Management Server, Group Policy and IntelliMirror, and so on.
Next, there's the Terminal Services Gateway. This feature allows users to access Terminal Services-hosted applications from a web portal anywhere on the Internet, secured via an encrypted HTTPS channel. The gateway can send connections through firewalls and correctly navigate NAT translation situations that stymied the use of this technology before. This saves corporations from having to deploy VPN access to remote users for the sole purpose of accessing a Terminal Services machine; plus, since the data is sent over HTTPS, almost anyone can access the sessions, even at locations where the RDP protocol is blocked by the firewall. Administrators can set connection authorization policies, or CAPs, that define user groups that are permitted to access TS through the TS Gateway machine.
Finally, in conjunction with the Terminal Services RemoteApp feature, there is also in Windows Server 2008 the TS Web Access feature, which lets administrators publicly display available TS Remote Programs on a web page. Users can browse the list for the application they want to run, click on it, and then be seamlessly embedded in the application—using all the features of TS Remote Programs—while retaining the ability to launch other programs from the same Web Access site. The service is smart enough to know that multiple programs launched by the same user should reside in the same Terminal Services session, making resource management a bit simpler. And, you can even integrate TS Web Access within SharePoint sites using an included web part.
Active Directory: Read-Only Domain Controllers
Windows Server 2008 introduces the concept of a read-only domain controller (RODC), which is great for branch offices and other locations where the machines hosting the domain controller role can't be physically protected in the same way as a machine in a datacenter might be. RODCs hold a read-only copy of Active Directory, which allows for the immediate benefits of faster logons and quicker authentication turnaround times for other network resources, but also for the long-term security benefits. No attacker can create changes in an easily accessible DC in a branch office that will then replicate up to the main tree at the corporate office, since the DC is read-only. The RODC can also cache the credentials of branch office users and, with just one contact to a regular, writeable domain controller up the tree, can directly service users' logon requests. However, this caching is left off by default in the Password Replication Policy for security reasons.
*.* Source of Information : O'Reilly Windows Server 2008: The Definitive Guide
No comments:
Post a Comment