Appendices

  • Article
On This Page

Appendix 1 - Downloads Appendix 1 - Downloads
Appendix 1A - Autoexec for Automated Deployment Appendix 1A - Autoexec for Automated Deployment
Appendix 2 Windows 2000 Active Directory Design Appendix 2 Windows 2000 Active Directory Design
Appendix 3 Windows 2000 Site Topology Appendix 3 Windows 2000 Site Topology
Appendix 4 - Windows 2000\IIS 5 Security Scripts Appendix 4 - Windows 2000\IIS 5 Security Scripts
Appendix 5 - Services for UNIX (SFU) Appendix 5 - Services for UNIX (SFU)
Appendix 6 - Interix 2.2 Appendix 6 - Interix 2.2

Appendix 1 - Downloads

The scripts and tools download (prototype) included as a supplement to this technical case study contains a working example of an unattended, automated server deployment process. It is a detailed implementation of the process described at a higher level in the "Over-the-Network Boot Floppy Disk or CD-ROM" subsection of the Deployment Options section of the Deployment and Migration guide.

The intent of this download is to provide a working model, which contains all the necessary batch files, scripts and utilities to perform an automated unattended installation of a Compaq DL380, DL360, or DL580(See footnote F1 at the end of this page).

It is only an example and not intended to be used for production implementations. The example is provided as an aid for familiarizing yourself with the mechanics of performing unattended automated deployments.

This prototype assumes that you have a good working knowledge of the Windows 2000 setup process and the sysprep utility in particular. Some files may need to be modified for your specific implementation and configuration.

Note: If you intend to set up the prototype in a lab environment, it is strongly recommended that you read through the autoexec.bat, setramd.bat, sysiniu.bat, shorten.bat, runsetup.bat, and all other batch files and scripts called by the unattended process to gain an understanding of deployment logic. It is also helpful if the reader has the latest copy of the Compaq SmartStart scripting toolkit documentation available from https://www.Compaq.com.

The included download contains a distribution directory structure(See footnote F2 at the end of this page), which can be set up on a server in a lab and used as a prototype for assisting customers, and partners familiarize themselves with developing a completely automated unattended server build process. The top level of the directory structure, for the extracted files follows:

Rootshr\
Prod
BootFloppy

This process uses a generic boot floppy disk, which would be inserted in each target server to be built. The boot floppy files can be found in the rootshr\bootfloppy directory(See footnote F3 at the end of this page). To use this floppy disk, you need a Windows 98 boot floppy disk, which contains command.com, io.sys, msdos.sys, and drvspace.bin. Then copy the contents of the rootshr\bootfloppy directory to the bootable floppy disk.

Note: The boot floppy disk is identical for each target machine. Comments are included in stream of the autoexec.bat file, other command files and scripts called by this process, which describe the function of each routine.

The download does not contain the actual sysprep image. You must build a reference machine, run sysprep, and then use a third-party tool to copy the image into the \rootshr\prod\images directory on their distribution server. Additionally, there are non- Microsoft tools and utilities referenced in the scripts and command files included in this download. However, the executables for the third-party tools used in the examples of this technical case study are omitted from the download. Instead a text file with a similar name, <root name-exe>.txt is included where the executable should be on the distribution share. The contents of the text file contain a web link to the third-party web site, where the tools and executables can be found. For example, "systype.exe" is included with the Compaq SmartStart scripting toolkit. The file on the share is called "systype-exe.txt" and it contains the web link to the location of the Compaq SmartStart scripting toolkit.

