Windows

and Linux
Integration:

Hands-on Solutions for a

Mixed Environment
Jeremy Moskowitz
Thomas Boutell

Copyright 2007 by Wiley Publishing, Inc., Hoboken, New Jersey

An update to ISBN 0-7821-4428-4.

Web Appendix

Windows 2003 / R2
Updated Procedures
If youre reading this, youve found the downloadable resources on http://www.WinLinAnswers
.com. This section is late-breaking material that we couldnt squeeze into the book. Thats because
this chapter is on Windows 2003 / R2, or, just R2 for short. R2 is Microsofts latest iteration of
Windows 2003 and it has much of the Services for UNIX (SFU) components built in.
R2 splits contains two main services:


Subsystem for UNIX-based Applicationsor SUA

Identity Management for UNIXor IMU

SUA helps UNIX-like applications work on Windows just as they did in Linux or UNIX.
Unfortunately, we dont have the ability to explore this here and will be focusing on IMU.
IMU, however, is the parallel for some of the pieces in SFU we explored in Chapter 3the
User Name Mapping Service, the NIS server, which rides on Active Directory and the ability to
embrace UNIX UIDs for users and GIDs for groups.
To that end, well revisit some of the procedures that we saw in the book itselfexcept this
time well perform these procedures with R2. This way, if you have R2, you can complete the
procedures you need to make the job happen.

Upgrading to R2
For the purposes of this book, were going to assume you already have Windows 2003 servers
and domain controllers, but will be making an upgrade (of at least one domain controller) to
R2. The installation of R2 from scratch isnt something well cover in depth here.

Were not going to talk much about loading a fresh Windows 2003 with R2
from scratch. If you get a Windows 2003 with R2 CD set, the first CD-ROM
(Windows 2003) will eventually prompt you for Disc 2, meaning the R2 disc.
Just follow the prompts, and youve got a fresh Windows 2003 with R2 ready
to go.

Web Appendix

Windows 2003 / R2 Updated Procedures

If you have trouble getting R2 to load (i.e., it wont accept your keycode)
you can try loading the first disc of the R2 set directly over your existing
Windows 2003 installation. Then, it should accept your second disc
because youve upgraded to R2 using disc 1.

However, it should be noted that there are basically two upgrading scenarios:
1.

Upgrading a domain where SFU is not already installed

2.

Upgrading a domain where SFU is already installed

These are two separate scenarios. If you have not already completed the exercises in the printed
book, you might want to first upgrade your domain to R2, then work through the exercises here.
However, in both scenarios, some steps to upgrade the domain are the same, and well perform those first.

Upgrading Your Windows 2003 Domain to R2

In all cases, the first thing you would do is pop in the R2 media. You are then presented with
the option to Continue Windows Server 2003 R2 Setup. If you click that, however, you
get the message seen in Figure A.1.
The dialog box says it all. In short, you need to run the command adprep /forestprep, which
is located in the R2 CD-ROM in the cmpnents\r2\adprep directory as shown in Figure A.2.
FIGURE A.1

In order to upgrade Windows 2003 to R2, the schema must be upgraded.

FIGURE A.2

Once you press C to continue, your schema will be upgraded to the R2 schema.

Upgrading to R2

Once performed, you can then run the R2Auto.exe on the root of the R2 CD-ROM and select
to Continue Windows Server 2003 R2 Setup. At this point, you may be instructed that you
have a service pack installed (and continuing will prevent any possibility of uninstalling it). Select
Yes when you agree to that. When you do, youll be at the R2 Setup Wizard. The wizard is selfexplanatory.
Once completed, youll be able to continue to load R2 components on the particular server
you want via the Add/Remove Windows Components found in Add/Remove Programs
in Control Panel. At this point we have to first ask ourselves whether or not SFU 3.5 was
previously installed on this server.

Upgrading a Server where SFU 3.5 (or 3.0)

Is Already Installed
Youve already performed the upgrade to the R2 schema. However, because SFU is already
installed on this server, you need to get from SFU to IMU in two big steps.
The first step is to save your SFU installation parameters. That is, while you cant do a direct
upgrade from SFU to IMU, you can first save your SFU configuration. Then, once IMU is
installed, it can find this saved configuration and keep on going as if nothing has changed.
The second step is to tell your R2 installation that you want to use IMU and utilize the saved
SFU configuration. Lets see how to do that now.

