— Kiaasa Dhanori Pune

Altiris Deployment Server automates Windows Server provisioning by PXE-booting a target machine into a Windows PE agent, then pushing a standardized image and post-install scripts over the network. This guide walks through the full lifecycle of an Altiris Deployment Server Windows Server build — from BIOS boot order and MAC capture to scheduling the deployment job and verifying the finished host — for both physical ("bare metal") and virtual machines.

Important context: Altiris was acquired by Symantec (now Broadcom) and the classic Deployment Server (DS 6.x) is end-of-life. Its capabilities were folded into Symantec Ghost Solution Suite and the agent-based Symantec Management Platform / Deployment Solution. The workflow below is faithful to the classic console and still common in legacy estates; where the same task is now done differently, the modern equivalent is called out. If you are building from scratch today, Microsoft Deployment Toolkit (MDT) with Windows Deployment Services (WDS), or SCCM/Microsoft Configuration Manager OS Deployment, are the mainstream replacements that use the same PXE-then-WinPE pattern.

The problem this solves

Manually installing Windows Server from media is slow, inconsistent, and impossible to audit at scale. Two engineers building the "same" server end up with different drivers, patch levels, partition layouts, and naming. An imaging server fixes this by making the network the install medium: every target boots the same WinPE environment, receives the same gold image, and runs the same scripted configuration, so the result is repeatable and compliant with your build standard.

The Altiris Deployment Server Windows Server build process delivers this through four ordered phases. They must run in sequence because each one produces an input the next phase needs — most importantly the target's MAC address, which is how Altiris uniquely identifies a machine that has no operating system yet.

Prerequisites before you start

Confirm every item below before touching a console — missing one is the single most common cause of a failed build.

• The Altiris (Deployment) Console is installed on your workstation and can reach the Deployment Server.
• You hold local administrator rights on the workstation running the console.
• For virtual targets, you have access to VMware vCenter (VirtualCenter) with rights to create and edit VMs.
• A PXE/DHCP environment exists on the build VLAN in the target datacenter. Where no build VLAN is available, request a static-IP boot ISO as a documented exception.
• You know the correct build standard for the target: site, edition (Standard or Enterprise), and architecture (32-bit or 64-bit).

Modern note: in MDT/WDS or SCCM the equivalents are a configured WDS PXE responder, a deployment share or distribution point, and an account with permissions to the deployment console — the same building blocks under different names.

Step-by-step: the Altiris Deployment Server Windows Server build

The four phases are: (1) select configuration options and capture the MAC, (2) add the server to Altiris inventory, (3) for brand-new machines run a Wait job to inventory them, and (4) select and schedule the deployment job. Then you power on and monitor.

Phase 1 — Select configuration options and capture the MAC address

Choices here are driven by the server's specification: its site (for example NHQ, NDC, SDC, or ELO), whether it is bare metal or a VM, and whether it runs 32-bit or 64-bit Windows. Two things must be true at the end of this phase: the network adapter is first in the boot order, and you have recorded the MAC address.

1. Set the system to boot from the network first. Enter the firmware setup and set the boot order to Network adapter first, hard drive second. Standard practice is to use the first onboard NIC as the PXE boot device, and to confirm PXE (Network boot) is enabled on that adapter.
2. For a physical server, verify it has been racked, powered, and cabled to the published standard; that its switch ports are turned up on the build VLAN; and that the out-of-band management interface (iLO/iDRAC/IPMI) is online and you can log in to it.
3. Capture the MAC on bare metal by booting into the BIOS and reading the NIC's PCI card information, then power the machine down. You will resume it later at the deployment step.
4. For a virtual machine, first create the base VM in vCenter with the standard Windows disk size and the correct OS type, then right-click it and choose Edit Settings....
5. On the Options tab, select Boot Options and increase the Power-on Boot Delay to 10000 milliseconds (10 seconds). The delay gives you a window to catch the boot and prevents the VM racing past PXE.
6. On the Hardware tab, select Network Adapter 1 and copy the value in the MAC Address field. Set the VM to boot from the network adapter (firmware/boot-order set to NIC first, hard disk second).

