Despite not being a kernel driver, Microsoft has added the Everything search app from voidtools to their Recommended Driver Block Rules in the January 14, 2025 Windows security update. Trying to run the Everything.exe is prevented with the message, A certificate was explicitly revoked by its issuer. Discussion around the issue first showed up on the voidtools forums a couple of weeks ago, with the cause being brought out on January 16.

Looking into the newly updated blocklist shows voidtools as being added:

<Signer ID="ID_SIGNER_VOIDTOOLS" Name="voidtools (Thumbprint: 4DA2AD938358643571084F75F21AFDDD15D4BAE9)">
<CertRoot Type="TBS" Value="2AAA2A578BDEB2F1DBAAE27B6358B87D14143B7FA98518A6AC576172677225AC"/>

Some Everything users have found a way to remove the certificate signature from the Everything executable to temporarily work around the block.

Is Microsoft overreaching by blocking a well-known search utility?

By setting up federation with Google, you can allow invited users to sign in to your shared apps and resources, such as SharePoint, with their own Gmail accounts, without having to create Microsoft accounts.

In testing, I received an error of AADSTS165000 when trying to access a shared file with an invited external guest user with a Google Gmail account. The issue ended up being a case-sensitive issue when adding in authorized redirect URIs to the Google developer project. The directions from Microsoft on how to create the project are available here, and one of the redirect URIs needs to be https://login.microsoftonline.com/te/<tenant name>.onmicrosoft.com/oauth2/authresp (where <tenant name> is your tenant name). If you copy your tenant name right out of the Azure Active Directory Portal area, the name will likely have a mix of uppercase and lowercase letters. If you leave it as is when entering the URL, users will receive the error code above when trying to access the resource. This authorized redirect URI needs to be entered as completely lowercase to resolve the issue.

File Searcher by Owner, the number one utility for finding files and folders owned by a particular user or group, is now open source and available on its GitHub repo.

Download the latest version here!

NetBox is one of the best IP Address Management (IPAM) and data center infrastructure management (DCIM) tools available. It is an open source web-based application that will only cost you the time and resources to set up an internal server. However, while there is step-by-step upgrade documentation available, it can be ambiguous at times and also misses some important steps resulting in errors and service start failures (e.g., "Service Not Found" errors). The following guide will help you to make sure your upgrades are successful and will provide tips on how to troubleshoot problems that may arise.

Although NetBox can run on CentOS, we highly recommend Ubuntu since the CentOS Project is sadly transitioning away from their traditional solid Linux distro to their new CentOS Stream distro which tracks ahead of Red Hat Enterprise Linux (RHEL) development. Therefore, the steps in this guide will be tailored toward Ubuntu Server. However, the ideas behind this guide can be transferred to a CentOS installation of NetBox as well.

Read on for the guide...

I recently wrote a PowerShell script for Windows that will check if a program or update is installed and, if not, download it using BITS in low priority, verify the download hash, and then install it and copy the verbose log to a central repository. The example is for the current latest Microsoft Surface Pro 7 firmware, but it can be adapted for just about any installer. 

Read on for the script code...

There are many different Git workflows out there. Gitflow has been one of the most popular for a decade now, especially for open source projects. It provides a standardized branching mechanism with a lot of flexibility. However, it is not recommended for projects that desire to maintain a single version in production. On the other end of the spectrum, GitHub flow is another popular branch-based workflow that simplifies the development workflow and is very friendly for continuous integration and continuous delivery (CI/CD). A major downside to Github flow is that features are merged directly into the Master/Main branch which greatly increases the probability of bugs or unstable code being released into production. It also may not be the best workflow for open source projects, which we at the The Grim Admin are full supporters of. Since all features are merged directly into the production branch, you need to really trust all of your developers and that can be hard at times when dealing with open source projects.

For our projects, most of the time we implement a simplified version of the Gitflow model. This modified workflow aims to be simpler in that it cuts out the release branches, which are unnecessary when maintaining a single version in production workflow. The Master/Main branch will always be the latest stable version released and tagged with an updated version number anytime the Develop branch is merged into it. Rebasing will occur if we need to streamline complex history.

How Does it Work?

As stated above, it's basically the Gitflow model without the release branches. There are two lifelong branches. The master branch stores the official release history, and the develop branch serves as an integration branch for features.

