SQL, Code, Coffee, Etc. - Data Musings by Marlon Ribunal

10/23/2026
by Marlon Ribunal
0 comments

Book Review: Microsoft 365 Copilot and Agent Administration Fundamentals

I don’t currently manage Microsoft 365 Copilot in an enterprise environment, but it is one of those technologies that I want to understand better. As AI becomes part of the tools organizations use every day, there is more to learn than just how to use Copilot.

Someone has to manage access, understand licensing, protect company data, and make sure these tools are being used appropriately. And if I ever find myself responsible for that side of things, I want to have a good foundation to start with.

That is where Steve Miles’ Microsoft 365 Copilot and Agent Administration Fundamentals, published by Packt, comes in.

The book covers quite a bit of ground, starting with the fundamentals of Microsoft 365 administration before moving into security, data protection, Copilot, and AI agents. It also prepares readers for the Microsoft AB-900 certification exam.

Understanding What Happens Behind the Scenes

One thing I appreciate about the book is that it starts with the basics. Before getting into Copilot administration, you need to understand the Microsoft 365 environment in which it operates. This includes identity, licensing, permissions, and the different services that make up Microsoft 365.

Some of these topics may already be familiar to IT professionals who work with Microsoft 365 regularly. For others, particularly those coming from a different area of IT, having these concepts explained in one place can be useful.

The security and data protection chapters are especially relevant. Copilot works with organizational data, so understanding how permissions affect what users can access is important. The discussions around Microsoft Purview, data governance, and oversharing in SharePoint help explain why deploying AI tools in an organization requires more thought than simply enabling a feature and giving users access.

This is probably one of the areas I find most interesting. We often talk about what AI can do, but there is another side to the conversation. What information can it access? Are existing permissions appropriate? What happens when sensitive information is exposed to people who should not have access to it? These are questions administrators need to consider before rolling out these tools.

Copilot and Agents Administration

The later chapters get into the administration of Copilot and agents, including licensing, usage monitoring, billing, access control, approval processes, and lifecycle management.

I like that the book covers these operational considerations alongside the features themselves. Understanding what Copilot and agents can do is one thing. Knowing how to manage them within an organization is another.

The sections on creating, testing, approving, and monitoring agents are particularly useful for anyone looking to understand how these tools fit into an organization’s existing environment. There is also value in learning how licensing and access restrictions affect what users can actually do.

Of course, reading about these administrative tasks is different from performing them in a live tenant. I would still want to get hands-on experience with the relevant admin centers and settings to reinforce what I have learned. But having the concepts laid out first gives me a much better starting point.

A Useful Learning Resource

Another thing I appreciate about technical books is having the material organized into chapters that I can revisit when needed. Online documentation is valuable, especially when looking for current configuration details, but sometimes I want a structured path through a subject before diving into individual features.

The book includes chapter summaries, key terms, Microsoft Learn references, and review questions. These are useful for reinforcing the material and preparing for the AB-900 exam. The exam-oriented approach also gives readers a way to check their understanding as they progress.

One limitation worth mentioning is that this is a fundamentals book. Readers looking for extensive, real-world deployment walkthroughs or advanced troubleshooting scenarios may need to supplement it with hands-on practice and Microsoft’s documentation. Given the breadth of topics covered, there is only so much detail that can fit into a single book.

Still, I think that is a reasonable trade-off for a resource intended to establish a foundation across Microsoft 365, security, Copilot, and agents.

Final Thoughts

Microsoft 365 Copilot and Agent Administration Fundamentals by Steve Miles is a useful addition to the technical bookshelf, especially for IT professionals who want to expand their knowledge beyond the technologies they currently manage.

I may not be administering Copilot in an enterprise environment today, but I can see the value of understanding what goes into managing it properly. If that responsibility comes my way in the future, I will have a starting point and a better idea of what I need to learn next.

And even if you are already working with Microsoft 365, the book offers a structured way to review the fundamentals and connect them to the administration of Copilot and AI agents.

That alone makes it a worthwhile read for anyone looking to get a better grasp of this part of the Microsoft ecosystem.

09/22/2026
by Marlon Ribunal
1 Comment

Creating a Custom SQL Server Security Checklist Using the DoD STIG

Here’s a follow up for our US Department of Defense STIG document. In my previous post, SQL Server Security Hardening Guide Using the DoD STIG Checklist, I walked through how I used the DoD STIG checklist as a starting point for reviewing and hardening a SQL Server environment.

