CCBoot - LAN Boot Software for Windows

I. LAN Boot Solution Background

LAN boot is a technology based on IP (Internet Protocol), UDP (User Datagram Protocol), DHCP (Dynamic Host
Configuration Protocol) and TFTP (Trivial File Transfer Protocol). It requires two computers: LAN boot server
and client. The client is a computer you want to boot up over LAN, while the server is a computer which
provides necessary data such as NTLDR, NBP (Network Boot Program), system image and so on for client
booting over LAN. LAN boot program allows to remote boot a computer over LAN without a hard disk. It is
therefore ideally suited for both diskless and thin clients. CCBoot support install windows xp over lan
and install windows xp over network.

For LAN boot solution, the boot process is as bellow:
o 1, Power on,
o 2, Load BIOS,
o 3, PXE stack built-in the NIC (Network Information Center),
o 4, Download NBP (Network Boot Program) from server to client's RAM by TFTP,
o 5, NBP's responsibility to perform the next step (a.k.a. 2nd stage boot).
As an administrator responsible for a network of about dozens of computers or more, LAN boot solution will
drastically reduce your daily workload. If you want to install or upgrade various softwares for all computers in
the network, you just need to do it once. It can also bring you enhanced Disaster Recovery solutions.
II. Using CCBoot to Build a LAN Boot Server
A. Install LAN Boot Server with CCBoot - An All-in-one LAN Boot Software
Download LAN boot software - CCBoot server installation package from -
http://www.ccboot.com/download.htm.
Launch ccbootsetup.exe on the LAN boot server and keep press the next button to the end.

Figure 1
CCBoot will use the following ports 67 (DHCP), 69 (TFTP), 3260 (iSCSI), 1000 (Image Upload), 8001
(Service Control). You need to open these ports in the firewall of the LAN boot server. Since CCBoot
v2.1, you also need to open port 66. V2.1 uses port 66 as DHCP backup.

Note: Please shut down the other DHCP services on the LAN especially the DHCP service in the
router.

Launch CCBoot and you will get the main interface as bellow:

Figure 2
B. Initialize The LAN Boot Server
Demo Environment
Server IP: 192.168.1.10
Gateway: 192.168.1.1
DNS Address: 192.168.1.1
IP Mask: 255.255.255.0
DHCP Range: 192.168.1.101-192.168.1.254

Launch the LAN boot software - CCBoot, menu "Options"->"Options Wizard" and configure step by
step as bellow:

Figure 3
You need to select the correct local IP address as "DHCP Server IP". Press "Scan DHCP" to check if
there are other DHCP services on the LAN. You need to stop other DHCP services on the LAN.

Figure 4
Set "Server IP Address". Normally, its the same as "DHCP Server IP".
Set "Write-back File Path" and "Image Save Path" as you want.

"Write-back File Path" is used to store the LAN booted clients write-back data. Youd better use a big
volume hard disk as "Write-back File Path". This disk should be formatted as NTFS and 64K bytes per
cluster.

"Image Save Path" is used to store the images for LAN booting. This disk should be also formatted as
NTFS and 64K bytes per cluster. Youd better use a fast speed hard disk as "Image Save Path". For
example, use an SAS hard disk.

Figure 5
Keep default values in "Server Cache Settings".

Figure 6
Keep default values in "Other Settings". Press the "Finish" button and confirm the popup dialog box.
C. Create Image for LAN Boot Windows XP
To boot Windows XP with the LAN boot software - CCBoot, you first of all need to create a system
image and here're the steps -
1. Choose one client PC as master PC used to create LAN boot image. Attach a hard disk on the
PC.
2. Delete all partitions first. Allocate a small MBR partition about 40G size and leave the rest
unallocated. Format the 40G partition with NTFS. Install Windows XP and the latest SP into
this partition.
3. After complete Windows installation, open the local area connection network properties and
configure as bellow:

Figure 7
Click "Properties".

Figure 8
Select "Internet Protocol (TCP/IP)" and click "Properties".

