Speed up client checkin

Customizations
1

(imported topic written by cstoneba)

I’m looking for ways to speed up client checkin upon installation, i noticed that the client spends alot of time setting user accounts that no longer exist. It looks like these users still exist in the masthead file, but no longer exist in the console.

Command succeeded setting “__Group___AdminBy_user123”=“False” on “Mon, 01 Nov 2010 14:27:50 +0000” for client (fixlet 269808)

does anyone know of a best practice to remove this old user account and increase TEM client checkin times?

2

(imported comment written by martinc)

This is something that I opened a PMR for a while back and was told to open an enhancement request:

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=28590

This is also a similar issue we had with old sites that were deleted. We were given some steps to delete the sites from the server and that helped with that situation.

The one thing you may be able try is to adjust the CPU settings for the client. We did bump it to 5% and it did seem to be a bit better.

3

(imported comment written by cstoneba)

voted. It’s a huge problem. Our clients take 4hours+ to checkin for the first time because they have to waste time evaluating all the old operators that no longer exist.

4

(imported comment written by cstoneba)

IBM-ers, do you have any solutions for a workaround? My customers are quite unhappy that they have to wait nearly 5 hours before they can see their endpoints in their TEM console.

5

(imported comment written by martinc)

Not an IBMer, but here are a couple suggestions

  1. As stated previously, increase the CPU utilization. You can have this set in the registry when you install the TEM agent so that it is not set by a policy action.

  2. Limit the initial sites that an agent is subscribed to. One way I did this was to create a folder on a system that would flag it as being recently built. I would then use this folder to exclude it from sites like “Patches for Windows” and also for any patch policy actions. This would be part of the build process which would run scripts and as a final step remove that folder.

I was thinking about testing out removing operators in my lab to see what would happen, but this would be totally unsupported and probably not recommended at all :slight_smile:

Martin

6

(imported comment written by cstoneba)

hi Martinc. Agreed, increasing BESCLient CPU utilization would probably help, and site subscriptions would help from a content perspective, but my problem is that those would be ( in my opinion) workarounds to a deficiency; that TEM is waisting time evaluating console users that no longer exist.

7

(imported comment written by martinc)

Totally agree. That is what I said to the support person in the PMR I had open. :slight_smile:

I was able to get something that removed old sites that were deleted, but never anything for old operators.

8

(imported comment written by Tim.Rice)

I voted for the RFE and urge anyone who wants to see this resolved to do the same. To vote for the RFE use the link at the bottom of the RFE page.

9

(imported comment written by jgstew)

We also have this problem. One workaround is to use the .exe installer with a clientsettings.cfg file that sets more aggressive default settings right away. This can also be done with the .pkg installer on the Mac. The use of the clientsettings.cfg file is not possible with the MSI installer.

We use the following task in the MasterAction site deployed to All Computers to speed up provisioning particularly in the case of the MSI installer which will not have any of these settings in place:

http://bigfix.me/fixlet/details/3674

It is recommended that you then reduce the WorkIdle after initial provisioning is completed. This could be done with a task that is relevant on machines with a subscribe time of action site > 1* days

I have not tested this in a long time, but I recall initial provisioning times when using the .EXE installer and a clientsettings.cfg file that matches what is being set in the “Recommended Client Settings - Initial Provisioning Speed up” task, Initial provisioning took ~15 min down from many hours.