Planet Lowyat

Personally, I have download Windows Server 2008 codename Longhorn from MSDN but yet to install and test it(My colleague installed as a VM guest in one of the VMware ESX 3.5 farm and it’s worked).

According to Yahoo and Inforworld, Windows Server 2008 enhancements work pretty much as expected such as restartable Active Directory Domain Services (AD DS) and several integrity-related NTFS enhancements. Other Longhorn changes can take quite a bit of planning to deliver what you’d want, plus may require you to buy new hardware to take advantage of them: Server Core, RODCs (read-only domain controllers), failover clustering, multi-path I/O, and Next Generation TCP/IP.

Restartable ActiveDirectory Domain Services
In previous versions of Windows Server, if ActiveDirectory installation becomes corrupt and an authoritative restore is necessary, you need to bring down the server and boot it in a special mode to do that restoration. The server and all of its services are completely down during this time.

Longhorn changes that scenario with Restartable ActiveDirectory Domain Services. Just turn off AD DS, and when you restore ActiveDirectory or do anything else with the database, the rest of the server’s services are still online. That means Windows Server 2008 can still handle DNS, DHCP, WINS, and all other requests. The one thing it can’t do while AD DS is off is authenticate users.

The only caveat on using Restartable AD DS involves human error: It’s possible to forget to turn the service back on.

Although you should rarely need to use Restartable AD DS, it’s nice to have for those times you do have to restore a large server, which can take 30 minutes or so to boot.

NTFS enhancements
Microsoft has made me very happy with its enhancements to NTFS. In Longhorn, NTFS is no longer just a file system. Instead, it’s an active part of the server and its integrity.

One of the changes, transactional NTFS, is just phenomenal. It lets you define transactions for server-level operations, so you can, for example, set up a transaction that copies files to a directory, creates a registry entry, and registers a DLL. Because these changes are handled as a single transaction, Longhorn ensures that they all complete or that the entire operation rolls back. That way, you won’t have an orphaned registry entry because the files didn’t copy over properly.

You can put anything into a transaction and enjoy the full atomicity, consistency, isolation and durability (ACID) properties that database people have enjoyed for years. The really nifty part about this is that you can also coordinate these server-level OS transactions with SQL Server or MSMQ transactions. For example, you could load data, FTP some files, and run an SSIS package all inside a transaction and not have to worry about picking up the pieces should one step fail.

NTFS has also been made self-healing. In Windows 2003, you have to bring down the server to fix corruption in the file system and run chkdsk.exe. Longhorn eliminates this need by letting NTFS monitor itself for corruption and fix itself in the background, without any interruption in service. When it comes across something it can’t fix itself, Longhorn’s NTFS can notify you and list possible solutions.

Server Core
Longhorn introduces Server Core, a stripped-down version of Windows that has only essential services running on it, to streamline the operation and security of main Windows roles such as DNS, DHCP, and file serving. It doesn’t even have a GUI; normal Windows operations are done completely from a command line, though some functions will call up a GUI when needed. Note that Server Core is not a separate product but an install option for Longhorn.

One benefit of using Server Core instead of the full-blown Windows Server 2008 is that the surface area for attack is significantly reduced: If you have fewer services running, there’s not as much on the machine to attack.

Using Server Core also means there aren’t as many things needlessly eating up resources. But there is a limit to Server Core’s utility: third-party applications usually won’t run on it. So if, for example, you have monitoring agents, check with your vendor to see if they do or will support Server Core.

Also, you cannot install anything that requires .Net, such as SQL Server or Exchange, and you cannot run PowerShell on it. But Core Server can be a target for PowerShell scripts and remote agentless monitoring tools. Also, Microsoft has published the Server Core APIs so you can write apps on Server Core as a host (not as a target).

In the traditional Windows sense, Microsoft has had the concept of dedicated servers for a long time. What it hasn’t had is the concept of a dedicated database or e-mail server. It would be good if Microsoft expanded the Server Core model to both SQL Server and Exchange so you could, for example, install Server Core with only the essential services needed for SQL Server. It’s the next logical step.

Read-only domain controllers
RODCs fetch a highly requested feature by customers ??? provide large IT shops a way to increase security at their branch offices. Because they are read-only, RODCs don’t let changes be made to then and don’t replicate anything back. That means branch offices can authenticate their users against an RODC’s database without having to send the credentials across the sometimes-slow WAN link.

RODCs fetch user credentials as users log on via the network, storing them in the cache so the WAN is not needed to authenticate the user the next time. The hub domain controller can adjust the cache settings and even choose whether the RODC caches credentials at all. The locally-cached-credentials approach is supposed to increase security because if an RODC is stolen, only the local credentials are stolen with it. This means the branch office is no less vulnerable using RODCs than it is not using them. (It’s impossible to cache user credentials locally on a server and have that server be immune to compromise if it gets stolen.)

