It sounds like you might mix something up here.
- The account and domain the Beacon service may be running under, is one thing.
- The credentials the beacon uses to connect to another Beacon or Inventory server, is another.
So you might run the new Beacon with B\svc-flexera, but configure the parent connection to use A\svc-flexera as credentials, because the other beacon is running in domain A.
Thanks all! Sorry for the confusion.
We are doing domain migration from domain A to domain B. Now, two domains are trust each other.
We have about 2000 servers have agent installed and are talking to domain A beacon. All servers in domain A will be decommissioned in the future, so we need to make all servers can talk to domain B beacon.
Instead of reinstalling the agent on all servers, we connect the beacon A to App servers (domain B), and then agents on windows server will recognize the new beacon B? Should connect beacon A to beacon B as a child beacon or parallel beacon?
The domain A and B run with different service accounts, does this cause authorization?
It should work like this:
- Existing agents "know" and communicate to Beacon A.
- Beacon A is reconnected to the new environment, which also includes Beacon B.
- Beacon A is fetching the latest updates, which includes details about Beacon B.
- From now on Agents "talking" to Beacon A, will also learn about Beacon B.
How both Beacons relate to each other (Parent-Child or in parellel) shouldn't matter. Also, this is a process, it may take time until all agents have caught up on the data.
A few things regarding the service accounts:
- As mentioned before, to run stuff you need to use the account from your own domain. To talk cross-domain you'll need the credentials for the target domain.
- If the domains have trust relationship, mixing accounts might be possible. Still, for the sake of transparency and future operability, there should be a clear plan what accounts are to be used.
- Agents do not authorize against the Beacon, so there shouldn't be a problem.