Deployment Solution

Hallo everyone

Hope everyone has had a great christmas and a good new years eve, hopefully with a limited amount of enjuries.

I have a question i'd like to hear someone else's point of view on.

In DS 7.1 we have PXE server functionality on our Site servers i sadly haven't fiddled too much with it.

The thing is i am going to be doing a farely large implementation later this year (yes of course i know it has to be realeased first - the new version ;) )
This implementation is going to be consist of 4 site servers which also is going to hold the PXE server role.
My question is pretty simple how would you handle PXE server requests ?

The thought in our heads are simply to create 4 IP helpers on each subnets pointing to each of the PXE servers, the thought is that the one which has least to do at the time handles the request, and starts to download the PXE image, but i have no idea if this will in fact work.

The second way to do this is to split up each subnet and pointing each of them to a PXE server but really this would be single point of failure, plus we would have to have a complete list of which subnets are point to which servers.

Solution nr. 2 is the one i would very much like to avoid, but i would like to hear other point of views, it could be that i haven't thought of a solution which would be much smoother and much more ingenious. who knows.

Looking forward to hearing from you guys.

Kind Regards
Morten Leth

Hello Morten,

You can create siteserver according to subnet and sites. If there will be one siteserver in a subnet then there should be no issue.

Or if you have one 1 subnet then define an iprange for your site server.

SBS/PXE installed on these siteserver will work on siteserver iprange

But you'd have to tweak the SQL a bit per TECH133468.  Please review that KB to understand what you'd be up against.  In theory though, if you used the query that returns the entire environment to each SBS server you'd be fine.  You'd then also have to be sure that each SBS server had all the same information.

The only thing I'd be concerned about is if the SBS server actually gets the information for the client.  Here's the deal I've not ever tested.  If you send a job to a client, then the instructions to reboot to that environment are sent to that client's task server (which is by default supposed to also be an SBS server).  If that client then boots to a different SBS server, will the SBS info be there?  It wont be treated as an unknown computer, but will it be treated automatically to the correct boot order?  hmmm...  I don't know.  My guess is that it will NOT get the menu you want.  hmmmmm...

What are your connections to each site server?  Is this all one location?  How many systems?

Regarding the "unknown" computers problem we actually have agreed upon we wouldn't have that checkbox ticked, so we don't respond to unknown computers in this setup.

The scenario you are describing there though is excactly the thoughts i have been thinking of, and atm. we have no idea on how this would work in a real life examble. - Perhaps you have a similar installation somewhere who actually have this scenario running?

The environment in which this is going to be implemented is 11.000 clients which all are going to running some sort of tasks, not at the same time of course, the lines which connects these clients are gigabit lines, so our infrastructure is pretty good, therefore we have designed it all to run from the datacenter, that's where our Notification Server and all of our 4 Site servers are going to be placed.

The clients are not all of course on the same subnet, but rather spread out on 200 different subnets, or so. The network is not something we are controlling, but we are the ones who needs to tell the network vendor how we want things to look like.

So Thomas, do you think my scenario i possible to create, with having 4 site servers (SBS) in one location and simply creating the 4 IP helpers to all of my 4 Site servers (SBS) or is tere a better way and more simple way to do this, when still avoiding the single point of failure.

Kind Regards
Morten Leth

I'll see what I can find out though.  My main concern is the SBS file sent to the individual server to let it know that you've sent a reboot to production may fail.

There is something else though that might help, a lot.  If you also put on all managed systems the automation folders (a bit of a headache I'll grant), then you'd not have to rely on the PXE servers at all except in the case of new systems or reimaging after a catastrophic failure.  The chance of failure therefore is significantly reduced.

Just a thought while I do some checking.  I'm not sure if this specific scenario has been discussed here.  Good idea frankly, just not sure if it's been talked about.

Sorry.  I'll see what I can find.

Hallo Thomas

It's greatly appreciated if you could find some meterial regarding this subject.
Meanwhile i'll comment on your suggestions. ;)

Yeah we could use the feature to create "automation partitions" but as you say they really are a pain to manage, if we needed to do a change afterwards we need to push out the new configurations to all of our clients, which we would really like to avoid. :)

But if you could write back on your findings, regardless if they are positive or negative it would be very nice.
And if we come to the conclusion that this has never been done before it would be nice to hear "Symantecs" point of view, if they in fact was willing to give a hand in doing the necesesary modifications in order to make this function (one could argue that it was in symantec's best interest to make this function :P)

Looking forward hearing from you Thomas.

Kind Regards
Morten Leth

We're pretty sure it'll break.  Sorry.

Frankly, I'm not even sure how I'd propose it be fixed.  We have one proposal in that suggests a fundamental re-write of PXE that would resolve the issue, but that's talking fundamental, and those are VERY hard to push through.

What will happen is that though PXE will in fact be "functional", the command telling the PXE server that "client X is booting using menu X" is only sent to the SBS server to which you are assigned via Task Server.  It isn't sent to the other SBS servers.  Hence, if pxe server y responds before pxe x, you don't get the right menu options, or, more likely, simply boot to production.

:(

I'll see if I can find a way to use this as leverage for our other proposal, but if you know anything about software, when you think of fundamental re-writes, well, just don't hold your breath.  Honestly, this would be a very tricky scenario to work out.  Well.....  there MIGHT be one other way...

Still, don't hold your breath.  Sorry.

Hallo Thomas

Thank you for your reply allthough it wasn't all that positive. :)
But it's still better to know how things would turn out before implementing it in the customer environment.
This does mean for me that we are forced to implement the IP helpers and distribute the load based on IP helpers in the network, which of course does mean Single-point of failure in our setup.
But still as said earlier, it's still better to know this before hand rather than seeing weird behaviour.

If you could try proceeding with what you suggested there it would be nice, and i would also gladly help out testing it in our environment if that should be needed.

Kind Regards
Morten Leth