can you use DNS to point clients to the new box using the old name? that's what we did.

Did you change DNS'ES when you moved servers? or just migrated to a new server with the same settings/db/certs?
- RD

I don't think we did but I am going to have to talk to my sys admin team. We virtualized our new JSS and I don't believe we used DNS to to point machines to the new JSS.

@CasperSally - when you pointed your clients to the new JSS did the clients pick up the new MDM profile?

@rderewianko - we migrated the database and settings to the new server. all our clients are talking to our old but still active JSS, we are just looking for the best method to flip them to the new JSS.

The few test machines that we tried were able to be easily flipped over, but as I mentioned, they still held the old MDM profile with the old JSS server info, even though they were now communicating with the new JSS. We think that could cause problems in the future because its not using the right apple push cert.

Sorry, we did the move before the hell that is MDM/certs. Lucky us, I guess.

@thanzig assuming you're not using the mobile part of casper, your best work flow would be.

Create a new MDM/Push Cert.
Create a new quickadd (through recon pointed to the new server)
Deploy it to all clients on any checkin (besides network change, as that'll give you too many false positives)
Let all clients connect to new.. When we did this, we had our old server named casper01.domain.com with our new as casper.domain.com. Took us about a month to migrate everyone.

@rderewianko

That is exactly what we did. We created a new MDM/Push cert for our new JSS. Then I created a QuickAdd package using Recon (using the new JSS URL) and added the package to a policy on our old JSS. We scoped it to a few test machines. It did work, those clients executed the policy and were showing up in the new JSS but............ when we went to "system preferences - profiles" - the MDM profile was the one for the old JSS. It did not pick up the new one. It's almost like its not a 100% clean enroll. We are assuming everything will be ok as long as we renew the Push cert on the old JSS every year and keep the server up, but none of us are comfortable with that. We want all the clients to have the new MDM/Push Cert.

The only way we have gotten around this is by unenrolling and re-enrolling. We can do this is batches without inconveniencing our users, but I would like to know if this is the only way.

@thanzig makes me think more that the new server doesn't have all the FW ports open for APN's.

If it's a linux box you can try:
nc -z gateway.sandbox.push.apple.com 2195
nc -z gateway.sandbox.push.apple.com 2196
nc -z 35-courier.push.apple.com 5223
nc -z albert.apple.com 443

Should report back: with succeeded.

I have written a wrapper that essentially has the QuickAdd package in it. the wrapper, does a jamf removeFramework, cleans up any other stuff that I need cleaned up while not connected to the JSS, remove manually installed policies etc, and then it runs the new QuickAdd package. The Wrapper package launches the re-enroll script from a launch daemon so that the old jss sees the job as completed and does not hang anything up with an orphaned jamf process or anything too.

@nessts Can you share that wrapper?

I took a class with Todd Ness @nessts. This man knows his stuff.

it uses so much proprietary stuff its not going to help you much. has function calls to stuff you wont ever see. The script can be a simple bash script though called from a LaunchDaemon

#!/bin/sh
/usr/sbin/jamf removeFramework
#anyother things you want to do
installer -target / -pkg /path/to/where/you/put/QuickAdd.pkg
defaults write /Library/LaunchDaemons/com.yourcompany.reenroll.plist Disabled -bool yes

launch daemon would be something like this

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Disabled</key> <true/> <key>Label</key> <string>com.yourcompany.reenroll</string> <key>ProgramArguments</key> <array> <string>/path/to/the/script/above.sh</string> </array> <key>RunAtLoad</key> <true/> <key>UserName</key> <string>root</string> </dict> </plist>

or just remove the launch daemon, quick add package and the script at the end of execution, , I leave it there in case i need to rebind a computer later.

Adapting CasperCheck may be a way to go:

https://github.com/rtrouton/CasperCheck

My personal preference is to use a cname for the main JSS address and to change the record to the new JSS once it's tested and ready.

If you're switching to a JSS that is a restore of the previous MySQL db backup, this should be fine.

If it's a JSS with new APNS and certs then I would use the removeFramework option, but leave a launch daemon on the macs with a QuickAdd package so they re-enroll when they are restarted.

I am in the midst of doing this now. I didn't add the remove framework but I did use:

jamf removeMdmProfile

I have that in a script that runs before the QuickAdd. Seems to work for removing MDM.

@jubei - I didn't even think of this. This would be perfect as it will preserve all the profiles on the client machines. Did you just create a policy that had the script and the package or did you do something custom? Did you create the QuickAdd package with Recon?

Yes it's all one policy. The script has that one MDM line and runs before the quickadd. QuickAdd was created via Recon yes.

I wonder if remove framework is a good step though. I've confirmed that all profiles are removed by the remove MDM script.

removeMdmProfile takes away all the profiles? This is what I'm trying to avoid. I just want it to replace the MDM profile associated with the old JSS and enroll it with QuickAdd to get the MDM profile of the new JSS. I will test it though.

@davidacland

When we migrated the database from the old JSS to the new, would it have been possible to transfer the Apple Push cert as well. That would solve all of this.

I could be wrong but you'll need to re-enroll the Mac since you changed the push cert. I would set it as a policy that only ran when the user is hard wired (that way if you have a config profile that sets wifi they won't lose it).

Before quickadd
JAMF remove mdm

After quick add (as a catch all)
JAMF mdm

That will re-enroll MDM. If you're not pointing to a different DNS name and you say you've kept your DB, then you wouldnt need a quick add, would you? You will need to re enroll MDM though since you have a new push cert. You can just throw these two commands in a script to re enroll in MDM but not re enroll in the JSS (if that makes any sense)

I think we have to un-enroll and re-enroll since there is a whole new Push Cert involved on the new JSS. We are pointing to a new DNS. We only have 80 clients so its not the end of the world if we have to touch re-enroll each one. We can stage it and make it easy.

If we had more clients we would take a different approach but I think we'll survive this.

If the JSS name was staying the same you would be able to re-download the push very from the Apple portal.

I normally have different A records per server but an over-arching CName record for the service itself that can be pointed to the primary server.

If the JSS address is changing then an unenroll and re-enroll is needed unfortunately.

There actually is a really easy way to redirect clients to a new JSS.

#!/bin/sh

sudo jamf createconf -url "https://yourjss/"

Then the clients will start looking at your new jss.

wow @GaToRAiD I have to try that out! Will that bring down new MDM profiles? I switched to a new host all together (no DB move).

@jubei from my testing it uses the same MDM profile just makes it trust the new one.

@GaToRAiD - Will that replace the MDM profile of the old JSS with the new JSS on a clients machine? I can get a client to point to a new JSS url, but its replacing the MDM push cert that I can only seem to update with a un-enroll and re-enroll.