Figure 9
Select "Obtain an IP address automatically" and "Obtain DNS server address automatically",
then click "OK" to save.
4. On the CCBoot LAN boot server you will find a client in the client list (Figure 10) that was
added by CCBoot automatically when the client PC got IP address from the CCBoot DHCP
service.

Figure 10
5. Double click the client to edit and check both "Enable Upload Image" and "Keep Write-back
File" (Figure 11), when press "save" button it will ask you "Are you sure to delete write-back
file?" Just press "No".

Figure 11
6. Download CCBoot client installation package from: http://www.ccboot.com/download.htm.
Launch ccbootsetupclient.exe and keep press the next button to the end. Then launch
CCBoot client and you will see the main interface as bellow (Figure 12).

Figure 12
7. Press the "Install CCBoot Client" button. After finished, it will require reboot system. Reboot
the client PC.
8. After reboot, launch CCBootClient again, input the correct "Server IP address", it should be
the IP address of the PC on which CCBoot server has been located. Input the image file name
as you want in the "Image File Name". Press the "Upload Image" button to upload the image
to the CCBoot server. Then CCBoot will create an image in the server "Image Save Path".

Note: CCBoot supports two types image file format. It supports VMDK if you are using
Windows 2003 as CCBoot server system. It will support both VMDK and VHD if you are using
Windows 7 or Windows 2008. As you can see in Figure 12, the file format depends on what
you have set for "Image File Name". For example, "XP01.vmdk" and "XP01.vhd".
D. LAN Boot Windows XP over Network
1. On CCBoot LAN boot server, double click PC101 (Figure 10) to open the master PCs
properties dialog box, uncheck "Enable Upload Image" and "Keep Write-back File".
2. Remove the HDD from the master PC, set it firstly boot from network (or LAN, PXE rom, or
some other similar settings) in BIOS settings so that it will start LAN booting Windows
XP.(Figure 13).

Figure 13
3. The first time LAN boot Windows XP on the master PC, you can modify its computer name
(Figure 14).

Figure 14
Set the computer name as you wish then press enter key to boot it over network (Figure 15).

Figure 15
4. On CCBoot server, "Options" -> "Settings" -> "Default Client Settings" -> "Disk Group" ->
press the ">>" button, select "XP01.vmdk" as the default boot image in "System Image
Selection" section.
5. Do the same as Step 2 and Step 3 for other client PCs with the same specifications as the
master PC to implement LAN boot resolution for them.

E. LAN Boot Windows 7 and Vista
LAN boot Windows 7 step by step.
LAN boot Vista step by step.


Install Windows Melalui Network (LAN)
Pengalaman berharga setelah menginstal windows via USB tidak bisa dilakukan pada Notebook Toshiba
Dynabook SS 2000 dan tidak adanya CD-Rom external, jalan satu-satunya adalah menginstal lewat Network
(LAN). setelah mencari-cari di google akhirnya saya menemukan tutorial di
http://www.lockstockmods.net/. Awalnya saya mendapat sedikit kesulitan dalam mengikuti tutorial
tersebut, dan akhirnya saya dapat melakukan instalasi pada Notebook Toshiba Dynabook SS 2000.

Disini saya akan memperjelas lagi tentang proses instalasi windows melalui Network (LAN). Berikut adalah
persiapan yang anda butuhkan :
1. CD Windows XP (untuk mendapatkan file-file dari direktori I386)
2. Laptop atau PC OS 2000/xp (sebagai server)
3. Kabel UTP atau LAN
Tahapan yang harus dilakukan :
Siapkan komputer host/server.
Download PXEserver software.
Download Bart Network Boot Disk (SMARTDRV.EXE) dan extract file SMARTDRV.
Buat folder baru dengan nama "winstall" pada C:\winstall dan sharing folder tersebut.
Copy folder i386 (dalam CD windows xp) dan SMARTDRV.EXE kedalam folder winstall.
Instal TFTPD32 PXEserver.
Download file OUTPUT, extract file OUTPUT dan pindahkan ke direktori C:\.
Jalankan TFTPD32 PXEserver, masuk ke tab DHCP server dan isi setup jaringan anda.

