- TCP port 5223 (used by devices to communicate to the APNs servers)
- TCP port 2195 (used to send notifications to the APNs)
- TCP port 2196 (used by the APNs feedback service)
- TCP Port 443 (used as a fallback on Wi-fi only, when devices are unable to communicate to APNs on port 5223)
Showing posts with label Jamf. Show all posts
Showing posts with label Jamf. Show all posts
Wednesday, March 11, 2015
Ports required for Apple Push Notification Service
We encountered a problem where Macs managed by Casper were unable to communicate with the JSS for Mobile Device Management (MDM). The solution was to allow the following ports access to Apple's 17.0.0.0/8 range (complete owned by Apple):
Wednesday, September 17, 2014
Device Signature Error when attempting to install packages through Casper
When attempting to install printers (and other packages) some Macs (10.9.x) would report an error "Device Signature Error-A valid device signature is required to perform the action." The helpful folks at JAMF Nation provided the following fix:
In ARD push out the following commands:
launchctl stop com.apple.apsd
rm /Library/Keychains/apsd.keychain
launchctl start com.apple.apsd
After the commands have been applied, Recon the machine again. You should now be able to install packages.
In ARD push out the following commands:
launchctl stop com.apple.apsd
rm /Library/Keychains/apsd.keychain
launchctl start com.apple.apsd
After the commands have been applied, Recon the machine again. You should now be able to install packages.
Monday, October 14, 2013
Macs Unable to Connect to Secure Sites: OCSPD File Deleted
We received a report that 400+ Macs in two countries and a dozen locations were suddenly unable to login. A quick fix was to remove the network cable, log in using the locally cached credentials and then plug the Ethernet cable back in. However, the users were then unable to connect to any web-page using https, Outlook mail (using OWA) or any other connection that required secure communication.
All the Macs were bound to AD and being managed by Casper.
We soon found that by removing the JAMF binary we were able to log in but we still could not access any secure resources. This made sense because at login/start-up the computer attempts to talk to the JSS and if secure communication is not possible the computer will hang.
Working with Apple Alliance Support (excellent as always) we were able to determine that the root of the problem lay in the fact that all the computers were missing the ocspd file from /usr/sbin/. The ocspd file is used during certificate validation and if it is missing or corrupt a secure connection can not be established.
Using Composer we created packages to deploy new ocspd files. Note: you must install like-for like, i.e. a good ocspd file from a 10.7.5 Mac must be deployed to another 10.7.5 Mac.
Unfortunately within a few minutes of deploying a new ocspd file, it was deleted. After more digging through logs we found that it was a JAMF process that was causing the deletion so we removed the JAMF binary from all the Macs, pushed the good ocspd packages using ARD and it resolved the issue.
After the good ocspd packages are deployed, remove all the old computers from the JSS, ensure that a valid push-notification certificate is installed and that "enable certificate-based communication" is ticked in the framework settings of the JSS. You should then be able to re-Recon all your Macs and the ocspd file will not be removed. TEST FIRST on a few Macs!
If you suspect this issue the first thing to do is go to /usr/sbin and see if the ocspd file is missing. If it is you must replace it with a known good ocspd file. As described above, the easiest way to do this is with Casper Composer but if you do not have a copy of it you can do the following steps and deploy using ARD.
sudo chmod 755 /usr/sbin/ocspd
All the Macs were bound to AD and being managed by Casper.
We soon found that by removing the JAMF binary we were able to log in but we still could not access any secure resources. This made sense because at login/start-up the computer attempts to talk to the JSS and if secure communication is not possible the computer will hang.
Working with Apple Alliance Support (excellent as always) we were able to determine that the root of the problem lay in the fact that all the computers were missing the ocspd file from /usr/sbin/. The ocspd file is used during certificate validation and if it is missing or corrupt a secure connection can not be established.
Using Composer we created packages to deploy new ocspd files. Note: you must install like-for like, i.e. a good ocspd file from a 10.7.5 Mac must be deployed to another 10.7.5 Mac.
Unfortunately within a few minutes of deploying a new ocspd file, it was deleted. After more digging through logs we found that it was a JAMF process that was causing the deletion so we removed the JAMF binary from all the Macs, pushed the good ocspd packages using ARD and it resolved the issue.
After the good ocspd packages are deployed, remove all the old computers from the JSS, ensure that a valid push-notification certificate is installed and that "enable certificate-based communication" is ticked in the framework settings of the JSS. You should then be able to re-Recon all your Macs and the ocspd file will not be removed. TEST FIRST on a few Macs!
If you suspect this issue the first thing to do is go to /usr/sbin and see if the ocspd file is missing. If it is you must replace it with a known good ocspd file. As described above, the easiest way to do this is with Casper Composer but if you do not have a copy of it you can do the following steps and deploy using ARD.
- Copy a good ocspd file to /usr/sbin/ to the non-working system
- Set ownership and permissions:
sudo chmod 755 /usr/sbin/ocspd
- Once the file has been copied and permissions applied the issue should be resolved- no reboot is required
Wednesday, November 7, 2012
Recon failed during the submit process. Could not recognize the JSS response
After upgrading to JSS 8.6 a site noticed that none of the Jamf binaries on the clients were being updated.
When we attempted to Recon the Macs again the process would fail with a message "Error enrolling computer. Could not recognize the JSS response."
We would receive the same error no matter what method we used to get the computer into inventory: local Recon, Quick-Add Package, command line enrolment, etc.
From the screen-shot it would seem that the problem had to do with the client or server's certificate. However, after renewing the JSS' certificate, double-checking that it was valid and that existing clients could communicate with the JSS we were at a loss to explain why Recon was failing.
The answer was both simple and completely crazy. It seems that if there is a non-standard character in the "Display message to User:" field in Restricted Software it causes Recon to fail with the above mentioned error.
The text of the original message: Este software no está permitido en la red corporativo
After changing "está" to "esta" we were able to Recon computers normally.
How bizarre is that?
A big thanks to Derek at Jamf support for figuring out the problem. We would have spent years hunting for a fix on our own.
When we attempted to Recon the Macs again the process would fail with a message "Error enrolling computer. Could not recognize the JSS response."
We would receive the same error no matter what method we used to get the computer into inventory: local Recon, Quick-Add Package, command line enrolment, etc.
From the screen-shot it would seem that the problem had to do with the client or server's certificate. However, after renewing the JSS' certificate, double-checking that it was valid and that existing clients could communicate with the JSS we were at a loss to explain why Recon was failing.
The answer was both simple and completely crazy. It seems that if there is a non-standard character in the "Display message to User:" field in Restricted Software it causes Recon to fail with the above mentioned error.
The text of the original message: Este software no está permitido en la red corporativo
After changing "está" to "esta" we were able to Recon computers normally.
How bizarre is that?
A big thanks to Derek at Jamf support for figuring out the problem. We would have spent years hunting for a fix on our own.
Thursday, March 29, 2012
Deploying McAfee ePO agent using Casper
Jamf has an excellent KB article on how to deploy the McAfee ePO agent.
https://jamfnation.jamfsoftware.com/article.html?id=182
However, if you have already installed the unmanaged client you will need to remove the agent before reinstalling.
1) Uninstall the existing (stand-alone) agent using Casper Remote by running the following command:
/Library/McAfee/cma/uninstall.sh
2) Install the agent using Casper Remote and the following command:
/Library/Application\ Support/McAfee/install.sh -i
If you do not first uninstall the agent you will receive the following error:
"An higher or same version of the agent is already installed installer: Error - The installed version of the agent is already greater than or equal to this version. Installation cannot continue"
https://jamfnation.jamfsoftware.com/article.html?id=182
However, if you have already installed the unmanaged client you will need to remove the agent before reinstalling.
1) Uninstall the existing (stand-alone) agent using Casper Remote by running the following command:
/Library/McAfee/cma/uninstall.sh
2) Install the agent using Casper Remote and the following command:
/Library/Application\ Support/McAfee/install.sh -i
If you do not first uninstall the agent you will receive the following error:
"An higher or same version of the agent is already installed installer: Error - The installed version of the agent is already greater than or equal to this version. Installation cannot continue"
Subscribe to:
Posts (Atom)