SQL is covered by the System Center license, as long as you only use it for ConfigMgr, so that won’t count.
As Niall already said, SQL replication, complexity, and it just doesn’t make ANY sense. Deploy a primary in a test environment, separate from your CAS and start testing there. After you’ve done that, remove your CAS. There are valid reasons to deploy a CAS and MULTIPLE primaries (yes, there are, even if you are below 100k clients), but I’ve never seen a use case for a single primary and a CAS. What political reason could that be? I can’t think of any. Cheers, David From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] On Behalf Of elsalvoz Sent: Thursday, 13 November 2014 8:07 AM To: mssms@lists.myitforum.com Subject: Re: [mssms] QA on prod $$$ not technical but has weight. Start by finding out how much SQL license would be over 3 years. :) Cesar On Nov 13, 2014 5:32 AM, "Niall Brady" <any...@gmail.com <mailto:any...@gmail.com> > wrote: sure, adding an additional primary to a heirarchy with a CAS will add a greater probability of SQL replication problems. On Thu, Nov 13, 2014 at 2:14 PM, SCCM FUN <sccm...@hotmail.com <mailto:sccm...@hotmail.com> > wrote: Yep I agree, just trying to give them a list of saying why its crazy, they don't accept its just crazy as a reason.. I already tried that... Ha. Any technical reasons u can think of ? --- Original Message --- From: "Niall Brady" <any...@gmail.com <mailto:any...@gmail.com> > Sent: November 13, 2014 7:58 AM To: mssms@lists.myitforum.com <mailto:mssms@lists.myitforum.com> Subject: Re: [mssms] QA on prod I've never heard of installing a primary simply to validate packages, that's crazy ! they can install a primary or a heirarchy in a TEST lab to test their packages and once done testing, import them into production, that's what I'd suggest. On Thu, Nov 13, 2014 at 1:36 PM, sccmfun <sccm...@hotmail.com <mailto:sccm...@hotmail.com> > wrote: I’m fighting a battle with the packaging team in regards to them joining a primary to our infrastructure so they can do testing on production. We have a CAS, one primary and this would be the second primary. I don’t wait to get into why do you have a CAS since you don’t have 100k clients, it’s more of a political reasoning than anything else. I believe that all testing should occur on their own primary not part of our infrastructure and when everything is validated they can re-create/import the package/work on the prod infrastructure. They have come back with if RBAC is set up correctly (which I’ve pretty much done) with the correct scoping and limiting what is the issue with them doing everything on a child primary. I’m looking for a list of why they shouldn’t do this, what harm could it cause to the production environment. If they are limited to only their QA machines they won’t be able to deploy their test packages for example to any other machines. I’m looking for some points I can give them saying if you do X, this will cause issues/conflicts with the production environment. Reason 1: They wouldn’t be able to do any hardware inventory testing for new classes they need to create/test as that can’t be scoped. If they create a new class to inventory they would need to modify the configuration.mof and that would impact everyone. I’m looking for reasons like that. Reason 2: They use SCUP for a lot of custom packages, they couldn’t import the SCUP metadata into their primary, it would need to be imported into the CAS which would “touch” all machines not just their QA machines they are limited too. Any other reasons anyone can think of? Thanks
