Troubleshooting is one of those skills that people often assume is just an IT thing. Like it’s something you only need if you’re staring at an error screen or trying to figure out why something won’t print.

Realistically, troubleshooting is one of the most universally useful skills you can develop. It applies to everything. Fixing a car, figuring out why a project at work fell apart, diagnosing why your sourdough didn’t rise. The thinking behind it is the same every single time. And once you internalize it, you’ll start spotting the patterns faster, cutting your troubleshooting time down, and building the kind of gut instincts that’ll make people think you’re just naturally good at fixing things.

I didn’t start in IT. I grew up working as a farm hand, worked a ton of odd jobs, dabbled in construction, moved into pipe lining then ultimately landed in plumbing. I spent years figuring out why equipment wouldn’t start, why a line was leaking, why something that worked yesterday didn’t work today.

When I eventually got into IT and started at a helpdesk, the problems were different but the thinking was identical. The same instincts I built up over years of hands-on work are what helped me move from helpdesk to CTO in under 5 years. I didn’t move up because I memorized every Microsoft KB article or Reddit post, but rather I already knew how to think through problems and filter for the most logical answer.

Nobody really teaches this skill either. You’re just kind of expected to figure it out, which can be frustrating. So I wanted to break down the real fundamentals that have helped me in my life, in hopes that it may help someone else along the way as well!

I think about these fundamentals in two buckets. There’s the stuff you actually do to find the problem, and then there’s the habits that make all of that more effective. This image shows how I think about the full troubleshooting toolkit:

These aren’t steps you follow in order like a checklist. They’re more like tools in a bag that you reach for based on the situation in front of you. Most of the time you’re going to start with “what changed?” because it’s the fastest way to narrow things down. But sometimes you get dropped into a problem with zero context and you have to work backwards from what IS working.

The order matters less than the fact that you’re reaching for the right tool at the right time, and that’s part of what you develop over time with consistent practice. That said, there’s a general flow that works really well for most situations, and that’s how I’ve laid them out below.

Start With What Changed

This is the single most important question you can ask when something breaks: what changed?

Something was working before. Now it’s not. Something happened between those two states. That’s your starting point. Every time. Doesn’t matter if it’s a network issue or a recipe you’ve made a hundred times that suddenly flopped.

People love to skip this step and jump straight to Googling symptoms or throwing random fixes at the wall. But if you can identify what changed, you’ve already narrowed your problem down significantly.

In IT this is huge. A user says “my email stopped working.” Okay, when? This morning? What happened this morning? Oh, there was a password reset last night? There’s likely your answer. Check your equipment uptime too. Does a reboot or a config change coincide with when the issue began? In the MSP world, being able to pull up a log and say “a Conditional Access policy was modified at 2:14 PM yesterday” can be the difference between a 10-minute ticket and a 2-hour rabbit hole.

Isolate the Problem

Most people want to go from “it’s broken” to “it’s fixed” instantly. That rarely works.

Problems are often just a bunch of smaller problems stacked on top of one another. The goal is to strip them away, get down to the core, get that working first, and then slowly layer complexity back on top.

Your car won’t start. It could be the battery, the starter, a fuse, the fuel pump, any number of things. If you replace the battery AND the starter AND the fuel filter all at once and the car starts, what actually fixed it? You just spent money and time on stuff that might not have been broken. Instead, check the battery voltage first. Good? Move on. Try jumping it. Turns over? Now you know your battery was dead. Doesn’t turn over? Now you’re looking at the starter or a fuse. Each test should rule something out and move you forward.

The same applies in IT when troubleshooting a VPN. Can you ping the gateway? Yes? Network is probably fine, move on. Can you authenticate? No? Now it's an auth problem, not a network problem. Each test narrows the scope.

The people who change five things at once and then can’t tell you which one fixed it? They’re starting from zero again next time. One thing at a time. It feels slower in the moment but it saves you so much pain in the long run.

Reproduce It

If you can make the problem happen on demand, you basically own it. Reproducing an issue means you understand the conditions that cause it, and once you understand the conditions, you’re really close to understanding the fix.

