Did you know BigFix is great for mergers and acquisitions in terms of gathering data, inventory, patch status, compliance status - all that even before you think about migrating networks and domains? This article explains how to deploy the agent to the new organization and segment them off in your BigFix environment. You can then gather information to develop your plan to start patching, deploying security software, and managing them, before the domains are migrated securely through your internet-facing relay.
The article explains how you set up DMZ relay for mergers and acquisitions so as to help gather inventory and develop a plan for domain migration. Once a company is acquired, the first step would be to install the BigFix agent on the newly acquired company’s machines. Once that is done, you can deploy local relays to check in to the DMZ relay to optimize the traffic. You can then install the agent to the rest of the machines in the newly acquired organization. You can gather information about the newly acquired company such as patch posture, software inventory, compliance, overlapping IP ranges, and an overall inventory of the environment. Once the agent is deployed, you can designate relays at the new organization that communicates with your DMZ relay. You can optimize the communications with the machines to start using the local relays that would check in securely through your company's DMZ relay. You can gradually take over the patch process, start hardening the new machines with your security software, and so on.
- Create your BES clinet installer so it checks in to your DMZ relay and not your root server. Open Notepad and copy-paste the following:
__RelaySelect_Automatic=0
__RelayServer1=http://DMZRELAYNAME:52311/bfmirror/downloads
_BESClient_RelaySelect_FailoverRelay=http://DMZRELAYNAME:52311/bfmirror/downloads
- Rename the DMZRELAYNAME section to suit the name of the DMZ relay your clients need to connect to when they are off the network.
- Save the file as clientsettings.cfg and save it into its own folder.
- Copy setup.exe and the masthead.afx into the same folder. This files can be found in your BES Installers folder on the BigFix server.
Provide this agent to your newly acquired company to install on one of their machines.
I prefer to do a single PC installation and allow that machine to check in. Once the machine checks in, I create groups within BigFix to distinguish the newly acquired domain. This way, if I have roles in the BigFix setup defined for my team, I only want to allow the acquisition team to see the new machines. This is done to ensure there is no action taken on the new machines. If there is any outgoing policy action, I can ensure that the new domain is not targeted. I prefer setting a domain property so it can be targeted in my group membership.
- Logged in as a master operator account, go to Tools > Manage Properties.
- Scroll down to “Domain/Workgroup – Windows”. Select Create a Custom Copy and click OK.
When you create an automatic group, you should find Domain/Workgroup – Windows.
- Create a new group for your domain. Select the property Domain/Workgroup – Windows "contains" and enter the new domain name.
- Edit the computer group roles so as to restrict who has access to the newly acquired machines. For instance, my "Servers-All" role can see all the servers. This probably works in most environments, but since you are dealing with two domains, you probably want to edit the role to only include the source company's domain and servers. My old server role was set up just looking at the device type that contained "server".
- Change the group to include the device type and the set "contains" to "SOURCE DOMAIN".
Now that the group is updated, ensure that your roles are set up so only the SOURCE domain machines are shown.
- Create a role for the NEW DOMAIN, so appropriate people on the acquisition team have access to the endpoints.In BigFix Console, go to Roles and create a new role called End Points – New domain and target the new group you created earlier.
You can get more granular and provide your desktop team on the acquisition team access to the newly acquired workstations and server team and vice versa. This will help even if anyone mistakenly targets the newly acquired company’s PCs before they are ready.
You may need to install the agent on a few more machines and verify if everything is working as expected. Check the NEW DOMAIN PC and see if any policy actions are targeting that machine that you do not want to. Failure to check could start a process of installing software, and so on before they are ready to test.
Now that you have a few NEW DOMAIN PCs on the network and roles are restricted so only certain people have access, policy actions are not being deployed. You can set up a relay on their network. This way, not all of the BigFix agents are checking in to your DMZ relay.
- Install the BigFix agent on the machine you intend to use as a relay. Once that PC is checked in, you can deploy the Install BigFix Relay on that machine.
- Once that relay is set up, create a new clientsettings.cfg file so those machines are checking in to their local relay.
- Paste the following into notepad
__RelaySelect_Automatic=0
__RelayServer1=http://NEWDOMAINRELAY:52311/bfmirror/downloads
_BESClient_RelaySelect_FailoverRelay=http://DMZRELAYNAME:52311/bfmirror/downloads
- Change NEWDOMAINRELAY to your new relay’s information and save the file as clientsettings.cfg.
- Create a folder called "New domain Client" and save the clientsettings.cfg file in to it.
- Copy setup.exe and masthead.afx into the same folder.
This is the agent you want the new company to deploy to their endpoints. They can utilize other tools to deploy the BigFix agent or create a login script. Once the agent installs, the PC will check into their local relay. The local relay will check in directly to your company's DMZ relay.
Once the agent is installed on all of your PCs, you can then start to develop your plan to integrate them. You can then run BigFix inventory scans, verify if they are patching their PCs, check security and compliance with the different BigFix modules. Once you have the plan ready, you can start integrating them and installing your security software, get them part of your patch cycle, gather inventory about used software, and so on.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Author
Brad Sexton is a BigFix technical advisor for the mid-Atlantic region. He was a BigFix administrator in a global enterprise for 7 years where he was using BigFix for OSD, Software Deployments, and patching. Brad joined the HCL BigFix team in 2018.
Review and editorial credits
Shivi Sivasubramanian is a senior-level technical author and editor with a demonstrated history of working in the technology industry. A firm believer in the magical power of words, she loves helping the community deliver expressive, minimalist, and user-friendly content. Shivi currently leads a team of information developers in BigFix.