How to Verify File Integrity Using PowerShell (SHA256)

When you download ISO files, patches, or software packages, corruption and tampering are real risks. Installing a corrupted infrastructure file, like a VMware ESXi image, will break your system. Don't assume a download finished perfectly—verify it.

Windows has a built-in way to do this using the PowerShell Get-FileHash command.

The Basic Command

To calculate the SHA256 hash of a file, use the following syntax:

Get-FileHash "C:\Path\To\Your\File.iso" -Algorithm SHA256

Real-World Example

Running the command against an ESXi ISO looks like this:

Get-FileHash "C:\Downloads\ESXi.iso" -Algorithm SHA256

Output:

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA256          3F2A9C6D5B3...                                                         C:\Downloads\ESXi.iso

The Hash value is the unique digital fingerprint of your file.

Extracting Just the Hash

If you only need the raw hash string for a script or a quick comparison, wrap the command in parentheses and call the .Hash property. This drops the formatting and path details:

(Get-FileHash "C:\Downloads\ESXi.iso" -Algorithm SHA256).Hash

Automating the Comparison

Vendors provide the expected checksum on their download pages. Instead of manually comparing a 64-character string, let PowerShell do it:

$expected = "PUT_EXPECTED_HASH_HERE"
$actual = (Get-FileHash "C:\Downloads\ESXi.iso" -Algorithm SHA256).Hash

if ($actual -eq $expected) {
    Write-Output "File is valid."
} else {
    Write-Output "File is corrupted or modified. Do not use."
}

Key Technical Details

  • Case-Insensitive: SHA256 string comparisons do not care about uppercase or lowercase letters.
  • Compatibility: This command works natively on PowerShell 5+ and PowerShell 7.
  • Primary Use Cases: Validating ISO files, software installers, and critical patch updates.

Verifying hashes is a mandatory step for secure system administration. Use Get-FileHash to confirm file integrity before moving anything into production.

How to Build a 1-Line PowerShell Ping Scanner (Subnet Sweep)

When you need to know which IP addresses are active on a network, you do not need to download a sketchy third-party GUI tool. You already have PowerShell.

You can perform a full subnet ping sweep in seconds using a single line of code.

However, I will be brutally honest: the standard command most people find online is flawed.

Usually, people suggest this:

1..200 | ForEach-Object { Test-Connection -ComputerName 192.168.4.$_ -Count 1 -Quiet }

That command executes perfectly, but the output is useless. Because it uses the "-Quiet" parameter by itself, PowerShell simply outputs a massive, unreadable wall of "True" and "False". You will not know which IP address is actually returning the "True".

Here is the corrected, practical version that actually tells you which IP addresses are online.

The Corrected 1-Line Scanner

Use this to print the IP address only if the machine responds.

My PowerShell 1-Liner

1..200 | ForEach-Object { $ip = "192.168.4.$_"; if (Test-Connection -ComputerName $ip -Count 1 -Quiet) { Write-Output "$ip is UP" } }

Output :

Stop Wasting Time Clicking "Properties": A PowerShell Script to Find Folders Over 1GB

Windows disk management is fundamentally broken. When your C: drive turns red, the native tools are useless. Clicking "Properties" on every single folder to see what is eating your storage is a massive waste of time.

You need automation. You need to see exactly where the heavy data lives without digging through nested directories.

Here is a straightforward PowerShell script that scans a specific path, calculates the size of every subfolder, and prints a clean, visual tree of anything over 1GB.

The Script

Copy this directly into your PowerShell environment or save it as a .ps1 file

The PowerShell Script