The general process is described below:

  1. Copy the contents of the \rootshr\bootfloppy directory to a bootable floppy disk that contains the Windows 98 boot files, that is, command.com, io.sys, msdos.sys, and drvspace.bin.

    1. Edit the autoexec.bat file as follows: replace \\MyServer\rootshr with the actual server name for the lab distribution share, that is, \\<servername>\rootshr

  2. Copy the \rootshr\prod directory to the network distribution server. Share rootshr as rootshr.

  3. Build a "reference server" that will be used as the master image server(See footnote F4 at the end of this page).

  4. Run sysprep to prepare the image to be copied.

  5. Use a third-party image copy utility to copy the image to the \\<server>\rootshr\prod\images directory on the distribution server. For this prototype, DriveImage Pro from Powerquest was used.

  6. Insert the boot floppy disk in the target server. This is the server that will be built based on the reference machine image. Remember: The target server has to use the same HAL as the reference server, that is, multiprocessor ACPI, single processor ACPI, multi-processor non-acpi and single processor non-acpi. Warning: The BIOS on the target server will be reset and all data on the target server will be lost.

  7. Restart or power up the target server. Upon power-up, the server boots off of the over-the-network boot floppy disk, whose autoexec.bat is illustrated in Appendix 1A. Commands in the autoexec.bat query the system type and serial number of the server. The serial number is the key that maps to a sysprep.inf that contains the server unique settings and the role for that particular target server. A script file is then called from the distribution share on a server, which determines the state of the server, writes a marker file to the floppy disk that specifies the role for the server, identifies the appropriate sysprep.inf for the server designated by the serial number returned earlier, and proceeds to:

    1. Configure the BIOS (using Compaq SmartStart scripting).

    2. Configure the mass storage controller (using Compaq SmartStart scripting)

    3. Reboot.

    4. Partition the disks (using Compaq SmartStart scripting).

    5. Reboot.

    6. Download the sysprep image.

    7. Modify the boot sequence by placing the A:\ drive last in the boot sequence.

    8. Download the appropriate sysprep.inf based on server serial number to the A:\ drive on the target machine.

    9. Reboot.

    10. The server boots from C:\ into the mini-setup wizard. All the questions for mini-setup are answered through the custom sysprep.inf file that was downloaded based on the servers serial #. The appropriate script file to configure the servers role is run by the GUIRUNONCE key in the sysprep.inf file.

    11. Reboot.

    12. Unless the servers role is a domain controller, the server is fully built at this point.

    13. If the role of the server was a DC, then a logon=1 is set in the sysprep.inf and the HKLM\software\Microsoft\CurrentVersion\Run key is populated through a batch file that is run by GUIRUNONCE(See footnote F5 at the end of this page).

    14. Dcpromo /answer:<answerfile>, is run from the run key when "autoadmin login occurs".

    15. Reboot.

    16. The DC is built as 1 of 4 roles, that is, first dc in the forest, replica dc of root domain, first dc in a child domain, or a replica dc of a child domain.

Appendix 1A - Autoexec for Automated Deployment

Below is an example autoexec that can be used on a floppy disk, boot partition, or PXE boot image. You may need to modify some of the drive letters to allow boot partition or PXE to utilize the autoexec.bat. The system assumes that you have already created the sysprep.inf with the appropriate settings for each computer and a valid distribution share exists.