Saving your SFU Configuration

To save your SFU configuration, you need to select the Identity Management for UNIX as if
you wanted to install it. Start out by clicking Start  Add or Remove Programs  Add/Remove
Windows Components. Then, youll find it tucked away in Active Directory Services  Identity
Management for UNIX.
When you do, youll be prompted to save your SFU configuration, as seen in Figure A.3.
FIGURE A.3

You can preserve your SFU 3.5 installation.

Web Appendix

Windows 2003 / R2 Updated Procedures

When prompted, select Yes. When you do, youll get a brief note that the save was successful,
as seen in Figure A.4.
FIGURE A.4

Your SFU 3.5 configuration will be waiting for you when you upgrade to R2.

Click OK to close the message and cancel out of the Windows Components Wizard.
Next, youll need to uninstall SFU 3.5. Youll do this inside the Add or Remove Programs
window in the Change or Remove Programs section as seen in the Figure A.5. Simply locate the
Microsoft Windows Services for UNIX entry and click Remove.
FIGURE A.5

You need to remove SFU 3.5 before you upgrade to R2.

While SFU 3.5 is being removed, you may be told that your NFS mounts are being disconnected. Upon completion, youll be asked to reboot and will need to do so.
Once logged back in as Administrator, youre ready to add the IMU components. Click
Start  Control Panel  Add or Remove Programs. Select Windows Components.
Locate and check Active Directory Services  Identity Management for UNIX and click OK.
This adds three components: Server for NIS, Password Synchronization, and their corresponding Administrative tools.
Additionally, locate and check Other Network File and Print Services and ensure that
Microsoft Services for NFS Server for NFS and all other components are selected (except
Client for NFS) as seen in Figure A.6.
Click OK at each screen to return to the Windows Components. Then, click Next to finish
loading the new Windows Components from R2.
Finally, when finished, youll likely be prompted to restart the server. Go ahead and
do so.

Windows 2003 / R2 Authentication Services

FIGURE A.6

Ensure all components (except Client for NFS) are selected

Upgrading a Server where SFU 3.5 (or 3.0)

Is Not Already Installed
This procedure is quite simple. Since SFU 3.5 isnt already installed, theres nothing to save.
Simply click Start  Control Panel  Add or Remove Programs. Select Windows Components and locate and check Active Directory Services  Identity Management for UNIX and
click Next. Finally, when finished, youll be prompted to restart the server. Go ahead and do so.

Windows 2003 / R2 Authentication

Services
In much of the first part of the book, we talked about how Windows can play nice by authenticating Linux clients. We showed how to make Windows 2003 pretend to be an NIS server
and also how to make Active Directory respond directly to LDAP and Kerberos requests.
In this section, now that weve got R2 ready to rock, we can briefly walk through the differences. Many of the things that are different are mostly cosmetic. That is, pretty much everything
works the same as it did under SFU 3.5. The click-click-clicks might be a little different, but,
as near as we can tell, its basically the same moving parts underneath the hood.
In this section, well explore two cases: either youre upgrading from SFU 3.5, or youre not.
So be sure to pay special attention to each heading as we describe the scenario you might be in.

Web Appendix

Windows 2003 / R2 Updated Procedures

Windows 2003 / R2 Domain Controller as an NIS Server

Here, well explore the idea of making Windows 2003 pretend to be an NIS server. Again, this
isnt really recommended, and we didnt go into it much in the printed edition of the book. The
reason why we didnt explore this too much is simple: NIS is at what is called its end of life.
While some NIS installations still exist, it is certainly not suggested that you bring up a new NIS
environment when LDAP (a much more modern way to go) is available.
However, well discuss using Active Directory as an NIS server in case you have Linux NIS clients
you want to leverage against Active Directory.
Again, however, if you can avoid NIS, do soand authenticate directly using LDAP and
Kerberos (as performed in the next big section).

Enabling NIS Services

Before we continue however, in both cases, if youve upgraded from SFU 3.5 to Windows 2003 / R2
or performed a fresh installation of Windows 2003 / R2Windows does something a bit unexpected. That is, it disables the services required to run the NIS server. This is a new security mechanismostensibly to ensure that only those people who want to run NIS will run NIS. In our
opinions, this is not ideal, as this isnt really documented anywhere.
Therefore, if youre planning on using NIS now, youll need to enable iteven if youve just
loaded it via Control Panel. To do so, click Start and locate My Computer, then right-click and
select Manage. Then drill down to Services and Applications  Services and locate Server for
NIS and double-click it. Change the status from Disabled to Automatic. Then click Start to start
it. You can see the changed service properties in Figure A.7.
FIGURE A.7

