Switch the BES Client's action site masthead to network with new relay

Does anyone have a way to solve switch the BES Client’s action site masthead from one BigFix server that is private network to another BigFix server that is managed by MPLS which has a Relay on the private network that the endpoints must connect to for communication.

I attempted to edit computer settings of bes client (linux) which is manual relay selection for both primary and secondary relay selected to main BigFix server. I edited the client setting unchecked the primary relay and added __RelayServer1 with the value to the new relay http://relay server:52311/bfmirror/downloads/. Even tried failover realy setting.

After the edit settings was completed , I took action on the switch masthead and it started to work , but it appears the masthead process removes all relay settings from the configuration file.

Any thoughts as to how to get around this as I will need to edit each endpoint.

I was going to use the standalone deployment tool but the user guide says that it will not replace the bes config file is it exists.

You can create a fixlet like the following in your original BES environment that will replace the masthead on the endpoint and restart the BESClient. When the BESClient restarts on the endpoint it will be pointed to the new BES environment.

Relevance:

version of client >= “9.0”
version of registration server >= “9.0”
not exists relay service and not exists main gather service

Action Script:

if {exists file “masthead.afxm” of folder “__Download” of client folder of current site}
delete __Download/actionsite.afxm
endif

prefetch masthead.afxm sha1:sha1_of_new_masthead size:byte_count_of_new_masthead http://url_of_new_root_BES_server:52311/masthead/masthead.afxm

continue if {exists file “masthead.afxm” of folder “__Download” of client folder of current site}

if {unix of operating system}
delete /etc/opt/BESClient/actionsite.afxm
move “{pathname of file “masthead.afxm” of folder “__Download” of client folder of current site}” /etc/opt/BESClient/actionsite.afxm
else
parameter “MastheadLocation”=“{pathname of file “actionsite.afxm” of storage folder of client}”
delete “{parameter “MastheadLocation”}”
move “{pathname of file “masthead.afxm” of folder “__Download” of client folder of current site}” “{parameter “MastheadLocation”}”
endif

client restart

Hope this helps.

Thanks for your response. I am using the site masthead to new server and that works fine. the problem is the relay that is on this network is from the new bigfix server and the network is fire wall from allowing direct access to the Multi tenant network bigfix server. So it must connect to the multi tenant relay. I tried edit computer settings to solve this and have it point to the new relay but when the new masthead is used by the client it appears to wipe out relay settings in the existing config file so it can only point to the new bigfix server, which it cannot access through the firewall.

What I am looking for is a way to set the new relay prior to the masthead file .

There are BESClient properties where you can specify static relay affiliations with priority. There’s also seek-lists for BESClient when automatic relay affiliation is enabled. Are your endpoints set for automatic or static relay affiliation?

The masthead for you new BES environment, is it bound to a server’s hostname or a transportable C-name/alias?

Thank you for your suggestions. The fixlet ID 1516,switch the BES Client’s action site masthead, that Downloads the new masthead from a web server - This action will download the file from the url http://lhostname of bigfix server:52311/Uploads/masthead.afxm and use it as the new masthead. Please put the file at that location or use a custom action to change the download url.

Yes you are correct you can edit computer properties to set relay. I did set the relay property to look at the relay from the other network and after switching the masthead file task for a moment it started to communicate and then the masthead process must reset the client configuration properties for the relay as it wiped out the settings.

Have you received any further information or resolved this issue? I am attempting this as well and noticed the settings getting wiped out. I did come across this article which seems to describe the issue, and I am just starting to look at the fixlets provided. It talks about tricking the client into thinking it is a new install so that you can set the settings.

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Switch%20Actionsite%20Masthead%20using%20Relays

You only need a new masthead if you want to change from one BigFix install to another. If you want to change to a different relay in the same BigFix environment then you would not download a new masthead.

If you are switching to a new BigFix environment, with a different root server then the client settings do get wipped out. You can create a new customsettings.cfg file to point the client a specific relay in the new environment. Here is the task we use to migrate from one environment to another. Replace BESServer Relay1, Relay2, Relay3 and Relay4 with your servers. You can have as many relays as you need in the _BESClient_RelaySelect_TertiaryRelayList setting.

