We were able to use switch masthead fixlet and resubscribe/migrate computer from BigFix A to BigFix B. But when we try to do it from BigFix B to BigFix A, it is throwing me a HTTP Error 5.
But in BigFix B, Iam able to access the URL that we have specified in Switch masthead Fixlet > Edit > Actions in the web browser. Can someone be kind enough to help me on what might be the issue?
I want to check if there is other way by editing the script, for example by manually copying the masthead file in to BigFix B and providing the path in the Switch masthead Fixlet > Edit > Actions. It will help me if you can please provide the sample edited script.
The destination BigFix masthead file will be usually copied to the Uploads folder in the source BigFix.
Is the BigFix A masthead file copied to Uploads folder in BigFix B? If the file is accessible, the action should show that the file is cached to the root server before the client tries to download it.
I tired that method also, even then I’m getting the http error.
I tired two methods:
One by trying to download masthead directly from BigFix A, throwing me http error 5.
Second method is copied the masthead file of A into upload folder of BigFix B client and then tried the URL by mentioning local host instead of calling out A. Even then it’s throwing me http error
There is no proxy setup in both BigFix Clients. Can I know if there is a way where we can place the masthead file in any Local drive and change the Fixlet > Edit > Actions code from download URL to local file path or something? Will this method work? If so, can you suggest on what to do?
To confirm, was the BigFix server A masthead file copied to the BigFix B Root Server or a client? The masthead file should be copied to (Root Server Install Folder)\wwwrootbes\Uploads on the Root server B, for example: C:\Program Files (x86)\BigFix Enterprise\BES Server\wwwrootbes\Uploads
All the Masthead Switch fixlet does is to copy the new deployment’s masthead file over the existing client’s ActionSite.afxm and restart the BESClient service
By default just copy it to "C:\Program Files (x86)\BigFix Enterprise\BES Client\ActionSite.afxm"
If you are referring to copy the actionsite file to target computer and restart the service, then it is not an ideal option for us as we need to run this fixlet action on 200+ computers.
I’ve ran the fixlet by placing the file in C:\Program Files (x86)\BigFix Enterprise\BES Server\wwwrootbes\Uploads and I’ve got an error saying ‘Invalid Signature’. Could @JasonWalker and @ssakunala please help me on how to fix the error.
A small note is that the Fixlet from BigFix A to BigFix B with URL(http://BigFixBservername:52311/masthead/masthead.afxm) ran successfully but when we try to run the fixlet from BigFix B to BigFix A by placing the file in localhost uploads folder (C:\Program Files (x86)\BigFix Enterprise\BES Server\wwwrootbes\Uploads), it is not working and displaying invalid signature.
How was the masthead.afxm you are creating in the Upload folder saved? I’ve seen cases where saving the file from a browser can change the file layout, eg line feeds not respected or replaces with LF/CR, and it is no longer recognized as a signed masthead. When you manually download that file and apply it to an endpoint do you get the same issue? If so they that rules out the fixlet and the issue could be your masthead. I do presume that you are copyng it as ActionSite.afxm and not masthead.afxm
Oops, I was misintrepetted the invalid signatiure as an error in the client log. That error on the action wouldn’t be related to the vallidity of the remote file, but still something to watch out for when working with the masthead.
I copied the masthead file directly from the server and not from the browser.
I have a question, I played around the fixlet > edit > action code before placing it in uploads folder and running the fixlet with default code. So would it have been causing this issue? If this might be a reason, a uninstall and reinstall of Target computer client might fix the issue?
I tired by removing download command and modified action code by keeping just if and else clause (instead of countinue if, if and else) with file path as downloads folder (Client > Downloads). When I ran the fixlet with these changes, I got the same error saying invalid signature.
Now when I ran the default masthead fixlet by placing masthead file in uploads folder, i got the same invalid signature error.
So, you’re moving a client from Deployment A to Deployment B.
The masthead.afxm from Deployment B needs to be copied to Server A’s wwwrootbes/Uploads folder.
On Deployment A you need to issue the action to the client to swap to the Deployment B masthead. This downloads masthead.afxm, which was obtained from Deployment B and copied to Deployment A’s wwwrootbes/Uploads folder.
One potential complication is if the client, or any of its parent relays, is configured to perform Direct Downloads. As the URL in the Task references http://localhost, if the client (or its parent relay) is configured for Direct Downloads it would be checking for a webserver running on port 52311 - which will not exist on the client, and on a Relay would not contain the masthead file. Ensure the client is not attempting Direct Downloads before running the masthead switch fixlet.
The error about an invalid signature is not on the Download, that’s on the signature of the Action itself. I’ve seen that occur when the client was trying to evaluate the action from one deployment, while its ActionSite.afxm referenced a different deployment - the action it downloads from the server cannot be authenticated against the certificate in the ActionSite.afxm. This could be possible if you have successfully replaced the ActionSite.afxm, but have not restarted the client; or if, through DNS aliases or HOSTS file manipulation, you have a client from one deployment trying to connect to a root server or relay on another deployment.
Note with the Masthead Switch action, you often will not get a result in the action status - because once the client switches to the new deployment, it can no longer report status to the old one. You have to check the new deployment to see whether the client has actually appeared there.
I could successfully move a client (computer) from Deployment A to B. The problem arises when I’m trying to move it from Deployment B to A.
Why am I doing this? It is because Deployment A is a new deployment with latest BigFix version and BigFix B is an older deployment. Before migrating all clients from old deployment B to new deployment A, I wanted to test the migration. So I started by installing BigFix client with actionsite file of deployment A on a sample asset and migrated it to B successfully. Now I want to try from B to A and I’ve been getting ‘invalid signature’ issue.
I’ve performed the same steps you’ve mentioned in the response for migrating of client from deployment B to A.
Any workaround on this? Or any potential reason on why the masthead switch is working from A to B and not B to A.
You’ll probably need to open a support incident so the team can work with you in a live session. There’s something in your description that I’m not understanding, and being able to look at which masthead files you have in which locations, and what you’re doing to edit the action, would probably be helpful.
When I moved the client from Deployment A to B, I modified the URL in fixlet action with http://Deployment B server name:52311/masthead/masthead.afxm and the client started reporting to deployment B successfully.
I tried the same procedure for moving the same client from Deployment B to A and got an http error 5, so I placed deployment A masthead file in deployment B- C:\Program Files (x86)\BigFix Enterprise\BES Server\wwwrootbes\Uploads and ran the default fixlet 1516 with the default download URL http://localhost:52311/Uploads/masthead.afxm and got the invalid signature as the result. I could still see that the client is reporting to B and it didn’t start reporting to A.
So to resolve this invalid signature i uninstalled target computer client and reinstalled it again as it’s the fix I’ve thought of. After reinstalling, i tried the above procedure and i could successfully migrate client from A to B and B to A without any issues.
