9.2 Patch 3 for IBM Endpoint Manager Platform

Release Announcements Platform (Release Announcements)
1

The IBM Endpoint Manager team is releasing 9.2 Patch 3 (9.2.3.68) of the IBM Endpoint Manager platform. The main feature of this release is the introduction of 64-bit support for the Windows server components (allowing the components to access more than 4 GB of memory). There are no security fixes in this patch release.

9.2 Patch 3 (9.2.3.68)

Changelist

  • 64-bit support for Windows server components (Server, Console, Web Reports, FillDB, and BESAdmin)
  • Fixes for general platform issues

More information by reading the full technical changelist at:

Components Affected

Server components and related tools. Agents and Relays are not included in this release.

Upgrade

Downloads and release information are available at:

Upgrade fixlets are available in BES Support version 1206 (or higher).

4 Likes
3

Thanks for the update. Our Dev instance updated without incident however, I am seeing a couple of issues…
1: Time taken for clients to report in is very very slow and secondly, Web reports have stopped with a message that No web reports are aggregating this database.

4

Could you file a PMR with this issue? To expedite the resolution, attach the Root Server, Web Reports Server, and FillDB logs to the PMR.

5

We have this update in production now.

No issues that I am aware of, other than some ongoing console performance issues, which may have improved somewhat, but seem to still be present.

6

I’ve noticed starting with version 9.2 that when a taking an action with a parameter query the button “Cancel” is active by default, meaning if I press enter from on my keyboard cancel is chosen. I’ve seen this behavior on multiple systems and it seems any console running 9.2 has this behavior.

This is frustrating for our users, who are used to being able to enter the value and press enter (which will now choose cancel).

Does anyone know if this was intentional? Is there a way to reverse this and have OK be active by default?

2 Likes
7

I did notice this recently. Definitely odd, but I could see why you might want the default to be cancel.

8

I upgraded Friday afternoon, and I’m seeing issues where Actions that are targetted Dynamically (by Group, or Dynamically to “All Computers”) do not seem to be taking effect on clients. 20 minutes after sending the Action, I still have no reported computers. Has anyone else seen such behavior?

Actions targetted to individual computers seem to be executing as expected.

9

I am also seeing this behavior. The majority of the clients are at 9.2.1.48, with some at 9.2.2.21, and a few at 9.2.3.68. None of them show up as reported if the target is dynamic by property.

10

What I found was that the BES Sites at Program Files (x86)\BigFix Enterprise\BigFix Server\wwwrootbes\bfsites were not getting updated. The modification dates on all of the directories & files stopped updating at the time of the upgrade.

The server’s logfile.txt referenced many “no response to SQL Query” error messages.

I ended up rebooting the BigFix server. So far it’s been working ok since then but I’m just waiting for another occurrence. If any IBM’ers are reading I have PMR 92607,004,000 open on this with some more detailed logfile excerpts.

11

This does sound a bit familiar to something I experienced, but I don’t remember the details.

At one point, making edits to custom sites that otherwise would not be edited just to rev the version number was needed to get them to start propagating again.

12

It appears that the Action with a dynamic target by property is not getting signed. The log is showing an entry:

FAILED to Synchronize - ... - class NotASignedMessage ...

I added a custom null action to test this, with a dynamic target, and a second failure entry appeared in the log.

13

Normally this definitely is signed. Have you tried a different operator? I’d suggest opening a PMR

14

I may need to do that. As I dig into this more deeply, I’m finding that a significant number of sites are missing from the bfsites folder. :confused: .

15

I followed the instructions in this technote to reset all of my sites.

http://www-01.ibm.com/support/docview.wss?uid=swg21687215

This resolved both issues - all of my sites are now populated on the bfmirror, and clients are evaluating the actions which used dynamic targets.

1 Like
16

I just upgraded to 9.2.3 this morning and was surprised to see that there were no update jobs for relays and clients. We have a process that installs the agent on new machines to the environment from the BESInstaller directory and noticed 20-30 machines have the client version 9.2.3.68 but I cannot push the latest version to all the existing clients. I understand if there was no change to the client installer but why would the version change. I always like to ensure my server/relays/clients are all running the same version but it seems like this is one of the first times that relays and clients are on a different version (mine are all 9.2.1.48)

17

It is nice to have everything at the same version, and I would keep doing that when possible, but it is not required. An 8.0 client should work just fine, though with some reduced functionality with a 9.2.3 root.

18

I agree. I was really hoping the Relay components would be bumped up to 64 bit components as well but I guess I will have to wait for a future patch. It is still a little weird that installing the agent from the BESInstaller directory gives you 9.2.3.68 clients but you can’t push it via Fixlet

1 Like
19

Tom, I understand and appreciate the desire to keep all the versions consistent, but we have intentionally changed our strategy here to provide patches for specific components when appropriate. This will give us more flexibility, in general, but most beneficially to add new OS support to our agents without having to wait for a full release of all components.

You’ve probably also noticed that our versioning scheme has changed a bit so the 3rd number in the version represents the patch number directly and each release will increment that number (so you don’t have to care about the 4th number). This should make it much easier to identify what patch levels you’re running (patch 1 is 9.2.1, patch 3 is 9.2.3) vs the older scheme (patch 5 is 9.0.835, patch 6 is 9.0.853). Our intention is to make it easier for customers to understand what they are actually running relative to what we release, and help the support process, since that’s always the first question that’s asked (and surprisingly often misreported).

The issue with the BESInstaller creating a client install package that we don’t release upgrades/fixlets for is one that we intend to fix. Once complete, that should generate an installer for whatever the latest client version is, 9.2.1 in this case.

2 Likes