RTM-Weekend! Win7, 2008 R2, Boot from VHD and more!

Yay! It’s RTM Weekend! Alright, not for everyone, because as we all are patiently waiting for August 6th as RTM hits TechNet and MSDN, but I needed to get the jump on things because I think I’m busy next weekend!

So, what does RTM weekend entail for me?  Testing was the first ground.   Testing installations on my hardware, and getting a feel for how I’ll architect my deployment model for Win7 and 2008R2!

First things first – Create bootable VHD Images to run my OS out of.    Yes, I planned to deploy my systems via Boot from VHD, so I needed to create bootable images! And for this little decision, I opted to take advantage of WIM2VHD! So, what exactly is WIM2VHD?  Well, that’s pretty simple to explain!

The Windows(R) Image to Virtual Hard Disk (WIM2VHD) command-line tool allows you to create sysprepped VHD images from any Windows 7 installation source. VHDs created by WIM2VHD will boot directly to the Out Of Box Experience, ready for your first-use customizations. You can also automate the OOBE by supplying your own unattend.xml file, making the possibilities limitless.
Fresh squeezed, organically grown, free-range VHDs – just like Mom used to make – that work with Virtual PC, Virtual Server, Microsoft Hyper-V, and Windows 7’s new Native VHD-Boot functionality!

All you need in order to be successful with WIM2VHD is:

  • A computer running one of the following Windows operating systems:
    • Windows 7 Beta or RC (or RTM)
    • Windows Server 2008 R2 Beta or RC (or RTM)
    • Windows Server 2008 with Hyper-V RTM enabled (x64 only)
  • The Windows 7 RC Automated Installation Kit (AIK) or Windows OEM Pre-Installation Kit (OPK) installed.
  • A Windows 7 or Windows Server 2008 R2 installation source, or another Windows image captured to a .WIM file.

Then, simply execute a command like I did below and you’re moving along!

Create a bootable VHD of Windows 7 Ultimate
cscript WIM2VHD.WSF /wim:D:\sources\install.wim /sku:ultimate /VHD:C:\vhd\win7ult.vhd

Create a bootable VHD of Windows Server 2008 R2 Enterprise
cscript WIM2VHD.WSF /wim:D:\sources\install.wim /sku:serverenterprise /VHD:C:\vhd\R2Ent.vhd

This frankly takes care of most of the work on your  behalf! (Sure did for me!)

FYI: The image defaults to 40gb, so if you want to change that, use this flag /size:<vhdSizeInMb>

After this point all you need to do is bcdedit and make the system bootable and you’re set!

bcdedit /copy {current} /d “New VHD Description”
    bcdedit /copy {current} /d “Windows 7 Ultimate”
bcdedit /set <guid> device vhd=[driveletter:]\<directory>\<vhd filename>
    bcdedit /set {GUID} device vhd=[c:]\vhd\win7ult.vhd
bcdedit /set <guid> osdevice vhd=[driverletter:]\<directory>\<vhd filename>
    bcdedit /set {GUID} osdevice vhd=[c:]\vhd\win7ult.vhd
bcdedit /set <guid> detecthal on
    bcdedit /set {GUID} detecthal on

And you can perform those same exact steps again for your 2008 R2 VHD as well.   It’s not only pretty straight forward, but it’s so simple anyone can do it! After performing those steps I was up and running on a system which had no data, nothing, notta!

Now, to apply some context and depth to how I chose to use my deployment model.  I’m running on my personal Lenovo T61p, which I have a Kingston 128GB SSD disk inside of.   Because I wanted to have ‘some’ kind of Native OS in order to help work on anything should something go wrong, I opted for a 2008 Server R2 Enterprise (Core) installation.  That gives me a minimal foot print, yet an OS I can feel comfortable and confident in being able to work on and with!  

What this enables is my NOS which runs on the “C:” drive, and has a VHD directory where my images live.  However, when I’m booted into either of my BootFromVHD OS’s on here, the native SSD becomes the “D:” drive whereby I can share files between the two systems!   However, if you forget to copy something to the shared volume and need to access it, feel free to use the mount VHD feature in the Disk Management tool (or Storage in 2008)

image image

I personally prefer to mount it read-only because… I don’t want to take any risks, especially when it comes to “Anti-Virus” or other things. (Unless that is my specific intention)

Now that you have a working and operational system you’re good to go! And if you stick with a NativeOS for Maintenance reasons, you can use it to take hard backups of your VHD’s for migration to other hardware or general recovery to other points in time! (note: You can backup the un-used OS from your active OS if you’d like as well :))

So, hope you have a good RTM weekend coming up, I look forward to being able to generate and use my license keys come August 6th!

When security best practices collide (Crippling iSCSI in Windows)

As a security guy, I can tell you – There are a lot of really good security best practices to be applied across all systems, applications, servers and a world over. But when implemented unchecked – Problems will arise.

What I am talking about specifically is this little doozy – EnablePMTUDiscovery

Value name: EnablePMTUDiscovery
Key: Tcpip\Parameters
Value Type: REG_DWORD
Valid Range: 0, 1 (False, True)
Default: 1 (True)

The following list describes the parameters that you can use with this registry value:

  • 1: When you set EnablePMTUDiscovery to 1, TCP attempts to discover either the maximum transmission unit (MTU) or then largest packet size over the path to a remote host. TCP can eliminate fragmentation at routers along the path that connect networks with different MTUs by discovering the path MTU and limiting TCP segments to this size. Fragmentation adversely affects TCP throughput.
  • 0: It is recommended that you set EnablePMTUDiscovery to 0. When you do so, an MTU of 576 bytes is used for all connections that are not hosts on the local subnet. If you do not set this value to 0, an attacker could force the MTU value to a very small value and overwork the stack.

    Important Setting EnablePMTUDiscovery to 0 negatively affects TCP/IP performance and throughput. Even though Microsoft recommends this setting, it should not be used unless you are fully aware of this performance loss.

    That little excerpt taken from:
    How to harden the TCP/IP stack against denial of service attacks in Windows 2000

    This KB article is still used and is applicable to the Windows 2003 space, but what does this do exactly?

    This will drop all transmissions over TCP/IP down to 576 byte packets. Oh and this is a global setting.
    So, you go to connect up to an iSCSI LUN, and it connects up just fine.
    Your host is working, your storage is working everything is all doozy.

    When you start to try to actually -use- that connection for storage though, you’ll begin to experience exponential latency. This latency will translate into IOPS problems and access to the disk, masking this making it appear to be a disk issue. This effectively cripples your application, yet is hidden so well from the system as a problem without sniffing or using something like mturoute you’d never know it is happening.

  • MTURoute is your friend and will help you determine your current MTU

    With that said, on any systems with iSCSI connectivity, I strongly encourage you to NOT disable this setting, ensuring that EnablePMTUDiscovery is always set to 1

    Thanks for your time!