After going through the checklist, I started thinking about what I would actually want to use the next time I perform a security review.

The DoD STIG for SQL Server is a great, solid starting point for establishing your security practices with SQL Server. In fact, it’s also a good template for your own STIG in your organization. So, you may want to create a custom checklist that makes sense from the perspective of your SQL Server environment.

The STIG is detailed, which is a good thing, but I found myself wanting something a little more practical for day-to-day DBA work. Something I could open, work through one item at a time, record what I found, and come back to later without having to navigate through the entire STIG document every time.

Questions to Ask

I want it to answer some simple questions:

What am I checking?
Why am I checking it?
How can I verify it?
What does PASS or FAIL look like?
What evidence should I record?
Does this requirement actually apply to this environment?
If I can’t meet a requirement, how do I document the exception?

So in this post, I’ll walk through how I’m building the checklist, based on the DoD STIG as the baseline (and I can then organize it into something I can actually use as a DBA).

The main thing here is to understand what the STIG is asking you to verify.

Once I have the STIG requirements in front of me, the next step is to break each rule down into information that I can actually work with. Rather than simply copying the requirement into my checklist, I want to capture a few key details for each rule.

This gives me enough information to understand what I’m checking, how I can validate it, and what I should record when I’m done.

Again, this STIG is just a starting point. Capture the checklist in a separate document that you can share in your organization.

What to Capture?

For every rule, capture:

STIG ID
Severity
Requirement
Check
Fix
Instance or Database
Applicable?
Current status

Let’s Create a Checklist

Let’s open the STIG Viewer, at the Checklist section, click New to create a new checklist.

Let’s select to create a checklist for a SQL Server Instance.

You have to options: Add individual rules or add all the rules in the STIG. Click the search icon to pick the individual rules or the plus sign to add all the rules. For the purpose of this blog post, let’s add few rules.

Select the rule by clicking the Plus sign. Select all that you want added in your checklist.

To save the checklist, navigate to the burger menu in the top left-hand corner and select Save. Give the checklist file an intuitive name.

Once saved, you can close the checklist builder. The STIG Checklist options will then give you a couple of options to load or create another checklist. Let’s open the checklist that we just created.

Review the checklist and check it against a specific instance or database that you want to assess. Here you can note the instance/database information and mark each rule with three statuses:

Green Check Icon: Not a Finding (meaning instance/database pass the rule),

Red Exclamation: Open (for further review), or

Crossed Circle: Not Applicable

Default Grey Circle: Not reviewed

Keep clicking the gray button to cycle through the statuses.

You can also leave a comment and findings details in each of the rules in the designated boxes at the bottom.

You can then export the checklist if you want to keep a separate file for the assessment (html and then print it to a pdf file).

Here’s some screenshots of the the example html…

Your Checklist as Your Tool

Instead of reproducing the STIG’s structure, I’d create something a DBA can work through. I’d create a checklist for the following categories:

Category	What you’re checking
Authentication	How users authenticate
Authorization	Who has access to what
Accounts & Logins	SQL logins, Windows accounts, disabled accounts
Privileges	`sysadmin`, server roles, database roles
Auditing	Login and security-related auditing
Encryption	TDE, TLS, encryption at rest
Network Security	SQL ports, protocols, exposure
Configuration	SQL Server security-related configuration
Database Security	Database-level permissions and ownership
Service Accounts	SQL Server service identities
Agent Security	SQL Agent jobs, proxies, credentials
Sensitive Data	PII and other protected information
Monitoring	Security events and changes
Documentation	Exceptions, evidence and remediation

That and among other things that may be applicable to whichever environment I happen to be working on.

This is where your checklist becomes your own tool, rather than just another copy of the STIG.

Most Important Thing, Document

This is an important part of the checklist. I don’t want the process to be simply about finding a problem and immediately changing the configuration. Involve everyone and, needless to say, document.

The goal is to first understand the current state, evaluate whether the setting actually needs to be changed, make the appropriate remediation if necessary, and then validate the change. This gives me a more deliberate process instead of treating every finding as something that automatically requires a configuration change.

This process would look as simple as the following:

1. Check – Determine the current state.

2. Evaluate – Decide whether the configuration is appropriate for your environment.

3. Remediate – Make the change if necessary.

4. Validate – Run the check again.

5. Document – Record what changed.

That gives you a repeatable process:

       CHECK
         ↓
      EVALUATE
         ↓
     REMEDIATE
         ↓
      VALIDATE
         ↓
     DOCUMENT

