I work with 2 customers both of whom have CAS and PRI environments. One has half your number of clients and the other, double. I have seen most of the ways in which a CAS and DRS can go screwy.
When DRS does fail you will need access to someone who has seen the problems before. There are not. THAT many people on tap. As a high level steer I would look to: - deploy 2 physical SQL Servers - setup Always On replication - Configure a site server with the minimum additional roles pointing to one of the SQL Servers as its database. This will be a VM - use Hyper-V replica on the site server - depending upon console access offload providers - configure FSP, SSRS and possibly WSUS on the same machine with the SSRS reporting against the replica - deploy client facing systems running MP Replica databases. Size these systems so that that have enough RAM to cache the entire database. Automate the creation of these VMs - Bring up a modicum of "ordinary" DPs at key locations - At second tier locations bring up Pull DPs pulling from a couple of site systems - Edit SCF so that distribution timeout is extended from default (9 hrs?) - consider using Branchcache for tiny sites - consider use of Azure based DP on sites where internet access is better than Corp access. > On 5 Oct 2015, at 19:25, Dwayne Allen <[email protected]> wrote: > > As someone who originally had a CAS and had to fight with management for 2 > years to convince them we were shooting ourselves in the foot and then spend > a good portion of this year figuring out how to migrate from an existing CAS > hierarchy to a single primary hierarchy with minimal downtime: You don't > want a CAS > > ----- > Dwayne Allen > [email protected] > (479) 310-0027 > >> On Mon, Oct 5, 2015 at 1:13 PM, Mike Dzikowski >> <[email protected]> wrote: >> I hadn't been on the list all day. This made my Monday :) >> >> Thanks Ryan! >> >> From: [email protected] >> To: [email protected] >> Subject: RE: [mssms] SCCM Redundancy Best Practices >> Date: Mon, 5 Oct 2015 17:55:38 +0000 >> >> X 150,000 >> >> >> >> J >> >> >> >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Jason Sandys >> Sent: Monday, October 5, 2015 1:16 PM >> To: [email protected] >> Subject: RE: [mssms] SCCM Redundancy Best Practices >> >> >> >> +150,000 >> >> >> >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Ryan >> Sent: Monday, October 5, 2015 12:12 PM >> To: [email protected] >> Subject: Re: [mssms] SCCM Redundancy Best Practices >> >> >> >> >> >> >> >> On Mon, Oct 5, 2015 at 12:01 PM, Charles Hiland >> <[email protected]> wrote: >> >> The end result is redundancy in our primary server and SQL database. >> >> >> >> >> >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Jason Wallace >> Sent: Monday, October 05, 2015 12:47 PM >> To: [email protected] >> Subject: Re: [mssms] SCCM Redundancy Best Practices >> >> >> >> Nooooooo! >> >> >> >> How many clients do you have? >> >> >> >> In CM16 you can have 200,000 clients. >> >> >> >> What do you expect to see from your new design? >> >> >> On 5 Oct 2015, at 17:41, Charles Hiland <[email protected]> wrote: >> >> We will be upgrading to SCCM 2016 next year, and I’m trying to figure out an >> ideal redundancy setup. At the moment we have one primary and 7 secondary >> sites (the secondary sites are just DPs). Does anyone have any ideas for >> best practice when it comes to redundancy? >> >> >> Currently we are thinking an off-site CAS with two primary servers. Do any >> common-place rules stand out that I am overlooking? >> >> Thanks in advance, >> >> Charlie >> > >
