DEV Community: Dmytro Poliakov

Beyond the "Access Denied": A SysAdmin’s Guide to SCCM Client Push Failures

Dmytro Poliakov — Tue, 14 Apr 2026 07:52:27 +0000

The struggle is real. You click "Install Client" in the MECM console, and you're met with a wall of silence. No client, no errors in the console, just a "No" that refuses to turn into a "Yes."

I spent the last few weeks troubleshooting some particularly nasty deployment issues: from Kerberos "ghosts" to security agents that act like brick walls. I decided to document the entire process on my blog, Hidden Obelisk, to help anyone else currently staring at a cryptic ccm.log.

What’s inside the deep dive:

Decoding ccm.log: How to find the specific "Request Block" and identify the "Cliff", the exact line where the installation dies.
The Kerberos Trap: Why a simple time drift (even 5 minutes) can make a healthy network look like it's completely broken.
The Hidden Blocker (AV/EDR): A real-case analysis of how ESET and other security solutions can silently kill a Client Push, throwing misleading error codes.
Registry Surgery: Fixing orphaned agents by manually correcting the AssignedSiteCode in the SMS\Mobile Client branch.

The "Tambourine" Era Ends Here

Stop guessing and stop relying on "magic fixes." If you want a repeatable, 7-step process to get your SCCM clients deployed successfully, this guide is for you.

Check out the full article here:
👉 Why Your SCCM Client Isn’t Installing: A Step-by-Step Fix

Finding Portable Software Across 10,000 Endpoints When SCCM Wasn’t Enough

Dmytro Poliakov — Sat, 04 Apr 2026 15:48:50 +0000

In a recent legacy cleanup project, I had to deal with a common but tricky problem: portable software that never shows up in standard inventory.

In our case, it was 1C:Enterprise left on user machines over time, often copied and run without installation.

The environment is fairly large (~10,000 endpoints), and even though we rely on Microsoft System Center Configuration Manager, it quickly became clear that not everything was visible.

Some instances:

weren’t listed in installed programs
didn’t appear in SCCM inventory
existed only as portable copies somewhere on disk

To get full visibility, I built a simple detection approach using only native Windows tools:

Group Policy to deploy the logic
Scheduled Tasks running at system startup
A VBScript wrapper for silent execution
PowerShell scanning local drives
Centralized CSV logging
Aggregation into a single Excel report

This approach required no agents and was easy to scale.

In the end, it helped identify 300+ machines with unauthorized or hidden installations that were completely invisible before.

I wrote a full step-by-step breakdown with screenshots and scripts here:
https://www.hiddenobelisk.com/detecting-portable-and-unauthorized-software-with-powershell-and-gpo/

Would be interested to hear how others handle similar cases when standard tools do not show the full picture.

Office 2016 on Windows 11: MSI vs Click-to-Run (A Practical Lab Experiment)

Dmytro Poliakov — Wed, 01 Apr 2026 09:34:56 +0000

Working with legacy Office deployments can sometimes lead to unexpected behavior, especially on newer operating systems.

In a recent lab experiment, I decided to take a closer look at how the MSI-based Office 2016 Volume License version behaves on Windows 11. The goal was simple: reproduce real-world issues and understand what’s actually happening under the hood.

The Problem

In the test environment, Office 2016 (MSI, KMS activated) was deployed on Windows 11 and used in a fairly typical scenario. Files were stored on network shares and accessed through Excel.

The issue appeared quickly. Excel would intermittently freeze when working with files over the network. Everything looked correct from a configuration standpoint, but the user experience told a different story.

Interestingly, a Click-to-Run based Office 2016 build in the same environment did not show the same behavior.

The Experiment

Instead of jumping to a full migration or switching licensing models, I decided to experiment within a controlled lab setup.

The idea was to test whether a modern Click-to-Run deployment could improve stability, while still keeping a Volume Licensing activation approach.

To make testing consistent, I used a custom script to handle the installation, configuration, and activation steps.

What Changed

The difference between MSI and Click-to-Run turned out to be more significant than expected.

MSI-based Office 2016 relies on older installation and update mechanisms, while Click-to-Run uses a more modern deployment model with ongoing updates and compatibility improvements.

In practice, this translated into noticeably better stability when working with network-based files.

Results

After switching to a Click-to-Run build in the lab environment, the freezing issues in Excel disappeared during testing.

The same files, same network conditions, and same system were used. The only difference was the deployment model.

From a practical standpoint, this suggests that the underlying installation technology can have a direct impact on application stability.

Takeaways

Deployment model matters more than it seems
MSI-based Office 2016 can struggle on modern systems
Click-to-Run provides better compatibility and stability
Lab testing can reveal issues that are hard to diagnose in production

Full Breakdown

I documented the full process, including the script and configuration used in this experiment:

👉 https://www.hiddenobelisk.com/from-office-2016-to-modern-click-to-run-a-practical-migration-approach-using-volume-licensing-in-enterprise-environments/

Deploying Poorly Packaged Applications with PowerShell and SCCM