@ECHO OFF
rem    The is this over-the-net boot floppy that was used for the sample automated unattended
REM          Compaq Server\Windows 2000 Setup.
REM
REM     Created 6/15/2000 Last updated 3/10/01 to include Compaq Smart Start Scripting logic
REM   for the DL360, DL380 and dl580
REM
REM     Note: Each Company needs to create their own Production
REM       XXXArray.ini (using acr.exe), XXXBios.ini(using conrep); diskxxx.ini (using cpqdisk /r) referenced
REM           in the prod directory of the distribution share.
rem
REM
rem --------------------------------- end of comments ----------------------------------------------------
REM Determine the model # of the server. Systype.exe queries the BIOS for Server Model, then finds that model in
REM  the ssstksys.ini and sets the error level accordingly. Ssstksys.ini for reference.
a:\systype SSSTKSYS.INI
if errorlevel 53 goto cpq580
if errorlevel 50 goto cpq380
if errorlevel 51 goto cpq360
:cpq580
call a:\cpq\dl580\580msnet.bat
goto prep
:cpq380
call a:\cpq\dl380\380msnet.bat
goto prep
:cpq360
call a:\cpq\dl360\dl360msnet.bat
goto prep
:prep
REM Find the random access memory (RAM) drive and set the environment variable
call \setramd.bat
REM Create the net directory on the RAM drive
md %RAMD%\net
:: Add the Ram drive to the Path, Create a command shell, set prompt level.
:: Copy a shell to the RAM drive.
:: The RAM Drive changes between boots. So, we need to use a symbolic representation.
path=%RAMD%\;%RAMD%\net;a:\;a:\dos;a:\NET
if not exist %RAMD%\command.com copy \command.com %RAMD%\ >nul
set comspec=%RAMD%\command.com
set prompt=$p$g
set dircmd=/O:N
set temp=%RAMD%\
set tmp=%RAMD%\
:: Replace user names, Passwords, "net use" drive, and \server\share appropriately for your distribution share.
set instID=stevete
set instpwd=MyPw0rD!
set usedrive=s:
set svrshare=\\MyServer\rootshr
:: Replace user names, Passwords, "net use" drive, and \server\share appropriately for the source.
::  for where the contents of the Compaq SmartStart partition will be copied from
set instID1=stevete
set instpwd1=MyPw0rD!
set SSdrive=s:
set SSSshare=\\MyServer\cpdsst
:: Copy files to the RAM drive so that later operations will occur faster.
echo Preparing the RAM drive...
copy \dos\*.* %RAMD%\ > NUL
copy \net\*.* %RAMD%\net > NUL
:: Let's start using the RAM drive.
%RAMD%
cd \
:: Extract the the tools to be used
echo Extracting DOS tools...
%RAMD%\extract /y /e /l %RAMD%\ %RAMD%\dostools.cab > NUL
echo Extracting network drivers...
%RAMD%\extract /y /e /l %RAMD%\net %RAMD%\net\netcomn.cab > NUL
copy a:\sysiniu.bat %RAMD%\net\sysiniu.bat > NUL
:: Load smartdrv to enable file caching and speed up copy operations
smartdrv.exe C+ /u /q 16384 /B:16384 /E:8192
:: Turnon DOSKEY
doskey /insert >NUL
:: Lock the setup partition to enable direct disk access.
if not "%RAMD%"=="D:" goto skipLock
echo Y|lock c: >NUL
:skipLock
::Randomly generate a computer name. Then update the system.ini before loading the network stack.
CD \net
sysiniu.bat
:// Start the network.
:: Now we can start the network stack
net initialize
netbind
umb
tcptsr
tinyrfc
nmtsr
emsbfr
net start
echo Logging onto the network ....
net logon /savepw:no %instID% %instpwd% /YES
echo Mapping the s: drive to %svrshare%
net use %usedrive% %svrshare% /YES
net use %SSdrive% %SSSshare% /YES
echo Query the BIOS for the Serial number.
s:\Prod\cpq\sn_util.exe < a:\snutlout.txt > a:\sn-resp.txt
a:\find /V " " < a:\sn-resp.txt > a:\sn.txt
copy /b /y a:\set_SNis.txt+a:\sn.txt a:\make-SN.bat
call a:\make-SN.bat
echo Random computer was set to %computername%
echo Serial Number: %sn%
echo Equate the SN stored as an env variable to a short file name.
call s:\prod\SN\shortenSN.bat
echo The shortened subdirectory is: %dir%
echo Copy the files requires during the mini-setup to the A: drive.
echo  The TXT files would be marker files put in the applicable directory to specify
echo   The role of the server, that is, Web, SQL Server, Exchange Server, App server, Terminal Server and so on.
copy s:\prod\SN\%dir%\sysprep.inf a:\sysprep.inf
copy s:\prod\SN\%dir%\*.txt a:\
echo Now that the environment is set up, we'll run the main setup scripts for Compaq server config.
echo   and Windows 2000 configuration.
rem   The GUIRUNONCE key in the sysprep.inf file is used to launch the scripts that will customize the
rem     server for a particular role, for example SQLServer, Web, App server, and so on.
s:\prod\runsetup.bat
:end

Appendix 2 Windows 2000 Active Directory Design

The delegated DNS sub-domain approach to naming was used. Specifically, internal.hotmail.com is the root of the Windows 2000 namespace. There is a one-to-one mapping of DNS sub-domain names and Windows 2000 domain names and these sub-domain names are identical. The Fully Qualified Domain Names (FQDNs) differ slightly from what you might expect as outlined in the note, later in this section.

Essentially the Windows 2000 domain names correspond to the pre-Windows 2000 FreeBSD front-door cluster DNS subdomains. At server migration time all front-door machines in the law3 FreeBSD cluster, with an FQDN of %hostname%.law3.hotmail.com join the law3 Windows 2000 child domain.

Note: After migration to Windows 2000, the DNS FQDN of a Windows 2000 front-door machine in the law 3 cluster is %computername%.law3.hotmail.com not %computername%.law3.internal.hotmail.com, even though internal.hotmail.com is the root of the windows 2000 namespace. The exception to this rule is for the domain controllers. The FQDNs of the Windows 2000 domain controllers for the Windows 2000 domain called internal.hotmail.com are dcx.internal.hotmail.com. Likewise, the FQDN of the Windows 2000 domain controllers for the Windows 2000 domain called Law3.internal.hotmail.com are dcx.law3.internal.hotmail.com. An example follows:

Windows 2000 Domain Controller FQDN

Member Server FQDN

dc1.law3.internal.hotmail.com

f1.law3.hotmail.com