Ganti current directory menjadi C:\OUTPUT
Server interface (sesuai dengan alamat IP server/komputer host)
Alamat DHCP yang diinginkan (mulai dari 192.168.2.210 - 2.240)
Boot file diisi dengan : pxelinux.0
Klik Save


Masuk ke tab setting TFTPD32
Pastikan isi base directory adalah "."
Isian lainnya adalah default.

Sambungkan notebook yang akan diinstal ke LAN dan pilih boot from PXE/LAN (jangan lupa untuk
menjalankan TFTPD32 pada komputer server).
Jika anda sudah berhasil boot from LAN, masuk ke Bar Network Disk.
Kosongkan TCP/IP parameter dan identification setting. Tekan OK
Maka akan muncul : none@PC-253*** Q:\Net>
ketik Q:\Net>fdisk (untuk melihat dan mempartisi hardisk anda)
ketik Q:\Net>net (untuk membuka Disk Connection)

Pilih browse untuk memilih connection, pilihlah nama komputer dan folder winstall yang telah di sharing,
tekan ok.
Exit Disk Connection
ketik Q:\NET>D: (lihat current connection, saya mendapatkan drive D dan biasanya berbeda-beda dengan
komputer lain)
ketik D:\>dir (pastikan isi direktori adalah i386 dan SMARTDRV.exe)
ketik D:\>smartdrv.exe (untuk mempercepat proses penginstalan)
ketik D:\>cd i386
ketik D:\i386>winnt
maka akan keluar tampilan windows xp setup

Selanjutnya anda bisa mengikuti perintah-perintah dari Windows setup.

The Desktop FilesNetwork-Booting Windows
Wes Miller

Contents
How PXE Works
Diving into RIS
WDSThe Beginning
Other Players
Wrapping Up
Over the next few months I'm planning to cover Windows Deployment Services (WDS), which is available
for Windows Server 2003 and is built into Windows Server 2008. WDS can be a very important component
in your deployment infra-structure, so I want to make sure you have a good foundation for the discussion.
This
first column will drill into the architecture of the Pre-boot eXecution Environment (PXE; pronounced pixie),
the history of Remote Installation Services (RIS), as well as other PXE-related technologies used at
Microsoft.
When I moved to the Windows core OS group in 2001, RIS was one of the technologies I inherited (and was
a bit terrified to own, due to its complexity and dependency on BIOS implementations and hardware). But
it was, in addition to Windows

PE, one of the technologies I enjoyed most in my role as a Program

Manager.
I remember when I first installed Windows 3.0using a set of 3.5" diskettes. Over time, installation became
easier by virtue of bootable CDs (included in some versions of Windows 98). But the thing was, installation
always required local media of some type, as well as a local hard disk.
Through the years, the ability to network-boot Windowsthat is, to boot it completely over the network
without requiring a hard diskhas been a frequent request of customers. Though some early versions of
Windows had that ability, Windows NT

never did. And while current versions of Windows Server

2003 and
Windows Server 2008 can be booted via an iSCSI initiator, the process is quite different in that it isn't truly
localit entails an ongoing dependency on a remote drive as the boot drive.
Prestaging Clients
Evaluating the RIS Client Prestaging Process
Planning for Network Security Enhancement Using Prestaged Clients
Prestaging Client Computers
Remote Operating System Installation
Beginning with Windows 2000, Microsoft began developing the technology that would eventually come to
be called RIS and that would allow for network-based installation. The goal of RIS was a relatively simple
oneto put an operating system image onto the local disk of the target computer using PXE.

How PXE Works
Figure 1 shows the PXE boot sequence. PXE is a relatively simple protocol that was developed by Intel and
other vendors as part of the Wired for Management initiative. PXE is derived from Dynamic Host
Configuration Protocol (DHCP), itself derived from BootP, and is typically implemented in your Network
Interface Card (NIC). Simply put, here's what happens:

Figure 1 PXE boot sequence (Click the image for a larger view)
Step 1 The system BIOS boots up and determines boot order.
Step 2 If the boot order puts PXE ahead of hard disks, or flash drives, or CD-ROMs, or if none of those
devices are present, the Universal Network Driver Interface (UNDI) is loaded from the NIC. The NIC features
an extremely small network device driver and a Trivial File Transfer Protocol (TFTP) implementation. (Some
BIOS implementations require end users to press the F12 key in order to PXE boot. That isn't standard, and I
appreciate the ability to disable it.)
Step 3 The system begins making a simple User Datagram Protocol (UDP) broadcast, looking for a DHCP
server. This is actually the first step of the PXE boot sequence and is referred to as Discover. Notice that the
protocol is UDPmeaning that if you haven't yet, you will need to spend some quality time with your
routers and switches to ensure that the PXE communications can all make it across.
Step 4 If a DHCP server hears the broadcast, it responds accordingly with an IP address. This step is referred
to as Offer. The important point to remember here is that PXE is stateless and the amount of system-
unique state information the client has to offer at this point is pretty limited (the MAC address and, if
available, the System Management BIOS GUID, also known as SMBIOS GUID).
Step 5 The client, after receiving the packet with the IP address, then states that it actually needs further
informationnamely the PXE server's address. Another broadcast occurs, which includes the information
from the DHCP server that originally responded. Here the client is telling the DHCP server, "I need more
informationspecifically, I need the location of a Network Boot Program (NBP)." This step is called
Request.
Step 6 The PXE server responds with the address of the PXE server and the location of the NBP, an
extremely small boot executable that is required to be smaller than 32KB. This step is called Acknowledge.
If you're playing along, you've probably noticed the acronym DORA (Discover, Offer, Request,
Acknowledge), a good way to remember the sequence.
Note that if you have installed Microsoft DHCP and WDS (or used some other vendor's technologies), the
request step doesn't occur and, in fact, the original Offer packet from the DHCP server already includes the
location of the PXE server and the NBP program (thus removing two steps, as well as some time).
Step 7 The client, which has the small TFTP protocol stack mentioned earlier, downloads the NBP from the
network location specified by the PXE server. TFTP is a dated, exceedingly small, stateless protocol. It
wasn't chosen for its security or its performanceand many router administrators disable it by default as a
result. It must be enabled for PXE to function.
Many PXE implementations (including RIS) include the ability to ask the user to press F12 to continue at this
point, but typically this can be disabled by the administrator of the PXE server. Next month when I look
further at WDS, I'll take a look at some of the enhancements Microsoft has put into the TFTPD (TFTP
Daemon) in WDS for Windows Server 2008 to improve performance.
Step 8 The NBP is initialized. In the case of RIS, this starts a Windows boot loader that begins the process of
taking deployment forward. PXE (at least the actual boot-level protocol) is no longer a component in the
process.
It's important to remember that PXE (whether RIS, WDS, or any other infrastructure) doesn't work well over
slow links (it can be transferring considerable amounts of data) or high-latency links such as satellites (the
communication simply doesn't perform well and may not even survive).
You may notice in the PXE boot process that when the client sends the request, there is nothing that
specifically asks, "Are you my mother?" There simply isn't a lot of state information for the PXE server to
know one way or another. What usually occurs is a race conditionwhere the first server to respond to
your client request will win. A couple of things can help reduce this problem:
Adjust the response speed of one PXE server or the other. Network latency and server horsepower
will impact how fast the servers respond. In fact, at Microsoft it used to be that the servers used by
Microsoft IT were so good that even if the PXE server was in your office, the corporate servers
would sometimes win. In this case, you just set your local PXE server to have no timeout at allfor
your prestaged clients.
Prestage the clients. This is very important if you are manipulating your PXE server to respond
ahead of other corporate IT servers. By prestaging your clients, you allow Active Directory to tell
WDS or RIS that yes, in fact, "I am your mother." Note that the use of the SMBIOS GUID is far
preferred as the unique identifier for your systems in Active Directorybut if an SMBIOS GUID is
not implemented in the systems (more likely in relatively older hardware), you can (and will have
to) use a GUID based on the MAC address. For more information, see the "Prestaging Clients"
sidebar.
Don't allow PXE communications to cross switches or routers; put a PXE server on each side. This
has the downside of being both expensive to implement and expensive to maintain (each server
must have its own image maintained).
RIS (and now WDS) servers, like Microsoft DHCP servers, must be authenticated against the Active
Directory implementation they are associated with. The goal is to reduce the issues that rogue PXE servers
may cause (such as PXE broadcast storms) by letting the Active Directory know about all of those servers.
Note that this protects only against servers Active Directory knows about. If you set up your own domain,
or a non-Microsoft PXE server, that won't be the case.
At Microsoft, an overzealous employee once configured a "zero-touch" deployment non-RIS PXE server.
This implementation worked by completely erasing the hard disk and putting down a new image. That
would have been fine if the deployment occurred in an isolated (off-network) lab, but unfortunately it
didn'tand it wound up erasing the disk of a Microsoft executive who had PXE early in his boot order
before the hard disk.
That hadn't been a problem, as Microsoft IT always required pressing F12 to PXE boot, but this PXE server
did not have a delay, an F12 prompt, or any type of notification. This meant that the executive effectively
lost his computer and any data not protected by his Roaming User Profile.
Let this story serve to highlight to you the necessity of isolating your PXE servers if you're going "zero-
touch," or at the very least to require pressing F12.

Diving into RIS
I inherited RIS after Windows 2000 had shipped. Time hadn't been kind to Windows 2000 as far as RIS was
concernedand testing, performance, and other constraints led to RIS for Windows Server 2000 being
used solely for Windows 2000 Professional deployment. The server products, unfortunately, couldn't be
deployed via RIS. Windows 2000 was only available for x86 machines, so it proved to be a good test bed for
RIS since it involved one product on one architecture. RIS included (and required) complete integration with
Active Directory, integrated well into the Microsoft DHCP server, and included its own TFTPD.
RIS uses the NBP to continue the TFTP downloadand bring down enough of the Windows kernel to begin
the setup process. (At a certain point, once Windows has switched from TFTPD to a Server Message Block,
or SMB,-based connection to the server, the literal codepath is actually shared with a traditional floppy-
disk-initiated install of Windows 2000 or Windows XP.) Once native-mode Windows has been initialized,
Windows setup begins the RIS OS Chooser (OSC) Wizard.
OSC screens are somewhat configurable, HTML 2.0-like pages. They are severely constrained and cannot
contain images or the like and, in fact, can't contain non-ANSI characters (which made deploying certain
locales of Windows complicated).
The end product of RIS is a txtsetup.sif file that sits on the RIS server. When the OSChooser Wizard
completes, the client is "soft-rebooted," but the location of the RIS server and of the txtsetup.sif file are
retained and reloaded after the soft reboot. This txtsetup.sif file is essentially the same as an unattend.txt
file, with several additional fields included to help RIS complete the setup process.
RIS could also perform a setup that looked much like traditional unattended setup (RISetup), and it had a
cloning-based infrastructure similar to Sysprep (RIPrep) and, in fact, shared code with it. But RIPrep could
also upload an image of itself to a RIS server.
RIS had some fundamental limitations that became apparent, however. The first was the lack of support for
server deployment. Certain exploits, such as Code Red and Sasser, combined with the IT complexities that
several key customers experienced recovering directly from the September 11th tragedy in 2001, led us to
actually fast-track a solution for existing Windows 2000 RIS servers to allow for Windows Server
deployment. This was something we had been working on for Windows Server 2003 but had not formally
released.
More on PXE-Related Technologies
Description of PXE Interaction among PXE Client, DHCP, and RIS Server
Planning for PXE-Initiated Operating System Deployments
PXE Architecture
Remote Installation Services
Remote Operating System Installation
Step-by-Step Guide to Remote OS Installation
WDS PXE Provider
What Is Remote Installation Services?
Windows Server 2003 Automated Deployment Services
Second, RIS lacked the ability to completely automate the OSChooser Wizard, which was later enabled with
the <META ACTION="AUTOENTER"> element in Windows Server 2003. Finally, the OSChooser was unable
to function properly with non-ANSI charactersa key weakness pointed out by several customers outside
of the United States.
As a result, you could not complete a RIS installation with a French keyboard, for example. Getting non-
ANSI characters working safely at the BIOS level on PCs from around the world was extremely complex and
it just wasn't easy to accomplish.
With the release of Windows Server 2003, we formally added support for the Intel Itanium architecture and
all server variants of Windows 2000 and Windows Server 2003. Windows Server 2003 took that one step
further with support for the x64 architecture.
RIS also had a significantly rewritten TFTPD to increase performance. Windows Server 2003 supported
booting up to 75 clients at the same time; bear in mind that the upper bound here is reached as the SMB
pipe fills up with network traffic to the clients.

