$$$ 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> 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> 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> >> Sent: November 13, 2014 7:58 AM >> To: 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> 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 >> >> >> >> >> > >
