locked
Taking over a Standalone Primary server from another Domain RRS feed

  • Question

  • Current Situation:

     

    Using SCCM 2012 R2 CU3

     

    Two domain in the one Forest, Test Domain and Production Domain.  SCCM 2012 R2 supports multiple domain environment, but for political reasons  I was unable to implement this at the time.  I was forced to implement two separate SCCM environments.

     

    SCCM Standalone primary site is installed and configured to publishing in the Test domain.

     

    Another SCCM standalone Primary site is installed and configured to publish to the production domain.

     

    All of the development work for the solution have been carried out in the Test SCCM environment. Now that we are nearing time to move to production the customer is finally accepting the extra effort to export and import applications and task sequences for OS builds is a constraint and will also impact ongoing operations. They are now looking at ways to speed up the OS build and application lifecycle, from test to production, so managing all with the one SCCM infrastructure in back on the table.

     

    Question:

     

    Since SCCM 2012 SP1 you have the ability to add a standalone primary site to a hierarchy. So I am investigation installing a CAS server in the Production domain to parent the Test Domain SCCM primary server.

     

    Does the fact that the SCCM Test environment is in another domain to the new CAS server raise any issues / problems?

     

    I appreciate any info / light you can shed on the matter.

     

    Paul.

    Thursday, January 22, 2015 1:10 PM

Answers

  • That will not work, because during the installation of the CAS you can expand only one primary site into the CAS. Also, when the goal is to take one environment away, I wouldn't use a CAS to combine those environments. I would migrate the content of the "test" environment to the production environment and than break down the test environment.

    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Thursday, January 22, 2015 1:18 PM
  • Hi,

    I agree with Peter and to add to his points as all configuration data like, OSD, Packages, Applications etc are global data and replicated to all Primaries and CAS it doesn't make any sense at all to have one CAS and two primaries. It was different in SCCM 2007 where primary sites only reported up to the Central site and the only package, osd e.t.c created at the central site was replicated to all Primaries. But in ConfigMgr 2012 that has changed with the new RBAC model.

    Regards,
    Jörgen


    -- My System Center blog ccmexec.com -- Twitter @ccmexec

    Thursday, January 22, 2015 1:49 PM
  • Sounds like a bad idea to me. Your "production" SCCM server(s) will then always be in your "test" domain, which by definition never receives the same amount of respect. You must migrate. Also, bear in mind that it is not supported to just change the domain membership of an SCCM Site System.

    Also #2, avoid a CAS.



    Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson

    Thursday, January 22, 2015 1:53 PM
  • First, as mentioned, I would *never* use a CAS unless I technically needed one (as mentioned multiple times above).

    As for using the production site for testing, sure. I see no issue with testing an application using the production site as simply adding an application has no impact on the site itself, what changes are the clients thus you need to make sure you are only test clients -- RBA is sufficient for this in most cases.

    Test environments and labs can also be very useful for isolated testing or testing things that actually change the site like upgrades.

    Either is technically valid though. It really depends upon your organization's stance. Also remember that maintaining a lab is an additional time sink particularly if your desire is to keep the configurations in sync.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Marked as answer by Garth JonesMVP Saturday, January 31, 2015 6:35 PM
    Friday, January 23, 2015 7:53 PM

All replies

  • That will not work, because during the installation of the CAS you can expand only one primary site into the CAS. Also, when the goal is to take one environment away, I wouldn't use a CAS to combine those environments. I would migrate the content of the "test" environment to the production environment and than break down the test environment.

    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Thursday, January 22, 2015 1:18 PM
  • Hi,

    I agree with Peter and to add to his points as all configuration data like, OSD, Packages, Applications etc are global data and replicated to all Primaries and CAS it doesn't make any sense at all to have one CAS and two primaries. It was different in SCCM 2007 where primary sites only reported up to the Central site and the only package, osd e.t.c created at the central site was replicated to all Primaries. But in ConfigMgr 2012 that has changed with the new RBAC model.

    Regards,
    Jörgen


    -- My System Center blog ccmexec.com -- Twitter @ccmexec

    Thursday, January 22, 2015 1:49 PM
  • Sounds like a bad idea to me. Your "production" SCCM server(s) will then always be in your "test" domain, which by definition never receives the same amount of respect. You must migrate. Also, bear in mind that it is not supported to just change the domain membership of an SCCM Site System.

    Also #2, avoid a CAS.



    Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson

    Thursday, January 22, 2015 1:53 PM
  • I would be curious to know what the responders to this thread would normally recommend to customers in terms of a test environment for creating apps, patches and particularly OSD components so they can be tested without risk prior to creation\importing into the production CAS or Primary?

    Would you do everything in the production CAS\Primary and use process or RBAC to reduce risk? So no separate test environment?

    Friday, January 23, 2015 4:18 PM
  • First, as mentioned, I would *never* use a CAS unless I technically needed one (as mentioned multiple times above).

    As for using the production site for testing, sure. I see no issue with testing an application using the production site as simply adding an application has no impact on the site itself, what changes are the clients thus you need to make sure you are only test clients -- RBA is sufficient for this in most cases.

    Test environments and labs can also be very useful for isolated testing or testing things that actually change the site like upgrades.

    Either is technically valid though. It really depends upon your organization's stance. Also remember that maintaining a lab is an additional time sink particularly if your desire is to keep the configurations in sync.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Marked as answer by Garth JonesMVP Saturday, January 31, 2015 6:35 PM
    Friday, January 23, 2015 7:53 PM