Migrate Policies and Profiles

[bcldonnelly]

Hello,
We may be a bit different, but we have spun up a completely separate JSS instance for QA that we test in prior to moving things to production. We're paranoid that way. Does anyone know of any method to export/copy/replicate/duplicate Policies, Profiles, and other settings between separate sites?

Our goal is to have a fully functional JSS instance that we can play in and test things from JSS upgrades, to new policies prior to making them available in our PROD environment, and I haven't found any method other than manually creating each item.

Thanks!

b

[mm2270]

There's nothing built in to do this, but you can look at playing with the API. The JSS REST API will let you get all the details on a given policy and may allow you to recreate the same policy settings on your production box also using the API. Its possible to create policies with it, but its not the easiest thing to do, at least as far as the API is concerned anyway.

I haven't tried this, but I may experiment. Its possible doing a curl -X GET to pull down the entire policy from Dev and saving into a local xml file, then doing some cleanup on it, and reimporting it to your Prod using curl -X POST using that xml will do it.

[chriscollins]

Yep as @mm2270 uou can do this with the API but you have to do a lot of cleanup primarily because in policies things like packages or scripts are referenced as being in a policy by their internal ID number in the database which will be different in different databases. Unless you just restored from a copy of your prod database to your dev and didn't add any new packages you were trying to use in the policy to be migrated over, etc.

[mm2270]

I just experimented with this and it works great!

What I did was pull down the xml of the policy first. General syntax:

curl -H "Accept: text/xml" -sfku apiusername:apipassword https://your.devjss.address.com:8443/JSSResource/policies/id/<id_number> | xmllint --format - > /tmp/<id_number>.xml

In the above, replace all elements with real ones, like apiusername with an API read and/or write account that can pull data on policies.
apipassword would be the corresponding password for that account.

Replace https://your.devjss.address.com:8443 with your DEV JSS address.

Finally, replace <id_number> with the JSS ID for the policy you want to duplicate.

Next, open the xml file in a text editor like TextWrangler or something that can handle and show xml formatting and won't mangle it (that means avoid TextEdit if you can)

Edit the following items:
At the top of the file where it shows

<policy>
  <general>
    <id>policyidnumber</id>

Change the policyidnumber between the <id> tags to 0. I'm not 100% certain this is necessary, but I did it to be sure it wasn't going to try creating a policy with the same ID number, which could end up being used already in your PROD JSS.

Directly under that section is the tag for the name of the policy. In my case I renamed it so it would show up under a name I could search easily for, but if you're OK with leaving the name as is, no need to touch that.

You may want to look through it and see if you need to edit anything else. I didn't since I wanted to see if I recreate/dupe a policy that looked nearly identical. But that's up to you and what you want to do.

Now, create a new policy using the following syntax:

curl -ku apiuser:apipassword https://your.prodjss.address.com:8443/JSSResource/policies/id/0 -X POST -T /tmp/<id_number>.xml

As before, replace all relevant pieces with real info, including of course, your production JSS address.

The -T part of the command points to the xml file that was exported and then edited above. Using id 0 tells the JSS to create a new policy and use that xml file as the template. In the above, I left out a few curl flags because I wanted to know about any possible errors. so no -s (silent output) or -f (silent fail, return err 22) in the above.

After I did this, our policy count went up by one on a refresh in the JSS, and searching for the policy by part of its unique name pulled it right up. It was enabled and had all the same settings as the original. This policy used a custom event trigger and a script with a parameter assigned to $4. and it all carried over.

All this said, there is one area that likely won't work well, which is with the computer scope. Since its unlikely your DEV and PROD environments will have identical computers and IDs, any scope assignment may get wiped out, or even give you incorrect scope. I'm not certain about all that, but its definitely possible. If you look at the xml from your DEV policy, look at the scope section and you'll see there are JSS IDs included in it so it knows exactly which groups or Macs its assigned to. Since the IDs between the 2 environments may not match up perfectly, its just something to keep in mind. You may want to remove all scope from the DEV policy after all testing is done before cloning it over.

Hope that helps. I would say this is the way to go with cloning them, but with the caveat from above about scope maybe causing some problems to keep in mind.

[mm2270]

Ah, and yes, @chriscollins makes a very good point about packages, scripts and other elements all being in the policy by their respective JSS IDs. I was only thinking computers and computer groups, but he's correct. Everything else will end up needing to be cleaned up as well. Hmm. given that, it may just be better to duplicate it manually. Still, I would explore the API since it can make quick work of setting up the basic stuff.

[bcldonnelly]

THAT is AWESOME!!!! I will give that a shot and report! you're awesome!
b

[KSchroeder]

Very nice, thanks to all for their input. The big one I'm worried about is Configuration Profiles, some of which have quite a few options configured and/or will require a lot of copy/paste to recreate (such as AD certificate requests, etc), and hence involve more opportunity to miss something in the re-creation of the setup. The scopes are easy enough to re-create I think, and as noted we won't have the same computers in DEV and PROD. Scrubbing the scopes and packages shouldn't be too bad. Brian is going to try it out.

[gachowski]

How about backup and restore?

C

[mm2270]

For Configuration Profiles, you can download them directly from your DEV JSS and then re-upload them into PROD. I'm not sure if there are issues with that process, but I would look at doing that first, before trying to clone those through the API.
For policies, you kind of have no choice, since there is no download button for a policy.

[Josh_Smith]

There is an existing project that you might want to take a look at that is using an approach similar to what @mm2270 describes: https://github.com/igeekjsc/JSSAPIScripts

The author presented at JNUC last year: https://www.jamfsoftware.com/resources/make-your-jss-feel-new-again-with-the-help-of-api/

With a little tweaking you could likely get this up and running in your environment pretty quickly.

[Josh_Smith]

Should have included this list of available options in the script at https://github.com/igeekjsc/JSSAPIScripts. Very cool stuff!

************ MAIN MENU ************
Which JSS resource would you like to migrate?
(WARNING - We strongly encourage you to proceed in order)
     1 = Sites
     2 = Categories
     3 = LDAP Servers
     4 = Accounts (JSS Admin Accounts and Groups)
     5 = Buildings
     6 = Departments
     7 = Extension Attributes (for computers)
     8 = Directory Bindings
     9 = Dock Items
    10 = Removable MAC Addresses
    11 = Printers
    12 = Licensed Software
    13 = Scripts
    14 = Netboot Servers
    15 = Distribution Points
    16 = SUS Servers
    17 = Network Segments
    18 = Computer Groups
    19 = OS X Configuration Profiles
    20 = Restricted Software
    21 = Packages
    22 = Policies
    23 = Advanced Computer Searches
    24 = Advanced Mobile Device Searches

    99 = Upload XML files from a specified directory to a specified resource
         (Useful if you have hand-edited XML files you need to upload)

    ? = README

     0 = EXIT

[mm2270]

Ah, nice! I didn't know about that project. That certainly seems like it would fit the bill!