Anyone who’s worked a helpdesk knows the pain of “it does it sometimes.” Okay, randomly when? Every day? Only in the morning? Only when you have 47 browser tabs open? Getting specific about reproduction is everything. “It’s broken” is a complaint. “It fails when I do X after Y” is a bug report. Big difference, and it makes a huge difference when you’re escalating to Microsoft support or a vendor.

Work Backwards From What You Know

When you’re really stuck, flip the problem around. Instead of trying to figure out why something is broken, start from what IS working and work backwards toward the break.

If water isn’t coming out of a faucet, you don’t start by digging up the water main. You check the faucet, then the valve, then the pipe, then the supply line. You follow the chain link by link until you find the break.

Network troubleshooting is literally this. You’re basically just walking up and down the OSI model. User can’t reach a website. Can they reach other websites? Can they ping the gateway? Do they have an IP? You’re walking backwards through the stack until you find where it falls apart. It’s not glamorous. It’s just methodical. But it works every single time.

Read the Error Message. No, Actually Read It.

When something gives you an error, a warning, a weird message, anything... actually read it. Slowly. Word by word.

I know that sounds obvious but most people see an error and immediately panic or dismiss it. Error messages are literally the system telling you what went wrong. They’re not always perfectly clear, but they’re almost always pointing you in the right direction.

Over the years, I’ve watched folks screenshot an error and immediately paste it into a chat asking for help without even reading what it says. Half the time the error literally tells you what to do. “Access denied. Contact your administrator.” It’s a permissions problem! “Certificate expired on 01/15/2026.” There’s your answer! Even the ugly ones, like the long PowerShell stack traces or cryptic Azure error codes, they still give you a thread to pull on.

Search Like You Mean It

One of the most underrated troubleshooting skills is knowing how to search effectively. When I started in IT, troubleshooting meant Googling the error, finding a forum post from 2009, scrolling past four “me too” replies, and finding the one answer with a green checkmark. The sources have evolved but the skill of searching well is just as important as ever.

Be specific. Don’t search “email not working.” Search “Microsoft 365 autodiscover failing external DNS.” Include version numbers and product names. Filter your results to the last year or month because a solution from 2019 might not be relevant in a cloud environment that’s changed three times since then. And learn to filter out the noise. A Microsoft Learn doc from someone who clearly reproduced the issue is worth 50 forum threads full of speculation.

Use Your Tools Wisely

The tools are really different now than they were even a few years ago, and the biggest shift is obviously AI. But the thing I think a lot of people are getting wrong is this: the tools don’t replace the process. If you don’t understand how to troubleshoot, AI will just help you be wrong faster.

AI is an incredible troubleshooting tool. I use it constantly! But use it as a collaborator, not as an authority. It's great at synthesizing information, explaining error messages in plain language, and brainstorming possible causes. It's not great at knowing the current state of your specific environment or always being accurate about product details that change frequently.

The biggest mistake I see is treating AI output as the answer instead of a starting point. If AI gives you five possible reasons your Intune policy isn’t applying, great, but you still need to go check each one. And please, don’t blindly paste AI-generated commands into production. Read them. Understand them. Test them somewhere safe. AI can and will hallucinate commands that look right but aren’t.

AI makes a good troubleshooter faster. It makes a bad troubleshooter more confident. And that’s a pretty dangerous combo.

Document What You Try

When you’re in the middle of troubleshooting something complex, write down what you’ve tried and what the result was. Even just quick notes.

There’s nothing worse than being two hours into a problem and thinking “wait, did I already try that?” A simple log keeps you moving forward and prevents you from going in circles.

In the MSP world this matters even more because your teammates might need to pick up where you left off. A ticket that says “troubleshot the issue and resolved it” is useless. A ticket that says “checked DNS, confirmed autodiscover CNAME was missing, added the record, verified in Remote Connectivity Analyzer, working now” is something the next tech can learn from. It’s also something YOU can reference six months later when another client has the same problem.

Know When to Step Away

