Video Screencast Help
Endpoint Management Community Blog

How many remote sites, can really manage, with OSD, a single Altiris server ?

Created: 10 Sep 2011 • Updated: 16 Sep 2011 • 12 comments
Pascal KOTTE's picture
+2 2 Votes
Login to vote

When talking OSD (Operating System Deployment): we speak about "DS" (Altiris Deployment Solution)...
But when speak about DS, must ask for "6.9 or 7.1" ?

About DS 6.9:

We already build with success a single DS 6.9, with 60 remote sites (or perhaps 55 only, but 2 times). So we can afford 60 secondary PXEs, connected to a single central DS.

Where is the maximal limitation ?

Well, in theory, only a total of 5'000 machines can connect the central DS server. I am pretty sure we can upper this number using Windows 2008.

Regarding numbers of remote sites maximum: a secondary PXE will only connect the DS central a single TCP session...

We often got a problem using DS 6.9 because of any change preboot files, immediate impact thousand remote sites, and overload WAN. The workaround is to "stop" the PXE config helper on each site, to start only during "maintenance hours" (out of business).

Notice the Symantec Management Platform Server can easier manage hundred of servers to automate start, stop services, on demand, or scheduled.

So with some care, not afraid to higher more 50 sites... But need to test carefully, and no idea where we should stop... (for sure 500! but for 250?)

About DS 7.1 (sp1):

The jump is not an upgrade, but a full "new" solution: because no more simple 2 tiers SQL/win32 application, with ability to manage 5'000 clients only.

The Symantec Management Platform with the Deployment Solution 7.1, is a huge 3-tiers MS-DotNet platform, can manage 20'000 to 50'000 (depending which source we read...), connected to a single Database/Management platform... I do not say, a single server there: for sure need additionnal servers, for external SQL store, package services, task services, and in particular for OSD the boot services (see http://www.symantec.com/docs/DOC3464)

  

Of course, the sizing will also depends of the other Altiris services/solutions used, or not (patch, delivery, inventory, etc...).

So the question here is, how many sites (and clients), before we need to up to a hierarchy of "SMP" servers. What can we do, using a single SMP (alias NS) ? For OSD !

At a 1st approach, it seems we got a bump up, being able to manage 5 or 10 times more...

At a second detailed view: We need to deploy a TASK (TS)+PACKAGE(PS) server on each remote site (to get a Boot Server: BS). We can deploy hundred of package servers. But only max 100 task servers, to connect a single NS... And the recommend is 10 max ???

Oh, oh...

So we can't build more than 50, and very max 100 remote sites, for a single CMDB/SMP/NS platform. Not more sites than DS 6.9!

Each BS (the site server with TS+PS), can manage 500 clients (1000 very max?): So I can in theory up to 25'000 computers, if was 500 on each sites...

A single NS if Less 50 sites to manage, if less 500 computers per site !
e.g. 15'000 computers: 1 HQ 5'000 (10 DS), 20 sites 500 computers (20 DS)...

  

If it is possible to consolidate a single TS for multiple sites, it is not really possible if need to deploy BS (OSD on PXE), must have 1 each site local.

In the real world, most of the time, numbered branch offices are small : eg. a central with 5'000, and 500 sites with 10 to 300 computers, with a total 10'000 remote computers, got a full total 15'000 computers. That is  meaning, we MUST build a hierarchy with 10 NS, and a central report one, all the same only 15'000 clients, (normally can be a single NS, max 3 NS). Happily: Hierarchy is big improvement in 7.1 :)

More 50 sites to manage, need multiple NS in a hierarchy,
all the same only 15'000 computers to manage...
e.g.: HQ 5'000 clients (10 DS), 500 sites of 200 clients (10 NS, 500 DS)

  

If need to make large OSD, we must quickly go back to a more conventional preboot folder or USB or DVD instead of PXE, or huge hierarchy build of multiple NS...

Or... install 5 DS 6.9, and deploy 500 secondary PXEs !?

I think I will have to talk some guys at Barcelona, next month... :)

Comments 12 CommentsJump to latest comment

Bourdin Laurent's picture

Pascal, I think you're on the wrong way if you compare DS6.9 and DS7,1 Scalability and architecture.

1 DS6.9 can handle 5 000 computers and 20 PXE servers ( more PXE work great, especially with some unsupported tweak aka Stop PXE Server Helper, but i guess that 20 is the max officially supported)