Tip: when a VM boots you can press ESC for a one-time Boot Menu, or choose <Enter Setup> to change the persistent boot order. Record the captured MAC exactly — a single wrong character means Altiris will never recognize the machine.

Phase 2 — Add the server to Altiris inventory

With the MAC in hand, register the machine so the console can target it. Altiris keys the object on the MAC, so this is what links the physical/virtual hardware to a deployment plan.

1. In the Computers pane (upper-left, below the toolbar), right-click and choose New Computer.... Multiple machines can be staged in one pass.
2. Click Add... to open New Computer Properties. On the General tab fill only three fields — the rest are populated automatically by deployment scripts:
   • MAC Address — the value captured in Phase 1.
   • Computer Name — the DNS/NetBIOS hostname; Altiris mirrors it into Name.
3. Click OK, then OK again on the Add Computer screen once all machines are defined. They now appear in the inventory list.
4. Right-click the new object, choose Properties, scroll the left-hand icons to Location, and fill those fields. Despite the labels, these are read as script variables by the deployment job, not true location data:

   Field on screen	What it actually carries
   Contact	Computer description
   Site	The site code: NDC, NHQ, SDC, or ELO

5. Click OK. Repeat for each additional machine you staged.

Phase 3 — Run the Wait job for brand-new machines

A machine the Deployment Console has never seen — a fresh server, or one repurposed with its partition wiped — must connect once so Altiris can inventory it before a real job runs. Because of how VMware presents hardware, you do this by dropping the object onto the correct Wait job that matches the OS install type:

• Building a 32-bit Windows Standard VM → use Wait 32.
• Building a 64-bit Windows VM → use Wait 64.

Boot the client to the Wait job; it parks in WinPE "connected" to Altiris and waiting for instructions. Previously deployed objects skip this phase.

Phase 4 — Select and schedule the deployment job

Now associate the inventory object with one of the predefined standard deployment jobs in the Jobs pane (lower-left of the console). These jobs are intricate; treat them as read-only.

WARNING: always drag the computer onto the job — never drag a job up into the computer inventory. Because a job can act on any object, including a whole folder, dropping a job on the wrong target (or fat-fingering Enter) can re-deploy and wipe many production servers at once. Do not open the individual components inside a job.

1. Drag the computer object from inventory and drop it on the desired job. The Schedule Job screen opens with three tabs: Job Schedule, Computer(s) Selected, and Job(s) Selected.
2. On Job Schedule, choose when it runs:
   • Do not schedule — you will set a start time manually later.
   • Run this job immediately — starts the moment you click OK.
   • Schedule this job — begins at a specific date and time.
   Use Allow this job to be deferred to delay start by a span, and Schedule in batches of to stagger many targets so they do not hammer the network at once.
3. Click Computer(s) Selected and confirm only the intended machines are listed.
4. Click Job(s) Selected and confirm only the intended job(s) are listed.
5. Click OK to schedule or start the job.

Start the deployment and watch it run

Power on the target. It should pick up an address from the build VLAN and begin a PXE boot.

1. The machine loads the Windows PE image over PXE and the Altiris agent contacts the server to learn its assigned workload.
2. Altiris transfers the payload — drivers and utilities, VMware Tools for VMs, OS installation files, and other build components.
3. Windows installation files are copied to the target, the system reboots, and post-install configuration completes.
4. To monitor: in the Jobs pane select the job, then in the right-hand list right-click the running computer and choose Properties to open Job Schedule Information. It shows the current step (for example "distributing the disk image") and how many scripted steps remain.

Common pitfalls and how to fix them

Most failures in an Altiris Deployment Server Windows Server build trace back to networking, boot order, or a mistyped MAC. Work the list below before escalating.

"Media Test Failure, check cable" during PXE boot

The NIC found no PXE responder. Causes and fixes:

• The cable is unplugged, the switch port is down, or the cable is in the wrong NIC. Connect the first onboard adapter and confirm the port is enabled on the correct build VLAN.
• PXE is enabled in BIOS or adapter firmware on a NIC that is not connected (or the wrong adapter is set to PXE). Enable PXE only on the connected first onboard NIC.