Sometimes the best troubleshooting move is closing your laptop and going for a walk. Your brain does a lot of processing in the background, and when you’re hyper-focused for too long you develop tunnel vision. You get fixated on one theory and stop seeing other possibilities.

I can’t tell you how many times I’ve been completely stuck on something, walked away, and then the answer just hit me 20 minutes later while doing something totally unrelated. If it’s not a production-down emergency, sleep on it. You’ll almost always see it differently in the morning.

Stubbornness is not the same thing as persistence.

Ask Better Questions

Troubleshooting is really just asking questions in the right order. And the quality of your questions determines how fast you get to an answer.

Bad question: “Why is this broken?”
Better question: “What specifically isn’t working?”
Even better: “When did it stop working and what happened right before that?”

This applies when you’re questioning a user, prompting AI, or just talking yourself through a problem. “My computer is slow” gives you nothing. “My computer started running slow after the last Windows update and it’s specifically slow when opening Office apps” gives you a clearer path.

And if you’re someone who asks for help in chats, Slack channels, or Discord communities, check out dontasktoask.com - it’s worth the quick detour! The core idea is simple: don’t ask “is anyone here who knows about X?” Just ask your actual question with specific and relevant details. You’ll get better help faster, and you’ll practice the skill of formulating clear, specific questions in the process.

Further Reading

If you’re in IT or the MSP space and want to go deeper on what it means to operate as a technician, I’d really recommend reading Mendy Green’s Laws for the Practical Technician over at Rising Tide. It covers a lot of complementary ground around the technician mindset, reading the screen, being intentional, and questioning your assumptions. I’ve shared it with my teams many times over the years and it’s always worth revisiting.

The Takeaway

Troubleshooting is a process. And the people who are “good at fixing things” have just internalized these fundamentals and apply the techniques consistently.

Start with what changed. Isolate variables. Reproduce the issue. Work backwards. Read the errors. Search well. Use your tools wisely. Document your steps. Step away when you need to. Ask better questions.

The tools will always keep evolving. AI is going to get better. New platforms and products will come and go. But these fundamentals are the same now as they were when I was diagnosing a root infested sewer line, and they’re the same as when I was sitting in a helpdesk trying to figure out why someone’s Outlook wouldn’t open. The problems may change, but the approach doesn’t.

That’s really it. The rest just comes with repetition!

Don’t get me wrong - Azure Foundry can be intimidating and it’s not nearly as user friendly as Grok or ChatGPT, but they don’t give you this level of access to developing and building your custom solutions. In just a few clicks you can deploy your own models with instant access using the Playground or utilize the REST API endpoints and integrate them into your application. You can expand even further by creating your own RAG pipeline with Vector Database storage and build your own custom agents.

Deploying Azure Foundry

You can access the Foundry portal from ai.azure.com and follow the Getting Started steps. In short, you’ll want to create a new project, ideally in East US 2 as your region - each region has limited access to models, but East US 2 has a good overall selection. Depending on the models you want to use, you may need to choose a different region but you can easily do that when the time comes. Review the pricing pages to filter on specific regions and see what’s available.

Once deployed, you should see a Project Overview page that probably looks pretty intimidating. Let’s break the navigation menu down into pieces:

• Overview is showing you the information needed to integrate into an application. Here you can see the base endpoints and API key for your project. Azure has done a pretty good job of simplifying endpoints but there are a handful depending on your usages.

• Resource Selector is along the top ribbon menu. As you build further and expand to more projects you’ll be able to swap between them all here.

• Model Catalog is the list of models for deployment. Just click one and deploy to get started!

• Playgrounds is the quick and dirty workspace to test your deployed models, agents, assistants, etc. Use your models here with minimal setup.

• Agents are the evolution of chatbots, capable of performing tasks directly rather than just providing answers.

• Assistant vector stores are an easy way to upload files and folders in bulk to give your models or agents the additional custom context and knowledge it needs to level up.

• Models + endpoints is a one stop shop for all your current deployed models and resources.

Deploying Your First Model