dc2.law3.internal.hotmail.com

f352.law3.hotmail.com

dc1.law6.internal.hotmail.com

F12.law6.hotmail.com

A best practice approach to developing the Windows 2000 namespace design is to start with an understanding of what directory enabled business applications will be supported combined with making the assumption that the design will consist of exactly one production public facing forest of exactly one domain(See footnote F6 at the end of this page). Then identify if there are factors, which would be better accommodated by moving to a multidomain namespace.

As such, we started the design phase with single forest of exactly one domain. However, in the pre-Windows 2000 configuration, there were duplicate host names for the FreeBSD machines. Each cluster of FreeBSD servers contained a range of host names, which were unique within the cluster. A cluster consisted of approximately 300 front-door machines. Each cluster corresponded to a DNS sub-domain, for example law1.hotmail.com, law2.hotmail.com, law3.hotmail.com, and so on. However, the same range of host names was used for each cluster. The Fully Qualified Domain Names (FQDNs) of these machines were unique because of the hierarchical nature of DNS. An example follows:

There existed a server with a host name of f1 in the dns domains of law1.hotmail.com and law2.hotmail.com, that is, f1.law1.hotmail.com/f1.law2.hotmail.com(See footnote F7 at the end of this page) through f300.law1.hotmail.com/f300.law2.hotmail.com, and so on.

Theoretically, we could have still used a single Windows 2000 domain and created a hierarchal DNS namespace which matched the DNS namespace used by the freebsd servers. However, there would be name collisions in the sites container in Active Directory. This is because with the current version of Windows 2000, the default behavior for storing the machine objects in Active Directory, is to use the short name instead of fqdn or ldap name, for example, server name = f1 is stored in Active Directory, instead of the ldap name of cn=f1, cn=computers,dc=law2,dc=internal,dc=hotmail,dc=com or the dns name of f1.law2.hotmail.com.

So, for all intensive purposes there must be unique host names within a Windows 2000 domain. Technically, it would have been an easy process to rename the machines when migrating from FreeBSD to Windows 2000. However, that would have added another layer of application regression testing to the critical path for the migration, causing a schedule slip. The other alternative was to put machines with identical short names into different Windows 2000 domains. The latter approach was selected at the time. The schedule could not slip. As such, a decision was made that would not negatively impact the schedule. The benefits realized through fewer domains did not warrant the risk of slipping the schedule.

The latter example explains why we ended up with 18 domains: Law1-Law15, Pav0, Pav1, and internal.hotmail.com. All of the servers have since been renamed. So, there are no longer duplicate host names in the environment, except for the domain controllers. The next logical step is to collapse the domains. The DCs with duplicate names would go away, for example, if we collapsed all the domains into objects.internal.hotmail.com or into internal.hotmail.com, there would be no need for dc1.law5.hotmail.com.

htmail05a

Appendix 3 Windows 2000 Site Topology

The Hotmail Windows 2000 sites correspond to physical data centers where the servers reside. The following symbol represents a site.

datac1 Where datac1 = data center 1; datac2 = data center 2 and so on

Each physical data center contains two domain controllers from the Windows 2000 forest-root (internal.hotmail.com). This allows for all domain queries to be resolved locally to the data center.

As illustrated in the following schematic, there are three sites: Datac1, Datac2, and Datac3. A Windows 2000 site is literally a collection of subnets. When designing sites, a site should be a region of connectivity with very high bandwidth and good connectivity. The plan of record at Hotmail was that each data center would become a Windows 2000 site.

A general discussion of the factors for determining Windows 2000 sites is beyond the scope of this technical case study. However, GC and Flexible Single Master Operation (FSMO) role holder placement is relevant.

General Guidelines for global catalog and FSMO placement within sites:

  • Position at least 1 DC and 1 GC per site, for local GC lookups. Two GCs preferred for local redundancy.

  • Position the Infrastructure master on a non-GC DC (not required).

  • At Hotmail, each domain has a GC. However, it is not required but does not hurt.

FSMO Data points

There are 2 forest-wide roles (Only 1 of each required per forest):

  • Domain Naming

  • Schema

There are 3 domain wide roles (1 of each required per domain)

  • PDC

  • RID

  • infrastructure

The FSMO role holders are depicted in the following figure:

htmail07a

A more detailed discussion of Windows 2000 sites can be found in various white papers on www.microsoft.com; search on keyword "windows 2000" and "sites".

Also check out the Active Directory white papers at https://www.microsoft.com/windows2000/library/howitworks/default.asp

