cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Beacons with different service account

Hello experts, 

I have a question about mapping old beacon to new environment new domain. 

We installed new FNMS (2020 R2 on Prem) on servers under domain B with service account B\svc-flexera . 

Our current FNMS is 2019 R2 under domain A with service account A\svc-flexera.

I mapped the current beacon to the 2020 R2 but got this error "

Should we run the current beacon with new service account B\svc-flexera? 

If the domain B account couldn't added on domain A servers, is there any other way to fix this?

 

Thanks a lot! 

(1) Solution

Hi,

It should work like this:

  1. Existing agents "know" and communicate to Beacon A.
  2. Beacon A is reconnected to the new environment, which also includes Beacon B.
  3. Beacon A is fetching the latest updates, which includes details about Beacon B.
  4. 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.

Best regards,

Markward

View solution in original post

(7) Replies

Sorry, here is the error message "Authorisation failed for download request to https://......"

Sorry, I don't follow you, may be you can explain better

From what I understand you have Beacon A, Beacon B in separate domain, this 2 domains have a trust relation between them?

Also I don't understand how you made de connections.

  • Beacon A -> App server
  • Beacon B-> App server

Or Beacon B -> Beacon A -> App server

But if you receive authorization failed, I think this is related to credentials.

 

 

If this is the case, Beacon B -> Beacon A, the Beacon B should be configured to connect with the service account configured on Beacon A or with authentication disabled, as it's a child beacon.

mfranz
By Level 17 Champion
Level 17 Champion

Hi,

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.

Best regards,

Markward

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? 

 

 

Thanks! 

Hi,

It should work like this:

  1. Existing agents "know" and communicate to Beacon A.
  2. Beacon A is reconnected to the new environment, which also includes Beacon B.
  3. Beacon A is fetching the latest updates, which includes details about Beacon B.
  4. 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.

Best regards,

Markward

Thanks for the information!