//Reset all relay settings
setting "__RelayServer1"="" on "{parameter "action issue date" of action}"  for client
setting "__RelayServer2"="" on "{parameter "action issue date" of action}"  for client
setting "_BESClient_RelaySelect_FailoverRelay"="" on "{parameter "action issue date" of action}"  for client
setting "_BESClient_Register_Affiliation_SeekList"="" on "{parameter "action issue date" of action}"  for client
setting "_BESClient_RelaySelect_TertiaryRelayList"="" on "{parameter "action issue date" of action}"  for client

download http://BESServer:52311/masthead/masthead.afxm

//Windows
if {windows of operatingsystem}
	
	//Create new Client Settings.cfg file
		delete __createfile
		createfile until __EOF__
IP:http://Relay1:52311/bfmirror/downloads/
__RelayServer1=Relay1:52311/bfmirror/downloads/
__RelayServer2=Relay2:52311/bfmirror/downloads/
_BESClient_RelaySelect_TertiaryRelayList=Relay3;Relay4
_BESClient_RelaySelect_ResistFailureIntervalSeconds=0
__EOF__
		delete "{pathname of parent folder of regapp "besclient.exe"}\Clientsettings.cfg.new"
		move __createfile "{pathname of parent folder of regapp "besclient.exe"}\Clientsettings.cfg.new"

	//Overwrite actionsite file
		delete "{pathname of parent folder of regapp "besclient.exe"}\ActionSite.afxm"
		copy "__Download\masthead.afxm" "{pathname of parent folder of regapp "besclient.exe"}\ActionSite.afxm"

	//Restart client and replace clientsettings
		delete __appendfile
		appendfile @echo off
		appendfile echo Your administrator is restarting the BES Client... Please Wait...
		appendfile net stop BESClient
		appendfile move /Y "{pathname of parent folder of regapp "besclient.exe"}\Clientsettings.cfg.new" "{pathname of parent folder of regapp "besclient.exe"}\Clientsettings.cfg"
		appendfile net start BESClient
		delete clientRestart.bat
		copy __appendfile clientRestart.bat
		runhidden clientRestart.bat

//UNIX
else

	//Create new Client Settings.cfg file
		delete __createfile
		createfile until __EOF__
[Software\BigFix\EnterpriseClient]
EnterpriseClientFolder = /opt/BESClient

[Software\BigFix\EnterpriseClient\GlobalOptions]
StoragePath = /var/opt/BESClient
LibPath = /opt/BESClient/BESLib

[Software\BigFix\EnterpriseClient\Settings\Client\__RelaySelect_Automatic]
value = 0

[Software\BigFix\EnterpriseClient\Settings\Client\__RelayServer1]
value = http://Relay1:52311/bfmirror/downloads/

[Software\BigFix\EnterpriseClient\Settings\Client\__RelayServer2]
value = http://Relay2:52311/bfmirror/downloads/

[Software\BigFix\EnterpriseClient\Settings\Client\_BESClient_RelaySelect_TertiaryRelayList]
value = Relay3;Relay4

[Software\BigFix\EnterpriseClient\Settings\Client\_BESClient_RelaySelect_ResistFailureIntervalSeconds]
value = 0
__EOF__
		delete "{pathname of parent folder of parent folder of client folder of current site}/besclient.config.new"
		move __createfile "{pathname of parent folder of parent folder of client folder of current site}/besclient.config.new"


	//AIX
	if {name of operating system starts with "AIX"}
		delete /etc/opt/BESClient/actionsite.afxm
		move __Download/masthead.afxm /etc/opt/BESClient/actionsite.afxm
		delete "{(client folder of current site as string) & "/__appendfile"}"
		appendfile #!/bin/sh
		appendfile sleep 30
		appendfile /etc/rc.d/rc2.d/KBESClientd stop
		appendfile sleep 30
		appendfile mv -f "{pathname of parent folder of parent folder of client folder of current site}/besclient.config.new" "{pathname of parent folder of parent folder of client folder of current site}/besclient.config"
		appendfile /etc/rc.d/rc2.d/SBESClientd start
		wait chmod 555 "{(client folder of current site as string) & "/__appendfile"}"
		run {"/bin/sh -c %22trap '' 15;'" & (client folder of current site as string) & "/__appendfile'%22"}

	//Linux/SunOS
	elseif {name of operating system starts with "Linux" or name of operating system starts with "SunOS"}
		delete /etc/opt/BESClient/actionsite.afxm_old
		delete /etc/opt/BESClient/ActionSite.afxm_old
		if {exists file ("/etc/opt/BESClient/actionsite.afxm")}
			move /etc/opt/BESClient/actionsite.afxm /etc/opt/BESClient/actionsite.afxm_old
			move __Download/masthead.afxm /etc/opt/BESClient/actionsite.afxm
		else
			move /etc/opt/BESClient/ActionSite.afxm /etc/opt/BESClient/ActionSite.afxm_old
			move __Download/masthead.afxm /etc/opt/BESClient/ActionSite.afxm
		endif
		delete "{(client folder of current site as string) & "/__appendfile"}"
		appendfile #!/bin/sh
		appendfile sleep 5
		appendfile /etc/init.d/besclient stop
		appendfile mv -f "{pathname of parent folder of parent folder of client folder of current site}/besclient.config.new" "{pathname of parent folder of parent folder of client folder of current site}/besclient.config"
		appendfile sleep 5
		appendfile /etc/init.d/besclient start
		wait chmod 555 "{(client folder of current site as string) & "/__appendfile"}"
		run "{(client folder of current site as string) & "/__appendfile"}"
	
	else
		//Fail if no OS was selected
		continue if {false}
	endif
