Changing the JSS address

[franton]

Hi,

So the big start of our massive JSS infrastructure upgrade is starting this week. One small detail to sort out and that's how to change the address that our clients are looking for the JSS.

We're going to have our new address and our existing address co-exist on the DNS pointing to the same server. I'll change the JSS address in our existing 8.62 server. Do I have to do any more work than that? I vaguely recall that Jared wrote a script attached to a policy to set this on the clients and I don't know if that would be required or not.

[Dtwerdohlib · Accepted solution]

When we changed the url for our JSS we had a policy that changed the address stored in the file at /Library/Preferences/com.jamfsotware.jamf.plist on all our clients.

defaults write /Library/Preferences/com.jamfsoftware.jamf jss_url https://nameofserver:8443/

Since you are using 2 addresses to point to one server you probably don't have to do this, but it's all a matter of preference I guess.

[donmontalvo · Accepted solution]

No FQDN? When we migrated from Xserve to Windows Server VM, we kept the old JSS up with a single policy...point computers to the new JSS. :)

[Dtwerdohlib · Accepted solution]

When we changed the url for our JSS we had a policy that changed the address stored in the file at /Library/Preferences/com.jamfsotware.jamf.plist on all our clients.

defaults write /Library/Preferences/com.jamfsoftware.jamf jss_url https://nameofserver:8443/

Since you are using 2 addresses to point to one server you probably don't have to do this, but it's all a matter of preference I guess.

[donmontalvo · Accepted solution]

No FQDN? When we migrated from Xserve to Windows Server VM, we kept the old JSS up with a single policy...point computers to the new JSS. :)

[franton]

I guess those the answers I was looking for. FQDN is planned Don ;) I wanted to sort out the last specific question I had before we proceed.

[jarednichols]

It is all a matter of preference. I used a DNS alias to redirect clients from old to new. I ensured that the new server had a proper certificate with the old server's FQDN as a SAN. Activate the redirect, let systems hit the new server, the first policy they hit changes the JSS URL in the plist.

The reason I went this way was to ensure that systems were able to check in to the new infrastructure before changing their URL. It seemed safer as there was an easy out: just stop the DNS redirect and let systems hit the old server again. With re-writing the JSS URL from the old server to direct to the new server, if something goes wrong you may be down to a visit down to the system as it may end up effectively unmanaged.

[franton]

I "stole" your jamf command from another thread, packaged that into a self service policy and tested it on my two test computers. Once that was ironed out, I created two smart groups: one had the old server name and the other had the new name. Made sure that Networks had put the proper entries in DNS so both addresses resolve to the same server (internally).

Tested the self service policy, debugged it, tested again, deployed to test group, confirmed working, now everyone is getting it ;)

[jarednichols · Accepted solution]

Hey no attribution. Plausible deniability ;)

[franton]

It's working nicely. Take the credit and run! :D

[pew]

I changed the URL being used for a customer this morning and found this thread helpful. Also, the following k-base article was useful for the testing process:

Verifying a Computer's Connection to the JSS: https://jamfnation.jamfsoftware.com/article.html?id=123

In particular:

/usr/sbin/jamf checkJSSConnection