App Portal Clone Prod to create Dev Environment

[joan_mckinley]

We would like to clone our production App Portal to create a development environment.  The virtual server would be clone and the databases would be backed up and restored on a different SQL Server.

We realize we have to change the admin settings to point to the new DB server.

Has anyone done that?  Do you think it will work?

Thanks!

Joan

[ChrisG]

I can't speak to whether this has been done, but one question which comes to mind is how the clone in the development environment would related to the SCCM (or other) system used for package deployment. I can imagine it might be dangerous to simply clone production settings into a development environment, and subsequently have the development environment hooked up to make changes in a production SCCM system.

[joan_mckinley]

Hi Chris,

Thanks for the response.  We have a development server that we can point to for FNMS but we would want to point to our production SCCM server.  We are trying to understand what the risks are.  If we delete a catalog item in the Dev App Portal, will it delete the deployment in SCCM?  We are going to test this when the DB is restored.

We could create a new DB for our Dev environment but we would still want to point to our production SCCM server.  

Can you help us see what the risks are?

[jdempsey · Accepted solution]

I've recently helped a customer through a process like this (though we didn't clone the app server).  The high-level steps are as follows:

1. Back up the production database and restore to the development SQL Server (potentially with a different DB name, like AppBrokerDEV vs AppBrokerPROD - this just helps keep them visually distinct)
2. Run SQL query on AppBrokerDEV to update [WD_SiteToAdvert].[CreatedByAP] = 0 to remove "ownership" of the existing SCCM collections and deployments.  (NOTE: This will prevent App Broker DEV from removing the production collections/deployments if you archive any of the catalog items on the DEV server or modify their deployment settings.)
3. Prepare development web server with all necessary prereqs (IIS, .NET, etc.)
4. Run App Broker setup on development web server, pointing to the restored database (AppBrokerDEV)
5. Archive one catalog item on the DEV App Broker server and verify that the associated collections/deployments aren't removed from SCCM (verify by requesting that catalog item in production)

While this process will work, I always recommend having a separate DEV SCCM environment.  When sharing an SCCM system between DEV and PROD, you have to take extra precautions to ensure you aren't negatively impacting the other environment.  Any new catalog items created in the DEV environment should be named in such a way to distinguish them from production catalog items (e.g. "[DEV] Adobe Acrobat DC" instead of just "Adobe Acrobat DC").  This will ensure you don't end up with naming conflicts in SCCM when the collections and deployments are created (and will also make it easier to identify the DEV versus PROD deployment objects when looking in the SCCM console).  Additionally, if you end up deleting/re-creating the deployments on any of the cloned catalog items (on the DEV server), you should rename that catalog item with the [DEV] tag first.  That way, when it creates new SCCM deployment objects in SCCM, it will create them with the [DEV] tag in the name.  Finally, keep in mind that there is no easy way to keep the catalog items in sync between DEV and PROD after the cloning operation.  Changes you make to production catalog items, such as archiving them or re-creating deployments, can cause the cloned catalog items in the DEV environment to stop working.  Likewise, changes you make in the DEV environment (new catalog items, archived catalog items, modified catalog items) will not be reflected in the PROD environment.

Hope that helps.