endif
3 Likes

Matt,

Would I include all lines above in a single action for both windows and unix? This is really good and thanks for all the great information.

Yes, this should work for Windows or Unix. One thing to be aware of is the client needs to know where to download the masthead from. So the download command needs to point to something the client can access. This can be the BES Server, a relay or somewhere else. Once the client gets the masthead it will use manual relay selection with the relays you set.

Thanks Matt. This would be great to have on BigFix. ME and or additional supported sites as this would seem to be the issue with most large deployments. Great work.

clientsettings.cfg

IP:http://NJRelay1:52311/bfmirror/downloads/
__RelayServer1=NJRelay1:52311/bfmirror/downloads/
__RelayServer2=NJRelay2:52311/bfmirror/downloads/
_BESClient_RelaySelect_ResistFailureIntervalSeconds=0

Hi Matt,
I have to switch from my old root server to new root server and i all following your steps to do so, i have tried for windows, i am able to switch the masthead but it is not taking the clientsettings.cfg file for manual relay selection my cfg file is as above please help. NJRelay 1 and 2 are my relay servers.

Clientsettings.cfg is only used by the product installer. The simplest solution would be to configure the relay settings with an action after you switch the masthead.

Hi All,

I have tried this but it is not working.
In logs it got stuck at Beginning relay select.
And in __BESData folder actionsite is not getting downloaded instead its name change to actionsite.0

Existing infra is 9.1 and new infra is 9.5.11
BigfixNJ1 and BigfixNJ2 are the relay servers in the new infra.
As endpoints are not communicating to main root server in new infra i have to communicate them via relay only.


download http://BigfixNJ1:52311/masthead/masthead.afxm

setting “__RelayServer1”="" on “{parameter “action issue date” of action}” for client
setting “__RelayServer2”="" on “{parameter “action issue date” of action}” for client
setting “_BESClient_RelaySelect_FailoverRelay”="" on “{parameter “action issue date” of action}” for client
setting “_BESClient_Register_Affiliation_SeekList”="" on “{parameter “action issue date” of action}” for client
setting “_BESClient_RelaySelect_TertiaryRelayList”="" on “{parameter “action issue date” of action}” for client

setting “__RelaySelect_Automatic”=“0” on “{parameter “action issue date” of action}” for client
setting “__RelayServer1”=“BigfixNJ1” on “{parameter “action issue date” of action}” for client
setting “__RelayServer2”=“BigfixNJ2” on “{parameter “action issue date” of action}” for client

//Overwrite actionsite file

delete "{pathname of parent folder of regapp “besclient.exe”}\ActionSite.afxm"
copy “__Download\masthead.afxm” “{pathname of parent folder of regapp “besclient.exe”}\ActionSite.afxm”

delete __appendfile
appendfile @echo off
appendfile echo Your administrator is restarting the BES Client… Please Wait…
appendfile net stop BESClient
appendfile net start BESClient
delete clientRestart.bat
copy __appendfile clientRestart.bat
run clientRestart.bat


Masthead get downloaded and replaced but it is not able to download actionsite.

The action is clearing the relay list. I’m not sure, check whether there are parameters you can supply on the Description tab or a second action to prompt for relays. If not, make a custom copy of the task to specify a new relay to use instead of the root server.

Add