We’ve got the project, now it’s time to deply your first model - click model catalog and pick one that interests you. You can filter on different tasks and categories, but I’m choosing to go with GPT 5 Nano - it’s powerful as an overall model and cheap to use, though you may opt for a different model based on your goals. Click Use this model to begin the deployment process then click Connect and deploy to wrap up. Once done you should see the overview page for your new model, typically showing the deployment name, endpoint URL, and API key for further integration.

Once you have your first model deployed you can view it and future models from the bottom left Models + endpoints menu item. Repeat the process to deploy more models, but be cautious of pricing. Nothing is exorbitant (aside from Sora!), but it can add up if you aren’t careful. Be sure to review the Azure pricing sheets - sage advice for anything in Azure! Work towards learning which models are good at what and try to leverage the right tool for the job.

Tip! Ask AI to help you pick and choose between models if you aren’t sure where to start.

Sandboxes and Playgrounds

Use your newly deployed models by navigating to the Playgrounds section. Here you can start from different templates (assistants, chats, pictures, audio, etc.), then tweak some parameters to get up and going. Add instructions or examples for more context and customization. Play with different configurations to see if you can refine and iterate until you’ve got exactly what you need.

Review the Microsoft Learn documentation to dig in further and learn the ins-and-outs of Azure Foundry and Playgrounds. Chats and assistants are powerful, but they really level up once you can provide some additional files and knowledge for it to reference and understand.

Building AI Brains - Vector Storage Databases

Vector databases are a type of storage system meant for easier retrieval of information by AI models. They transform raw data into embeddings which are indexed and stored as vectors. Similar data is stored near each other within the database, helping build out the relational infrastructure for faster retrieval. I’m going to stop pretending to understand; read this great breakdown for further info on vector databases. Back in Azure we’re going to navigate to Assistant vector stores in the bottom-left of the navigation menu.

Add a new store and create it, then add files needed to improve the context for your assistant. Luckily all the Microsoft documentation is on GitHub making it easy to download or link for building out your knowledgebase. I’ve been toying with Azure DevTest Labs recently so I’m choosing to upload a few related documents about it to discuss more with my assistant.

Connecting it All Together

Back in the Playgrounds we can open an assistant session. Select your model, give it your instructions, tweak the parameters, and now add the File Search tool and attach our vector store database for knowledge. Similarly you can use the Agents playground and create a new deployment and file search focused on a specific scenario - feed it instructions, prompts, files, add actions and tools for it to use, etc. Experiment and see what you can create - want to dig in more? Use this Microsoft Learn documentation to follow along and build an AI Agent with Foundry!

Hopefully you can see that there’s a ton of possibilities with Azure Foundry. It’s not as polished but leaves lots of room for creativity and customization, and the most powerful part of it is its API structure. Build your own models or agents and integrate them directly into your Web App, Logic Apps, and more using the ample connectors available. Azure Foundry gives you so much sample code and documentation for jumping off and making your own creation.

Not sure how to get started? Read my previous article on Vibe Coding with Lovable to build your own custom website and host it with Azure!

Often these applications make hosting your newly AI-created website a paid feature or lock you into their domain. If you already use Microsoft Azure, then leveraging their Static Web Apps (SWA) will allow you to host a website for free, making use of Microsoft’s built-in features like global routing, custom domain names, SSL certificates, Docker deployments, and even incorporate API backends using Function Apps. We’ll be using Lovable to create our website, but these hosting steps work for any app, regardless of how it was developed.

This article will assume you already have the following accounts and access:

• Lovable account (free tier is fine)

• Azure Subscription

• GitHub account

• Domain Name / DNS Registrar

Using Lovable to Build an App

First we need to determine what to build. Keep it simple and focused when beginning, describing the core functions and features of the application in its most basic state - or don’t! Go experiment and see what gives you the best results. Lovable has lots of documentation on what they think works best for creating applications if you aren’t sure where to begin. I’m going to attempt to create a website that searches for recipes using the Spoonacular API with secure server-side routing.