Ensure that the Server for NIS is started and set to Automatic.

Windows 2003 / R2 Authentication Services

Additionally, before proceeding, also make sure that two other services are also set to automatic and started at this point: Server for NFS and User Name Mapping. One of these services
(Server for NFS) can be seen in the screen shot in Figure A.7, but the other (User Name Mapping) cannot.

Configuring your Windows 2003 / R2 NIS Server

If you want to configure your R2 server as an NIS server, you need to run the new IMU tools.
These are located in Start  Programs  Identity Management for UNIX  Microsoft Identity
Management for UNIX as seen in Figure A.8.
FIGURE A.8

You can start IMU from the Start menu

Remember what we said about the relationship to accounts in Active Directory and their NIS
account counterparts (which are also stored in Active Directory): theyre almost like two separate accounts that need to be synchronized with each other.
Once the tools are loaded, well perform two steps: one is changing how long synchronization between Active Directory account information and the NIS account information occurs,
and also turning on the actual password synchronization feature. This is accomplished in the
next two sections.

Changing the NIS Synchronization Schedule

By default, recall this synchronization happens but once a day. So, if you reset a UNIXenabled users password using Active Directory Users and Computers, it could take up to a
day for the changes to actually take effect and then be propagated to all domain controllers.

Web Appendix

Windows 2003 / R2 Updated Procedures

For our purposes, well change this value from 1 day to 5 minutes. With the Microsoft Identity
Management for UNIX console open, right-click over the Server for NIS branch and select
properties. In the General tab, change the time from 1 day to 5 minutes as seen in Figure A.9.
FIGURE A.9

Change the Active Directory to NIS update from 1 day to 5 minutes.

Once performed, click Apply, then OK.

Specifically Enabling Password Synchronization between Active Directory and NIS

This is a new feature of Windows 2003 / R2, which differs from SFU 3.5. In SFU 3.5, the NIS
table, called passwd was always exposed via Active Directory. That is, whenever the command
ypcat -d nisdomainname passwd

was issued from, say, a Linux machine to the NIS server running on Windows, the password
hash was always exposed.
With the password hash known, its a lot easier for an attacker to perform a dictionary
attack and get the password. Once the attacker has the password, they have the Active Directory credentials they need to masquerade as that user!
R2 provides two options (where SFU 3.5 only had one):


Option 1: Whenever the Active Directory password is changed, also update the UNIX NIS
password table.

Option 2: Whenever the Active Directory password is changed, dont update the UNIX NIS
password table.

SFU 3.5 only allowed for option 1. This basically meant the password was always available
and susceptible to prying eyes if they were dedicated enough to acquiring it. The fact that it was
hashed added a layer of security, but it wasnt much.

Windows 2003 / R2 Authentication Services

Now in R2, you can choose not to shuttle the password into the NIS passwd tables. This
adds an additional layer of security by keeping it from being updated in such a public way and
thus less susceptible to prying eyes.
And, this is the default. If you want to seriously consider using Active Directory as your NIS
server, youll likely want to turn this on (even though that makes your Active Directory less
secure). To adjust for this, you need to specifically turn on the password synchronization for
accounts that are NIS enabled.
Start by opening up the Identity Management for UNIX console, if its not already open, with
Start  All Programs  Identity Management for UNIX  Microsoft Identity Management for
UNIX. Once open, right-click over the words Password Synchronization and select Properties.

Specifically Turning on the Password Synchronization Feature

Next, we have to specifically click on the Configuration tab and turn on the password synchronization engine. Do this by clicking in the Enable Windows to NIS (AD) Password Sync check
box as seen in Figure A.10.
FIGURE A.10

Be sure to click Enable Windows to NIS (AC) Password Sync.

When you click the check box youll be asked to scan all domain controllers to ensure they
are using Windows 2003 / SP1. If you do not have SP1 on all your domain controllers, be sure
to do so before continuing in production.
Once performed, click Apply, then OK to finish.

