Profile manager shows only device placeholders

[ass17]

Can anyone shed some light as to why all my devices are still place holders? See below

 

Does it have anything to do with an error in the logs relating to "auth_token doesn't exist" then next line reads "filter chain halted as verify_auth_token rendered or redirected"

[BushPig]

Sorry to bring back an old thread, was just wondering if you ever found the answer to this? We are having similar problems, and have been scratching our heads for days. It now appears to be enrolling iPads but not iMacs

[dr_Wiley]

Having the same issue, does anyone have any ideas?

[BushPig]

We scratched our heads for ages on it, in the end it was ports on the External firewall that needed opening - baffles me why it needs external access for what is our internal network to be honest.

[Carter]

ONly time I've seen this is if I removed a device from PM? When you delete an item it will keep it there as a place holder as seen in your image. I then need to select the device again and remove.

[BOFHxx]

Can anyone shed some light as to why all my devices are still place holders? See below

[ATTACH]27187[/ATTACH]

 

Does it have anything to do with an error in the logs relating to "auth_token doesn't exist" then next line reads "filter chain halted as verify_auth_token rendered or redirected"

 

Was this by any chance working in the past, but this has happened since an upgrade, perhaps when you were running Mavericks on the server?

 

I had this exact problem and it was due to a bug in the OS X Server upgrade. The good news is server keeps a backup of your previous data which you can use to revert then run the upgrade again (or you could revert to a backup).

 

https://support.apple.com/en-gb/HT201063 may be of interest.

[alfatec]

What server version are you running?

When you go to Profile Manager/my devices on the workstation what order are you installing the certificates?

Are the ports open on your external firewall to Apple?

Do you have the server as an exception in your proxy bypass settings (this is the one that got us)?

[dr_Wiley]

Hi all we finally got it working, apparently its caused by

The apple push service first does a DNS TXT query for "push.apple.com" [nslookup -query=txt push.apple.com]. This will return "count=50" or some number XX. The daemon then creates a name using a number between 1..XX and creates DNS name X-courier.push.apple.com. This DNS name then returns an ipaddress in the 17.X netblock that belongs to Apple. The Smoothwall is seeing in the URL request, courier.push.apple.com not for example 34-courier.push.apple.com. After looking at the certificate presented by https://34-courier.push.apple.com , it does not have a wildcard certificate and its certificate says its only valid for "courier.push.apple.com". It looks like Apple have "fudged" the header so when a browser/software reads the request back it see the request was made to courier.push.apple.com, this appears to be to make the certificate they give out be valid.

 

So if you are behind a smoothwall box and have push notification issues you may need to do the following (we applied the proxy.pac to the mac server)

 

You will need to adjust firewall rules and Guardian policies to allow these push notifications to succeed:

 

Firewall Rules:

 

Ports that need to be open for outgoing traffic:

 

TCP + UDP 2196 for all IP's

TCP + UDP 5223 for all IP's

TCP + UDP 49321 to 49335 for all IP's

TCP 443 to 17.0.0.0/8 TCP 80 to 17.0.0.0/8

 

Guardian Policy:

 

Please browse to "Web proxy > Web proxy > Automatic configuration". Add the following domains/IP's to the "Exception domains and IP addresses:" section:

push.apple.com

17.0.0.0/8

You will need to make sure the iPads are set to use the proxy.pac file as the iPad manual proxy settings do not have the capability to exclude domains from being proxied.

 

Create the following policies:

 

Under Guardian > Web filter > Exceptions, destination IP's add:

17.0.0.0/8

Please configure the following:

Browse to Web proxy > Authentication > Exceptions. Add the following categories to Auth exceptions:

SSL/CRL

Software Updates

Authentication Exceptions

iTunes

Save the Authentication exceptions list. Browse to Guardian > Web Filter > Policy Wizard and create a policy with the following conditions:

Who:Everyone

What:Authentication Exceptions, SSL/CRL, Software Updates, itunes

Where:Everywhere

When:Always

Action: Whitelist

Confirm and save this rule.Browse to Guardian > Web Filter > Policies and move the policy you created up the table until it is above any block or blanket block in place for the group Unauthenticated IPs. You may have this group in a policy folder in position 2 in the table by default if you did not have Unauthenticated IPs allowed to use the web proxy prior to migrating. If this is a fresh install please check whether Unauthenticated IPs is included in the aforementioned policy folder.

[HereIGoAgain2601]

The proxy exception caused this problem for us... spent days trying to work it out and turned out to be something so simple.