Nathan C. McGuire

Author: Nathan McGuire

  • Zsh vs. Bash on macOS: Should You Care?

    Starting with macOS Catalina, Apple ditched Bash as the default shell and gave Zsh the crown. Cue the collective sighs and confusion. But here’s the deal—if you’re doing any real terminal work on macOS, it’s worth knowing why that switch happened and whether you should care.

    Why the Switch?

    Apple made Zsh the default for licensing reasons. The version of Bash that shipped with macOS was ancient (v3.2 from 2007) because newer versions use GPLv3, which Apple didn’t want to mess with. Zsh doesn’t have that problem, so… boom, default.

    But it’s not just a legal shuffle—Zsh brings some goodies to the table.

    Zsh Perks

    • Auto-suggestions: Like fish shell vibes—Zsh can guess what you’re typing and finish your thought. Bash can’t do that natively.
    • Globbing on steroids: More powerful wildcard matching. Want to match all files with two digits and a .logextension? Zsh makes that easy.
    • Plugins & Themes: Oh My Zsh turns Zsh into a productivity beast. You get Git status right in the prompt, syntax highlighting, fancy themes… Bash just feels barebones after.
    • Customization: Bash can be customized too, sure—but Zsh makes it easier and sexier.

    Downsides?

    Not much, unless you’ve got a pile of Bash scripts with weird quirks. Zsh is mostly compatible, but not 100%. You might have to tweak some syntax here and there.

    Also, Zsh’s .zshrc isn’t the same as .bash_profile or .bashrc, so your muscle memory might need a refresh.

    So, Which Should You Use?

    If you’re already neck-deep in Bash and it’s working? Stick with it.

    If you’re starting fresh or want something more modern and extensible? Zsh is the move. Especially if you’re living in Terminal daily. Install Oh My Zsh, pick a theme, grab some plugins, and feel like a hacker god.

  • From K-12 IT to Healthcare IT: Preparing for a Major Career Shift

    After years in K-12 education IT, I’ve recently accepted a role in healthcare IT. While I haven’t started yet, I’ve been reflecting on what this transition means—what skills carry over, what new challenges I’ll face, and how I can prepare for the shift.

    For those in IT considering a similar move, here’s what I’ve learned so far as I prepare to step into this new world.

    What K-12 IT and Healthcare IT Have in Common

    At first glance, education and healthcare seem like vastly different industries, but IT professionals in both fields share some major responsibilities:

    • Security & Compliance – In schools, we deal with FERPA (protecting student data); in healthcare, it’s HIPAA (protecting patient records). Both demand strict access controls, encryption, and careful handling of sensitive information.

    • Mission-Critical Systems – Whether it’s a school-wide internet outage during state testing or a hospital’s electronic health records (EHR) system going down, IT failures have real-world consequences. Uptime is non-negotiable.

    • Limited Budgets, High Expectations – Schools and healthcare facilities often need to do more with less. Stretching hardware lifespans, optimizing software costs, and making smart infrastructure investments are key skills in both environments.

    Key Differences Between K-12 and Healthcare IT

    1. Always-On Infrastructure

    In K-12, IT can plan maintenance windows around weekends or summer breaks. In healthcare, there’s no downtime—systems need to be available 24/7. Any updates, patches, or changes must be carefully planned to avoid disrupting patient care.

    2. Complexity of Systems

    K-12 IT teams manage student information systems (SIS), Google Workspace, and classroom technology. Healthcare IT involves electronic health records (EHR), medical imaging (PACS), diagnostic equipment, and secure messaging systems—all of which must integrate smoothly to avoid treatment delays.

    3. The Stakes are Higher

    A mistake in education IT might mean a teacher loses access to their lesson plan. In healthcare, an IT failure can delay patient care, disrupt surgeries, or compromise life-saving treatments. The pressure to get things right is significantly greater.

    How I’m Preparing for the Transition

    • Studying Healthcare IT Basics – Learning about EHR systems (like Epic or Cerner), HIPAA compliance, and medical device security before day one.

    • Strengthening Security Knowledge – While security is always a priority, cyberattacks on healthcare organizations are a constant threat. Reviewing best practices for network segmentation, access control, and ransomware defense.

    • Adjusting to 24/7 Operations – Expecting on-call responsibilities and tighter change management procedures compared to the more flexible schedules in K-12 IT.

    Final Thoughts

    Switching industries is always a challenge, but IT fundamentals—security, uptime, and problem-solving—are universal. While I expect a learning curve, I’m confident that my experience in K-12 IT has prepared me for what’s ahead.

    If you’ve made a similar transition (or are considering one), I’d love to hear your thoughts—what was your biggest challenge? What helped the most? Drop a comment or reach out!

  • Enabling Remote Desktop Access on Windows with PowerShell

    When managing a remote network or administering systems across multiple locations, enabling Remote Desktop Protocol (RDP) becomes an essential task. Here’s a quick and efficient way to set up RDP on a Windows machine using PowerShell commands. This method ensures secure connections, including Network Level Authentication (NLA) and the appropriate firewall settings.

    1. Enable Remote Desktop Connections

    First, you’ll need to enable RDP connections on the system. By default, Windows disables Remote Desktop connections for security reasons. You can change this setting using PowerShell.

    Set-ItemProperty'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\'-Name"fDenyTSConnections"-Value0

    This command modifies the registry key that controls RDP access. Setting fDenyTSConnections to 0 ensures that RDP is enabled on the machine.

    2. Enable Network Level Authentication (NLA)

    Network Level Authentication (NLA) adds an additional layer of security by requiring users to authenticate before establishing a full RDP session. This is a recommended best practice to prevent unauthorized access and reduce the risk of exploitation.

    Set-ItemProperty'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\'-Name"UserAuthentication"-Value1

    By setting UserAuthentication to 1, you ensure that NLA is required for all RDP connections, thus enhancing the security of remote desktop access.

    3. Enable Windows Firewall Rules for RDP

    Now, we need to ensure that the Windows firewall allows incoming RDP connections. Windows Firewall typically blocks most incoming traffic unless explicitly allowed. Luckily, you can enable the necessary firewall rules for RDP with this command:

    Enable-NetFirewallRule-DisplayGroup"Remote Desktop"

    This command enables the built-in firewall rules under the “Remote Desktop” group, allowing RDP traffic to pass through the firewall.

    Final Thoughts

    By running these three PowerShell commands, you can quickly and securely enable Remote Desktop access to a Windows machine. The combination of enabling RDP, enforcing NLA, and allowing RDP through the firewall creates a balanced approach to remote access that is both efficient and secure.

  • Understanding Transactions in T-SQL: BEGIN, ROLLBACK, and COMMIT

    ⚠️When a transaction is active, SQL Server locks affected tables and rows, preventing other queries from modifying them until the transaction is committed or rolled back. Long-running transactions can cause blocking, deadlocks, and performance issues, especially in high-traffic databases.

    Understanding Transactions in T-SQL: BEGIN, ROLLBACK, and COMMIT

    When working with Microsoft SQL Server, data integrity is crucial. Imagine running an update query on a production database and realizing midway that something is wrong—without transactions, your partial changes would be saved, potentially causing data corruption. That’s where T-SQL transactions come in.

    Transactions in SQL Server allow you to group multiple operations into a single unit. If all operations succeed, the changes are committed; if something fails, you can roll back to ensure no partial updates occur. Let’s dive into the three key transaction commands: BEGIN TRANSACTION, COMMIT, and ROLLBACK.

    1. BEGIN TRANSACTION

    The BEGIN TRANSACTION statement marks the start of a transaction. From this point forward, SQL Server tracks all changes until you either commit them (COMMIT TRANSACTION) or undo them (ROLLBACK TRANSACTION).

    Example: Starting a Transaction

    BEGIN TRANSACTION; UPDATE Employees SET Salary = Salary * 1.10 WHERE Department = 'IT';

    At this stage, the salary updates are made but not yet saved. If an error occurs or if we decide to cancel, we can roll back to the previous state.

    2. COMMIT TRANSACTION

    Once you’re satisfied that all operations in the transaction were successful, you use COMMIT TRANSACTION to make the changes permanent.

    Example: Committing a Transaction

    BEGIN TRANSACTION; UPDATE Employees SET Salary = Salary * 1.10 WHERE Department = 'IT'; COMMIT TRANSACTION;

    Now, the salary changes are saved, and they cannot be undone.

    3. ROLLBACK TRANSACTION

    If something goes wrong, you can revert all changes made since BEGIN TRANSACTION using ROLLBACK TRANSACTION. This ensures data integrity by preventing partial updates.

    Example: Rolling Back a Transaction

    BEGIN TRANSACTION; UPDATE Employees SET Salary = Salary * 1.10 WHERE Department = 'IT'; -- Simulating an error IF @@ERROR <> 0      ROLLBACK TRANSACTION; ELSE       COMMIT TRANSACTION;

    In this case, if an error occurs, the changes are discarded, and the database remains unchanged.

    4. Using TRY…CATCH for Safe Transactions

    To handle errors properly, wrap transactions in a TRY…CATCH block.

    Example: Safe Transaction Handling

    BEGIN TRANSACTION; BEGIN TRY     UPDATE Employees SET Salary = Salary * 1.10 WHERE Department = 'IT';     COMMIT TRANSACTION; END TRY   BEGIN CATCH     PRINT 'Error occurred. Rolling back changes.';     ROLLBACK TRANSACTION; END CATCH;

    If any part of the transaction fails, it will be rolled back automatically.

    5. Nested Transactions (Be Careful!)

    SQL Server allows nested transactions, but only the outermost COMMIT TRANSACTION truly saves the changes. Rolling back anylevel undoes everything.

    BEGIN TRANSACTION;   UPDATE Employees SET Salary = Salary * 1.10 WHERE Department = 'IT';     BEGIN TRANSACTION;       UPDATE Employees SET Bonus = Bonus + 500 WHERE Department = 'IT';     COMMIT TRANSACTION; ROLLBACK TRANSACTION; -- This undoes all changes, including the bonus update.

    Even though we committed the inner transaction, the rollback at the outer level undoes everything.

    Conclusion

    Using transactions in T-SQL ensures data consistency and integrity. Always wrap critical updates in BEGIN TRANSACTION, and use ROLLBACK when things go wrong. If you’re running production queries, consider using TRY…CATCH to prevent data disasters.

    By mastering BEGIN, COMMIT, and ROLLBACK, you gain full control over your SQL operations—ensuring changes only persist when everything runs smoothly.

    Have you ever had to roll back a bad update? Let me know in the comments!

  • How to Check Service Provider Status Pages (Before Panicking)

    You’re sitting at your desk, trying to get work done, when suddenly—your internet drops, emails won’t send, or a critical SaaS tool refuses to load. Before you flood your IT team (or Twitter) with complaints, there’s one simple step that can save everyone time: checking the provider’s status page.

    Major service providers maintain public status pages to report outages, scheduled maintenance, and ongoing incidents. Knowing where to find them can mean the difference between informed troubleshooting and unnecessary frustration.

    Why Check Status Pages?

    • Instant Answers – No need to guess if an outage is affecting others. A status page confirms it.
    • Saves Time – If the issue is provider-side, you can stop wasting time rebooting routers or reinstalling apps.
    • Avoids Unnecessary Tickets – IT teams love fewer tickets. If it’s a widespread outage, they’re likely already aware.
    • Plan Around Maintenance – Some downtime is scheduled. A quick check helps you prepare.

    Where to Find Status Pages

    Most major service providers maintain dedicated status pages. Here are some of the big ones:

    Internet & Cloud Providers

    ISPs & Telecom

    SaaS & Productivity Tools

    Financial & Payment Services

    Developer & Hosting Services

    What to Look For

    Once you’re on a status page, check for:

    • Current incidents – Is there an outage affecting your region or service?
    • Past incidents – If your issue just resolved, a recent outage may have been the cause.
    • Scheduled maintenance – Check if downtime was planned.
    • ETA for resolution – Some providers update with estimated fix times.

    What If There’s No Reported Outage?

    If the status page says everything is fine, but you’re still experiencing issues:

    • Check third-party outage trackers – Sites like Downdetector aggregate user reports.
    • Ask colleagues – Are others in your office having the same issue?
    • Reboot your equipment – Classic move, but sometimes necessary.
    • Check your ISP status – If your internet is down, it might not be the service provider’s fault.

    Final Thoughts

    Next time something isn’t working, don’t panic—check the status page first. It might save you a headache and a support call. Bookmark the pages you rely on most and stay ahead of outages like a pro.

    Have a favorite status page or a story about an outage? Share in the comments!

  • Securing Email from Your Domains with DMARC, DKIM, and SPF

    Email security is more important than ever. If you own a domain and use it for email, you need to protect it from spoofing, phishing, and abuse. Cybercriminals love to impersonate domains to send fraudulent emails, which can lead to financial loss, reputation damage, or even legal trouble.

    Fortunately, there are three key technologies that help secure your domain’s email: SPF, DKIM, and DMARC. Together, they form the backbone of modern email authentication. Here’s what they do and how to implement them.

    SPF: Sender Policy Framework

    SPF helps prevent spammers from forging your domain in the “From” field of an email. It does this by specifying which mail servers are authorized to send email on behalf of your domain.

    How to Set Up SPF

    1. Create a TXT record in your domain’s DNS.
    2. Define the mail servers allowed to send emails for your domain.
    3. Use the format:
    v=spf1 include:_spf.google.com -all

    This example allows Google Workspace to send email and blocks everything else.

    1. Publish the record and test it using tools like MXToolbox.

    SPF Best Practices

    • Keep it short: SPF records have a 10 DNS lookup limit.
    • Always end with -all (hard fail) or ~all (soft fail).
    • If multiple services send mail on your behalf, include them using include:.

    DKIM: DomainKeys Identified Mail

    DKIM adds a digital signature to your emails. This signature allows the recipient’s mail server to verify that the email wasn’t tampered with during transmission.

    How to Set Up DKIM

    1. Enable DKIM signing in your email provider’s settings.
    2. Generate a DKIM public-private key pair (many providers do this for you).
    3. Add a DNS TXT record containing your public key. Example:
    default._domainkey.yourdomain.com  TXT  v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...
    1. Test your DKIM setup using Google’s DKIM checker.

    DKIM Best Practices

    • Rotate your DKIM keys regularly.
    • Use 2048-bit keys if possible for better security.
    • Ensure your email provider actually signs outgoing mail with DKIM.

    DMARC: Domain-based Message Authentication, Reporting & Conformance

    DMARC is the final piece that ties SPF and DKIM together. It tells mail servers what to do with unauthenticated emails and provides reporting so you can monitor unauthorized activity.

    How to Set Up DMARC

    1. Add a TXT record for _dmarc.yourdomain.com.
    2. Define your DMARC policy. Example:
    v=DMARC1; p=reject; rua=mailto:[email protected];  
    • p=reject blocks unauthorized emails.
    • rua= sends reports to your email for analysis.
    1. Start with a monitoring mode (p=none) to gather data before enforcing stricter rules.

    DMARC Best Practices

    • Start with “none” (p=none) to analyze traffic.
    • Gradually move to quarantine (p=quarantine) and then reject (p=reject).
    • Use a DMARC reporting service like Postmark’s DMARC tool for better visibility.

    Important Note for Bulk Senders (Gmail & Yahoo Requirements)

    As of February 2024, Gmail and Yahoo require stricter email authentication for senders who send 5,000 or more emails per day. If you send bulk emails (e.g., newsletters, marketing emails), you must:

    1. Have a DMARC policy, at least “p=none” – A valid DMARC record is now mandatory
    2. Ensure all outgoing mail is authenticated with SPF and DKIM.
    3. Enable easy unsubscription (one-click unsubscribe for marketing emails).
    4. Keep spam complaint rates below 0.3%.

    Failing to meet these requirements could result in your emails being rejected or marked as spam. For more details, check Google’s Sender Guidelines.

    Email Header Analysis: DKIM, SPF, and DMARC

    When troubleshooting email delivery issues or checking for spoofing, analyzing the email headers is crucial. Three key email authentication mechanisms—DKIM (DomainKeys Identified Mail), SPF (Sender Policy Framework), and DMARC (Domain-based Message Authentication, Reporting & Conformance)—help verify the legitimacy of an email.

    In this post, I’ll break down how to analyze an email’s headers and verify these three mechanisms.

    Extracting Email Headers

    Email headers contain routing and authentication details. To analyze them:

    • Gmail: Open the email → Click the three dots → “Show Original”
    • Outlook: Open the email → Click “File” → “Properties” → Copy headers from “Internet headers”
    • Apple Mail: View → Message → “All Headers”
    • Thunderbird: View → Message Source

    Copy the headers and paste them into a tool like MXToolbox’s Header Analyzer or manually check each section.

    SPF (Sender Policy Framework) Analysis

    SPF verifies whether the sending IP is authorized by the domain’s DNS. Look for this header:

    Received-SPF: Pass (domain.com: domain of [email protected] designates 192.168.1.1 as permitted sender) 
    • Pass → The sending server is authorized.
    • Fail → The sending server is not listed in the SPF record.
    • SoftFail → The server is not authorized, but the domain allows it under certain conditions.
    • Neutral → The domain has not set an explicit policy.
    • None → No SPF record found.

    To manually check SPF, run:

    nslookup -type=TXT domain.com

    Look for a v=spf1 record, which should list allowed IPs or include mechanisms (e.g., include:_spf.google.com).

    DKIM (DomainKeys Identified Mail) Analysis

    DKIM ensures the email is not tampered with by verifying a cryptographic signature. Look for this header:

    DKIM-Signature: v=1; a=rsa-sha256; d=domain.com; s=selector; h=from:subject:date;

    The verification result will be in another header, such as:

    Authentication-Results: dkim=pass header.d=domain.com
    • Pass → DKIM signature matches the public key.
    • Fail → Signature is invalid or missing.
    • Neutral/None → No DKIM record found.

    To manually check DKIM, retrieve the public key using:

    nslookup -type=TXT selector._domainkey.domain.com

    If the key exists, compare it to the DKIM signature in the email headers.

    DMARC (Domain-based Message Authentication, Reporting & Conformance) Analysis

    DMARC builds on SPF and DKIM, providing instructions on how to handle failures. Look for this header:

    Authentication-Results: dmarc=pass (policy=none) header.from=domain.com

    DMARC checks if the email aligns with SPF/DKIM and applies a policy:

    • None → Just monitor and report (no enforcement).
    • Quarantine → Treat failed emails as suspicious.
    • Reject → Block unauthorized emails outright.

    To check a domain’s DMARC policy:

    nslookup -type=TXT _dmarc.domain.com

    Example DMARC record:

    v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100
    • p=none/quarantine/reject → Policy type
    • rua=mailto: → Where reports are sent
    • pct=100 → Applies policy to 100% of emails

    Example Header Analysis

    Let’s analyze a real-world scenario. Here’s an excerpt from a sample email header:

    Received-SPF: Pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender) Authentication-Results: spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass

    • SPF Pass → The email was sent from an authorized server.

    • DKIM Pass → The email has a valid signature.

    • DMARC Pass → The email aligns with SPF or DKIM, following policy.

    This email is legitimate. If SPF or DKIM failed, and DMARC was set to reject, the email would likely be blocked.

    DMARC Report Analysis: Understanding Your Email Traffic

    Once DMARC is in place, you’ll start receiving aggregate and forensic reports. These reports provide insights into who is sending email from your domain and whether those emails are passing authentication.

    Types of DMARC Reports

    • Aggregate Reports (RUA):

    • Sent daily in XML format to the email specified in rua=mailto:your-email.

    • Shows which IPs are sending mail on your behalf and their SPF/DKIM pass/fail status.

    • Helps identify legitimate services that need to be authorized or malicious senders to block.

    • Forensic Reports (RUF):

    • Sent immediately when an email fails DMARC.

    • Contains email headers and sometimes message body (redacted for privacy).

    • Useful for identifying specific spoofing attempts.

    How to Analyze DMARC Reports

    1. Use a DMARC Report Viewer:
    1. Check for Unauthorized Senders:
    • Look for IP addresses that shouldn’t be sending mail from your domain.
    • If you see an unknown IP, investigate whether it belongs to a service you use or a malicious actor.
    1. Verify SPF and DKIM Alignment:
    • Ensure that your legitimate services are passing SPF and DKIM checks.
    • If they are failing, update your SPF record or DKIM settings accordingly.
    1. Gradually Tighten Your Policy:
    • Start with p=none to collect data.
    • Move to p=quarantine once confident in the setup.
    • Finally, enforce p=reject to block spoofed emails entirely.

    Final Thoughts

    Implementing SPF, DKIM, and DMARC significantly reduces the risk of email spoofing and phishing attacks. SPF defines who can send, DKIM verifies email integrity, and DMARC enforces policies while giving you insights.

    Just as important as setting up DMARC is analyzing the reports—without it, you won’t know if your policies are working or if legitimate emails are getting blocked.

    Take the time to configure these properly, and you’ll protect your domain, improve email deliverability, and make life harder for cybercriminals.

    Need Help?

    If you’re struggling with DNS records or email security, reach out, and let’s get your domain locked down!

  • Create Windows Installation Media on Mac

    Prepare the ISO File

    1. Download the Windows ISO file from Microsoft’s official site.

    2. Save it to a convenient location (e.g., your Desktop).

    Insert and Identify the USB Drive

    1. Insert the USB drive into your Mac.

    2. Open Terminal and type:

    diskutil list

    3. Find the device identifier for your USB (e.g., /dev/disk2). Make sure you identify the correct disk to avoid overwriting other drives.

    Unmount the USB Drive

    Run the following command to unmount the USB (replace /dev/diskX with your USB identifier):

    diskutil unmountDisk /dev/diskX

    Convert the ISO to a Hybrid Format (if needed)

    macOS doesn’t always work well with ISO files, so convert it to a .img format:

    diutil convert -format UDRW -o ~/Desktop/Windows.img ~/Desktop/Windows.iso

    This creates a Windows.img.dmg file on your Desktop. Rename it to Windows.img for simplicity:

    mv ~/Desktop/Windows.img.dmg ~/Desktop/Windows.img

    Write the ISO to the USB

    1. Use dd to write the image to the USB:

    sudo dd if=~/Desktop/Windows.img of=/dev/rdiskX bs=1m status=progress

    • Replace /dev/rdiskX with your USB identifier (use rdisk for faster writing).

    • if= specifies the input file (the Windows image).

    • of= specifies the output drive (the USB).

    • status=progress displays real-time progress.

    2. Be patient. This process may take a while, and there will be no progress indicator.

    Eject the USB

    Once dd is complete, eject the USB drive:

    diskutil eject /dev/diskX

    Test the USB

    Insert the USB into your Windows PC, and boot from the USB to ensure it works as install media. You may need to change the boot order in the BIOS/UEFI.

    ⚠️ Caution: The dd command can permanently erase data if used incorrectly. Double-check your disk identifier before running the command.