function Get-FolderTreeSize {
    param (
        [string]$Path = "C:\",
        [int]$Level = 0,
        [double]$MinSizeGB = 1
    )

    $folders = Get-ChildItem -Path $Path -Directory -ErrorAction SilentlyContinue

    foreach ($folder in $folders) {
        $size = (Get-ChildItem $folder.FullName -Recurse -File -ErrorAction SilentlyContinue |
                 Measure-Object Length -Sum).Sum

        $sizeGB = $size / 1GB

        # Show only if greater than 1 GB
        if ($sizeGB -ge $MinSizeGB) {
            $indent = "  " * ($Level * 2)
            $sizeFormatted = [math]::Round($sizeGB, 2)

            Write-Output "$indent|-- $($folder.Name) [$sizeFormatted GB]"

            # Go deeper only for large folders
            Get-FolderTreeSize -Path $folder.FullName -Level ($Level + 1) -MinSizeGB $MinSizeGB
        }
    }
}

# Run for Program Files
Get-FolderTreeSize -Path "C:\Program Files" -MinSizeGB 1

How It Works

This is not a complex script, but it is highly efficient. Here is exactly what it is doing

  • Targeted Scanning ($Path): It starts at your designated path. The example above defaults to checking C:\Program Files.

  • Silent Error Handling (-ErrorAction SilentlyContinue): Windows will block access to system or hidden folders. This parameter tells the script to ignore those access denied errors and keep moving, rather than filling your screen with red text.

  • Math on the Fly (Measure-Object): It looks inside every folder, grabs the byte size of every file, adds them up, and divides by 1GB to give you a readable number.

  • Recursive Logic (Get-FolderTreeSize calls itself): If it finds a folder over 1GB, it dives into that specific folder to see what is causing the bloat, automatically indenting the output so you can read it like a map.

How to Run It

  1. Open Windows PowerShell (Run as Administrator if you want to scan restricted system folders).

  2. Paste the entire block of code above and press Enter.

  3. The script will immediately output a clean list of every folder over 1GB in your Program Files.

If you want to scan your entire C:\ drive instead, just change the last line to: Get-FolderTreeSize -Path "C:\" -MinSizeGB 1

Why Your Strong Cloud Architecture is Bleeding 30% of Your Budget

Companies waste thousands of dollars on complex FinOps tools and third-party consultants, hoping for a magical fix to their escalating cloud bills. It is a waste of time and money.The reality is uncomfortable: you do not need advanced FinOps to save money in Azure. You just lack basic operational discipline.

Most cloud inefficiencies are not the result of poor architectural design; they are the result of laziness. You can solve the vast majority of your Azure cost overruns by enforcing three simple practices.

1. Cost Dashboards: Stop Flying Blind

You cannot fix what you refuse to look at. If your engineering team does not know what their infrastructure costs on a daily basis, they will not optimize it.

You do not need a custom-built, AI-driven analytics platform. Use native Azure Cost Management dashboards. Put the numbers on a screen where the team can see them. Make the daily burn rate visible to the people actively provisioning the resources.

2. Strict Tagging: No Owner, No Resource

Untagged resources are financial garbage. If an Azure resource is running without a designated owner, project, or environment tag, it is a liability.

Implementing a tagging strategy is not a technical challenge; it is a management challenge. Enforce a strict policy today: if a resource is not properly tagged, it gets shut down. Period. When developers realize their undocumented test servers will be deleted, your tagging compliance will hit 100% overnight.

3. Monthly Reviews: Enforce Accountability

Cost optimization is not a one-time project. It is a recurring operational requirement.

Make cloud costs a mandatory line item in your monthly engineering reviews. Force team leads to justify their spend. If the bill went up 15% this month, they need to explain exactly why. When people know they have to defend their budget publicly, they suddenly become very good at turning off idle virtual machines.

Simple Practices. Large Impact.

Stop looking for a complex FinOps silver bullet. Start doing the basics. Build the dashboards, enforce the tags, and hold the reviews. The discipline alone will solve your cost problems.


Scaling the Metal: Building a GPU Observability Stack from Scratch

Most people take the easy route with managed Kubernetes and cloud-native monitoring. I didn’t. I built a full GPU Observability Stack on bare metal. No AWS, no GCP, no safety nets—just five nodes and a mountain of YAML.

The Architecture : The setup spans a 5-node bare-metal cluster (1 master, 4 workers). To simulate a high-performance environment, I’m running 16x simulated NVIDIA A10G GPUs.