VM build fails mid-copy while transferring install files

Usually network latency on a busy VMware environment. Retry the failed step rather than restarting the whole build:

1. Select the job; the right pane lists the running computers.
2. Right-click the target, choose Properties, and use Status Detail to see which step failed; close the dialog.
3. Right-click the job containing the failed task and choose Retry Task.... The job resumes at the failed step instead of starting over.

The VM races past PXE

Increase the Power-on Boot Delay to 10 seconds and confirm the NIC is first in the boot order so the firmware reliably reaches the PXE prompt.

"New Parallel Port" Add New Hardware wizard on first VM login

This is a harmless VMware artifact. Ignore it, or let Windows install the recommended driver to clear it.

Wrong Wait job for the architecture

Dropping a 64-bit build on Wait 32 (or vice versa) leaves the machine stuck. Match the Wait job to the OS install type before running the real deployment job.

Verification: confirm the build succeeded

A job that reports complete is not the same as a server that meets standard. Verify before handing it over:

• Log in to the new server once the OS install finishes.
• Confirm BGInfo is present on the desktop and shows the correct hostname, IP, and build details — a quick proof the post-install scripts ran.
• Check the computer name and domain/IP match what you entered in inventory.
• Confirm the correct edition and architecture with winver or systeminfo.
• On VMs, verify VMware Tools is installed and current; clear any leftover hardware-wizard prompts.
• Spot-check disk layout, time zone, patch level, and that the host is reachable on the correct production VLAN after the build VLAN hand-off.

From a command prompt, a fast sanity sweep looks like: hostname, ipconfig /all, systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"System Type".

Mapping the classic flow to modern tools

If you are maintaining this in a legacy estate, the steps above stand. If you are modernizing, the same PXE-then-WinPE pattern maps cleanly onto current tooling:

The mental model — identify the machine by MAC, PXE it into a tiny OS, push a gold image, run scripts, verify — is identical across all of them, which is why the troubleshooting instincts you build on Altiris carry straight over.

Key Takeaways

• The four phases — configure/capture MAC, add to inventory, Wait job (new machines), select deployment job — must run in order because each feeds the next.
• The MAC address is the linchpin: it uniquely identifies an OS-less machine, so capture and enter it exactly.
• Set network/PXE first in the boot order and, for VMs, raise the boot delay to 10 seconds so the target reliably reaches the PXE prompt.
• Always drag the computer onto the job, never the reverse, to avoid mass-redeploying production servers.
• Altiris Deployment Server is end-of-life; the same workflow lives on in MDT/WDS and SCCM/Configuration Manager OS Deployment.

Frequently Asked Questions

Why does Altiris use the MAC address instead of a hostname?

A bare server has no operating system and therefore no hostname, IP, or domain identity yet. The MAC address is burned into the NIC and is the only stable identifier available during a PXE boot, so Altiris uses it to match the booting hardware to the New Computer record and its assigned deployment job.

What is the Wait job and when do I need it?

The Wait job (Wait 32 or Wait 64) boots a brand-new or freshly wiped machine into WinPE and parks it "connected" so Altiris can inventory it before a real deployment runs. Run it only for machines the console has never seen; previously deployed objects skip this step. Match the job to the target's architecture.

Is Altiris Deployment Server still supported, and what replaced it?

The classic Altiris Deployment Server is end-of-life. Its capabilities moved into Symantec (Broadcom) Ghost Solution Suite and Deployment Solution. For new deployments, Microsoft Deployment Toolkit with WDS, or SCCM/Microsoft Configuration Manager OS Deployment, are the standard tools and use the same PXE-then-WinPE imaging approach.

How do I fix a "Media Test Failure, check cable" PXE error?

It means the NIC found no PXE server. Confirm the first onboard adapter is cabled, the switch port is up on the correct build VLAN, and PXE is enabled only on that connected adapter — not on a disconnected or wrong NIC. Correcting the adapter and VLAN clears the error in nearly every case.

For more hands-on Windows Server, virtualization, and system administration walkthroughs, subscribe to @explorenystream on YouTube.