Dmytro Poliakov — Tue, 31 Mar 2026 12:01:18 +0000

In real-world environments, not all enterprise software comes with a proper installer.

Recently, I had to deploy a legacy DLP agent that had:

multiple versions across endpoints
different ProductCodes
the same display name
limited documentation
and no reliable upgrade path

Trying to handle this using standard logic in Microsoft SCCM (multiple detection rules, MSI-based upgrades, etc.) quickly became messy.

The Approach

Instead of relying on SCCM alone, I moved the logic into a PowerShell-based installer.

The idea is simple:

Detect if the application is installed
Check the installed version (via ProductCode)
Remove anything that doesn’t match the target version
Install the correct version with required parameters

In SCCM, the detection method stays clean — it only checks for the new version.

Why This Works Better

No need for multiple detection rules
No leftover versions after upgrades
Full control over install/uninstall logic
Works even with poorly packaged or legacy software

Key Idea

Instead of trying to model every scenario inside SCCM, centralize all logic in a script.

This makes deployments more predictable and much easier to maintain.

Full Breakdown

I wrote a detailed step-by-step guide here (including SCCM setup and scripts):

👉 https://www.hiddenobelisk.com/how-to-deploy-poorly-packaged-applications-using-powershell-and-microsoft-sccm/

Automatically create missing PTR records in Windows DNS using PowerShell

Dmytro Poliakov — Mon, 30 Mar 2026 07:15:24 +0000

Dealing with DNS inconsistencies can be frustrating, especially when PTR (reverse DNS) records are missing for existing A records.

This is a pretty common issue in Windows DNS environments, and it can cause problems with:

Reverse lookups
Email systems
Monitoring and security tools

I ran into this recently and decided to automate the fix.

What the script does

Scans DNS zones for A records
Detects missing PTR records
Automatically creates PTR entries

It’s a simple approach, but it helps keep forward and reverse DNS in sync.

Example usage

Run the script in PowerShell with administrative privileges:

.\create-missing-ptr.ps1

Why this matters

In many environments, PTR records are often forgotten or not created automatically.

Fixing this manually is time-consuming, especially in larger networks.

Automating it saves time and reduces errors.

GitHub repository

Servant-of-Inos / create-missing-ptr-records

Automatically create missing PTR records from A records using PowerShell (Windows DNS)

DNS PTR Record Auto Create Script

This PowerShell script automatically creates missing PTR (reverse DNS) records for existing A records in a Windows DNS environment.

Useful for maintaining DNS consistency and avoiding reverse lookup issues in enterprise networks.

Features

Scans DNS zones for A records
Detects missing PTR records
Automatically creates PTR records
Helps maintain forward and reverse DNS consistency

Use Case

In many environments, PTR records are not always created when A records are added.

This can cause issues with:

Reverse DNS lookups
Email systems
Security tools
Network troubleshooting

This script helps fix that automatically.

Usage

Run PowerShell as Administrator
Execute the script:

.\create-missing-ptr.ps1

Review output and confirm changes

Requirements

Windows DNS Server
PowerShell
Administrator privileges

Full Guide

For a detailed step-by-step explanation, see the full article:

👉 https://www.hiddenobelisk.com/how-to-automatically-create-missing-ptr-records-for-a-records-in-windows-dns-powershell-script/

Disclaimer

Test in a safe environment before running in production. Use at your own risk.

View on GitHub

Full guide

I also wrote a full step-by-step explanation here:

https://www.hiddenobelisk.com/how-to-automatically-create-missing-ptr-records-for-a-records-in-windows-dns-powershell-script/

How do you usually handle PTR record management in your environments — manual, scripts, or something else?

Mass phishing cleanup in on-prem Exchange with PowerShell

Dmytro Poliakov — Sat, 28 Mar 2026 19:23:20 +0000

Dealing with phishing incidents in on-prem Exchange environments can quickly turn into a nightmare, especially when you need to remove malicious emails across multiple mailboxes.

Manual cleanup is slow, error-prone, and not really an option when time matters.

Recently I had to handle exactly this situation, so I put together a simple PowerShell script to speed things up.

What the script does:

Searches for phishing emails across mailboxes
Removes them using Exchange Management Shell
Helps automate incident response

Nothing overly complex, but very useful in real-world scenarios.

Example usage

Run the script from Exchange Management Shell:

powershell:
.\cleanup-phishing.ps1

Why this matters

If you've ever dealt with phishing in a corporate environment, you know how painful cleanup can be.

Automating even a small part of the process can save a lot of time and reduce human error.

GitHub repository

You can find the script here:
https://github.com/Servant-of-Inos/exchange-phishing-cleanup-script

Full step-by-step guide

I also wrote a detailed guide explaining how it works and how to use it safely:

https://www.hiddenobelisk.com/mass-phishing-cleanup-script-for-on-premises-exchange-2010-2016-2019/

Curious how others handle phishing cleanup in Exchange — do you rely on scripts, tools, or manual processes?