Verifying NIS Accounts Are Viewable

Now, lets create a brand new user using Active Directory Users and Computers. Well assume
youve UNIX-enabled at least one group, say, Nurses group.

10

Web Appendix

Windows 2003 / R2 Updated Procedures

From this point, youll jump to Chapter 3, How to UNIX-Enable your Active Directory
Users and Groups, page 167 of the book. In my examples here, Ive created an account called
nurse4 with a UID of 24601 and who is a member of the nurses group, with a GID of
10000 and a password of p@ssw0rd.
You can now check the NIS servers accounts using the command
ypcat -d nisdomainname passwd

Below, the command for my domain named demo is

ypcat -d demo passwd

You can see the output of the command seen in Figure A.11.
FIGURE A.11

The NIS server should dump its database as output with a ypcat command.

Note that the password hash is the default value of ABCD!efgh12345.

However, you might remember you changed the synchronization time to be every 5 minutes.
You would think that if you wait 5 minutes then retype the command, that the password hash
would change to a valid value.
But it wont. Why not? Lets examine the steps you just performed to create the new user,
nurse4:


You created the account with Active Directory Users and Computers

You set the Active Directory password when you created the account

You then UNIX-enabled the account

And therein lies the problem! There is no UNIX password on this account! Whats the trick
to getting the password into the UNIX half of the account? Reset the accounts password
(even though you just created it) using Active Directory Users and Computers. Then once the
refresh interval hits, you should see the password hash change to something meaningful.

Sometimes, I have found that the password hash did not change, but it
worked anyway. I can only suspect this is a bug in the yp stack from R2.
This also happened in SFU 3.5.

Microsoft has an excellent document about how to embrace UNIX NIS servers
into the mix, say, as slave (subordinate) servers. Its in an online-only document entitled Best Practices for Server for NIS and can be found at http://
tinyurl.com/r7slh.

Windows 2003 / R2 Authentication Services

11

At this point, you could possibly retire UNIX NIS servers, as youre now using Active Directory to pretend to be NIS. However, dont forget to touch your Linux machines and tell them
where the new NIS server is. We have an example on how to do this in Chapter 3 of the book.

Using R2s Extended Active Directory for Linux

Authentication via LDAP and Kerberos
In Chapter 3 of the book we used SFU 3.5, extended the Active Directory schema, then had
Linux clients utilize Active Directory to look up account information for login.
Now that our schema has been upgraded to Windows 2003 / R2, we need to change some
things so performing lookups via LDAP and authentication using Kerberos works with this new
schema. The idea is that Windows 2003 / R2 uses a different schema than SFU 3.5 does. So,
when Linux clients try to look up simple things in Active Directory like user name, UID number,
GID number, and the like, they now need to be told this new locationnot the old location
from SFU 3.5.
The old schema is the SFU 3.0 schema (which is the exact same schema for SFU 3.5.). You
can read all about the ins and outs of the new schema, called RFC 2307, here at http://
www.ietf.org/rfc/rfc2307.txt.
Both schemas define lots of attributes that a Linux client could use. So, what we need first
is an apples to apples comparison of those attributes. In Table A.1, we can see the original SFU
name and the new corresponding R2 name (via RFC 2307) for the same attribute. Note in some
cases, there isnt an RFC 2307 attribute to express how to do something in SFUhence, the
Microsoft team just kept the same name.
TABLE A.1
attributes

Original SFU names and new R2 names for corresponding

SFU Name

R2 / RFC 2307 Name

msSFU30UidNumber

uidNumber

msSFU30GidNumber

gidNumber

msSFU30Gecos

gecos

msSFU30HomeDirectory

unixHomeDirectory

msSFU30LoginShell

loginShell

msSFU30ShadowLastChange

shadowLastChange

msSFU30ShadowMin

shadowMin

msSFU30ShadowMax

shadowMax

12

Web Appendix

Windows 2003 / R2 Updated Procedures

TABLE A.1
Original SFU names and new R2 names for corresponding
attributes (continued)
SFU Name

R2 / RFC 2307 Name

msSFU30ShadowWarning

shadowWarning

msSFU30ShadowInactive

shadowInactive

msSFU30ShadowExpire

shadowExpire

msSFU30ShadowFlag

shadowFlag

msSFU30MemberUid

memberUid

msSFU30MemberNisNetgroup