1 DS7.1 can handle 20 0000 Computers and 50 PXE Sites ( and 7 500 computers max on each site)

More than One DS6.9 is not an "official architecture"

The NS Hierarchy can solve the limit of the 50 remote sites if needed.

Anyway, except bootwiz this two product are just different.

DS6.9 is for me the best OSD tools ever if you want a zero-touch deployment behind a console (ghost solution is a good tool too if you are behind the deployed computer)

DS7.1 is young. Very young. It just work (with a lot of effort) and several needed things are not there. NS Integration of DS7.1 is ... dirty (I don't have any other word). But in some case, it's useful.

Just for fun, some integration sample :

- You have a wonderful tool to create PXE Preboot (Bootwiz). This tool include an agent (Dagent for DS6.9) and a ay to include  OEM tools. When you want to change the Agent (PECTAgent for DS7.1), the Symantec way is to drop the original agent and add the new agent through the OEM function. It's ... dirty

-You have a tool to replace tokens in your Tasks scripts. You want to implement a replacement token tool for unattend and sysprep files. Extanding the usage of Tokens is not a good idea, it's better to creat a new token replacement process without any user control (changing the %TOKEN% to @TOKEN) and put this tool directly on a dll on the PECTAgent. It's ... stupid

-You deploy a new Agent (PECTAgent) without any Inventory ability. It's shure, no one need to now the computer product name when you deploy a computer.

-You deploy a new OS with the wonderful SOI tool on DS7.1. The SMP and deployment agent installation is made through the SetupComplete.cmd method. OK. So you copy the entire sources from the task server ? NO, it's too simple. You prefer deploying the Bootstrap tool and download the sources directly from the SMP server (23Mb accross a WAN...). I prefer no to talk about the DSPluginIstall.exe, it's just ... funny ?

-Last but not least : Bare metal Deployment. Deploying software directly after deploying an operating system is too simple. You have to create a server job; deploying a software is not possible on a computer without the Software Management Agent. The only thing that the Software management agent have to do is : Talking to the SMP server that the computer use a license. Create a tool to populate the license table at the begining of the job would be to easy; It's ... bullshit

 

DS7.1sp1 just work. For me it's not a real product today, just some bricks putting by some devellopers without any management. But it works. You can deploy Operating Systems through a web console. But if this product still live in 2014, i hope tha every point i've wrote will be replaced by real products.

+2
Login to vote
Pascal KOTTE's picture

Agree most, except multiple DS 6.9 not supported. I can out very old Architecture "Altiris" document with such design (with a "big package" replicated from NS6, to script auto-import updated jobs into others DS 6.9: Yep a simple "replication"). But I guess, you were talking about integrating multiple DS 6.9 into the NS7.1 architecture: that is not supported from Symantec for sure. But each DS 6.9 server, himself and associated agents, are supported.

So I guess everybody does the same us: deploy NS/SMP/CMS/ITMS 7.1 + DS6.9...

But our team is also working on the "addon scripts", to supply and make DS 7.1, usable. Like (force deploy the soft manage plugin, force hardware inventory to get the model number, etc...) But still in LAB for the moment.

I do not find the KB to say the official limitation to 20 PXE... But I heard about a few times.

Hope for a better version 7.3 ? In 2014 :)

~Pascal @ Kotte.net~ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

+2
Login to vote
mclemson's picture

I've heard rumor that 300 TS/PS/DS site servers per NS will be supported in 7.2, up from the current of 50 DS/150TS/500PS.  And, as always, each site server supports up to 7500 clients.

Mike Clemson, Senior Systems Engineer, ASC
Intuitive Technology Group -- Symantec Platinum Partner
intuitivetech.com

+1
Login to vote
Pascal KOTTE's picture

The actual official limitation of the sexondary PXEs into a single PXE manager DS 6.9 is: 15 !!!

here the KB: http://www.symantec.com/docs/HOWTO56037 provided me from Network23 (thanks:)

That is really fun, because in 2005, with ask for Altiris a confirmation they will support 55 remotes sites connected the same PXE Manager !!

I put this 2005 architecture document in there: https://www-secure.symantec.com/connect/articles/it-seems-i-still-see-some-customers-installing-multiple-ds-version-6-multiple-sites

So this July 2011 created article, looks like a "fake" one ???