setting “_BESClient_RelaySelect_FailoverRelayList”="relay1;relay2;relay3" on “{parameter “action issue date” of action}” for client

(And supply your own list of relays the client can reach in the new deployment)

Hi Jason,
Here I am removing the existing relay settings on the client for old infra…

setting “__RelayServer1”="" on “{parameter “action issue date” of action}” for client
setting “__RelayServer2”="" on “{parameter “action issue date” of action}” for client
setting “_BESClient_RelaySelect_FailoverRelay”="" on “{parameter “action issue date” of action}” for client
setting “_BESClient_Register_Affiliation_SeekList”="" on “{parameter “action issue date” of action}” for client
setting “_BESClient_RelaySelect_TertiaryRelayList”="" on “{parameter “action issue date” of action}” for client

Then here i have provided the settings for the new infra…

setting “__RelaySelect_Automatic”=“0” on “{parameter “action issue date” of action}” for client
setting “__RelayServer1”=“BigfixNJ1” on “{parameter “action issue date” of action}” for client
setting “__RelayServer2”=“BigfixNJ2” on “{parameter “action issue date” of action}” for client

And these relay servers are accessible from the clients on port 52311.
Please correct me if I am doing wrong.

Thanks

Looking for some help here. I’ve setup the above task to switch the masthead to our own one (for the purposes of on-boarding an group of client machines who already have BigFix on their own environment), and it does what it’s supposed to do.

However once the client connects - via the __RelayServer1 client setting - to the new environment, the server immediately initiates a client reset. At which point, all the client settings are wiped. (Doesn’t give the client time to download the new relays.dat file or anything.) As we don’t permit clients to talk directly to the root/masthead DNS alias, this leaves the clients in limbo permanently.

The only way I can see to workaround it would be to add a hosts file entry or something similar, to point it to the correct relay via the master DNS alias. I’ve thought about setting the fallback relay on our own environment masthead but we’re on 9.5.11 - which is when this was introduced - and they are on 9.5.10, so don’t believe their clients can make use of that feature.

Does anyone have something smarter that could be done here?

1 Like

I haven’t done this in a while, but…my recollection was that the client settings aren’t wiped, but they all have their “effective date” cleared so they will apply any new settings from the new deployment regardless of effective dates. But the __RelayServer settings are “special” in that the client itself clears them during relay selection.

Can you try instead applying _BESClient_RelaySelect_FailoverRelay or _BESClient_RelaySelect_FailoverRelayList settings for the new deployment before/during the masthead switch? I usually prefer FailoverRelayList for its flexibility, and usually configure it to include top-level relays, DMZ relays, and any Disaster Recovery Site relays so the client has several options to try.

It’s not a hard rule, but by convention, client settings starting with a single underscore are “permanent” configuration settings, while settings beginning with two underscores are meant to be dynamic and managed internally by the client.

Yeah unfortunately @JasonWalker, I had basically for that part:

action parameter query "Relay FQDN" with description "Please enter the relay to be assigned to the selected client(s), using the relay's advertised FQDN hostname (or IP) ONLY. (URL will be auto-filled)"

delete __createfile
createfile until __EOF__

__RelaySelect_Automatic=0
__RelayServer1=http://{parameter "Relay FQDN" of action}:52311/bfmirror/downloads/
__RelayServer2=
_BESClient_RelaySelect_FailoverRelay=http://{parameter "Relay FQDN" of action}:52311/bfmirror/downloads/
_BESClient_RelaySelect_FailoverRelayList={parameter "Relay FQDN" of action}
//_BESClient_RelaySelect_TertiaryRelayList=Relay3;Relay4
_BESClient_RelaySelect_ResistFailureIntervalSeconds=30
__EOF__

	delete "{pathname of parent folder of regapp "besclient.exe"}\clientsettings.cfg.new"
	move __createfile "{pathname of parent folder of regapp "besclient.exe"}\clientsettings.cfg.new"

That all worked:

At 12:28:34 +0100 -
Initializing Site: mailboxsite
Initializing Site: opsite10
Initializing Site: opsite101
Initializing Site: opsite102
Initializing Site: opsite3
Existing mailbox site does not match computer ID, starting client reset
Processing Download plugins
At 12:28:34 +0100 - opsite10 (http://BFX-root:52311/cgi-bin/bfgather.exe/opsite10)
Removing operator site (operator no longer valid)
At 12:28:34 +0100 - opsite101 (http://BFX-root:52311/cgi-bin/bfgather.exe/opsite101)
Removing operator site (operator no longer valid)
At 12:28:34 +0100 - opsite102 (http://BFX-root:52311/cgi-bin/bfgather.exe/opsite102)
Removing operator site (operator no longer valid)
At 12:28:34 +0100 - opsite3 (http://BFX-root:52311/cgi-bin/bfgather.exe/opsite3)
Removing operator site (operator no longer valid)
At 12:28:34 +0100 - CustomSite_CIS_for_Windows_10(http://BFX-root:52311/cgi-bin/bfgather.exe/CustomSite_CIS_for_Windows_10_-28FIS-29)
Removing custom site (url mismatch)
At 12:28:34 +0100 -
Adding custom site (CustomSite_CIS_for_Windows_10)
Removing client mailbox site since we have no keys.
Beginning Relay Select
At 12:28:35 +0100 -
RegisterOnce: Attempting secure registration with 'https://BFX-failover:52311/cgi-bin/bfenterprise/clientregister.exe?
At 12:28:36 +0100 -
Unrestricted mode
Scheduling client reset; Computer id changed to 933019
Configuring listener without wake-on-lan
Registered with url 'https://BFX-failover:52311/cgi-bin/bfenterprise/clientregister.exe?
Registration Server version 9.5.11.197 , Relay version 9.5.11.191
Relay does not require authentication.
At 12:28:37 +0100 -
Completed automatic client authentication key exchange.
Client has an AuthenticationCertificate
Created mailboxsite and marking to gather
Relay selected: BFX-failover. at: x.x.x.x:52311 on: IPV4 (Using setting IPV4ThenIPV6)
Client resetting
Configuring listener without wake-on-lan
At 12:28:39 +0100 -
Unrestricted mode
Created mailboxsite and marking to gather
Entering Service Loop.
Starting Service Loop.
A2AServer::Start().
Beginning Relay Select
At 12:28:40 +0100 -
RegisterOnce: Attempting secure registration with 'https://BFX-root:52311/cgi-bin/bfenterprise/clientregister.exe
At 12:28:41 +0100 -
RegisterOnce: GetURL failed - General transport failure. - BAD SERVERNAME (winsock error 4294967290 - registration url - http://BFX-root:52311/cgi-bin/bfenterprise/clientregister.exe?

But post client reset, the effective dates are still there but the values are gone! E.g.:

_BESClient_RelaySelect_FailoverRelay
effective date Thu, 25 Jul 2019 12:28:39 +0100
value

So I’m thinking the only way to work this is to set the master DNS alias = the failover relay in the hosts file. Unless there’s some other way? I just can’t see one… Hoping someone will prove me wrong :slight_smile:

BUMP.

We’re trying to do this exact thing right now. Switch mastheads /BF environments on endpoints in the DMZ. The DMZ servers only have access to the DMZ server. We are using a modified “Switch BES Client Action Site Masthead” fixlet.

The endpoint receives the masthead and configures secure registration without issue. However, it zeros out the FailoverRelayList, relay, etc. I have to log in to the server, set the registry value for the failoverrelay, and then restart the BESclient for it to connect.

download http://bigfixmaster.domain.com:52311/masthead/masthead.afxm
continue if {exists file “masthead.afxm” of folder “__Download” of client folder of current site}
if {unix of operating system}
delete /etc/opt/BESClient/actionsite.afxm
move “{pathname of file “masthead.afxm” of folder “__Download” of client folder of current site}” /etc/opt/BESClient/actionsite.afxm
else
parameter “MastheadLocation”=“{pathname of file “actionsite.afxm” of storage folder of client}”
delete “{parameter “MastheadLocation”}”
move “{pathname of file “masthead.afxm” of folder “__Download” of client folder of current site}” “{parameter “MastheadLocation”}”
endif
// Set DMZ Relay
setting “_BESClient_RelaySelect_FailoverRelayList” = “bigfix-dmz-relay.domain.com” on “{now}” for client
setting “_BESClient_SecureRegistration” = “supersecretpassword” on “{now}” for client

client restart

Have you opened a ticket with L2 regarding your statement that the FailOverRelay is cleared out? Additionally, have you enabled BESClient debug logging to level 10,000 for this action? I would be curious to see more details from the client as that’s not the expected behaviour as far as I’m aware.

1 Like