And I’d emphasize that STIG compliance doesn’t automatically mean every setting should simply be changed without considering the environment.

If this was a real checklist for a SQL Server environment I am responsible for, this is my starting point. I expect the checklist to change as I use it, find gaps, and learn more about what works in an actual SQL Server environment.

The STIG gives me a solid baseline, but turning those requirements into something I can consistently use as a DBA makes the exercise much more useful for me.

My next step is to take these checks and start turning them into T-SQL scripts where possible, so instead of manually checking everything, I can let SQL Server help me identify what needs attention.

Have fun and enjoy securing your SQL Server!

09/15/2026
by Marlon Ribunal
1 Comment

T-SQL Tuesday #202 SQL Server Outage You’ll Never Forget: A Roundup

Update: I initially missed to include Edwin Sarmiento, Andy Levy, Chad Callihan, and Rebecca Lewis outage stories. I just added them in the roundup below.

When I put together the invitation for T-SQL Tuesday #202, I wasn’t sure what kind of stories would come out of it.

The topic was simple:

That one SQL Server outage you’ll never forget.

I expected stories about bad queries, failed deployments, storage problems, or maybe a database that decided to have a very bad day. What I got was much more interesting.

There were stories about ransomware, corrupted databases, deleted storage, power and cooling failures, an identity column reaching its limit, and even a floppy disk. A server Meltdown too.

Some of these outages lasted hours. Others lasted days or even weeks.

And what I really enjoyed was that most of these stories weren’t just about what went wrong. They were about what people learned afterward.

Here are the stories I was able to collect.

Deborah Melkin: Sometimes a Floppy Disk Is All It Takes

Deborah Melkin shared a story from earlier in her career involving a server reboot that went very wrong. A bootable floppy disk had been left in the server. It contained an fdisk /mbr command. The server was rebooted, the command ran, and suddenly they had a much bigger problem than they expected.

The team had to find another server, reinstall SQL Server, and restore the databases from backup. The lesson seems obvious now, but that’s one thing I like about outage stories. Things that seem obvious after the fact aren’t always obvious when you’re standing in the middle of the problem.

Sometimes the lesson is simply to understand what is actually sitting in or connected to the server before you reboot it. And, of course, make sure your backups are somewhere other than the server you’re trying to recover.

Read Deborah’s full story

Andy Yun: The Outages That Live in Infamy

Andy Yun shares two non-SQL Server outages before getting to his SQL Server story. The first was when a backhoe literally dug up his company’s T1 line, leaving them without Internet for most of the day.

The second happened at a software company that supported market traders, where executives chose not to have a backup Internet connection after moving the office to VoIP. When the Internet went down, the entire office, call center, and data center were effectively offline, including their phones.

Both stories reinforced the same lesson: single points of failure hurt.

His SQL Server outage happened while Andy and another DBA were at PASS Summit, when a SAN administrator accidentally deleted the production transaction-log LUN for an instance with several hundred databases and several terabytes of data. Fortunately, their backups were good, and Andy used sp_restoregene to quickly generate the restore commands.

They initially tried four parallel restores, but the SAN couldn’t handle the load, so they stopped and worked with the business to prioritize the databases. The full recovery took three or four days.

What Andy realized afterward was that while they had tested restores for CHECKDB, they had never tested a full-instance restore at that scale. The experience also made him realize how important it was to understand the storage and infrastructure that your disaster recovery plan depends on.

Read Andy’s full story

Aaron Bertrand: When an INT Runs Out

Aaron Bertrand’s story is a good reminder that capacity problems aren’t always about disk space, memory, or CPU. In this case, an identity column reached the maximum value for an int. The result was an outage at Stack Overflow. The immediate solution wasn’t to change the column to bigint.

That would have been much more difficult to do during a live production outage. Instead, the identity was reseeded into the negative range, buying the team years of additional capacity. Problem solved. Until it happened again. A later operation involving IDENTITY_INSERT caused the identity value to move toward the positive limit again. So the team had another outage. And they reseeded it again.

I liked this story because it shows how an emergency fix can create another problem if the underlying issue isn’t eventually addressed. It also reminded me that we tend to think about capacity in terms of infrastructure. But data types have limits too. Sometimes the thing running out of room isn’t the disk.

Read Aaron’s full story

Rob Farley: When Corruption Leaves You With Very Few Options