Depending on the complexity of your request you will likely get a mix of results - probably a bit of “wow, this is really cool” mixed with “but this button doesn’t do anything, this one 404s when you click on it, and whose data is this?”. AI is extremely powerful but it’s not a miracle worker just yet - expect some rough patches and frustrations along the way. Be patient, tell it the errors you see on the screen, provide screenshots, explain what you want it to do or how you want it to look, etc.

Typically I’d continue working on the application further and refine it before bothering to host it, however, in the spirit of moving this blog along, let’s jump to the next step - GitHub!

📌 Tip! If you’re creating an app with multiple pages, or routes, then you may need to nudge Lovable a bit. Let it know you’re building an app with Azure and you need to list out your routes.

Syncing Your App to a GitHub Repo

Once you’ve gotten your app to a working state you can begin the process of syncing it to your GitHub account. From Lovable you can find the GitHub integration in settings and configure it with these steps - I’d highly suggest giving Lovable permissions to specific repositories instead of all repositories when asked. Follow the prompts, and your application will be seamlessly transferred. You can follow the links to jump to it and see the app’s codebase.

Deploy Azure Static Web App from GitHub

With our app now in GitHub, we can create our Static Web App (SWA) to deploy from the repo's codebase ensuring it’s always up to date with the latest build.

1. Navigate to portal.azure.com and search for and select Static Web App from the menu.

2. Fill out the required details - select or create a resource group, give your app a name, select your repo from your integrated GitHub account, and set the output location to dist for a smooth launch! I’ll also map the api folder since I’ll be using it, but you might not be!

   

   📌 Tip: Lovable often uses React and Vite for its creations and it outputs into dist during the build process.

3. For the Deployment Configuration page select Deployment token.

4. Create your application and click go to resource once it’s done. It should only take a minute, though it will continue setting up for another 5-10 minutes before it has fully deployed everything it needs.

5. You can monitor and troubleshoot the deployment from GitHub by going to the Actions tab of your repo. This is the CI/CD magic - it runs each time you update your repo and tells Azure to redeploy from your updated code. Review any errors and work through them with Lovable if needed.

   

6. From the Azure Overview tab you can see the major configuration settings and details about the app. You can access it from the URL listed in the top-right. We can add a custom domain next.

   

From now on as you make updates to your repository it will run the GitHub Action workflow to keep the Azure app updated. Check actions again in the future if you have issues updating the website.

Adding Environmental Variables

My app uses an Environmental Variable to securely store our API key for Spoonacular instead of hardcoding it. Variables allow you to write dynamic code and increase security as well as improving collaboration and sharing. If your app doesn’t have an API then you can skip this section!

1. In Azure navigate to Environment Variables on the left side.

2. Add a new variable named SPOONACULAR_API_KEY and enter the API key secret for the value then save it.

Adding a Custom Domain

You got your website up and running and could technically call it quits here, but you’ll probably want to route it to a custom domain if you have one.

1. Click custom domains and then add a ‘Custom domain on other DNS’ unless you already use Azure to manage your domain, in which case you would choose the first option.

   

2. Enter your preferred domain name for the website. I’m going to use recipe.dustinlepi.com for this app.

3. Azure will supply you with the DNS records to add, so you’ll need to navigate to wherever you manage your domain’s DNS. For me that’s going to be Cloudflare.

   

4. Add your new DNS records and save. If you also use Cloudflare then you’ll want to toggle off their proxy protection.

   

5. Back in Azure click add to wrap up. DNS may take some time to propagate so don’t worry if you see an error at first. If everything is correct, it will eventually succeed.

6. Set your new domain to be your default domain unless you have reason not to.

7. All done! Hopefully you can now access your website by its custom domain.

Conclusion

If you’re like me, you may need to go revisit Lovable and flesh out your app some more. As you continue working with Lovable it will push updates to GitHub, which in turn push changes to your website. You can also configure Lovable to push changes to a secondary dev branch in GitHub instead of “pushing to prod”. Once you are ready to update prod you can initiate a pull request from the dev > main branch and commit your new changes.

All of this robust Enterprise cloud technology, and it’s free! We’ve barely scratched the surface of features in Static Web Apps, like environmental variables, incorporating databases, or adding function apps for API endpoints. Want to learn more? Here’s a similar Microsoft training you can follow along with, or get the blog’s example website from the GitHub repository here!

