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
A
Windows 2003 / R2
Updated Procedures
If you’re reading this, you’ve found the downloadable resources on http://www.WinLinAnswers
.com. This section is late-breaking material that we couldn’t squeeze into the book. That’s because
this chapter is on Windows 2003 / R2, or, just R2 for short. R2 is Microsoft’s 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 Applications—or SUA
 Identity Management for UNIX—or IMU
SUA helps UNIX-like applications work on Windows just as they did in Linux or UNIX.
Unfortunately, we don’t 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 3—the
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, we’ll revisit some of the procedures that we saw in the book itself—except this
time we’ll 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, we’re 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 isn’t something we’ll cover in depth here.

We’re 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 you’ve got a fresh Windows 2003 with R2 ready
to go.
2 Web Appendix  Windows 2003 / R2 Updated Procedures

If you have trouble getting R2 to load (i.e., it won’t 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 you’ve “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 we’ll per-
form 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 3

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, you’ll be at the “R2 Setup Wizard.” The wizard is self-
explanatory.
Once completed, you’ll 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
You’ve 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 can’t 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. Let’s 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, you’ll find it tucked away in Active Directory Services  Identity
Management for UNIX.
When you do, you’ll be prompted to save your SFU configuration, as seen in Figure A.3.

FIGURE A.3 You can preserve your SFU 3.5 installation.

4 Web Appendix  Windows 2003 / R2 Updated Procedures

When prompted, select Yes. When you do, you’ll 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, you’ll need to uninstall SFU 3.5. You’ll 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 discon-
nected. Upon completion, you’ll be asked to reboot and will need to do so.
Once logged back in as Administrator, you’re 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 correspond-
ing 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, you’ll likely be prompted to restart the server. Go ahead and
do so.
 Windows 2003 / R2 Authentication Services 5

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 isn’t already installed, there’s nothing to save.
Simply click Start  Control Panel  Add or Remove Programs. Select Windows Compo-
nents and locate and check Active Directory Services  Identity Management for UNIX and
click Next. Finally, when finished, you’ll 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 authen-
ticating 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 we’ve got R2 ready to rock, we can briefly walk through the differ-
ences. 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, it’s basically the same moving parts underneath the hood.
In this section, we’ll explore two cases: either you’re upgrading from SFU 3.5, or you’re not.
So be sure to pay special attention to each heading as we describe the scenario you might be in.
6 Web Appendix  Windows 2003 / R2 Updated Procedures

Windows 2003 / R2 Domain Controller as an NIS Server

Here, we’ll explore the idea of making Windows 2003 pretend to be an NIS server. Again, this
isn’t really recommended, and we didn’t go into it much in the printed edition of the book. The
reason why we didn’t 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, we’ll 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 so—and authenticate directly using LDAP and
Kerberos (as performed in the next big section).

Enabling NIS Services

Before we continue however, in both cases, if you’ve upgraded from SFU 3.5 to Windows 2003 / R2
or performed a fresh installation of Windows 2003 / R2—Windows does something a bit unex-
pected. That is, it disables the services required to run the NIS server. This is a new security mech-
anism—ostensibly to ensure that only those people who want to run NIS will run NIS. In our
opinions, this is not ideal, as this isn’t really documented anywhere.
Therefore, if you’re planning on using NIS now, you’ll need to enable it—even if you’ve 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 7

Additionally, before proceeding, also make sure that two other services are also set to auto-
matic 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 Map-
ping) 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): they’re almost like two sepa-
rate accounts that need to be synchronized with each other.
Once the tools are loaded, we’ll perform two steps: one is changing how long synchroniza-
tion 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 UNIX-
enabled user’s 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.
8 Web Appendix  Windows 2003 / R2 Updated Procedures

For our purposes, we’ll 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, it’s 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 Direc-
tory 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, don’t 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 wasn’t much.
 Windows 2003 / R2 Authentication Services 9

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, you’ll 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 it’s 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 synchro-
nization 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 you’ll 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, let’s create a brand new user using Active Directory Users and Computers. We’ll assume
you’ve UNIX-enabled at least one group, say, Nurses group.
10 Web Appendix  Windows 2003 / R2 Updated Procedures

From this point, you’ll jump to Chapter 3, “How to UNIX-Enable your Active Directory
Users and Groups,” page 167 of the book. In my examples here, I’ve 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 won’t. Why not? Let’s 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! What’s the trick
to getting the password into the UNIX “half” of the account? Reset the account’s 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. It’s in an online-only docu-
ment 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 you’re now using Active Direc-
tory to pretend to be NIS. However, don’t 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 R2’s 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 location—not 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 isn’t an RFC 2307 attribute to express how to do something in SFU—hence, the
Microsoft team just kept the same name.

TABLE A.1 Original SFU names and new R2 names for corresponding
attributes

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 13

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
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 Direc-
tory 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
Directory—using the new R2 schema. All we need to do is to tell the Linux client’s /etc/
ldap.conf what RFC 2307 attributes to use—which is what R2 uses—and we’re 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 don’t change. Again, in the first portion, we’re 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 attributes—the 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 direc-
tions 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 service’s 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, we’ll 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 Map-
ping tab. Click on the “Use simple maps” check box to get started. Then, click the “Add” but-
ton. Here, you’ll 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
right—it’s 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) field—which 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 con-
sole. 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 high-
lighted 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, it’s likely because you omitted the entry for “NIS server
name (optional).” Again, this isn’t optional.

Once you’ve performed User Name Mapping successfully, you’re 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 sys-
tem. It also extends the schema with RFC 2307, which means Microsoft’s 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 Gate-
way isn’t 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 Server—SFU 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 (short-
ened to http://tinyurl.com/nvmdb)