The stack is built on three pillars:Metric Collection (DCGM Exporter): The core engine. It interfaces directly with the NVIDIA drivers to expose hardware-level telemetry.

Storage & Querying (Prometheus): Scrapes the DCGM endpoints and stores time-series data.

Logging (Loki): Captures the "why" behind the "what," pulling logs from every pod to correlate errors with performance spikes.

Visualization (Grafana): The single pane of glass for real-time health.

Current Cluster Performance :

After 12+ hours of continuous, stable metric collection, the numbers are in:

MetricStatusAllocated :  GPU Memory  92.1 GB

Avg. GPU Utilization 46.3%

Uptime (Metrics) 12h 14m

Why Bare Metal?

Cloud services hide the complexity, but they also hide the bottleneck. By running this on-prem:

Zero Latency: Metrics don't travel over the public internet.

Full Control: I control the driver versions, the kernel parameters, and the hardware interrupts.

Cost Efficiency: No "managed service" tax for high-bandwidth GPU telemetry.

Troubleshooting : Check pod status and reason

kubectl get pods -n monitoring
kubectl describe pod  -n monitoring
# Look for: Events section at the bottom — it tells you exactly why it failed
Check pod logs
kubectl logs  -n monitoring
kubectl logs  -n monitoring --previous
# --previous shows logs from crashed container
Prometheus Not Scraping GPU Metrics .Check if DCGM service is reachable
kubectl get svc -n gpu-operator | grep dcgm
kubectl port-forward svc/nvidia-dcgm-exporter -n gpu-operator 9400:9400 &
curl http://localhost:9400/metrics | head -20
kill %1
Check scrape config was applied
kubectl get secret -n monitoring | grep prometheus
kubectl describe prometheuses -n monitoring
Check PrometheusRule was created
kubectl get prometheusrule -n monitoring
Check label matches
kubectl get prometheusrule gpu-alerts -n monitoring -o yaml | grep labels -A5
# --Must have label: release: kube-prometheus-stack
 

#Kubernetes  #GPUInfrastructure  #Prometheus  #Grafana  #DevOps  #MLOps  #Infrastructure #Observability  #SelvamaniS

Latency problem destroying your hybrid cloud performance

What if the latency problem destroying your hybrid cloud performance has nothing to do with your cloud provider, your datacenter, or your network gear and everything to do with a single architectural assumption nobody questioned?

A few years ago, I was working on a platform integrating private datacenters with cloud infrastructure across multiple regions.

On paper, the architecture was solid.
Cloud scalability. Datacenter control. Secure connectivity.

Then the symptoms started appearing.

Latency spikes hitting 380ms on workloads designed for sub-10ms internal response.
Intermittent application slowdowns with no clear infrastructure failure.
Support tickets blaming the cloud. The network team blaming the apps. The app team blaming the network.

Nobody was wrong. But nobody was finding the real problem either.

After weeks of tracing, we found it.

Cloud services were architected assuming low-latency local environments.
Datacenter workloads assumed stable, predictable internal netw orks.
Hybrid introduced something neither side had designed for a third failure domain that lived between them.

The WAN was being treated like a local backplane. Every cross-environment call paid the latency tax. Repeatedly. Silently. Until it wasn't silent anymore.

We redesigned with one principle: architect for the worst connection, not the best.

Critical workloads were repositioned closer to their data dependencies.
Network paths were simplified fewer hops, explicit traffic engineering.
Cross-environment calls were audited and reduced by 60%.

Latency dropped from 380ms average to under 40ms within two weeks.

The lesson that stayed with me:
Hybrid cloud isn't just a cloud strategy.   It's a networking and architecture discipline  and most teams only discover that after something breaks.

Has your team hit a hybrid connectivity problem that looked like something else entirely? What was the real root cause when you found it?

- Selvamani S

#HybridCloud #CloudArchitecture #InfrastructureEngineering #EnterpriseIT #Networking #SelvamaniS