Two words: Global Data Everything they create in that child primary site in the following categories will now be a part of your production hierarchy:
· Alert rules · Client discovery · Collections rules and count · Configuration Items metadata · Deployments · Operating system images (boot images and driver packages) · Package metadata · Program metadata · Site control file · Site security objects (security roles and security scopes) · Software updates metadata · System Resource List (site system servers) Reference: Technical Reference for Site Communications in Configuration Manager<http://technet.microsoft.com/en-us/library/gg712990.aspx> They are not in Kansas anymore! (By Kansas, I mean ConfigMgr 2007 and earlier). That primary site provides no kind of “security” boundary anymore. Bruce Hethcote | Technical Training Team From: [email protected] [mailto:[email protected]] On Behalf Of elsalvoz Sent: Thursday, November 13, 2014 9:07 AM To: [email protected] 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" <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[email protected]>> Sent: November 13, 2014 7:58 AM To: [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 ________________________________ Legal Notice: This email is intended only for the person(s) to whom it is addressed. If you are not an intended recipient and have received this message in error, please notify the sender immediately by replying to this email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any attachments may be privileged and/or confidential. The unauthorized use, disclosure, copying or printing of any information it contains is strictly prohibited. The opinions expressed in this email are those of the author and do not necessarily represent the views of 1E Ltd. Nothing in this email will operate to bind 1E to any order or other contract.
