Server core is a lightweight, capable edition of Windows Server 2008.  A lot of baggage isn't there, making more resources available for network applications, while reducing the attack surface area.

 Some GUI tools are still available, but one of them that's not is a facility to manage the Windows Update process on the server console.  Arguably a sophisticated infrastructure wouldn't need this, and could use WSUS instead.  However there are those servers that need some administrative looking-after.

 A script to manually drive the windows update process for critical updates is available from Microsoft--follow this link.

 The script is dead easy to use, just copy to a server core machine and run using cscript.

1. Install Server 2008 Core x64 from DVD Media
 
2. Rename computer to new name
   Netdom renamecomputer %computername% /newname:SERVER1
 
3. Lookup the name of the network interface
  netsh interface ipv4 show interface
 
4. Assign IPv4 Address
   netsh interface ipv4 set address name=”Local Area Connection 2”
   source=static address=192.168.3.1 mask=255.255.255.0 gateway=255.255.255.0 1
 
5. Assign DNS servers
 Netsh interface ipv4 add dns name=”Local Area Connection” 192.168.3.5
 Netsh interface ipv4 add dns name=”Local Area Connection” 192.168.3.6 index=2
  
6. Join the domain
   netdom join %ComputerName% /domain:INTRANET /userd:<domain\user> /passwordd:*
 
7. Reboot windows (if not prompted)
   shutdown -r -t 0
 
8. After reboot, enable remote administration
   netsh advfirewall firewall set rule group="Remote Administration" new enable=yes
   netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes
 
9. Enable remote desktop from any client type
   Cscript %windir%\system32\SCRegEdit.wsf /cs 0
   Cscript %windir%\system32\SCRegEdit.wsf /ar 0
   netsh firewall set service type=remotedesktop mode=enable
 
10. Add Hyper-V Role
   bcdedit /set hypervisorlaunchtype auto
   start /w ocsetup Microsoft-Hyper-V
 
11. Update Hyper-V
   Run the file: 
   mu_update_for_windows_server_2008_kb950050_x64.msu

12. Activate Windows
   cscript %WinDir%\System32\slmgr.vbs -ato
 
12a. If windows won't activate and needs a VLK changed to a MAK
   start /w slmgr.vbs -ipk FFFFF-FFFFF-FFFFF-FFFFF-FFFFF
   start /w slmgr.vbs -ato
   (careful, the feedback popups sometimes popup behind the DOS window, so move it around before re-entering the command over and over)
 
13. Reboot windows (if not prompted)
   Shutdown -r -t 0

14. Install remote admin tools for Hyper-V
   Install the following on your desktop (choose depending on whether you run Vista x86 or x64)
   Hyper-V_Admin_Windows6.0-KB952627-x64.msu (Vista x64 Client)
   Hyper-V_Admin_Windows6.0-KB952627-x86.msu (Vista x86 Client)
   mu_update_for_windows_server_2008_kb950050_x86.msu  (Server 2008 x86)

15. Add the Hyper-V snap in to an MMC.exe instance on your desktop, connect to the Hyper-V virtual server from there, and you're off to the races!

In my work I often use Microsoft VirtualPC on my laptop to demonstrate software for clients and to conduct training.  Most anyone who's used a VPC to do a demonstration of server-based products--the kind that should be deployed on "real servers"--has at some point had the unpleasant experience of apologizing for poor performance during a pivotal moment in a demo.

I'm always looking for ways to speed up demos, and there are only a few general approaches I know of:

1. Lighten the "weight" of the VPC, so there's not so much bulk for the VPC OS to deal with and so the demo "fits" the constraints of the host's capabilities
2. Use a better VM technology (I'm currently converting my demos to Hyper-V--more on that in the future)
3. Separate the guest OS I/O from the host and use a fast external HDD

The faster disk option (#3) is one I employed some time ago when I had a spare 7200rpm disk to use as an external VHD store, but I never really "proved" that it worked better than the 5400 rpm disk it replaced.  I also never "proved" that moving to external USB 2.0 disks had helped in the first place! 

Recently I happened to have several USB 2.0 hard disks and some spare time available. (I upgrade way too often and I have too many computers).

I decided to do a somewhat scientific experiment to see if, in fact, the faster hard drive had actually helped, and if the performance of the external disks were similar to their internal alternatives.  The two variables I was able to change based on available hardware:

1. Dive interface SATA/IDE
2. Disk rotation speed (5400rpm/7200rpm)

Other than these factors, all else is the same (same PC, same brand USB 2.0/HDD enclosure, same tests). In addition to comparing the performance with the different external disks, I benchmarked the internal disk.  This was an interesting test because the internal and external 200GB drives are identical Seagate 200GB 2.5" drives--so the test should be an "apples to apples" comparison of throughput lost through USB 2.0.

The test environment:

• Lenovo ThinkPad X61 2Ghz Core2Duo CPU, Windows 2008 Standard x64, 4GB RAM 
• Test #1 - Copy a single 8GB VHD file from the ThinkPad to the USB hard disk
• Test #2 - SQLIO with large IO load (sequential I/O, 256KB read/write, 2 threads, 60 seconds, 100MB file size

Here are the test results:

Well, it appears that switching from a 5400 RPM disk to 7200 RPM USB 2.0 disk had actually delivered no benefit.  But I was a little suprised that the SATA interface also seemed to have no benefit over the older IDE technology...I had assumed that would have made a difference given the difference in transfer rates between the two. 

So, when USB 2.0 is the external I/O path, it seems that one needn't be too picky about the drive itself.  The USB interface is just too slow and inefficient to leverage the latest hard drive technologies.