I will provide in there an old technote (2006) that was for designing multiple sites, using a single DS, or 2, according of the global size of sites.
Please notice this architecture is for Deployment Solution DS 6.9 only !!!
For using DS 7.1, the architecture & design is not the same (but similar regional concepts).
But for now, 99% my current customers are still DS 6.9 for OS deployment, so I believe worldwide are still using also a lot DS 6.9 instead of DS 7.1.
I am pretty sure I already see some very good article regarding DS 7.1 architecture.
I publish this one, because I was searching an existing to explain some customers still plan to install multiple DS, for less 1000 computers, but in multiple locations.
I do not find any clear article or KB this subject, so if I miss one, just tell me & link in there please ;-)
Simplify Architecture plan for Altiris Deployment Solution 6.x !
Altiris Notification server 6.0 (NS), CMS 6.0, SMP7, CMS 7.0
Deployment solution 6.5, 6.8, 6.9 (DS) that is included into CMS, but separately...
Windows 2003 SP1 (W2003, W2k3, service pack 1)
NEW ALTIRIS ARCHITECTURE PROPOSITION
for middle size company from about 300 to 3000 PC clients
As-it-was – multiple DS: Official Model to deploy OS image on multiple sites
Still on a lot of "old" documentations & design:
Each remote site must have a DS server to be available to deploy OS image (using PXE)
A DS “Library” folder is automatically replicated to each sites using a unique Package in NS (each DS are a package server). This « package » can be 2 to 6 GB size or more.
The update of the replication must be ordered manually with a « update distribution point » on the NS console.
High impact maintenance overload for a lot of remote DS,
Especially for customer with high number of very small sites.
E.g.: Using deployment server for 50 sites of 10 PC, need to connect and manage 50 different consoles, all the same consolidated into NS/Dsweb.
DS tasks must be repeated 50 times because it is not possible to run 1 « job » on multiple DS in one operation.
The import process, of the updated tasks, replicated on each site using the “Library” folder, into each DS: is resetting the history of the previous operations from existing Tasks.
Never do this:
This is the very "BAD" design
To-be – Simplify model: Multiple Sites, unique central DS.
It is possible to use a unique central DS to manage multiple sites.
We do not recommend creating a replicated file share for the “express”, only for the source packages & images must be replicated on local file share.
Lower the number of DS at a minimum number (or a single), using local site Share or Package Server for IMAGEs & large files storage.
Automation tasks are build to use multiple local PXE to avoid WAN preboot overload (30Mb linux, 120Mb winPE). Altiris architecture permit hierarchic multiple PXE scenario
The administration is highly simplified, and the replication process is limited only to DSL packages & disk images (sources). The maintenance is also more simple.
The WAN traffic is the main point to verify. The decision to install or not a local DS can be done regarding the balance of :
To permit a central DS, All DS Tasks scripts must be intelligent enough to be able to run from any site without getting error or exceptions. For example by using DFS source share or DNS alias share, or conditional reference table to mount a dedicated local share on fixed source network drive letter.
The benefits will be loosed if we must create a separate task for each sites
(except for specific local site tasks)
In this scenario: we can also propose in addition to use "embedded" preboot partition on "bad WAN" sites, to avoid PXE transport of the boot image (especially for WinPE preboot, 130MB compressed)
enjoy OSD with DS 6.9, all the same to be replace in the next 2, or 5 years, with DS 7.x (I believe in 2012).