Rob Farley wrote about an outage involving a bad disk controller that corrupted hundreds of database pages and even affected some backup files. This was one of those situations where the normal recovery path wasn’t enough. Rob and the customer’s CTO started looking at the database table by table, using clustered indexes, nonclustered indexes, DBCC PAGE, older backups, and other sources of information to reconstruct what they could.

One of the interesting parts of the story was discovering that a nonclustered index could still contain information that was missing from the corrupted clustered index. That meant even damaged parts of the database could potentially be useful during recovery.

Eventually, they were able to rebuild the tables and indexes and get the system back online. Reading this made me think about how different troubleshooting becomes when you’re no longer trying to find the best query plan or fix a blocking problem. When you’re dealing with serious corruption, you’re looking for anything that can help you recover the data.

Read Rob’s full story

Vlad Drumea: Two Weeks of Ransomware Recovery

Vlad Drumea shared probably one of the biggest incidents in this collection. His organization was hit by Ryuk ransomware in 2020. More than 60 SQL Server instances across more than 30 VMs were involved. Recovery took more than two weeks. This wasn’t simply a matter of restoring a database.

The environment itself had to be treated as compromised. Vlad described rebuilding VMs, recreating SQL Server directories, restoring system databases, restoring user databases, dealing with reinfection, fixing broken LSN chains, and rebuilding a VM from scratch. There was also a lot of automation involved using PowerShell, T-SQL, and dbatools. What really stuck with me was the human side of this story.

Recovery involved 16-hour workdays for more than two weeks, and Vlad talks about the burnout that followed. We spend a lot of time talking about backups, DR, security, and automation. Those things matter. But there are also people sitting in front of those computers at 2 AM trying to get a business back online. That’s part of the story too.

Read Vlad’s full story

Jeff Taylor: SQL Server on Fire, Literally!

Jeff Taylor shared two stories involving infrastructure problems. The first started with a power outage in an office that had effectively become a small data center. The servers had battery backup. The air conditioning didn’t. As the room heated up, the team started using fans and eventually began shutting servers down to keep the hardware from being damaged.

The temperature eventually approached 120°F. That incident resulted in a much larger infrastructure redesign, including better cooling, battery backup for the cooling, a generator, and fire suppression.

Then there was another incident involving a Dell server where Jeff was replacing memory and a drive. After powering it back on, he saw a flash. Then smoke. The problem apparently involved an iSCSI cable that had been damaged during the earlier heat incident and eventually shorted when the equipment was moved.

It’s a good reminder that SQL Server doesn’t operate in a vacuum. Power, cooling, storage, networking, and the physical environment are all part of keeping a database available.

Read Jeff’s full story

Edwin Sarmiento: When the Windows XP Image Wiped Out SQL Server

Edwin Sarmiento shared a story from a System Center deployment project where he was responsible for building a ConfigMgr environment for a healthcare company. To keep the deployment isolated, he placed ConfigMgr on its own network and set up a separate SQL Server.

During testing, he scheduled a Windows XP image deployment to run against some demo virtual machines. The problem was an incorrect IP address range. Instead of deploying the image to the demo VMs, it deployed to the SQL Server machine and wiped out the entire server.

Edwin actually discovered the problem after receiving a 6:15 AM alert that SQL Server was down, eventually logging in to find the SQL Server machine displaying the Windows XP desktop. Fortunately, this was an isolated environment and there was no disruption to the customer’s normal business operations.

What stood out to me about Edwin’s story is that his biggest lesson wasn’t about ConfigMgr or SQL Server. It was about the people involved, the decisions they make, and the importance of planning for what can go wrong before it does.

Read Edwin’s full story

Thomas Rushton: When the Server Room Gets Too Hot

The Lone DBA shared a story about a server room in an old Victorian mill building that overheated after the air conditioning failed during a hot summer weekend.

The servers were shut down, and after things cooled down, most of them came back online without any obvious problems. One server, however, kept crashing intermittently. They patched it, updated drivers, replaced the memory, HBAs, CPUs, and even the storage, but nothing fixed the problem.

Eventually, while replacing the motherboard, an engineer discovered that a daughterboard had partially melted during the overheating event, causing an intermittent short circuit. It’s a good reminder that a server room getting too hot isn’t just a temporary availability problem. It can cause physical hardware damage that may not show up until much later.

Read The Lone DBA’s full story

Andy Levy: When Your Database Time Travels

Andy Levy’s outage happened while he was away for the weekend and started with more than 250 notifications on his phone. His two-node SQL Server Failover Cluster Instance had repeatedly failed over, and both nodes had gone offline. When he checked the databases, he discovered that roughly two months of work had disappeared.

