Steps to create JSS test environment

If you are importing your JSS into a VM, you should be able to isolate your VM from the network long enough to change the DNS and IP address so that clients aren't confused. Another thing that you will need to consider, is that the JSS instance that you are testing with, was installed on a specific DNS name. In order to utilize a different FQDN, you're going to need to actually reinstall the JSS.

My suggestion would be to create a VM of your server and install a clean copy of 9.x JSS on it and use an export of your existing database to import into your VM. This will allow you to have all of your existing information in your 9.x JSS, even though your clients won't be reporting to it. From that point, you can change policies, enroll computers, etc.. Which should give you a good idea of what you're getting into.

I'm currently in the process of setting up a blank server OS with a new install of JSS 9.x and I will be attempting a couple of sneaky things that I want to be able to do with the JSS on it. I won't have a FQDN since I don't need to test outside of my LAN, but this is the path that I would recommend.

Hope this helps.

We've always had three JSS enviroments:

Dev > Test > Prod

Dev = latest and greatest version of JSS
Test = Matches Prod environment, for vetting
Prod = The live environment

I wonder if there's a feature request for making it easy(ier) to manage having multiple environments in place? Including rsyncing DP's between environments (Prod > Test and Prod > Dev), not the same as replication within a single environment.

My suggestion would be to create a VM of your server and install a clean copy of 9.x JSS on it and use an export of your existing database to import into your VM. This will allow you to have all of your existing information in your 9.x JSS, even though your clients won't be reporting to it. From that point, you can change policies, enroll computers, etc.. Which should give you a good idea of what you're getting into. @Joseph.Morris

OK, this makes sense... but I have a stupid question... how do you prevent the clients from reporting to both prod and non-prod?

@Bhughes just because you restored your production data base to your test environment doesn't mean the devices will check in there. You will want your test environment to have a different URL than your production environment. Since the JSS URL is different the clients will check into your production and not your test unless you specifically enroll a client into your test environment. Hopefully my explanation makes sense.

@mpermann thanks, good to know. We were very weary when setting up our non-prod, to the extent that we removed the scopes to all our config profiles, etc... which, in essence, made it worthless.

@Bhughes I personally haven't loaded our production database into our test environment. I simply have a small number of test machines to test some of the functionality. Probably not the best test environment to be honest, but as long as I can test the major things we use with a few systems them I'm relatively happy.