If you have a vision and Photoshop skills, you could probably complete this all in a day. Lacking both creativity and patience, I opted to let Claude and Lokka handle it instead. Honestly, the results surpassed anything I would’ve created 😅.

Getting Familiar

Let’s first talk a bit about MCP servers. Think of them as bridges connecting tools like Claude to external systems, such as your Microsoft environment, allowing them to pull or push data securely. Plugins that supercharge Claude’s abilities, letting it interact with APIs in real time. In this post, we’ll use two MCP servers to customize your Microsoft Entra sign-in experience and branding.

• Lokka is an MCP server created by Merill Fernando that works with Claude to extend its capabilities and connect into your Microsoft environment via Graph API. This lets Claude retrieve (and potentially set or update) information directly in your Microsoft tenant, all through natural language.

• Alongside Lokka we’ll also be using the Microsoft Docs MCP server to pull in up-to-date Microsoft Learn documentation. That means Claude can check the official docs as it works - how powerful is that?!

I can’t stress this next part enough: MCP servers are like handing Claude a sword ⚔️. It’s up to you to make sure it’s wielded responsibly. I would not connect this to a production environment or feed it any sensitive data, especially until you fully understand how each piece of the puzzle works and what risks lie where.

You can take precautions, such as limiting the scope of the API permissions, reviewing every Graph API request before it’s sent, or restricting access with CA policies, but this is still the wild west - use common sense and always be curious, yet cautious. Having a solid understanding of permissions for Entra applications can be helpful.

Public service announcement over!

Getting Setup and Connected

To proceed you’ll need to have access to and configure the following.

• Claude Desktop - Application for interacting with Claude locally. The free tier totally works, but expect to bump into some usage limits.

• Lokka - MCP server that connects Claude to your Microsoft tenant via Graph API and app registration. Review the various ways of getting Lokka setup and configured.

• Microsoft Docs - Allows Claude to search Microsoft Learn docs in real time. No auth needed. View instructions for the Claude Desktop client within the Getting Started table.

First install Claude Desktop and get signed in. Next you can set up Lokka, which will need permissions to your Microsoft tenant. Lastly, add the Microsoft Docs MCP server.

Claude uses a JSON configuration file to identify available MCP servers (or “tools”) and their connection details. To view your configuration file, navigate to Developer > Open App Config File in the ribbon menu.

Here’s an example, though yours may look slightly different depending on your chosen Lokka authentication method:

{
  "mcpServers": {
    "Lokka-Microsoft": {
      "command": "npx",
      "args": [
        "-y",
        "@merill/lokka"
      ],
      "env": {
        "TENANT_ID": "YOUR TENANT ID",
        "CLIENT_ID": "YOUR APPLICATION OR CLIENT ID",
        "CLIENT_SECRET": "YOUR CLIENT SECRET"
      }
    },
    "microsoft.docs.mcp": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://learn.microsoft.com/api/mcp"
      ]
    }
  }
}

Once you’ve adjusted your configuration file, you will need to re-open Claude or reload the extensions before you begin (select Developer > Reload MCP Configuration). Now let’s ask Claude to check our connections and verify connectivity:

🤖 Can you check and verify access to Lokka and Microsoft Docs tools?

Just like that, Claude tapped into our MCP tools, confirmed it can authenticate to our Microsoft tenant, and pulled fresh info straight from Microsoft Learn. Are your wheels turning yet? Just think of the possibilities this opens up!

Lokka, can you check Sally’s recent sign-in and audit logs for anything suspicious or out of the ordinary from the last week? Can you review best practices for Conditional Access policies and compare them to my current environment? Can you help me plan this upcoming configuration change and see how it may impact us? We’re truly in wild times!

Planning our Facelift

Now we’ve got all the pieces connected, next we need to go find how to adjust the company branding settings. Let’s first start by digging into the documentation and seeing what requirements we need to abide by.