Or perhaps a way to upper the improvement of the version 7.1 ???

OK I don't know why this limitation of 15, all the same I was hearing 25 in the past, and I believe WAN usage was the main issue. Of course, from time to time, we loose a PXE remote site connection, but we restart the PXE helper, and it is back.

~Pascal @ Kotte.net~ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

+1
Login to vote
R Gines's picture

The number of supported Task Servers supported by one NS continues to improve. It was 50, then 100, and now 300 have been tested with one NS. 

In addition, the next release of DS due out Q1 of 2012 will make significant improvments in the way DS leverages Task Servers so that you will not require a TS on each site where you want to use PXE (DS site services). This will significantly reduce the number of required Task Servers required to use DS 7.x.

+1
Login to vote
Pascal KOTTE's picture

Thanks Rick, I hear from Steven R. the Task servers (TS) are taking same bandwidth, if placed into the computer's remote site they are managing, than in the central HUB. Because the traffic from each clients to their TS, is the same the repeated traffic from the TS to the NS...

(I don't understand clearly the benefits of TS, except if lot of tasks configured to run on task server instead of clients? Not a lot of job for such... Yes I know, that is for real time management...)

So we can consolidate a single TS for multiple sites, with a total of... 500 clients ! (eg. 10 sites with 50 clients)

Except currently wanted to use OSD: need a local TS for building a PXE, and so my asking. What you say is you allow a separation the PXE from the TS, so we will be able to deploy a true "Boot Server" (BS = PXE),

  • as a site service (BS) ?
  • we can deploy and manage like others (Monitor, TS, PS) ?
  • and this "silly" ghost 'BS', default installed on each TS+PS... vanishing ? at last !
  • Like a so nice DS 6.9 architecture ?
  • With a true integration in this nice "Site & Services" console part ?

(Except I would like to know why "Site and Services" not integrated any of the existing part of the standard NS console, so not possible to integrate a custom menu easily???)

If yes, that is good news :) See that at Barcelona.

One more question: How will you solve the "Wake up on LAN" ? If not sent localy the site, accross a WAN not supporting WOL, of course... Did you plan also to restablish the so nice "WOL proxy" settings, integrated the NS6 agent, not any more working on version 7 ??? We need a local Task server on the same subnet to make it works, with more chance...

~Pascal @ Kotte.net~ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

+1
Login to vote
mclemson's picture

My understanding is that more TS/PS will be supported per server, with the DS PXE services being separated from the TS/PS requirement.  So you can have PXE servers that do not run TS/PS.  You are correct that TS location should be in the data center unless it's required at a remote site for PXE reasons, because there is no bandwidth benefit to putting TS close to the clients.

Mike Clemson, Senior Systems Engineer, ASC
Intuitive Technology Group -- Symantec Platinum Partner
intuitivetech.com

+1
Login to vote
Pascal KOTTE's picture

Last update: official number for tasks servers: 150 ! (sp1itms71)

Announcement: sp2 feb. 2012?, will able to extend this number, allowing the PXE deployment without requiring Task+Package deploy ?? Nice to see that soon :)

As soon as we reach 500, it should be OK :P

Thanks a lot to Carsten G. & Paul B. this info.

~Pascal @ Kotte.net~ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

+2
Login to vote
mclemson's picture

I can't imagine an environment that needs 500 task servers once PXE servers no longer require it on-box.  What sort of environment are you picturing?

Mike Clemson, Senior Systems Engineer, ASC
Intuitive Technology Group -- Symantec Platinum Partner
intuitivetech.com

+1
Login to vote
Pascal KOTTE's picture

But honnestly, for the moment, I got only 2000 computers on 200 sites. But better being 50% capacity than 100% :)

All other customers we have is not more 60 sites max. :P

~Pascal @ Kotte.net~ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

+2
Login to vote
HXG's picture

Is is possible to run the Deployment Site Services component on a Windows 7 or XP machine without Task Services? 

+1
Login to vote
Pascal KOTTE's picture

I heard that a next improvment will allow to run PXE services, without needing install of a Task server (that is needing IIS installed).

But as long you install IIS, and correction option security removed for win7, it should be possible to run Win7 or XP as Deployment site server.

Please keep us inform about the result your test: never try this before (but win2008 and Win2003 are pretty similar Win7 and XP, and I do it with success :)

~Pascal @ Kotte.net~ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

+2
Login to vote