Windows 1903 and Bigfix Clients

Im seeing multiple cases where after a Windows 1903 upgrade, before the users logs on for he 1st time after the upgrade to see the “Hi, We’ve got updates for you” message, the bigfix client goes to “sleep” and greys out on the console.
Wake on Lan wont wake, them, and the power settings are set to not allow windows to turn off the ethernet adapter,
Typically I can remote to the endpoint with Bigfix (Tivoli ) Remote control and log in and then restart the computer and sometimes, a second reboot is necessary…
Using the lates client 9.5.13 and server infrastructure.
the services,msc show the clients “running” along with the Client helper tool
If I hadnt got the Remote control function, these machines are not reachable with the clients in this catatonic state. Anyone else seeing this kind of behavior?

Your first step is to enable Client Debug Logging so you can see if the client is actually processing anything.

We’ve updated a few systems to 1903 manually (not using BF) and didn’t seem to have any issues with the client (using 9.5.12).

Thanks Alexa… Im actually using an edited version of your 3 stage 1809 files but replaced the iso with the 1903 one etc.
Just need to stagger that restart etc.
Ive turned on the logging… I’ll take a look at the results.

Oh. In that case, take a look Windows 10 1803 Update at this thread. We talk about 1903 being a more stable install and not affected by the “bug”. So the install itself can now utilize the /norestart switch and BigFix Post-Action verbiage can be used.

That being said, I’ll be looking forward to the release of the BigFix 1903 native update fixlets.

1 Like

I have a snippet from logs… its a bit odd that twice, a machine stalled at the same point after the 1903 install
the point at which it stops, is

Tue, 23 Jul 2019 14:56:47 -0400 Evaluate unprocessed file Windows Defender/Analyses.fxf
Tue, 23 Jul 2019 14:56:47 -0400 DebugMessage EvalLog Windows Defender.Analyses.fxf@00000000:Background Evaluation
Tue, 23 Jul 2019 14:56:47 -0400 DebugMessage EvalLog Windows Defender.1000:Background Evaluation

its almost like its timing out and the endpoint never recovers, greys out until rebooted and then starts the process again.

We are seeing the same thing with Win 10.1903 with our testing here where I work.

We have seen the same Debug Messages and the BES Client stops responding under Win10.1903. If you run the Relevance through the QnA debugger it apparently does the same thing. I copied all of the property relevance clauses from the “BigFix Manager for Windows Defender” Analysis into a .QNA file and had our Workstation Engineers try it, but it won’t respond. They have not yet tried each element by itself. I’m working on a way to get my hands on a 1903 system to do some testing.

My initial reaction was to update the local subscription relevance to the “BigFix Windows Defender” site to exclude the 1903 systems until we can identify either the cause or a better workaround, or hopefully HCL updates something.

2 Likes

I just played with it a bit and the problem seems to be the following Relevance (using the 9.5.13.130 FixletDebugger) …

(exists select objects "* from MSFT_MpComputerStatus" of wmis "ROOT\Microsoft\Windows\Defender" | false)

It’s not returning a result on systems with 1903 installed (hanging). Even in the FixletDebugger, it hangs the debugger and you have to force it to quit. On my non-1903 Win10 system it returns “false” (since I don’t have Defender installed).

Guess this deserves a ticket to Support ticket with HCL.

I’ll open a support ticket and see where it goes.

2 Likes

I just wanted to say this is some great debugging and is definitely worth filing a support ticket. WMI queries are always a bit dangerous to use in relevance, as they are prone to spawning new processes and to slow evaluations or hangs.

1 Like

WMI can also be very dependent on the specific OS configuration (including drivers and other services that add themselves to the WMI chain) and has been unstable in some cases in the past so you might be asked if this is common among all endpoints or if its specific configurations

I’ve opened a Case with HCL and have sent them the Debug Logs, along with details from my testing so far.

2 Likes

Thanks @TimRice … Much appreciated.

Just after the update of the Windows 10 I noticed that my Skype was causing some problem and that too with the mic, so I tired a lot to Fix Skype Mic Not Working problem so that I can work with the application again.

This is possibly the Windows 10 Microphone and Camera privacy setting…
Its a registry setting that allows apps to access Mic and camera and also available in Settings.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppPrivacy
LetAppsAccessMicrophone It should be set to 0
LetAppsAccessCamera Also set to 0

OK, I finally got a reply from HCL about this issue. Basically, because the content is hosted on an xForce server that they have no control over, there is nothing that they can do in the short term. I’m going to copy the content out of the site and put it into a “local” site that I can control better. I’m still going to leave the relevance set to exclude the Win10.1903 systems until I can come up with a better solution for detecting Windows Defender on them, but that will have to wait a while.

I’ve asked for an RFE to be created (apparently the RFE portal is not quite ready for primetime). Once I know the details for the RFE, I’ll post it back here. As with IBM, the more people that “Vote” for an RFE, the more likely the developers are to start working on it.

Actually, the plan to get get ALL the appropriate App Exchange content picked up by HCL if possible.


Hi Tim,

As a follow up to my voice mail this is the response I received from the Product Management team :

As you’ve noted, the BigFix integrations on App Exchange with 3rd parties (other than with IBM products) are no longer hosted and available. There are two elements with that:

  1. The Apps/integrations are no longer available for download from App Exchange itself (so, no one else can try to get access to the content)
  2. The content/sync servers that hosted the content in question are on xforce.com domains which we no longer own. Which means that even if we wanted to publish a bug fix/update to the content in question, we can’t do so.

So, with that background, we are exploring the migration of these Apps, but it will take some time.

My recommendation in the interim is for affected customers to adjust Computer subscriptions to the site, or perhaps better yet to export content of interest to an interim custom site (as the previous external site is essentially no longer updateable).

I will provide further interim recommendations via the Forum.

All we can really do at this point would be to open an RFE, and a forum post for that RFE to get other users of the App Exchange content that is no longer available to sign up to the RFE to get more leverage for a speedier resolution.

I just received this from HCL Support … They created an RFE for me for this subject. Still no way for anyone to view it or vote on it. Time will tell! :slight_smile:

Your RFE has been submitted to the product development team who will review your input and provide status updates as decisions are made regarding the request. Currently, there isn’t a way to view the RFE already submitted or to subscribe to them.

The product Offering Management team will provide status, inform you if the requirement has been accepted and, if so, will provide a time line for resolution, and the delivery vehicle.

Thanks @TimRice Much appreciated… I think we added the 1903 relevance to be ignored in the original site in the master admin console. Had to get a boat load of machines to reboot to call home to sync the site but it seems better

For anyone seeing the issue with Windows Defender please email me and let me know so I can update the Product Team with a better count of affected customers.
Thanks
Dave Langridge BEM
david.langridge@hcl.com