WDSThe Beginning
When we started working on RIS for "Longhorn" (the code name for what became Windows Server 2008), it
became apparent that we needed to take a step back. As I've mentioned in my column before, we had
already made big bets on image-based (WIM) setup from Windows PE. As a result, the key tenet underlying
WDS was image-based deployment from a PXE-booted instance of Windows PE.
We also knew that Windows Server 2003 would be the common platform for Windows Vista

deployment,
and that we would need an "out of band" solution for WDS downlevel. As a result, WDS was able to run on
Windows Server 2003 SP1 and was built into Windows Server 2003 SP2.
Since it can operate as a RIS server (Legacy mode), a hybrid server (Mixed mode), or a WDS-only server
(Native mode), WDS allows you to migrate to formal WDS-style deployments as warranted. I have heard
customers asking if there is a way to install RIS on a Windows Server 2003 SP2 system. Yes, there isyou
install WDS and run in Legacy mode. Figure 2 shows the supported operating systems.
Figure 2 Platforms supported for deployment
Operating
System
RIS (Windows
2000)
RIS (Windows Server
2003)**
WDS (Windows Server
2003)****
WDS (Windows
Server 2008)
Windows 2000
Pro
X X X X
Windows 2000
Server
* X X X
Windows XP Pro X (x86 and IA64)*** X X
Windows Server
2003
X (x86 and IA64)*** X X
Windows Vista X X
Windows Server
2008
X X
* support.microsoft.com/kb/308508 and support.microsoft.com/kb/313069 added support for Windows
2000 Server via RIS.
** WDS Legacy and Mixed mode support this same matrix for legacy installs.
*** Windows Server 2003 SP1 added support for x64-based systems. IA64 systems only supported RISetup-
based installation.
**** Native Mode support.
WDS in Windows Server 2003 SP1 and SP2 sought to begin the migration process to WDS. As I've
mentioned before, the key features WDS added in Windows Server 2008 were a revised TFTPD, Extensible
Firmware Interface (EFI) boot support, and of course, multicast-based deployment.

Other Players
Automated Deployment Services (ADS) was built by another team within Microsoft, primarily with the goal
of rapid server provisioning. ADS featured formal sector-based imaging, its own boot agent (smaller than
Windows PE but not as full-functioned), its own TFTPD, and very advanced multicast. The functionality built
into ADS became available to a degree in System Center Configuration Manager (SCCM), though there is
not 100 percent feature parity.
Windows XP Embedded featured full PXE-boot via its own TFTPD into a RAMDisk, but could not remote
deploy that way. The technology was designed to support booting numerous systems from the same disk
image at the same time via PXE.

Wrapping Up
So that's the history, in brief. To find out more, see the "More on PXE-Related Technologies" sidebar. Next
month, I'll dive into WDS fundamentals, to be followed by columns on WDS advanced functionality
(multicast and more) and, finally, using WDS without using WDS, by which I mean going beyond the existing
WDS/setup experience to roll your own deployment techniques.

Wes Miller is a Senior Technical Product Manager at CoreTrace (www.CoreTrace.com) in Austin, Texas.
Previously, he worked at Winternals Software and as a Program Manager at Microsoft. Wes can be reached
at technet@getwired.com.