Devices that are in the WAN can be managed with BMC Client Management (BCM) almost exactly as if they were on the LAN. The only modules that will not be available are the asset discovery scanning of these devices or the OS deployment to them.
Apart from that it will be possible to inventory the devices, deploy applications to them, patch them, take control of them through the remote control module, etc...
This is made possible by the ability of the BCM agents to build tunnels between the devices in the WAN and their parent, as it is described in this other KA: Client Management: Is it possible to take control of a device that is connected through the internet
Main prerequisites:
In order to manage devices which connect over the Internet, a relay must be contactable on TCP ports 1610 and 1611 (reverse is not required). This is true whether the clients connect through a VPN or through a DMZ relay. The following KA explains how to test if an agent is set properly to communicate with its parent: Client Management: How to test if a device is reachable?
Also, the relay(s) to which the devices will connect to must be properly sized: as a reminder, the maximum number of children for a Windows Server relay is 2000 children, 5000 for a linux relay. Make sure to review the prerequisites. The following KA explains how to monitor the number of clients under each relays of the environment: Client Management: Check if the parent does not have too many children (queue full)
Two scenarios:
A- VPN:
If the devices connect to the network through a VPN, they must be capable of reaching a parent on the port 1610. This implies that their relay module is configured properly to connect to an internal relay. One must make sure that the current settings will dispatch the clients to the proper relay(s). If the clients use a relay list, the ranges that are set in the relay list might need to be refined accordingly to the ip range the devices will get when they'll be connected through the vpn.
The following KA explains how to use and set the relay list mechanism: Client Management: How to use the relay list mechanism to select relays.
In case the use of the relay list or the dhcp mechanism can't apply to this situation because, as an example, it would make all children connect to the same relay and overload it with too many clients, there could be alternatives such as making relay selection scripts or such as creating queries that would split devices between various relays, e.g: Client Management: load balance devices across relays - USE WITH CAUTION
B- DMZ
If the devices do not (always) connect through a VPN, one or more DMZ relay(s) will have to be set up. The agent configuration will have to be updated according so the device can pick the LAN relays when it's connecting through the LAN, or pick the DMZ relay(s) when connecting through the WAN.
B1- Adapt the timeouts
When the devices are on the WAN they will most likely have a less stable connection. The default parameters of the BCM agents are more targeted at a LAN environment. This is why the first and most important step is to reconfigure the agents to manage connection timeouts better.
Before going any further, make sure to follow this KA and set the existing agents and the rollout configurations accordingly: Client Management: How to limit "Queue Full" message on DMZ Relay with dedicated parameters. Note that exports of the necessary operational rules are attached to this other KA to ease the process.
B2- Relay selection
As mentioned in the VPN section, the relay module settings of the clients might have to be reviewed. If the devices connect through the WAN, they will not be able to use the relay list or the dhcp mechanisms to select their relay. This implies to have the DMZ relay set as a static or as a backup relay in the devices relay module settings.
As per the VPN, it is very important to size the DMZ relay(s) properly. It might be relevant to set several DMZ, by location maybe, in order to avoid having more that 2000 (Windows) or 5000 (linux) children to the DMZ relay.
B2-1 Update existing configurations
This can be configured on each device manually via the console or by using an Operational rule having the step "Relay Module Setup" assigned to each client with settings such as the following example:
The example above uses two methods to select a parent, the Static definition first and if that is unreachable the client then tries the Backup definition.
-
Static would attempt to connect to the parent "InternalParent" (replace with the IP, Hostname, or Fully Qualified name of an internal relay or the master server)
-
If the Static parent is unreachable, the client would then use the Backup entry of 'PublicRelay.MyDomain.com' (replace with the public IP address or the public Domain Name entry that resolves to the public IP address of the DMZ relay).
Note:
The above doesn't take other relay selection mechanisms into account, such as relay list selection, but they could very well be adapted with the relay list selection before "static, backup" in the field "Mechanism List" field, e.g "list,static,backup" (then the field "List Server URL" should be updated as well etc..)
B2-2 Rollouts
The rollout configuration used to deploy the devices that will be on the WAN must be updated. The following applies to the relay selection settings only, do not forget to combine them with the timeout settings from the KA Client Management: How to limit "Queue Full" message on DMZ Relay with dedicated parameters.
Within the rollout configuration used to install or reinstall these BCM agents, configure the rollout communication as this:
Notes:
- For security reasons the master should not be in a DMZ, even if there are les than 500 devices on this environment. It is more secure to set a dedicated relay for that, even though it would actually have very few clients.
- This KA explains how packages and patches are downloaded by clients from their relays: Client Management: A quick overview on how packages and patches are sent to the target devices
- For devices that never connect to the LAN, it is possible to set the clients to download their patches from the internet directly, instead of having to download them from their parent. To achieve this follow this KA: Client Management: How to set agents to download patches themselves from the internet (DownloadPatchAsSaaS)
Next:
- Enabling a DMZ relay enhances the ability to use the remote control on request (agentless) to devices that are in the WAN: Client Management: How to take control on request (agentless)
- It might be interesting to set the clients in the WAN to download patches themselves: Client Management: How to set agents to download patches themselves from the internet (DownloadPatchAsSaaS)