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 > > > > >
