We are having issues with how quickly it takes our clients to check in.
We deploy new machines using a Ghost image that has the Big Fix client already on it.
When we pull a machine out of the box, put our image on it, and power it up, it takes 20 minutes minimum before the machine appears in Big Fix. Is there a way to speed this process up?
I also have a fixlet running that enables the client user interface on all machines, the image has the client interface disabled, is it possible to somehow force a refresh from the client, so that it computer checks in to see what filxets are being pushed to it without having to wait for the standard timer based check in?
Additionally, we have about 200 offers that are available to each machine. This list repopulates every time you restart a computer, is there a way to cache the offers in the cache on the local machine so that list is populated immediately when the computer starts? The process takes as long as 5 minutes before all offers are available.
20 Minutes would be long compared to what we experience but there are many factors to consider. Also we usually aren’t too interested in when it shows up in the console but when it actually starts running the actions we want during the provisioning phase and then re-evaluating content that may not have been previously relevant.
According to the client logs when was the first time reporting results in vs. when you see it in the console? The client initialization and sync with all of the sites can take some time for it to download and evaluate the content. The client will be reporting in as it goes. You can enable debug for the client and then you will have much more detail in what it has to do when starting up for the first time. I would do this to get good understanding of what the client is doing. I think you will find that the client is very busy and you will want to find ways to reduce or improve what it has to do.
With 200 offers it sounds like you may have a large amount of Fixlet messages, several operators and perhaps many open actions that the client needs to comprehend. We have always enabled out clients to use high level of CPU in the initial startup and then reduce to normal later in to help in this startup. We also in the process of moving to defer the subscription of some sites to be post the initial provisioning phases to shorten things up, and believe this will help.
Also the refresh of the console could be a factor. The data may actually reported and in the database but the console refresh is long enough to give the appearance of a tardy report. You could look at running a query against the DB to see when data first arrives if you are wanting to dig that deep.
I don’t have much experience with layers of relays or offers at this point so someone else will need to respond with suggestions there.
For your question about getting the client to report in faster after initial install/image, you can increase the CPU usage available to the agent and it will be much faster for initial report-in… You can do something like this:
It would also be nice to “mark” this computer as a “new image” because it will help you target your “new computer policies” and it will also help you disable the high CPU settings after a while. To do this, you might want to add a custom setting “NewComputer”=“True”
Now that you have a computer with high-CPU settings and marked as a new computer, you create a custom Fixlet to turn off these settings… To do that, you can do something like this…
Relevance:
(now - boot time of operating system > 30 * minute) AND (value of setting "_BESClient_Resource_WorkIdle" of client != "10" OR value of setting "_BESClient_Resource_SleepIdle" of client != "480") AND (value of setting "NewComputer" of client = "True")
Action:
setting "_BESClient_Resource_WorkIdle"="10" on "{parameter "action issue date" of action}" for client
setting "_BESClient_Resource_SleepIdle"="480" on "{parameter "action issue date" of action}" for client
setting "NewComputer"="False" on "{parameter "action issue date" of action}" for client
setting "NewImageComplete"="{now}" on "{parameter "action issue date" of action}" for client
This Fixlet will basically look for computers that are marked “NewComputer” = “True” with high CPU settings that have been booted for longer than 30 minutes (or change to whatever you want) and then it will switch back to the default CPU settings and change “NewComputer”=“False”… It also will write out the time it completes (just in case you want to know).
Set this Fixlet as policy and it should automatically disable the CPU settings for you…
Note that I didn’t test any of this relevance/actionscript here (but I have seen many customers take similar approaches)…
several times in the logs during the process of building a new machine. However the machine is listed when i open the bigfix console. I have had this machine on for an hour now, with no offers available when there should be 200+. The client logs show activity while it evaluates each of 24,000+ fixlets (we have the patching package) available through the patching site. I am seeing some patches for windows,apple,linux,etc. being evaluated in my client logs, but not many. It seems to be going at a crawl, i see about 4 items being added per minute to the log, at this rate it will be done by the end of the year. I am on a very fast brand new machine, and have an incredibly fast connection to the BES Server. I have the client wait times configured as described in the post above 500 and 1. CPU activity does not seem to be of the matter here (client rarely even steps up from 0-1% in task manager), so I am down to two questions.
Is there a way to cache available offers on a machine?
Could our BigFix server hardware be holding me back? When starting the console, it takes me 2 minutes and 15 seconds to get from entering my password and pressing enter to the point that I have information available in the “Computers” tab and the console is operable. This seems very slow to me.
If you have your client CPU settings set to workidle of 500 and sleepidle of 1 and you don’t see the BESClient CPU above 1%, then something is not configured right… Can you send me the settings that you are using (you can send me a BESClient Diagnostic log from a new computer that is taking a long time to report if you want).
AFAIK, client settings are stored in the registry. Here’s the reg file I use to set the CPU usage higher during our build process:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\Settings\Client\_BESClient_Resource_WorkIdle]
"value"=
"100"
"effective date"=
"Fri, 05 Mar 2010 17:42:46 -0500" [HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\Settings\Client\_BESClient_Resource_SleepIdle]
"value"=
"350"
"effective date"=
"Fri, 05 Mar 2010 17:42:46 -0500"
For instant gratification, restart the BES Client service after applying these registry settings. You should immediately notice a difference in CPU usage.
@macook: the clientsettings.cfg file is used only at installation time to pre-configure settings.
@boyd & @macook: You should use the edit computer settings dialog in the console to set client settings. The effective date behavior is important and the console will handle it for you. You don’t typically (ever?) want to be hardcoding that date. Right-click on a computer and select ‘Edit Computer Settings…’. To target multiple computers, select more than one computer before right-clicking, or click the ‘More Options’ button in the single computer ‘Edit Settings’ dialog.
Can you show me an example of how to use clientsettings? I see all the individual options it has from the links above, but i cant find anything that says “make a file clientsettings.cfg, place it in the folder install directory, then run setup.exe”
In any case, changing the maximum cpu usage seems to be causing a measurable increase in performance. On older machines it is still sluggish (about 20 minutes), but it used to take literally hours before any offers were available.
We have 2 things left to address:
When a computer turns on that has 200 some offers available to it, I would like to not have to sit and wait for the client to contact the server, then the server to make the offers available…etc. Essentially i would like to sit down at a workstation, turn it on, and have the offers there as soon as possible.
Is there a way that the client can cache the offers that are available to it?
If caching is not possible, is there a way that you would suggest to set the CPU throttle up so that for the first 5 minutes after boot up the BES Client has more CPU available?
The client does cache all offers, actions, fixlets, etc. It will only need to go to the server to grab anything new since the last time it checked in.
It sounds to me like you might have something slowing down your clients abnormally. Have you run the client diagnostics tool to find out what it’s doing during it’s evaluation loop?
we had a similar issue and what we did was re-evaluate how we were pushing our sites to the new systems. We ended up maxing the CPU settings on the new images, creating an auto group for them and restricting the site relevance to the relevance of the auto group (not the membership in the auto group, but the actual relevance
for
the group). This sped our new client evaluation time from 40 minutes to 6 minutes.
I am looking at disabling some of our sites entirely. We have the full patching package with Mac, Sun, and a dozen Linux distributions. However, we only run windows PC’s, there is no reason those sites need to be enabled.
macook, if you go to Tools > Manage Sites & select a site that shouldn’t apply to Windows, you can then click Properties > Subscription and filter it to the appropriate group of machines.
Does anyone know where BigFix keeps its cache of available offers?
Offers are just actions with different settings. You will find them in the action site folder or your operator site folders in the files Action_XYX.fxf or sometimes Action_XY_XYZ.fxf (not positive about the second format, but it will be there for environments running DSA).
However, these are not user editable. It’s sometimes convenient to look at them for troubleshooting purposes, but I don’t think it’s germane to the problem you are trying to solve in this thread.
I don’t think that will work. If you use our standard instructions to image your machines, each new client will reset itself when it comes up, so those files would get deleted even if you included them on the image.
I think you are better off following some of the other suggestions in this thread and elsewhere, particularly increasing the work/idle settings during the initial load. There are several threads that offer strategies to get machines up and running as fast as possible after imaging.