• Master/Main: Always the latest live branch containing the production code. When the Develop branch is merged into it, the Master/Main branch will be tagged with the latest release version number. 
• Develop: The Develop branch is a one-time branch off of Master/Main and contains the complete history of the project. All features will be merged into into this branch and when reviewed will make their way to the Master/Main branch.

While these two branches are continuous branches that last for the life of the project, the next two branches are created and only exist until they are merged back into either the Master/Main or Develop branches.

• Hotfix: This is a branch created directly off of the Master/Main branch and should only be used if you need to quickly patch production releases. Having a branch for critical bug fixes allows you to address serious issues without having to wait for the next feature release or interfering with ongoing development. Hotfixes are not the norm and should be an exceptional case. When ready, hotfixes will be merged onto both Master/Main and Develop branches. 
• Feature: Each new feature will reside in its own branch created off of the Develop branch. A new feature branch can also be created for non-critical bugs in released code that can wait until the next planned release. If possible, feature branches should not be very long-lived. Once ready for code review, a merge/pull request should be made to merge your commits into the Development branch.

Conclusion

This workflow is nice because contributors only need to worry about two types of branches: Hotfix & Feature. A detailed Git history is available on the Develop branch, while the Master/Main branch is always the latest production version ready for install or download AND is tagged so as to easily find previous release versions. This also works well for open source because of the extra layer of code review.

We'd love to hear your thoughts in the comments!

This popular screensaver utility has been updated! Two versions have been released:

1.6.3 (2020-06-15) - The final version that runs natively on older operating systems, requiring either .NET 2 or 3.5.

• General
  • Huge rewrite of a number of parts of the application to increase stability and remove some rare error messages.
• Bug/Security Fixes
  • Hid action button if option "CancelOnMouseMove" is enabled.
  • Fixed issue where you can't have both "CancelOnMouseClick" and "CancelOnMouseMove" enabled at the same time.

2.0.3 (2020-06-15) - Includes all the updates from version 1.6.3 and has been converted to run natively on newer operating systems.

Download the latest versions of Screensaver Operations

After many years, we've released the next version of File Searcher by Owner!

File Searcher by Owner is the number one utility for finding files and folders owned by a particular user or group.

Download File Searcher by Owner 2.0

Much of the code has been rewritten and there are a number of new features in this release:

Version 2.0.2.0 (2020-05-15)

• General
  • New major version 2.x
  • Upgrade .NET to 4.5.1
• Bug/Security Fixes
  • None
• New Features
  • Added filename column to search list view
  • Dropdown at bottom right to convert from bytes to kB (kilobyte), KiB (kibibyte), MB (megabyte), MiB (mebibyte), etc. all the way up to YB (yottabyte) and YiB (Yobibyte)
  • Easily set owner on found files from the search list view
  • Logging - click red (i) button at top-right

Known Issues

• Minor: Right-click "Send To" options fail to work
• Minor: Option to convert owner string from SID/SAM to User Principal Name (UPN) is unavailable when run on a Domain Controller or non-domain computer

Upcoming Features

• Search all files in a directory and see the current owners.
• Search for multiple owners at the same time.
• Save log file (for now you need to copy and paste the text to another platform or app)
• Add path & owner to log of searches
• Add date created/modified/accessed fields

OK. Here is how I deployed the AlwaysOn VPN in device tunnel (rather than user tunnel) using PowerShell. Continue on for the steps...

If you're like me, you've run into the following set of errors when trying to use CMake on Windows and especially when trying to compile Python code:

-- Building for: NMake Makefiles
-- The CXX compiler identification is unknown
-- The C compiler identification is unknown
CMake Error at CMakeLists.txt:131 (project):
  The CMAKE_CXX_COMPILER:

    cl

  is not a full path and was not found in the PATH.

  To use the NMake generator with Visual C++, cmake must be run from a shell
  that can use the compiler cl from the command line.  This environment is
  unable to invoke the cl compiler.  To fix this problem, run cmake from the
  Visual Studio Command Prompt (vcvarsall.bat).

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.

CMake Error at CMakeLists.txt:131 (project):
  The CMAKE_C_COMPILER:

    cl

  is not a full path and was not found in the PATH.

  To use the NMake generator with Visual C++, cmake must be run from a shell
  that can use the compiler cl from the command line.  This environment is
  unable to invoke the cl compiler.  To fix this problem, run cmake from the
  Visual Studio Command Prompt (vcvarsall.bat).

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
  the compiler, or to the compiler name if it is in the PATH.

Read on for instructions on how to get past this error...