memberNisNetgroup

msSFU30NetgroupDetail

nisNetgroupTriple

msSFU30IpServicePort

ipServicePort

msSFU30IpServiceProtocol

ipServiceProtocol

msSFU30IpProtocolNumber

ipProtocolNumber

msSFU30OncRpcNumber

oncRpcNumber

msSFU30IpHostNumber

ipHostNumber

msSFU30IpNetworkNumber

ipNetworkNumber

msSFU30IpNetmaskNumber

ipNetmaskNumber

msSFU30MacAddress

macAddress

msSFU30BootParameter

bootParameter

msSFU30BootFile

bootFile

msSFU30NisMapName

nisMapName

msSFU30NisMapEntry

nisMapEntry

msSFU30Password

userPassword

msSFU30MemberOfNisNetgroup

see note

Windows 2003 / R2 Authentication Services

TABLE A.1
Original SFU names and new R2 names for corresponding
attributes (continued)
SFU Name

R2 / RFC 2307 Name

msSFU30Aliases

see note

msSFU30NisDomain

see note

msSFU30PosixMember

see note

msSFU30PosixMemberOf

see note

msSFU30NetgroupHostAtDomain

see note

msSFU30NetgroupUserAtDomain

see note

msSFU30CryptMethod

see note

msSFU30Name

see note

msSFU30PosixAccount

posixAccount

msSFU30ShadowAccount

shadowAccount

msSFU30PosixGroup

group

msSFU30IpService

ipService

msSFU30IpProtocol

ipProtocol

msSFU30OncRpc

oncRpc

msSFU30IpHost

ipHost

msSFU30IpNetwork

ipNetwork

msSFU30NisNetgroup

nisNetgroup

msSFU30NisMap

nisMap

msSFU30NisObject

nisObject

msSFU30Ieee802Device

ieee802Device

msSFU30BootableDevice

bootableDevice

13

14

Web Appendix

Windows 2003 / R2 Updated Procedures

TABLE A.1
Original SFU names and new R2 names for corresponding
attributes (continued)
SFU Name

R2 / RFC 2307 Name

msSFU30Top

see note

msSFU30MailAliases

see note

msSFU30NetId

see note

msSFU30NetworkUser

see note

Note: Wherever the R2 Name is blank, it means that the SFU Name is being
used in the R2 schema as there was no RFC 2307 equivalent to these.

Reviewing /etc/ldap.conf
In Chapter 3, we talked about how to get Linux clients to authenticate directly to Active Directory using the SFU 3.5 schema. Using the SFU 3.5 schema, we told /etc/ldap.conf what to
look for inside an Active Directory when we used the SFU 3.5 schema.
Now, with only some slight changes, we can make that same Linux client talk to Active
Directoryusing the new R2 schema. All we need to do is to tell the Linux clients /etc/
ldap.conf what RFC 2307 attributes to usewhich is what R2 usesand were in business.
Listing A.1 is the listing you will substitute in place of Listing 3.1 on page 178 of the book.

Listing A.1: /etc/ldap.conf for LDAP authentication against Active Directory with R2
(RFC 2307) updates
# Here, we'll use unencryupted LDAP port 389. ("ldap")
uri ldap://windc1.ad.corp.com
base dc=ad,dc=corp,dc=com
binddn cn=dirsearch,cn=Users,dc=ad,dc=corp,dc=com
bindpw p@ssw0rd
nss_base_passwd dc=ad,dc=corp,dc=com
nss_base_shadow dc=ad,dc=corp,dc=com
nss_base_group dc=ad,dc=corp,dc=com
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user

File Services with Windows 2003 / R2

15

nss_map_attribute uid sAMAccountName

nss_map_attribute uidNumber uidNumber
nss_map_attribute gidNumber gidNumber
nss_map_attribute loginShell loginShell
nss_map_attribute gecos name
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member
nss_map_attribute cn sAMAccountName
pam_login_attribute sAMAccountName
pam_filter objectcategory=User

The first portions of the listing dont change. Again, in the first portion, were providing the
pieces required to touch Active Directory: the Active Directory dirsearch account and where
in Active Directory to start our searches. None of that changes. The only things that do change are
the attributesthe SFU 3.5 attributes that are being dumped for the R2/RFC 2307 attributes.
The rest of the authentication story pretty much stays the same. Be sure to follow the directions in the rest of Chapter 3 to complete the story, especially the part on how to create home
directories on the fly as users log in.

