Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 1 subscriber
  • Views 3117 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,

    It sounds like there are 2 problems:

    1. SEC creating a task on the clients which will run.

    2. The RMS package not re-configuring itself to point to the new parent, even when you run setup manually.

    For the first, the SEC server addresses the client using the NetBIOS name.  When you are at the SEC server and you do:

    \\<remoteclient>\

    Go into the scheduled tasks and create a task, are you using the IP, FQDN or NetBIOS to reference the remote client?

    Are you doing this as the same account as the one you enter in the protection wizard?

    If you need to use a FQDN to address the client, you may need to add the other domains in the domain suffix list on the SEC server.

    As for the second, i.e. running setup manually doesn't point the machine at the new SEC server, even though:

    1. The parent address value in the mrinit.conf in the root of the CID does point to the new SEC server.

    2. There is no mrinit.conf in the rms sub directory of the CID that points elsewhere.

    3. There is no mrinit.conf.orig file in the clients remote management system directory.

    I can only assume that when the clientmrinit.exe runs, the installer helper exe the RMS installer launches to configure the router on the client it takes exception to the registry keys that are all ready on the machine.  If you could paste the contents of the last clientmrinit log file (\windows\temp) it would help.

    Otherwise, I'm sure deleting the following registry keys on a client prior to installing woukd work:

    pkc and pkp of the router and the agent.

    cac

    the 3 certidentity keys,

    the parent address key.

    I would think the reinstall would work then work.

    Thanks,

    Jak

    :6023
Reply
  • 0

    Hi,

    It sounds like there are 2 problems:

    1. SEC creating a task on the clients which will run.

    2. The RMS package not re-configuring itself to point to the new parent, even when you run setup manually.

    For the first, the SEC server addresses the client using the NetBIOS name.  When you are at the SEC server and you do:

    \\<remoteclient>\

    Go into the scheduled tasks and create a task, are you using the IP, FQDN or NetBIOS to reference the remote client?

    Are you doing this as the same account as the one you enter in the protection wizard?

    If you need to use a FQDN to address the client, you may need to add the other domains in the domain suffix list on the SEC server.

    As for the second, i.e. running setup manually doesn't point the machine at the new SEC server, even though:

    1. The parent address value in the mrinit.conf in the root of the CID does point to the new SEC server.

    2. There is no mrinit.conf in the rms sub directory of the CID that points elsewhere.

    3. There is no mrinit.conf.orig file in the clients remote management system directory.

    I can only assume that when the clientmrinit.exe runs, the installer helper exe the RMS installer launches to configure the router on the client it takes exception to the registry keys that are all ready on the machine.  If you could paste the contents of the last clientmrinit log file (\windows\temp) it would help.

    Otherwise, I'm sure deleting the following registry keys on a client prior to installing woukd work:

    pkc and pkp of the router and the agent.

    cac

    the 3 certidentity keys,

    the parent address key.

    I would think the reinstall would work then work.

    Thanks,

    Jak

    :6023
Children
No Data
Unfiltered HTML