removeFramework on JSS

Our JSS is running the client binary for another JSS.  If I execute
/usr/sbin/jamf removeFramework will it remove any server components?
I'm referring to the article
http://jamfsoftware.com/kb/article.php?id=038 listing installed
components I'm not sure whether to proceed. Any ideas? Thanks.

Privileged/Confidential Information may be contained in this message. If
you are not the addressee indicated in this message, you should destroy
this message. For more information on WPP's business ethical standards
and corporate responsibility policies, please refer to WPP's website.

If it were me, I'd set a DNS alias from the old server to the new one. As long as you're not using a certificate on the new server that does not contain the DNS addresses of the old server, this would be fine. This is how we did our cutover from old hardware to new hardware. If you *are* using a cert on the new server that does not contain the old server's information, I'd say revoke it and issue a new cert with the proper info. This is a task easier handled outside of the clients themselves. Once they're talking to the new server, then you can worry about updating their pref files to reflect the new server name. Once all of your clients have the new pref, then remove the DNS alias.

j

Thanks but it's not an old JSS, it's *another* JSS. Someone
accidentally added one as a managed client to the other. It's not
having any detrimental affect as far as I know, I just want to remove
the framework and stop it checking for policies without breaking the
JSS at the same time.

Ollie

Why not remove the preference file for the JAMF Binary? or Better still re-create it.

This would be non destructive.

Re-add your server in to your JSS and build your config file using the following command
--------------------------
jamf help createConf
--------------------------
Usage: jamf createConf [-url <url>] [-allowInvalidCertificate] [-server <servername>] [-target <drive>]

-url The URL of the JSS

-allowInvalidCertificate Allows "insecure" SSL connections

-k Synonym for -allowInvalidCertificate.

-server The IP Address or DNS name of the server

-target The target drive that the conf file should be created on

Tomos

Yup, I'd go that route in this case. I thought it was a question of transitioning.

j
---
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

oops... once your unload the launchd process you should remove that as well

so after

sudo launchctl unload /Library/LaunchDaemons/com.jamfsoftware.task
sudo rm /Library/LaunchDaemons/com.jamfsoftware.task

This will make sure that the next time you reboot it does not try to contact a third party JSS

TT

Ok, maybe I answered too soon. (AND I SENT THIS DIRECTLY AND FORGOT THE LIST AGAIN.... below is both posts in one... my apologies)

How about you remove the Binary...??

sudo rm /usr/bin/jamf

or both the binary and the preference file

sudo rm /usr/bin/jamf
sudo rm /Library/Preferences/com.jamfsoftware.jamf

After which ever your choose run
sudo launchctl unload /Library/LaunchDaemons/com.jamfsoftware.task
sudo rm /Library/LaunchDaemons/com.jamfsoftware.task

The JAMF Binary is not used by the JSS. So you could safely remove this without causing an issue to the server. But removing the preference would do the same thing. Also I have noted a change in the removeFramework flag by the fact it does not remove the Composer Repository any more.

Tomos

Thanks Tomos - I was worried about the JAMF binary being used in some
way by the JSS. I will remove those launchdaemons as well.

Cheers