The more you tell Claude what you’re wanting, the better your outcomes will be. I started with the prompt below, but feel free to customize and experiment to see what you can come up with.

🤖 Research the latest Microsoft documentation for Company Branding settings in Entra. Identify all available settings, including visual elements (logos, background images, favicons) and text elements (sign-in page text, hints). For each setting, detail how it can be updated (manual upload or Graph API), along with any constraints like file formats, size limits, or dimensions. Source the information from our microsoft.docs.mcp tool or official Microsoft Learn documentation only.

Once your request is submitted, Claude then begins querying the Microsoft Docs MCP connection for relevant settings. It will pause often to reason through new information it finds, looping through this process many times until it’s gathered enough detail.

Interface Overview:

• Left Panel – Chat: This is Claude’s conversation view, where you can see its reasoning process and the results it’s retrieving.

• Right Panel – Artifact: A standalone content area where Claude can display documents, files, or code it creates. In this case, it’s showing a complete playbook for updating our Company Branding.

💡 Tip: If you’re not getting the results you want, keep working with Claude. Be specific, don’t assume it knows exactly what you mean. Define your request explicitly for best results.

If you aren’t sure how, ask Claude to interview you to uncover the details it needs.

As Claude will likely mention, in order to allow Lokka to update Company Branding automatically you’ll need to add the following application permission to your Lokka App Registration:

OrganizationalBranding.ReadWrite.All

Subscribe now

Almost ready! We technically have everything we need to get started, but you’ll probably want to give Claude some more context about what you’re looking for. Think of it like hiring a branding agency: the more you share about your style, tone, and vision, the closer the result will be to what you want. I’m choosing to give it free reign to go wild.

Updating our Company Branding Configuration

Claude and Lokka are off to the races, working towards a new sign-in experience, for better or worse! Our first draft had some issues, like clashing colors and unappealing designs. Clicking download also crashed the artifact view (instead, download and open the HTML page directly).

Work with it, massage it, or yell at it until you get closer to what you’re looking for. Don’t be afraid to start a new chat if the current feels “too far gone” and you would rather a fresh start.

Hopefully you’ve updated most of your branding via Lokka’s Graph API connection. It may give you some grief with images or files - if you are persistent and technical, you can likely talk Claude through updating the images by requesting it to PUT and stream the data directly through the API.

If that doesn’t work, you can finalize changes in the Entra portal. Navigate to Entra ID > Custom branding. From here you can edit and navigate through the various sub menus uploading the handful of logos, images, and files needed to wrap up. If they aren’t named intuitively then ask Claude to update the names for easier importing.

Keep testing the changes until you like what you see. Using InPrivate or Incognito views are helpful for this, though note it can occasionally take a few minutes for things to sync up after saving changes in the portal and API. Use your browser tools to help pinpoint issues if you feel comfortable enough. F12 on most browsers, or somewhere in settings or more tools, will launch developer tools.

You can use the console view to help identify errors or issues, and the elements view will show you the overall styling - here you can make visual changes to test in real time if you have a good understanding of CSS. You can also right-click a section on the screen you want to review and click inspect to take you right to that element in dev tools.

Wrapping Up

Don’t stop at the first result Claude gives you. Keep branching off, keep experimenting. If you don’t like the style, ask for something more realistic or provide references. Claude tends to lean vector-heavy, but you can pair it with other tools like ChatGPT or Grok for logos, resizing, or even creating entirely new images. Half the fun here is Frankensteining tools together until you land on something that feels right.

I won’t pretend the process is perfect. I probably spent 30 minutes arguing with a bot, but the results weren’t half bad personally. Better than what I could do at least. More importantly, it felt like peeking into the future of IT administration. Watching Claude tear through Microsoft docs and brute-force Entra settings at lightning speed? Equal parts impressive and terrifying.

One last reminder: be cautious with permissions. Don’t let Lokka become a “God tool” with more access than it needs. Remove unused app permissions when you’re done experimenting, and always think through the risks. It’s fun to push the boundaries, but your tenant security should never be an afterthought.

So… what else could you build with the power of Lokka and Microsoft Docs?

Leave a comment