File Services with Windows 2003 / R2

If you want to perform the Network File System (NFS) exercises we did in the book now using
R2, the User Name Mapping (UNM) service needs to be working properly. Recall that the
UNM services goal is to map UIDs to specific Active Directory users so that when NFS requests
come in, it can find the proper user account.

Setting Up Simple Maps for NFS

To start out, click Start  Programs  Microsoft Services for Network File System. To make
sure the UNM is working properly, well make sure Simple Maps are working. This is similar
to what we did in Chapter 4, Mapping Active Directory User Accounts to UNIX UIDs on
page 253 of the book.
Start by right-clicking over the words User Name Mapping and select Properties.
When here, change the Refresh interval to synchronize user and group names with User
Name Mapping to 5 minutes from the default value of 1 day. Then, click on the Simple Mapping tab. Click on the Use simple maps check box to get started. Then, click the Add button. Here, youll enter three things:


The first box requests the NIS domain name. It might already be automatically
populated, but if not, be sure to enter in your NIS domain in lowercase. If you enter
it in uppercase, it will fail to work.

16

Web Appendix

Windows 2003 / R2 Updated Procedures

The second box, labeled NIS server name (optional) is not optional. Yes, you read that
rightits not optional. Put in either the IP address or the name of your Windows NIS
server, or enter in localhost as seen in Figure A.12.

The third box requests the Windows domain. This should be automatically populated.

FIGURE A.12
Ensure that you put in the word localhost in the NIS Server Name
(optional) fieldwhich is not optional. Also be sure to put your NIS domain in lowercase.

local host

Click OK to close each of the windows to return back to the Microsoft Services for NFS console. Now, to verify Simple Maps are working, right-click over the words User Maps and
check the checkbox labeled Show Simple Maps. Then, click F5 while User Maps is highlighted to see the map of any Active Directory user and their UNIX-enabled counterpart as seen
in Figure A.13.
FIGURE A.13
Ensure that you see the Active Directory (Windows User) and the UNIX
users in the simple map.

Final Thoughts

17

If this fails to work, its likely because you omitted the entry for NIS server
name (optional). Again, this isnt optional.

Once youve performed User Name Mapping successfully, youre ready to use Windows NFS
in precisely the same way as we performed in the book. You can create unified Windows and
UNIX home drives, for instance by following our guidance in the book.

Note that in R2, there is no more NFS gateway. That is, you cannot use a single
R2 system to arbitrate incoming SMB requests from Windows XP machines
and have them locate NFS mounts.

Final Thoughts
R2 is nice because it takes the most used components and puts them right into the operating system. It also extends the schema with RFC 2307, which means Microsofts implementation of
storing UNIX accounts in Active Directory is now standards compliant.
Even with all that good news, SFU 3.5 might still be useful in some cases, even though R2 is
available. Specifically, the NFS client for Windows XP is only found in SFU 3.5, and also, it should
be noted that it is built into the business edition versions of Windows Vista. And, the NFS Gateway isnt part of R2. So, if you need to set up an NFS gateway on a Windows 2003 (not with R2)
or, say a Windows 2000 ServerSFU 3.5 is the only game in town. So, you can still download it
at http://tinyurl.com/24pys. It is supported by Microsoft Product Support (PSS) via paid
support until 2009.
The programmers out there might want to get their hands on the R2 Utilities and SDK for
UNIX-based Applications. This pack of goodies has the following components:


Base Utilities

SVR-5 Utilities

Base SDK

GNU SDK

GNU Utilities

UNIX Perl

Visual Studio Debugger Add-in

You can track that down here

http://www.microsoft.com/windowsserver2003/R2/unixcomponents/webinstall
.mspx (shortened to http://tinyurl.com/q7eps)

18

Web Appendix

Windows 2003 / R2 Updated Procedures

Additionally, you may be interested in seeing some live motion about these new R2
features. I found two resources to help you out.
http://www.microsoft.com/technet/community/events/windows2003srvR2/add-52
.mspx (shortened to http://tinyurl.com/la4p8)
http://www.microsoft.com/emea/itsshowtime/sessionh.aspx?videoid=77 (shortened to http://tinyurl.com/nvmdb)