He shut down SQL Server to prevent things from getting worse and began working with his team on recovery. They ultimately restored the databases from backups to a cold spare SQL Server, getting the critical systems back online within a few hours. The postmortem revealed that a storage move two months earlier had left the two cluster nodes pointing to different copies of the virtual disks. Everything appeared fine until patching rebooted both nodes and caused the cluster to fail over to the VM connected to the older copy of the storage.

The databases had essentially “time traveled” two months into the past. What I liked about this story is how many small things had to line up for this to happen, and how weekly test restores, off-site backups, backed-up TDE certificates, and regular Export-DbaInstance scripts made the recovery possible.

Read Andy’s full story

Chad Callihan: What Time Is It?

Chad Callihan shared a deployment that appeared to go perfectly, only for users to start reporting later that morning that some data had the wrong times. Some records that should have been stored in local time were being saved in UTC, while other records were correct.

The problem wasn’t SQL Server itself, but another part of the release. Once identified, they were able to stop the problem, but cleaning up the incorrect data became the bigger challenge. Their environment had multiple time zones, with different tables, databases, logs, and error messages using different time references. Figuring out which records had the wrong time without changing the ones that were already correct made the cleanup particularly difficult.

The outage itself wasn’t very long, but Chad describes the cleanup as one of the worst parts of the experience. It’s a good reminder that deployments can appear successful while still leaving behind problems that may not show up until users start working with the data.

Read Chad’s full story

Rebecca Lewis: When SQL Slammer Took Down Both Data Centers

Rebecca Lewis takes us back to January 2003 and the SQL Slammer outbreak. Her organization had a primary data center in Chicago and a DR site in New York, but the worm came in through an approved VPN connection and quickly spread across the internal network. The resulting traffic overwhelmed their routers, eventually taking down both sites.

More than 400 physical servers had to be recovered, one at a time, while keeping clean machines isolated from infected ones. The IT and DBA teams worked through the weekend and had everything recovered by about 4 AM Monday, just in time for the market open. What stood out to me was that geographic redundancy didn’t help when the same problem could reach both locations.

The firewall had done its job, but the threat came through a legitimate connection that was already inside the network. It’s a great reminder that having a DR site doesn’t necessarily protect you from every kind of failure.

Read Rebecca’s full story

M G: A Comment That Deserved to Be Part of the Roundup

A person who goes by their initial M G don’t have a blog, but left a detailed comment on my invitation. I thought the story was too interesting to leave out.

The incident involved SQL Server 2016 and a SharePoint database with around 15 million rows and more than 850 GB of binary data. Three databases were repaired, but the fourth became the real problem. There were hundreds of suspect pages, a corrupted clustered index that was also the primary key, and a DBCC CHECKTABLE ... REPAIR operation that had been running for weeks and failing.

What caught my attention was the eventual workaround. Changing the database’s PAGE_VERIFY setting from CHECKSUM to OFF allowed the primary key to be dropped. That exposed another problem: SharePoint had accumulated roughly 90,000 duplicate elements. This is exactly the kind of kind of troubleshooting story that is difficult to forget because there isn’t necessarily a clean checklist that tells you what to do next. You investigate. You try something. You learn something new. Then you try again. And sometimes the solution comes from a place you weren’t expecting.

What I Took Away From These Stories

After reading through all of these, I noticed something. The actual cause of the outage was often not SQL Server itself. It was the environment around SQL Server.

A floppy disk. A SAN administrator deleting a LUN. An identity value reaching its limit. A bad disk controller. Ransomware. A lack of cooling. Corruption inside a SharePoint database.

These are very different problems, but they have something in common.

You don’t always know what the outage is going to look like until you’re already in it.

That’s probably why these stories are useful. You can study SQL Server performance. You can learn backup and restore. You can learn Availability Groups. You can learn PowerShell and dbatools. You can learn monitoring. But eventually, something unexpected is going to happen.

The best thing we can do is learn from people who have already been there.

And that’s what I really liked about this month’s T-SQL Tuesday. These weren’t polished success stories. They were stories about things going wrong.

And those are often the stories I remember the longest.

Thank you to everyone who took the time to participate in T-SQL Tuesday #202, whether you wrote a full post or shared your experience in the comments.

And thank you to Steve Jones for giving me the opportunity to host this month’s T-SQL Tuesday.

Until the next outage…

No, God forbids. It ould be yours, and hopefully the stories above give you the resolution route.