Search the Community

Hi, I will try to shortly (as possible) describe my problem and I have a few questions... I administer sccm in a network having <who knows how many> different offices and around 50k active clients. The network is also NOT connected to the internet. I used to have bdp's set up almost on every vlan, eventually this became unmanageable, got to over 2k bdp's making it unsupported and chocked the system as it had too many offline bdps. Eventually after a case with a support engineer we got rid of all of those bps leaving us With only 3 DP's sitting in our main DC. Now we practically cannot distribute anything because every time we try 1 of 2 things happen: 1. Too many PC's attempt connection to the dp's eventually flooding the firewall 2. Users at remote sites get their bandwidth eaten up completely. I am aware that a single DP cannot support more than 4k client and That I have to assign many more DP's The problem is that for some ridicules security reasons (NOT negotiable) all ports are closed between different user Lans. In addition, there are only few DC's and putting DP's in them is: 1. Not enough 2. Will still generate above 2 problems I am also aware of solutions as branch cache and / or multicast but: 1. Branch - we still have XP machines and win 7 migration going pretty slow. 2. Network guy's say multicasting is still not possible on our network and will take very long time to enable support for it (?!?!) Regarding the problem I mentioned above about flooding the firewall with sessions: A little reading and testing revealed that the problem is 10 times worse when bits is used and deployment contains multiple files because of how bits works.... (Round robin between all distributed files about every second) Rate limiting - we also don't know what bandwidth we have from out main dc to every site / office, plus rate limiting being global setting in cm07 doesn't help either (although we could just use gpo instead but still... we don't know the bandwidth). We are thinking about turning off bits so we generate less sessions but that would mean no resume ability... and even less bandwidth control. We also checked the option of applying QOS but network guy's said it would take them ages to implement globally so no for now ---------------------------------------------------------------------------------------------------------------------------------------------------------- This ends the description of current state, now I need advice \ answers. 1) Any general applicable advice? 2) Alternate content providers (Adaptiva OneSite / 1e Nomad) - I see them as probably the perfect solution for except: WAAAY too EXPENSIVE Think otherwise? Anyone uses it? Will it solve my problems? How hard would it be to implement / how long it will take? Do they sell / have customer support worldwide (bonus for onsite)? 3) Since we do not like spending $$$ And since I’m a curious guy - I always wondered how cool it would be to use torrents on our network. Now I am beginning to see how this can actually solve my problems for wan distribution Assuming I take the basic idea described here: http://www.rarst.net/software/torrent-deploy-files/ And tweak it a little (or a lot), I have done some basic tests and have ideas how to automate/ script this... Now the question is - how can I make it play nicely with SCCM? Assuming I can write some script to initiate a BT download, Do some stuff with the content on completion, And deploy this with SCCM - it can cover me in the SW Distribution part. But what about software updates - where your packages do not have a "program" for you to customize and let it find the updates in the folder uTorrent put them in? If there was an easy guide how to implement a real Alternative Content Provider using the api.... Only thing I found is this: http://msdn.microsoft.com/en-us/library/hh948148.aspx If you have a trick to edit what SCCM runs when advertising updates Or if you have a trick to "pre-stage" client cache (download with BT, put it there, make client accept and skip download) Those would also be nice.