Dev/Testing JSS

New Contributor III

Good Evening All.
JAMF have kindly given me an activation code for a Dev/Testing JSS.
My plan is to build a replica JSS and use this to test updates to JSS and server OS etc. So that it's as much like the production server I'd like to import the current production database.

My thinking is as the Dev JSS has a different name and IP address, so the current clients shouldn't talk to it?

Is there anything I'm missing as this seems alittle too straight forward to me ;)


Contributor II

Hey @notverypc

This is exactly what I did. Had a mirror image of the production JSS as my test JSS.

Don't worry your computers and mobile devices will continue to only speak with the prod JSS, just make sure you change the URL in the test JSS

There are a few things to keep in mind from my experience. - If going from linux to linux I had some issues with the restoring the prod JSS DB to the test JSS DB using the JSS DB Utility and ended up just restoring the DB using mySQL tools, pretty easy to find with a quick google. - Can't quite remember if you have to or not but just incase I recommend grabbing a new push certificate - Obviously change the URL - If using VPP I would recommend removing the VPP token from your test JSS and applying for a second one from apple if you need it for testing purposes. It did work for a while having the token in both however the issues that it caused me in the long run were not worth it. - Make sure you build the test JSS as the same version as prod.

I have probably forgotten something but just ask and I'll try and help.


Contributor II

I've done this in the past. It does help as you can have lots of data if your testing DB backups and things of that nature.

Couple of things off the top of the head. Remove your VPP and/or DEP accounts. Things can go sideways when you've got one account across different servers. Make sure your DPs are changed so you don't delete or reconfigure production packages or configurations. Create a new push certificate for your dev environment.

There is probably a knowledge base that covers this but these are the things I can think of we've done.

New Contributor III

Thanks @PatrickD and @Brad_G good to know I'm on the right track.

Contributor III

What I did was create a DEV and TST environments. For the DEV one I exported the database from the PRD and used it for the DEV. We develope new policies out here and make sure things work before moving them to PRD. Our TST environment is used to test the next version of JAMF and ensure it would work well in our environment.

For our naming convention, it was as simple as adding the letter DEV or TST to it (i.e