This was a whole month and a bit ago, and I never got around to throwing it here on the site, but I will now announce that I am a Red Hat Certified System Adminstrator!

It’s a tough day for some at Mozilla, I imagine, with pretty much all Firefox add-ons suddenly being disabled due to an expired intermediate certificate.

I love Firefox. I love having a browser that is not increasingly proprietary (*cough* Chrome *cough*), and so I too was hit by this issue.

Mozilla rolled out a fix using their studies system, and users were told to go to about:studies and it would show up within 24 hours.

My about:studies was a blank white page. Not a blank list of studies with the explanatory text — an entirely blank page. Here’s what it should have looked like:

I delved into the Firefox source code to see if I could track this down.

Running Firefox with the -jsconsole switch revealed errors relating to IndexedDB and the Top Sites component. Initially, I ignored these, but it turns out they were likely symptoms of the same problem.

In the end, I found toolkit/components/normandy/lib/AddonStudies.jsm, which I believe is the backend that the about:studies frontend JavaScript code talks to.

const DB_NAME = "shield";
const STORE_NAME = "addon-studies";
const DB_OPTIONS = {
  version: 1,
};
const STUDY_ENDED_TOPIC = "shield-study-ended";
const log = LogManager.getLogger("addon-studies");


/**
 * Create a new connection to the database.
 */
function openDatabase() {
  return IndexedDB.open(DB_NAME, DB_OPTIONS, db => {
    db.createObjectStore(STORE_NAME, {
      keyPath: "recipeId",
    });
  });
}

So, I knew I was looking at IndexedDB and I needed to locate what was happening with this particular shield database.

This StackOverflow answer was old, but gave me a hint of where to look. In the Firefox profile folder, there is storage/permanent. Inside here, a number of subfolders, including chrome (no, not Chrome — chrome) and other folders relating to devtools.

I noticed that in the chrome folder, I had four files for two different databases. Each database had a .sqlite-wal file and a .sqlite-shm file. This didn’t seem right — these are an index and a write-ahead log, but where is the actual data file? There should be a .sqlite file as well with the actual data for both databases.

So, I deleted these four .sqlite-wal and .sqlite-shm files from my profile (after a backup, of course, and when Firefox was not running).

A restart of Firefox later — several databases were regenerated and reappeared in that folder. Critically, about:studies was no longer blank and displayed as it should have — albeit with no studies yet.

A Fix? A Workaround?

Performing these steps may cause your Firefox profile to be irreparably damaged. This is an advanced and entirely unsupported process. Proceed at your own risk and only with a backup.

Great caution should be exercised here — I don’t know what these chrome IndexedDB databases contain, or should have contained. In any case, I’m pretty sure that the absence of the .sqlite file but the presence of the wal and shm files meant that Firefox was unwilling to delete them and start again for fear of losing something.

However, if you are experiencing the same problem:

• Quit Firefox
• Go to your Firefox profile folder
• Back up your profile
• Inside the profile folder, go to storage/permanent/chrome/idb
• See if you have any .sqlite-shm and .sqlite-wal files without a corresponding .sqlite file
• If so, move the .sqlite-shm and .sqlite-wal files elsewhere on your disk, away from your Firefox profile, and restart Firefox
• See if about:studies is no longer a blank page

A recent upgrade to System Center Operations Manager, taking it to the new 2019 release, perhaps combined with an update to the Windows Server management packs, created an interesting issue.

On the management server, an alert was triggered about the management server itself:

Resolution State: New
Alert: Server Service: File and Printer Sharing Ports Blocked
Source: SCOM (SMB)
Path: SCOM.fqdn
Last modified by: System
Last modified time: 3/13/2019 2:14:28 PM
Alert description: Either Windows Firewall is disabled or the firewall inbound rules for TCP ports 445 or 139 are disabled.

Interesting. Did the upgrade to SCOM 2019 or the management pack somehow break Windows File Sharing? And if it did, why hadn’t we noticed more significant issues than just this alert?

Well, no — it looks like this alert is actually earlier from March, but perhaps the alert has re-surfaced, post upgrade, as the monitor re-evaluated. What I was sure about, however, was that the file sharing ports were indeed open and that this alert couldn’t be correct!

Right? Right?

To the Firewall!

Investigating all the relevant firewall rules revealed that everything was in order — Windows File and Printer Sharing exceptions were allowed, as appropriate, across the board.

What is it Detecting?

So, it was time to dig a little deeper.

I was able to go to the Alert details and click on the Alert Monitor to drill down and find the details of how the monitor was coming to this apparently erroneous conclusion.

I extracted the script and tried running it manually on the server using cscript.

With a few WScript.Echo calls of mine sprinkled in, the relevant part of the VBScript that powered the monitor was as follows:

Dim rule

For Each rule in fwPolicy2.Rules
  If (rule.Protocol = NET_FW_IP_PROTOCOL_TCP) And (rule.LocalPorts = "445") Then
    WScript.Echo("Proto " + CStr(rule.Protocol) + " and port " + rule.LocalPorts + " enabled: " + CStr(rule.Enabled))
    WScript.Echo("rule.Profiles: " + CStr(rule.Profiles) + " and rule.Enabled " + CStr(rule.Enabled))

    If (Not rule.Enabled) And (rule.Profiles And fwCheckProfile )  Then

      WScript.Echo "Setting file sharing ports enabled to true"
      fwFileSharingPortsEnabled = "True"

      Exit For

    End If

  End If
Next

So, let’s go ahead and run this.

The script also checks to see if any non-hidden shares exist on the server and will only put the monitor in an unhealthy state if at least one exists.

It iterates over all the rules for port 445, decides all the rules are enabled, which would allow access to File Sharing, but then ends up with fwFileSharingPortsEnabled still being false.

This propagates to the ultimate script output of a PropertyBag with the value Disabled under PortStatus.

All the rules are enabled, but the result is that it considers the ports not open for business??

Is this Logic?

It seems to me that there is a logic error here:

If (Not rule.Enabled) And (rule.Profiles And fwCheckProfile )  Then

Only if the firewall rule is not enabled and the profile matches the current network profile, we consider the port enabled?

Remember that if the rule is not enabled, traffic would be blocked by the Windows Firewall.

It seems that this might be a simple logic error in the management pack. A comment later in the script even states:

‘ Only if regular share exists and port 139/445 are not open will portStatus be returned as “Disabled”

Am I missing something obvious?

I’d Report This…

I cannot figure out where I should report this, if I’m correct in thinking how this should be working. Should I complain on a forum? Is there a System Center Operations Manager support Short-Form “Bird” Social Media Site Before It Went Terrible profile? Product Support?

An Unorthodox Workaround

For now, disabling at least one of the rules for port 445 suppresses this alert. For example, if you don’t need or want Remote Event Log Management, you can disable the Remote Event Log Management (NP-In) rule. This script will then return Enabled and the alert will not be fired.