Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 1 subscriber
  • Views 3012 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Remote site takeover with SEC

MawfTech

Hi all, need some suggestions please.

Got a remote site that's had a standalone SEC 3.1 deploying v7.6 SAV to a CID and then clients in that office that update from that. All is well with this and running fine.

Obviously, I now want to migrate these to v9.5 as v7.6 is end of life shortly. The local server is not man enough for (and I don't want it to be destroyed by)  SEC4.x console and UM so I've deployed a CID from HQ down to the branch office via our own SEC 4.0 installation. The CID works fine and I can install new installations from it without any problem.

Now, the bit that's stumped me. From my SEC 4 console, I can 'find' machines in the branch office and they appear in the unassigned section. I've created a new group for this branch and configured updating pointing at my shiney new v9.5 CID. Only problem I have is that when I drag a machine from unassigned to the relevant group and it auto runs 'protect', feed in sufficient credentials........nothing :( Machine continues to update and inform the local SEC. Even if I remove the machine from the local SEC prior, a protect is simply ignored. I can happily protect machines that have never been part of that branch office SEC but I cannot grab control of a machine that has already seen the local SEC.

Without wanting to simply uninstall each client and reinstall from the new CID, is there an easy way to redirect a machine to the HQ SEC? Tech support are working on this too but at the moment seem dumbstruck by the question - guess I have to wait for it to escalate to get anywhere there.

Matt

:5975


This thread was automatically locked due to age.
Parents
  • 0

    Hi Jak,

    "When you say:

    "feed in sufficient credentials........nothing"

    What exactly is nothing "

    Exatly that. I see in the SEC 4.0 console, the standard orange arrow which never goe green. On the client, no task is created though I can hppily create a task myself remotely, run it and see the results. After standard 5 minutes, the SEC 4 console returns the standard error "'the installation didn't start, the computer may have been shut down.......". It's almost like it realises it's controlled elsewhere and aborts the task deployment but there's no logs to show this.

    "If you bootstrap a client from the 9 distribution point does that work, does the machine become managed?"

    No, it happily installs the new version and updates RMS and AU too but then continues to notify the local SEC 3. As I've removed the machine from any local SEC groups, it appears in the unassigned section of that, in blue and showing correctly the new CID update points but obviously as unknown policy compliance.

    "When the machines were managed by SEC 3.1 at the remote site....." no, no custom mrinit.conf so only the cac.pem and mrinit.conf would be changed if I follow my ow logic.

    Obviously to crack this, I can simply uninstall the entire suite from the clients and reinstall but I can't think why I shoul not be able to do this locally. Security wise it's nonsense, I've got administrative credentials to install so should be able to take on or shift machines at will. Can't imagine larger installations not facing this issue i.e. person moves from one branch office to another but new office cannot capture the user into their own SEC without having to completely reinstall.

    Matt

    :6017
Reply
  • 0

    Hi Jak,

    "When you say:

    "feed in sufficient credentials........nothing"

    What exactly is nothing "

    Exatly that. I see in the SEC 4.0 console, the standard orange arrow which never goe green. On the client, no task is created though I can hppily create a task myself remotely, run it and see the results. After standard 5 minutes, the SEC 4 console returns the standard error "'the installation didn't start, the computer may have been shut down.......". It's almost like it realises it's controlled elsewhere and aborts the task deployment but there's no logs to show this.

    "If you bootstrap a client from the 9 distribution point does that work, does the machine become managed?"

    No, it happily installs the new version and updates RMS and AU too but then continues to notify the local SEC 3. As I've removed the machine from any local SEC groups, it appears in the unassigned section of that, in blue and showing correctly the new CID update points but obviously as unknown policy compliance.

    "When the machines were managed by SEC 3.1 at the remote site....." no, no custom mrinit.conf so only the cac.pem and mrinit.conf would be changed if I follow my ow logic.

    Obviously to crack this, I can simply uninstall the entire suite from the clients and reinstall but I can't think why I shoul not be able to do this locally. Security wise it's nonsense, I've got administrative credentials to install so should be able to take on or shift machines at will. Can't imagine larger installations not facing this issue i.e. person moves from one branch office to another but new office cannot capture the user into their own SEC without having to completely reinstall.

    Matt

    :6017
Children
No Data