But headquarters is safer as a result. Not only do RODCs keep a hacker from accessing headquarters’ user credentials from a branch office, they also let you limit the stolen users’ ability to access headquarters’ resources. Here’s how: Windows Server 2008 lets a domain administrator grant local admin rights on the RODC to a normal domain user. Therefore, if the RODC becomes physically compromised, none of the accounts stolen will have elevated rights anywhere else in the domain. That confines the breach to that branch office.

However, having a server stolen out of a server room isn’t that common. In my 15 years in IT, I haven’t even heard of it happening anecdotally.

If you decide you want the extra protection of RODCs, be aware that you need at least one Longhorn domain controller on the network and that the domain compatibility level has to be at least Windows 2003.

Failover clustering
Longhorn provides several clustering enhancements as well. One of the most important is the new quorum model. In Windows 2003, the typical clustering scenario depends on the quorum node ??? essentially, the master disk ??? being available to the nodes that share the clustered data. This need for a quorum node thus presents the very single point of failure that clustering is designed to prevent. Although Windows 2003 provides the alterative majority-node clustering model, in which each node has a local copy of the quorum data, most implementations of Windows 2003 use the shared-node approach because they have just two nodes not enough for a majority-mode approach.

Longhorn’s new quorum model merges the shared-node and majority-node models. Instead of a quorum node that the cluster must have to function, all nodes can have the quorum data. And in the case of a two-node cluster, each node plus the shared-storage device get a vote, assuring that if any one fails there is still a majority to constitute a quorum.

Clustering in Longhorn is now SAN-friendly as well. In Windows 2000, failover clustering used SCSI resets regularly. (A SCSI reset is a command that breaks the reservation on the target device. These bus resets affect the entire bus and all devices connected to it, so a SCSI reset causes all the devices on the bus to be disconnected.) Windows 2003 improved on that by using SCSI resets only as a last resort. In Longhorn, failover clustering doesn’t use SCSI resets at all. Coupled with the new quorum model, this change goes a long way to making your cluster more stable.

Microsoft has also overhauled hardware compatibility for clustering. In Windows Server 2003, IT had to check a static Hardware Compatibility List or the Windows Server Catalog, which pretty much covered just entire clustering solutions from various vendors, not their individual components. But with Longhorn, Microsoft provides tools so you can test your hardware yourself. That shifts hardware compatibility to a best-practices model, and gives vendors as well as users more control over the choices they make. (Vendors still have to conform to the Windows Logo Program’s requirements.) This doesn’t mean that Microsoft recommended that you piece together a clustering solution from mismatched hardware, but you can if you want or need to.

There is a big caveat to the clustering enhancements: You may not be able to just upgrade your current cluster to Longhorn. The new enhancements come with new hardware requirements, and there’s no guarantee that your current hardware will be supported. And if you upgrade your current environment to Windows Server 2008 as is, it may become unstable or even unavailable. Be sure to download and run Microsoft’s compatibility tools on your current hardware before upgrading your cluster.

Multi-path I/O
Windows Server 2008’s new Multi-path I/O capability is designed to increase your uptime by letting you set up a redundant path to your disks in case of hardware failure. But understand that this feature is only as production-ready as your budget. It does not work right out of the box when you install Longhorn; you have to have the hardware that will support it.

Next Generation TCP/IP
Longhorn has a completely revamped TCP/IP stack called Next Generation TCP/IP (NGTCP). NGTCP’s biggest improvement is the auto-adjusting of the receive window. The Receive Window Auto-Tuning capability determines the optimal receive window size per connection by measuring the bandwidth-delay product (the bandwidth multiplied by the latency of the connection) and the application retrieval rate. It then automatically adjusts the maximum receive window size on a regular basis. This can actually increase performance by orders of magnitude under the right conditions.

Of course, there is a catch: To take advantage of this feature, both servers involved in the communication have to use NGTCP. Today, that is limited to Vista and Longhorn.

Another seriously cool feature in NGTCP is the transport offload engine (TOE). The TOE lets the server offload TCP processing to the NIC, so the server’s CPU can concentrate on server processes instead of communication processes. Offloaded processes include checksum calculations for both TCP and UDP, IP security authentication and encryption, segmentation of large TCP packets, and the TCP stack itself. But again there’s a catch: You need specialized NICs.

Sounds Good? How about WinFS(Windows File System)? How about SysInternals tools? Most of the system admin love sysinternal tools. CLI(Command Line Interface)? Yes I think Powershell will be powerful.