{ "version": "https://jsonfeed.org/version/1.1", "title": "Jarrett Williams", "home_page_url": "https://jarrettwilliams.com/", "feed_url": "https://jarrettwilliams.com/feed.json", "description": "Practical notes on IT operations, systems engineering, Azure, automation, networking, and datacenter work.", "language": "en-US", "authors": [ { "name": "Jarrett Williams", "url": "https://jarrettwilliams.com/" } ], "items": [ { "id": "https://jarrettwilliams.com/blog/publishing-a-static-site-to-cloudflare-pages/", "url": "https://jarrettwilliams.com/blog/publishing-a-static-site-to-cloudflare-pages/", "title": "Publishing a Static Site to Cloudflare Pages Without Making It a Whole Project", "content_html": "

I like static sites because they are simple in all the ways that usually matter later.

\n

There is no app server to babysit, no database to drag along, and no pile of moving parts that turns a small website into an ongoing maintenance project. If all you need is a blog, portfolio, or personal site, that simplicity is hard to beat.

\n

Cloudflare Pages is a good fit for that kind of setup.

\n

#What Cloudflare Pages actually does

\n

At the basic level, Cloudflare Pages hosts your built site and puts it behind Cloudflare's network. You give it the finished output, and it serves the site over HTTPS on a fast edge platform.

\n

That is really the whole pitch.

\n

If your project builds into a folder like dist, public, or out, Cloudflare Pages can take that output and publish it. You do not need a full application runtime just to serve a few pages.

\n

#Why static is nice for smaller sites

\n

The biggest benefit is not that it is trendy and not even that it is fast, although it usually is.

\n

The biggest benefit is that it keeps the problem small.

\n

If a page looks wrong, you check the generated files. If the domain is wrong, you check DNS. If the deployment fails, you look at the build or the upload step. That is a much easier troubleshooting path than chasing problems through a server process, framework config, database, and hosting panel at the same time.

\n

For a personal site, that matters a lot.

\n

#The basic workflow

\n

Most static-site deployments to Cloudflare Pages follow the same rough pattern:

\n
  1. Write or update the content.
  2. Run the build.
  3. Make sure the output folder looks right.
  4. Publish that output to Cloudflare Pages.
  5. Attach the custom domain and verify the live site.
\n

That may sound obvious, but it helps to keep those steps mentally separate. A lot of deployment confusion comes from mixing them together.

\n
\n \"A\n
A simple way to think about it: build the site, publish the output, then verify the actual domain.
\n
\n

#What "build" means in plain English

\n

When people talk about building a static site, it can sound more complicated than it really is.

\n

In practice, the build step just takes your source files and turns them into browser-ready pages.

\n

That might mean:

\n\n

When the build is done, you are left with a plain folder of files that a browser can read directly.

\n

That is the part I care about most before publishing. If the output is clean, the deploy is usually straightforward.

\n

#A simple example

\n

For a lightweight project, the build may be as simple as:

\n
bash
npm install\nnpm run build
\n

After that, you may end up with something like:

\n
text
dist/\n  index.html\n  about/index.html\n  blog/index.html\n  assets/styles.css
\n

That dist folder is the website.

\n

Everything outside that folder is source code, content, and build logic. Useful for you, but not the thing visitors actually need.

\n

#Two ways to deploy it

\n

There are two common ways to publish a static site to Cloudflare Pages.

\n

The first is to connect a Git repository. In that setup, Cloudflare watches a branch, runs your build command, and publishes the output automatically when you push changes.

\n

The second is direct upload. In that setup, you run the build yourself and upload the finished output folder using a tool like Wrangler.

\n

Both are valid.

\n

If the repo and build process are stable, the Git-connected route is convenient. If you want more control, or you are working with a custom setup and want to verify the build before it goes live, direct upload is often the cleaner option.

\n

#What actually gets pushed

\n

This is the part that clears up a lot of confusion.

\n

Cloudflare Pages does not need your entire project in order to serve a static site. It needs the built output.

\n

If you use Git integration, Cloudflare pulls the repo and builds it on its side. If you use direct deployment, you build the site locally and upload the output folder yourself.

\n

Either way, the important question is the same:

\n

Is the final output correct?

\n

That is what people are going to hit in the browser.

\n

#A direct-deploy example

\n

If you want to keep things simple and explicit, a direct deploy is easy to follow:

\n
bash
npm install\nnpm run build\nnpx wrangler pages deploy dist --project-name your-project-name
\n

That sequence does three things:

\n
  1. installs the project dependencies
  2. builds the static site
  3. uploads the built output to Cloudflare Pages
\n

I like this flow because it leaves very little mystery about what is happening.

\n

You can stop after npm run build, open the dist folder, and confirm the pages are there before you publish anything.

\n

#Where people usually get tripped up

\n

One common mistake is treating a static site like a server app.

\n

If the site is just HTML, CSS, images, and a little JavaScript, do not make deployment harder than it needs to be. Build it, publish it, and keep production simple.

\n

Another common mistake is assuming the site is broken when the real issue is the domain cutover.

\n

Sometimes the build is fine and the upload is fine, but DNS still points somewhere old. Sometimes the browser is just serving cached content. Sometimes the wrong host is still responding.

\n

When that happens, I usually check things in this order:

\n
  1. Did the site build successfully?
  2. Did the deployment actually finish?
  3. Does the Pages preview URL look right?
  4. Does the custom domain point at the correct Pages project?
  5. Is the browser showing something stale?
\n

That order saves a lot of time.

\n

#The domain part

\n

Once the Pages project is working on its preview or project URL, the rest is mostly DNS and verification.

\n

You add the custom domain in Cloudflare Pages, update the DNS records if needed, and wait for the domain to verify. After that, I like to check both the project URL and the production domain to make sure they are serving the same site.

\n

If the old homepage is still showing up, I do not immediately start rewriting code. I check whether the domain is really pointed at the new deployment first.

\n

#Why I still like this setup

\n

Years from now, I would much rather come back to a small repo with markdown posts, a build script, and a predictable hosting target than try to remember why a personal site needed an overcomplicated stack.

\n

That is the real appeal here.

\n

For the right kind of site, static output plus Cloudflare Pages keeps things fast, cheap, and pretty easy to manage. It is not the answer for every project, but for a straightforward blog or personal site, it is a solid option that does not create extra work for no reason.

", "summary": "A practical walkthrough for getting a simple static site onto Cloudflare Pages without turning deployment into a second job.", "date_published": "2026-04-28T00:00:00.000Z", "tags": [ "Cloudflare", "Static Site", "DevOps" ], "image": "https://jarrettwilliams.com/assets/images/social-card-publishing-a-static-site-to-cloudflare-pages.f0338a4b.png" }, { "id": "https://jarrettwilliams.com/blog/remove-empty-okta-groups/", "url": "https://jarrettwilliams.com/blog/remove-empty-okta-groups/", "title": "How to remove empty groups in OKTA manually or via API?", "content_html": "

How do I remove empty groups in OKTA manually?

\n

Let's say we have a case of an app import for an org-to-org that imported groups accidentally. Now that those groups from the other tenant are in your tenant, it is extremely annoying when searching as these groups will show as zero users. Moreso, the only way to \"remove\" these groups is manually, one by one.

\n

What if I told you there was a way to do this via python and the OKTA API?

\n

Manual Approach (Admin Console)

\n
    \n
  1. Navigate to Groups: Log in to your Okta Admin Console, go to Directory > Groups.
    2. \n
  2. Filter for Empty Groups: Okta doesn't have a direct filter for groups with zero members, but you can sort or search manually. Look at the \"Members\" column - groups showing \"0\" are your targets.
    3. \n
  3. Delete Empty Groups: Click on a group with zero members, then hit the More Actions dropdown (or similar option depending on your interface) and select Delete Group. Confirm the deletion. Repeat for each empty group.
    4. \n
\n

This works fine if you only have a handful of groups to check, but it's tedious for a large organization.

\n

Automated Approach (Okta API)

\n

For a faster, scalable solution - especially if you have many groups - use the Okta API:

\n
    \n
  1. Get an API Token: In the Admin Console, go to Security > API > Tokens, and create a token with appropriate permissions.
    2. \n
  2. List All Groups: Use the API endpoint GET /api/v1/groups to fetch all groups in your Okta org. This returns a JSON list with group details, including member counts.
    3. \n
  3. Identify Empty Groups: Parse the response. Each group object includes a _embedded section with stats (if requested via expand=stats in the query). Check \"membersCount\": 0 to find empty ones.
    4. \n
  4. Delete Empty Groups: For each group with zero members, grab its id and send a DELETE /api/v1/groups/{groupId} request. You'll need to authenticate with your API token.
    5. \n
\n

Here's a more robust Python script that handles pagination, error checking, and provides more detailed output:

\n
python
import requests\n\n# Replace these with your actual Okta details\nAPI_TOKEN = "your-api-token-here"  # Your Okta API token\nORG_URL = "https://your-domain.okta.com"  # Your Okta domain\n\n# Set up headers for API requests\nHEADERS = {\n    "Authorization": f"SSWS {API_TOKEN}",\n    "Accept": "application/json"\n}\n\ndef get_all_groups():\n    """Fetch all groups with pagination."""\n    groups = []\n    url = f"{ORG_URL}/api/v1/groups?expand=stats"\n    while url:\n        try:\n            response = requests.get(url, headers=HEADERS)\n            response.raise_for_status()\n            data = response.json()\n            if isinstance(data, list):\n                groups.extend(data)\n            else:\n                print(f"Unexpected response: {data}")\n                break\n            url = response.links.get("next", {}).get("url")\n        except requests.exceptions.RequestException as error:\n            print(f"Error fetching groups: {error}")\n            break\n    return groups\n\ndef get_member_count(group_id):\n    """Fallback: Check member count by fetching users in the group."""\n    try:\n        response = requests.get(f"{ORG_URL}/api/v1/groups/{group_id}/users", headers=HEADERS)\n        response.raise_for_status()\n        return len(response.json())\n    except requests.exceptions.RequestException as error:\n        print(f"Error checking members for group {group_id}: {error}")\n        return None\n\ndef delete_empty_groups():\n    """Delete groups with zero members."""\n    groups = get_all_groups()\n    if not groups:\n        print("No groups found or error occurred.")\n        return\n\n    for group in groups:\n        if "id" not in group or "profile" not in group or "name" not in group["profile"]:\n            print(f"Skipping malformed group: {group}")\n            continue\n\n        group_id = group["id"]\n        group_name = group["profile"]["name"]\n\n        if "_embedded" in group and "stats" in group["_embedded"]:\n            member_count = group["_embedded"]["stats"].get("usersCount", -1)\n        else:\n            print(f"Stats unavailable for {group_name}, checking members directly...")\n            member_count = get_member_count(group_id)\n\n        if member_count is None:\n            print(f"Skipping {group_name} due to error.")\n            continue\n\n        if member_count == 0:\n            try:\n                delete_response = requests.delete(f"{ORG_URL}/api/v1/groups/{group_id}", headers=HEADERS)\n                if delete_response.status_code == 204:\n                    print(f"Deleted empty group: {group_name} (ID: {group_id})")\n                else:\n                    print(f"Failed to delete {group_name}: {delete_response.status_code} - {delete_response.text}")\n            except requests.exceptions.RequestException as error:\n                print(f"Error deleting {group_name}: {error}")\n        else:\n            print(f"Skipping {group_name} - has {member_count} members")\n\nif __name__ == "__main__":\n    print("Starting Okta group cleanup...")\n    delete_empty_groups()\n    print("Cleanup complete.")
\n

Things to Watch Out For

\n\n

The API method is your best bet for efficiency. If scripting isn't your thing, you could also export the group list via a tool like Okta Workflows or a third-party integration, filter for zero-member groups in a spreadsheet, and delete them manually or via API calls. Either way, you'll have a cleaner Okta setup by the end of it.

", "summary": "A guide on removing empty groups in OKTA using both manual and automated approaches.", "date_published": "2025-02-25T00:00:00.000Z", "tags": [ "Okta", "Identity", "Automation" ], "image": "https://jarrettwilliams.com/assets/images/social-card-remove-empty-okta-groups.e9ddff25.png" }, { "id": "https://jarrettwilliams.com/blog/datacenter-technician-tools/", "url": "https://jarrettwilliams.com/blog/datacenter-technician-tools/", "title": "Essential Tools for a Datacenter Technician's Visit", "content_html": "

When a datacenter technician prepares for a site visit, having the right tools can make all the difference. Whether you're curious about what goes on behind the scenes in these digital powerhouses or considering a career in datacenter management, understanding the essential tools is a great place to start. Let's explore what a datacenter technician might pack for their next visit.

\n

#1. Laptop and Diagnostic Software

\n

A technician's most crucial tool is often their laptop, loaded with diagnostic software and remote management tools. This allows them to interface with servers, run tests, and access documentation on the go. You should also have a network card / USB NIC if your laptop does not have one built in. It's worth noting that in 2025, most laptops do not come with built-in Ethernet ports, making an external network adapter essential for direct connections to datacenter equipment.

\n

#2. Network Cable Tester

\n

In a world of complex connections, a network cable tester is invaluable. It helps technicians quickly identify issues with Ethernet cables, ensuring data flows smoothly through the datacenter. FLUKE is a wonderful brand, the more expensive cable testers really do a great job. You want to be able to identify the problem down to the exact area of a cable. Don't go cheap here.

\n

#3. Multimeter

\n

A multimeter is the Swiss Army knife of electrical testing. It measures voltage, current, and resistance, helping technicians diagnose power-related issues in servers and other equipment.

\n

#4. Screwdriver Set

\n

A variety of screwdrivers is essential for opening server cases, rack-mounted equipment, and various hardware components. A good set includes both flathead and Phillips head screwdrivers in different sizes.

\n

#5. Electrostatic Discharge (ESD) Wrist Strap

\n

Static electricity can be a silent killer of sensitive electronic components. An ESD wrist strap grounds the technician, preventing accidental damage to expensive equipment.

\n

#6. Flashlight or Headlamp

\n

Datacenters can be dimly lit, especially behind server racks. A good flashlight or headlamp helps technicians see clearly when working in tight spaces.

\n

#7. Label Maker

\n

Organization is key in a datacenter. A label maker helps technicians clearly mark cables, servers, and other equipment, making future maintenance much easier.

\n

#8. Zip Ties and Velcro Straps

\n

Cable management is crucial for airflow and organization. Zip ties and Velcro straps help bundle and secure cables neatly.

\n

#9. Thermal Imaging Camera

\n

While not always necessary, a thermal imaging camera can be incredibly useful for identifying hot spots in the datacenter, helping prevent equipment failures due to overheating.

\n

#10. Safety Gear

\n

Safety should always come first. Technicians often carry personal protective equipment like safety glasses, gloves, and sometimes even ear protection for noisy environments. I usually bring earbuds or bluetooth headphones to play music and drown out the datacenter noise.

\n

#11. Cables and Crimp Kit

\n

Always bring cables. Extra cables. Fiber patch cables, Ethernet cables, power cables, you name it. You'll never know when you must swap a cable. Things happen.

\n

#Conclusion

\n

The tools a datacenter technician carries reflect the complex and critical nature of their work. From diagnosing network issues to ensuring proper cable management, these professionals rely on a diverse toolkit to keep our digital infrastructure running smoothly. While the average person might not need these tools in their daily life, understanding their use gives us a glimpse into the intricate world of datacenter maintenance and the skilled professionals who keep our data flowing.

", "summary": "A comprehensive guide to the tools and equipment a datacenter technician needs for a successful site visit.", "date_published": "2024-02-19T00:00:00.000Z", "tags": [ "Datacenter", "Hardware", "Field Notes" ], "image": "https://jarrettwilliams.com/assets/images/social-card-datacenter-technician-tools.778acecb.png" }, { "id": "https://jarrettwilliams.com/blog/change-primary-user-microsoft-endpoint/", "url": "https://jarrettwilliams.com/blog/change-primary-user-microsoft-endpoint/", "title": "How to change the primary user of a device in Microsoft Endpoint from the last logged in user. Via Powershell. Via Graph API. In bulk.", "content_html": "

Alright, I figured it would be good to start posting some tips and tricks to the world. I manage a Microsoft 365 E5 environment and utilize Autopilot for the quick deployment of computers. As you go through hundreds of deployments, day after day, you do get set on autopilot. It works well. A year goes by and look at that, your IT Deployment techs are the primary users on so many laptops in Endpoint. How do we fix this?

\n

Well, I have the script for you. Run this in Powershell ISE with enough permissions to poll Graph API. Make sure you have the Graph API Powershell module imported.

\n

Install with `Install-Module -Name Microsoft.Graph.Intune`

\n

Now, the script:

\n
powershell
# Connect-MgGraph -Scopes "DeviceManagementManagedDevices.ReadWrite.All", "User.Read.All"\n# Function to get the last logged-on user for a device\nfunction Get-LastLoggedOnUser {\n    param (\n        [string]$DeviceId\n    )\n    $device = Get-MgDeviceManagementManagedDevice -DeviceId $DeviceId\n    if ($device.usersLoggedOn -and $device.usersLoggedOn.Count -gt 0) {\n        # Assuming the last item in usersLoggedOn is the most recent\n        $lastUser = $device.usersLoggedOn | Sort-Object -Property lastLogOnDateTime -Descending | Select-Object -First 1\n        return $lastUser.userId\n    }\n    return $null\n}\n\n# Get all Windows 10 and 11 devices\n$devices = Get-MgDeviceManagementManagedDevice -Filter "operatingSystem eq 'Windows' and (operatingSystemVersion startswith '10.' or operatingSystemVersion startswith '11.')"\n\nforeach ($device in $devices) {\n    try {\n        $lastUserId = Get-LastLoggedOnUser -DeviceId $device.id\n        if ($lastUserId) {\n            $lastUser = Get-MgUser -UserId $lastUserId\n            # Check if the current primary user is different from the last logged on user\n            if ($device.userDisplayName -ne $lastUser.displayName) {\n                $body = @{\n                    "userId" = $lastUserId\n                }\n                # Update the primary user\n                Update-MgDeviceManagementManagedDevice -ManagedDeviceId $device.id -BodyParameter $body\n                Write-Host "Updated primary user to $($lastUser.displayName) for device: $($device.deviceName)"\n            } else {\n                Write-Host "Current primary user is already correct for device: $($device.deviceName)"\n            }\n        } else {\n            Write-Host "No last logged on user found for device: $($device.deviceName)"\n        }\n    } catch {\n        Write-Host "Failed to update primary user for device $($device.deviceName): $_"\n    }\n}
\n

Get-LastLoggedOnUser: A helper function to find the last user who logged on to a device by checking the usersLoggedOn property. This assumes the last item in this list is the most recent, which might not always be true if the list is not sorted by login time.

\n

Get-MgDeviceManagementManagedDevice: Used to fetch Windows 10 and 11 devices from Intune.

\n

Update-MgDeviceManagementManagedDevice: Updates the device's primary user to the last logged-on user if they differ from the current primary user.

\n

Error Handling: Basic error handling to catch and report issues with updating each device.

\n

Important Notes:

\n", "summary": "A guide on updating the primary user of devices in Microsoft Endpoint using PowerShell and Graph API.", "date_published": "2024-02-18T00:00:00.000Z", "tags": [ "Microsoft Intune", "PowerShell", "Automation" ], "image": "https://jarrettwilliams.com/assets/images/social-card-change-primary-user-microsoft-endpoint.27804f5b.png" }, { "id": "https://jarrettwilliams.com/blog/disable-bluetooth-menu-macos/", "url": "https://jarrettwilliams.com/blog/disable-bluetooth-menu-macos/", "title": "Disable the bluetooth menu on macOS with a mobileconfig .plist file", "content_html": "

I do not have a ton of time, but I do have a bluetooth problem.

\n

What we have here is a plist for a MDM like JAMF Pro that will disable the bluetooth menu on macOS.

\n
xml
<?xml version="1.0" encoding="UTF-8"?>\n<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">\n<plist version="1.0">\n<dict>\n    <key>Label</key>\n    <string>com.example.disablebluetoothmenu</string>\n    <key>ProgramArguments</key>\n    <array>\n        <string>/usr/bin/defaults</string>\n        <string>write</string>\n        <string>com.apple.controlcenter</string>\n        <string>Bluetooth</string>\n        <string>-bool</string>\n        <string>false</string>\n    </array>\n    <key>RunAtLoad</key>\n    <true/>\n</dict>\n</plist>
\n

This plist file, when deployed through a Mobile Device Management solution like JAMF Pro, will disable the Bluetooth menu in the macOS control center. It does this by setting the Bluetooth key in the com.apple.controlcenter domain to false using the defaults command.

\n

Here is a breakdown of what the plist does:

\n\n

This can be useful in environments where you want to restrict Bluetooth usage or simplify the user interface by removing unused options.

", "summary": "How to disable the Bluetooth menu on macOS using a mobileconfig .plist file.", "date_published": "2024-02-17T00:00:00.000Z", "tags": [ "macOS", "Endpoint Management", "Configuration" ], "image": "https://jarrettwilliams.com/assets/images/social-card-disable-bluetooth-menu-macos.39baa626.png" }, { "id": "https://jarrettwilliams.com/blog/hello-world/", "url": "https://jarrettwilliams.com/blog/hello-world/", "title": "Hello world!", "content_html": "

Welcome to my new blog about Information Technology and System Administration.

\n

I am Jarrett Williams, an IT professional with a passion for technology and problem-solving. This blog is my platform to share insights, tips, and experiences from the world of IT and system administration.

\n

Here is what you can expect from this blog:

\n\n

Whether you are a seasoned IT professional, a budding system administrator, or just someone interested in the world of technology, I hope you find valuable content here.

\n

Feel free to leave comments, ask questions, or suggest topics you would like me to cover. Let us learn and grow together in this ever-evolving field of Information Technology.

\n

Stay tuned for more posts coming soon.

", "summary": "Welcome to my new blog about Information Technology and System Administration.", "date_published": "2024-02-16T00:00:00.000Z", "tags": [ "Meta", "Career" ], "image": "https://jarrettwilliams.com/assets/images/social-card-hello-world.fb8d250d.png" } ] }