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