API Error: ComputerGroup is enabled for a site.

mjhersh
Contributor

I have a script that updates certain policies via the Casper API. These policies are scoped to multiple smart groups in multiple sites.

During testing, where I didn't have multiple sites, everything worked fine. But in production, I get some strange behavior:

  1. The API policy PUT call returns "Error: ComputerGroup (ID:xxx, Name:Blahblahblah) is enabled for a site."
  2. Subsequent GET calls on the policy return updated information, as though the PUT succeeded.
  3. The updated information is NEVER reflected in the JSS.
  4. After some time, API GETs again return the old information, confirming the original failure.

Why is this failing? Why does it matter if a smart group is site-enabled in the first place? Why is the API returning false data?

Any ideas?

I'm hoping someone has seen this before. If not, I'll try to create a simplified, generic script to share that reproduces the problem.

1 ACCEPTED SOLUTION

mjhersh
Contributor

For future Googlers running into this problem, here is the workaround I came up with:

For each site-enabled group you have, create a second smart group that simply targets Computer Group > Member Of > [that other group]. Leave the smart group's site set to None, and use that for scoping policies instead of the original group.

I talked to JAMF Support about this and they were able to reproduce the issue. Hopefully it will be fixed in a future version, but for now, this is the workaround.

View solution in original post

3 REPLIES 3

mjhersh
Contributor

I created a test script that shows the behavior. It works the same on my test and production servers (9.91). This requires a little setup:

  1. A smart group (or static group, I guess) assigned to a site.
  2. A policy NOT assigned to a site, but scoped to the above smart group.

The script is below. Fill in the three strings at the top with your server, API account credentials, and the policy name from step #2.

If the test policy is in the same site as the smart group, the PUT call succeeds. Otherwise I get the error. This doesn't help me because in reality I'm working with policies scoped to multiple smart groups in multiple sites.

#!/usr/bin/python

import subprocess
from xml.etree import ElementTree

# build the base URL
base_url = 'https://your.jss:8443/JSSResource/policies/'
creds = 'TestUser:TestPassword'
policy_name = 'TestPolicy'

# get the policy data
xml = subprocess.check_output(['curl', '-s', '--user', creds, '-X', 'GET', '{base}name/{name}'.format(base=base_url, name=policy_name)])

# parse and edit XML. In this example we'll just disable the policy.
tree = ElementTree.fromstring(xml)
enabled = tree.find('general/enabled')
enabled.text='false'

# get the ID so we can use it in the update URL
pid = tree.findtext('general/id')

# regenerate XML
xml = ElementTree.tostring(tree)

# update policy via API
command = ['curl', '-s', '--user', creds, '-X', 'PUT', '-T', '-', '{base}id/{id}'.format(base=base_url,id=pid)]
shell = subprocess.Popen(command, stdin=subprocess.PIPE, stdout=subprocess.PIPE)
# pipe in the XML
shell.stdin.write(xml)
result = shell.communicate()[0]
shell.stdin.close()

#print the result, which should be the the ID of the policy (in XML form)
print result

mjhersh
Contributor

For future Googlers running into this problem, here is the workaround I came up with:

For each site-enabled group you have, create a second smart group that simply targets Computer Group > Member Of > [that other group]. Leave the smart group's site set to None, and use that for scoping policies instead of the original group.

I talked to JAMF Support about this and they were able to reproduce the issue. Hopefully it will be fixed in a future version, but for now, this is the workaround.

gda
Contributor

Still not fixed. We ran into the same issue.