Appendix 4 - Windows 2000\IIS 5 Security Scripts

This technical case study draws on experience gained by Microsoft engineers who upgraded Web servers to Windows 2000 Server at the MSN Hotmail Web-based, e-mail service. A variation to these scripts was applied to the actual reference servers at Hotmail prior to running sysprep and creating the master image as described earlier in this technical case study. The scripts contained herein were modified from the standpoint that they were highly customized to the Hotmail application and would probably "break" other similar implementations. However, the essence of the security settings and method for automated implementation are germane to many hosted Web environments.

Securing IIS 5.0 using Batch oriented command files can be found at: https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/deploy/confeat/seciis50.mspx. This technical case study describes the use of command files or batch programs to automate the security settings on a Web server running Windows 2000 Server or Windows 2000 Advanced Server and Internet Information Services 5.0 in an enterprise or hosted environment. This technical case study is intended for system administrators and assumes familiarity with Windows 2000 Server and IIS 5.0, registry settings in the operating system, and metadata settings in IIS 5.0. This technical case study does not attempt to provide a detailed explanation of registry settings or metadata settings. For that information, turn to the documentation for Windows 2000 Server and IIS 5.0.

The following is a related white paper that lists some recommendations and best practices to secure a server on the Web running Windows 2000 and Internet Information Services (IIS) 5. The settings err on the side of security over functionality, and therefore it is important that you carefully review the suggestions below and use them to derive your own-hosted environment (Secure Internet Information Services 5 Checklist at: https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/tips/iis5chk.mspx).

For information related to tuning IIS 5 check out: The Art and Science of Web Server Tuning with Internet Information Services 5.0 found at: https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/maintain/optimize/iis5tune.mspx.

Appendix 5 - Services for UNIX (SFU)

Microsoft Windows Services for UNIX 2.0 provides a set of additional features to Windows NT and Windows 2000 that allow for greater interoperability with existing UNIX-based systems in the enterprise. Microsoft Windows Services for UNIX 2.0 provides a full range of supported and fully integrated interoperability components that make it easy for customers to integrate Windows NT version 4.0 and Windows 2000 operating systems into their existing UNIX environments. Microsoft Windows Services for UNIX 2.0 provides interoperability components that utilize existing UNIX network resources and expertise within organizations. It also provides manageability components that enable organizations to simplify network administration and account management across both platforms.

Additional information for Windows 2000 Services for UNIX can be found in the: General Services for UNIX version 2.0 White Paper at: https://www.microsoft.com/windows/sfu/techinfo/default.asp

And related papers at: https://www.microsoft.com/WINDOWS2000/sfu/default.asp

Appendix 6 - Interix 2.2

Microsoft Interix 2.2 is the easiest way for customers to take advantage of their previous investments in UNIX-based legacy applications as they move to the Windows operating system. Additional white papers and technical resources can be found at: https://www.microsoft.com/WINDOWS2000/interix/default.asp
F1 - These server types support the Compaq Smart Start scripting and this is used in the prototype. This prototype is still applicable for non-Compaq installations. However, you would need to use the vendor specific alternative to Smart Start Scripting for configuring the BIOS and mass storage controller. Sysprep and the other non-Smart Start scripts used in this prototype are hardware vendor independent.

F2 - The download is a self extracting executable that will extract into a predefined directory structure. The directory structure would be copied to the distribution server. There are comments in the autoexec.bat file that describes how to map the drives from the over-the-network boot-floppy to the distribution server.

F3 - The autoexec.bat file listed in Appendix 1A is a print-out of the autoexec.bat file in the \bootfloppy directory..

F4 - Reference the sysprep documentation on https://www.microsoft.com.

F5 - Note: The batch file to populate the run key with the "dcpromo /answer:" command is not included in this sample. That exercise is left to the reader. Regini.exe from the Windows 2000 reource kit works well for doing things like populating the registry.

F6 - You should also consider having one development forest and possibly one production internal corporate forest, which is leveraged for the server resources running the business of the organization. In some organizations, the latter would include the resources for HR, finance, IT, corporate affairs, legal, and the line of business units. In summary, there would be at least one public facing forest, possibly one internal facing forest and one development/QA forest. Investigation of the viability or need to create an internal forest for Hotmail was out of the scope of the migration effort. For the purposes of this paper all references to the AD design are referring to the public facing forest, except where noted.

F7 - F1 = servername or hostname. It's short for front-door server 1.

Click here to return to the introduction page of the Microsoft Hotmail Migration Technical Case Study.