The CIS Windows 11 Benchmark v4.0 is a 300-page PDF. It is the canonical reference for Windows hardening — every major endpoint management platform, auditor, and security team uses it. But it exists as a document for humans, not a database for machines.
To build a compliance agent that could compare Intune configuration profiles against CIS recommendations, I needed the benchmark data in a structured format: benchmark ID, setting name, recommended value, severity, description, remediation steps, and the exact Intune Settings Catalog path to configure it. None of that exists as a public API or pre-built dataset. The only authoritative source is the PDF.
So with a lot of help from Claude Code I created extract_benchmarks.py — a one-off script that reads CIS_Microsoft_Intune_for_Windows_11_Benchmark_v4.0.0.pdf and produces benchmarks.json. a JSON formatted list of all the CIS Benchmark recommendations from the PDF file. What looked like a simple, two-hour task took considerably longer. Here is what I ran into.
The script follows a three-stage pipeline:
pypdffrom pypdf import PdfReader
r = PdfReader("CIS_Microsoft_Intune_for_Windows_11_Benchmark_v4.0.0.pdf")
full_text = "\n".join(page.extract_text() or "" for page in r.pages)
Simple enough in concept. The complications were entirely in stages 2 and 3.
The PDF has a table of contents that spans roughly twenty pages. It lists every benchmark by section number and name. When you extract the full text of the document, those titles appear twice — once in the ToC, once in the actual benchmark section.
This matters because I needed to split the document into per-benchmark blocks. Claude Code helped me use the following anchor pattern:
ID_LEVEL_RE = re.compile(r"(\d+(?:\.\d+)+)\s+\((L1|L2|BL|NG)\)\s+Ensure\s+")
This matches lines like 1.1 (L1) Ensure 'Allow Cortana Above Lock Screen' is set to 'Disabled'. The problem: the ToC contains exactly this pattern for every benchmark, so finditer returned double the expected matches — one from the ToC entry and one from the actual content.
The filter was simple but non-obvious: every real benchmark section contains the string "Profile Applicability:", which marks the start of the structured body. ToC lines do not. So after splitting on the anchor, Claude Code suggested to discard any block that lacked this string:
if "Profile Applicability:" in block:
blocks.append((bench_id, level, block))
This cut the block count exactly in half and left only genuine benchmark entries.
PDF text extraction does not know about document structure — it knows about character positions on a page. Headers and footers land in the extracted text wherever they happen to fall in reading order, which is often mid-sentence or mid-field.
The CIS PDF has page numbers that appear in the extracted text as isolated lines like \nPage 47\n in the middle of a description paragraph. Once again Claude Code came to the rescue with a method to strip the page numbers before any further processing:
def clean(text: str) -> str:
text = re.sub(r"\nPage \d+\s*\n", " ", text)
text = re.sub(r"\s+", " ", text)
return text.strip()
The second substitution collapses all remaining whitespace — tabs, multiple spaces, newlines — into a single space. This is destructive (it loses formatting), but since I was extracting fields into flat strings anyway, it was the right trade-off for this use-case.
Each benchmark title follows a pattern like:
Ensure ‘Allow Cortana Above Lock Screen’ is set to ‘Disabled’
The setting name is in single quotes, and the recommended value is in the second quoted phrase. But not every title follows this pattern. Some read:
Ensure ‘Windows Firewall: Domain: Firewall state’ is set to ‘On (recommended)’
And others are more irregular:
Ensure ‘Minimum password age’ is set to ‘1 or more day(s)’
Luckily Claude Code found an elegant way for the extractor to handles this in two passes — first try to match the quoted pattern, then fall back to the raw title:
def extract_setting_and_recommendation(title_block: str):
title = clean(title_block)
title = re.sub(r"\s*\((Automated|Manual)\)\s*$", "", title)
setting_m = re.search(r"'(.+?)'", title)
setting = setting_m.group(1) if setting_m else clean(title)[:80]
rec_m = re.search(r"is set to '(.+?)'", title)
if not rec_m:
rec_m = re.search(r"is set to (.+?)$", title)
recommendation = rec_m.group(1).strip().rstrip(".") if rec_m else ""
return setting, recommendation
The (Automated) / (Manual) suffix that CIS appends to some titles also needed stripping — it is metadata about the audit method, not part of the setting name.
The remediation section of each benchmark contains the Intune Settings Catalog navigation path. In the source document this looks clean:
Settings Catalog path: Above Lock > Allow Cortana Above Lock
But after PDF text extraction, long paths are broken across lines wherever the PDF renderer wrapped them, with no consistent delimiter. A path like:
Administrative Templates\MS Security Guide\Enable Structured Exception
Handling Overwrite Protection (SEHOP)
comes out as two lines that need to be joined. Worse, some paths continue across a page boundary, which means a stray page number sits in the middle.
Claude Code suggestion was to have the CSP extractor use a regex that captures everything between the "Settings Catalog path to" marker and the next known field boundary, then have it join the lines:
def extract_csp(remediation_text: str) -> str:
m = re.search(
r"Settings Catalog path to .+?\.\s*\n((?:(?!Default Value:|References:|Audit:|Impact:|Rationale:|Profile).+\n?)+)",
remediation_text,
re.DOTALL,
)
if m:
lines = [l.strip() for l in m.group(1).splitlines() if l.strip()]
path_lines = []
for line in lines:
if re.match(r"Note:", line, re.IGNORECASE):
break
path_lines.append(line)
return " \\ ".join(path_lines).rstrip(".")
return ""
The " \\ ".join(path_lines) reconstructs the backslash-separated hierarchy from whatever the PDF broke into separate lines. The Note: stop condition prevents footnotes that immediately follow the path from being absorbed into it.
Some CIS controls apply to settings that Intune cannot configure through the Settings Catalog or Administrative Templates. They require either a direct registry OMA-URI or a PowerShell script. The PDF says so explicitly in the remediation text: “This setting is not possible through Settings Catalog”.
For these, Claude Code added the following code so the remediation steps builder detects the signal and changes the output entirely:
is_powershell_only = "not possible through Settings Catalog" in text or (
"PowerShell" in text and not is_settings_catalog
)
if is_powershell_only:
steps.append(
"Remediation not possible via Settings Catalog or OMA-URI; "
"deploy via Intune Scripts or Remediations blade"
)
Rather than generating a Settings Catalog navigation path that does not exist, the tool tells the agent (and the user) the honest truth: this one needs a script.
The raw PDF remediation sections are verbose. They contain audit procedures, default value explanations, references to Group Policy paths, and sometimes two or three paragraphs of context. None of that is useful to someone who just wants to know where to click in Intune.
Here Claude Code suggested code so the build_remediation_steps function synthesizes a four-to-five step list tailored to the profile type:
def build_remediation_steps(remediation_text, csp, setting, recommendation):
steps = []
is_settings_catalog = "Settings Catalog" in text
is_admin_templates = "Administrative Templates" in (csp or "")
is_endpoint_security = any(
kw in (csp or "").lower()
for kw in ["firewall", "defender", "antivirus", "exploit", "bitlocker"]
)
# Step 1 — where to navigate in Intune
if is_admin_templates:
steps.append("In Intune: Devices > Configuration profiles > Create > "
"Windows 10 and later > Administrative Templates")
elif is_settings_catalog:
steps.append("In Intune: Devices > Configuration profiles > Create > "
"Windows 10 and later > Settings Catalog")
elif is_endpoint_security:
steps.append("In Intune: Endpoint Security > select the relevant policy type")
# Step 2 — what to configure
if csp:
steps.append(f"Navigate to and configure: {csp}")
# Step 3 — value to set
if recommendation and csp:
steps.append(f"Set the value to: {recommendation}")
# Step 4 — any PDF notes
note_m = re.search(r"Note:\s*(.+?)(?:Default Value:|References:|$)",
remediation_text, re.DOTALL | re.IGNORECASE)
if note_m:
steps.append(f"Note: {clean(note_m.group(1))[:200]}")
# Step 5 — assign
if steps and not is_powershell_only:
steps.append("Assign the policy to the target Windows 11 device groups")
The distinction between Settings Catalog, Administrative Templates, and Endpoint Security is important for the agent: these are three different places in the Intune portal, and a user following the wrong navigation path will not find the setting.
The JSON output is keyed by category name, not by section number. "Above Lock", "Administrative Templates", "Credential Guard", and so on. The mapping from section number (1, 4, 9…) to human-readable name came from the ToC.
Parsing the ToC reliably was its own small problem. The table of contents lines look like:
1 Above Lock .......... 42
4 Administrative Templates .......... 87
But the dots and page numbers vary in format. Fortunately for me Claude Code is also skilled in regex and produced the regex that captures them:
toc_re = re.compile(
r"^[ \t]*(\d{1,3})[ \t]+([A-Za-z][A-Za-z0-9 /\(\)\-]+?)[ \t]*(?:\.{3,}|[ \t]+\d+[ \t]*$)",
re.MULTILINE,
)
This matches a leading number, then a name that starts with a letter and contains alphanumeric characters and common punctuation, followed by either a dotted leader (......) or a plain number at the end of the line. The "ensure" not in name.lower() guard drops individual benchmark titles that happen to match the pattern.
Running the script on the 300-page PDF takes about 30 seconds and produces a structured JSON file grouped by category:
Reading PDF...
323 pages, 1,247,831 chars
Mapped 18 top-level sections
Found 246 benchmark blocks
Parsed 246 benchmarks across 18 categories
(14 PowerShell-only / no CSP path)
Category breakdown:
Above Lock: 1
Administrative Templates: 47
Credential Guard: 4
Firewall: 24
...
Wrote benchmarks.json (187 KB)
246 benchmarks, 18 categories, 187 KB. Every entry has a structured id, setting name, recommendation, severity, description, CSP path, and a list of concrete Intune navigation steps.
{
"Administrative Templates": [
{
"id": "4.1.3.1",
"setting": "Prevent enabling lock screen camera",
"recommendation": "Enabled",
"severity": "High",
"description": "Disables the lock screen camera toggle switch in PC Settings and prevents a camera from being invoked on the lock screen.",
"csp": "Administrative Templates\\Control Panel\\Personalization\\Prevent enabling lock \\ screen camera",
"remediation": [
"In Intune: Devices > Configuration profiles > Create > Windows 10 and later > Administrative Templates",
"Navigate to and configure: Administrative Templates\\Control Panel\\Personalization\\Prevent enabling lock \\ screen camera",
"Set the value to: Enabled",
"Assign the policy to the target Windows 11 device groups"
]
}
]
}
The benchmark database is loaded once at container startup and held in memory:
class CISBenchmarkDatabase:
BENCHMARKS = json.loads(_BENCHMARKS_FILE.read_text(encoding="utf-8"))
The agent has three tools for querying it:
get_cis_benchmarks(category) — all controls in a categorysearch_cis_benchmarks(query) — keyword search across all setting namesassess_compliance_status(benchmark_id) — full detail and remediation for one controlNo network call, no external API. The LLM gets structured, pre-processed data it can reason over directly — rather than being asked to interpret raw PDF prose in context.
Claude Code’s reasoning rocks, it sure helped this human-in-the-loop understand and validate the code. I really enjoy my first Claude Code experience as it not just speed up my code production, but gave me a great learning experience by following its reasoning to not just understand the code but also validate the code and the JSON output. So I encourage you to not just copy and paste the code, but ask your prefered Model/Agent/AI to create your own version of the script (and have fun watching its reasoning and iterations as it tackles the challenges it faces)
PDFs are not documents, they are drawing instructions. Text extractors reconstruct reading order from character positions, which means anything the PDF author relied on visually (line breaks, columns, indentation) may not survive extraction intact. Budget time for this.
Anchor-based splitting beats page-by-page processing. Trying to process the PDF page by page would have been fragile — benchmark entries frequently span pages. Finding a reliable anchor that marks the start of each benchmark and slicing the full text string was simpler and more robust.
Generate output for the consumer, not for the document. The raw PDF remediation text is written for a human reading a PDF. The JSON output should be written for an LLM reasoning about Intune. Those are different audiences with different needs, and the gap between them is where most of the parsing logic lives.
One-off scripts deserve real engineering. This script only runs once per benchmark version. But because it was the foundation the entire agent was built on, errors in it would silently produce wrong compliance answers. Investing in the regex quality, the fallbacks, and the edge case handling was worth it.
]]>A few months ago I came across Jannik Reinhard’s blog post on building your own Intune agent with Microsoft Foundry. Jannik is well known in the Intune community for his tooling and automation work, and his post did something rare: it showed me in clear steps how to create a working, deployable example of an Intune agent in Microsoft Foundry that talks to a real Microsoft Graph endpoint — not a toy demo, but something I could actually plug into my own tenant.
Reading it, I felt confident that I could extend his framework with my specific use-case: an Agent that could check the CIS benchmark compliance of my Intune policies. The agent Jannik built answers general Intune questions. But what if it could also compare what it finds against the CIS Windows 11 Benchmark? Instead of just telling you what your configuration profiles contain, it could tell you whether those settings are compliant with a recognized security standard — and what to do if they are not.
That idea became this project.
The Intune CIS Compliance Agent is a hosted AI agent that:
You run it inside Azure AI Foundry as a kind: hosted agent, and interact with it through the Foundry playground — no custom UI needed.
Example questions it can answer:
I started from Jannik’s IntuneAgent repository. The core architecture he established — a Microsoft Agent Framework agent, Microsoft Graph helpers, @ai_function-decorated tools, and a Dockerfile targeting the Foundry responses protocol — was exactly the right foundation. I kept that structure and layered in three things:
1. CIS benchmark data Unfortunately you can only download PDF formatted CIS Benchmark files, which present some additional challenges and introduce higher token consumptions for most agents.
Luckily I got some help and magic from Claude Code that helped me to extract the CIS Windows 11 Benchmark v4.0 controls into a benchmarks.json file and built a CISBenchmarkDatabase class that supports category lookups, keyword search, and direct ID lookups. The benchmark data lives locally in the container — no external API call required to check a control.
Note: I’ll share more on my CIS Benchmark PDF to JSON convertion in the next post.
2. Settings-level profile inspection
Intune stores configuration profiles across three separate Graph API endpoints: Settings Catalog (/configurationPolicies), Legacy templates (/deviceConfigurations), and Administrative Templates (/groupPolicyConfigurations).
With help from Claude Code I extended Jannik’s original get_device_configuration_settings tool to fetch the actual per-setting values from each profile and normalizes them into a format the LLM can compare against benchmark expectations, ensuring it included Settings Catalog, Legacy Templates and Administrative Templates settings.
The tool accepts an optional profile_name parameter. When provided, it passes $filter=name eq '...' (Settings Catalog) or $filter=displayName eq '...' (Legacy) directly to the Graph API — so only the matching profile is fetched, and settings details are retrieved only for that one profile. This reduces a query about a specific profile from potentially 15+ sequential Graph API calls down to 2, and cuts the LLM context from a full tenant dump to a single profile. When profile_name is omitted, the tool falls back to fetching everything — useful for broad compliance surveys.
3. Compliance assessment tools
And with the help from Claude Code I added three new agent tools — get_cis_benchmarks, search_cis_benchmarks, and assess_compliance_status — to give the agent everything it needs to answer compliance questions: what the benchmark recommends, what severity applies, and what the exact remediation steps are.
The agent logic was relatively straightforward. The interesting engineering was in making the container work correctly as a Foundry hosted agent. Foundry’s kind: hosted protocol sits between the playground UI and your container, and there are some gaps between what Foundry sends and what the Agent Framework’s development server expects.
I worked through five issues, each one revealed only after the previous was fixed.
Running locally, main.py dropped into an interactive input() loop and worked as expected.
In a container, stdin is not a terminal — the first input() call immediately hits EOF and the process exits.
Foundry sees the container crash within seconds of starting. It took me a little while to understand the log messages and work with Claude Code on a fix.
Claude Code Fix: Check sys.stdin.isatty() at startup. If there is no terminal, skip the interactive loop entirely and start an HTTP server. If there is a terminal, run the interactive loop as normal.
if not sys.stdin.isatty():
# start HTTP server
else:
# interactive loop
Foundry sends GET /readiness probes before routing any traffic to the container. If those probes fail, Foundry kills the container before a single user request arrives. The Agent Framework’s serve() helper exposes /health — but not /readiness or /liveness, which Foundry requires.
Claude Code Fix: Use DevServer directly instead of serve(), get its underlying FastAPI app, and register the missing routes:
devserver = DevServer(port=8088, host="0.0.0.0", ui_enabled=False)
devserver.set_pending_entities([agent])
app = devserver.get_app()
@app.get("/readiness")
def readiness():
return {"status": "ready"}
@app.get("/liveness")
def liveness():
return {"status": "alive"}
Foundry calls POST /responses. DevServer listens on POST /v1/responses. Foundry does not let you configure the path it calls.
Claude Code Fix: A pure ASGI middleware class that rewrites the path in the request scope before forwarding:
if scope["type"] == "http" and scope.get("path") == "/responses":
scope = dict(scope)
scope["path"] = "/v1/responses"
scope["raw_path"] = b"/v1/responses"
Using a pure ASGI class (rather than FastAPI’s BaseHTTPMiddleware) matters here: BaseHTTPMiddleware buffers the entire response before forwarding it to the client, which silently breaks streaming. A pure ASGI class passes the send callable through unchanged, so SSE frames flow out in real time.
DevServer routes requests to a specific registered agent using metadata.entity_id in the request body. Foundry’s Responses protocol does not send this field.
The entity_id is generated with a random UUID suffix at startup — something like agent_in_memory_intunecomplianceagent_14fd26e737bb47a29d00501a2576f13e — so it cannot be hardcoded.
Claude Code Fix: In the middleware, resolve the entity_id at request time by calling the executor’s entity discovery, then inject it into the buffered request body before forwarding:
executor = await devserver._ensure_executor()
entities = executor.entity_discovery.list_entities()
entity_id = entities[0].id # cached after first call
data = json.loads(raw_body)
data["metadata"].setdefault("entity_id", entity_id)
_ensure_executor() initializes once and caches the result, so the per-request overhead is negligible.
This one was subtle. The request returned 200 OK, the agent started executing, the LLM credential was obtained — and then CancelledError. The log showed:
ClientSecretCredential.get_token_info succeeded
[CANCELLATION] Execution cancelled via CancelledError
ERROR: ASGI callable returned without completing response.
The bug was in _patched_receive, the callable I substituted for the original receive so DevServer would read the patched body instead of the original. After the body was consumed, subsequent calls returned {"type": "http.disconnect"} immediately.
In ASGI, the server calls receive() a second time during streaming to detect client disconnection. My function answered “yes, the client disconnected” before they actually had — causing DevServer to cancel the in-flight LLM call.
Claude Code Fix: Forward subsequent calls to the real receive rather than faking a disconnect:
async def _patched_receive():
nonlocal consumed
if not consumed:
consumed = True
return {"type": "http.request", "body": patched_body, "more_body": False}
return await receive() # forward to real receive for disconnect detection
After this fix, the agent ran to completion and the Foundry playground showed a full response.
The full fix sequence — five issues, five deployments — took a morning. Each issue was only visible after fixing the previous one, which is what made it interesting rather than frustrating. The container logs were clear at every step.
The end result is an agent that:
demo host: Esther Barthel
The Microsoft Agent Framework is genuinely useful. The @ai_function decorator handles JSON schema generation, parameter validation, and tool registration automatically. Writing a tool is just writing a Python function with type hints and a docstring. The framework takes care of the rest.
Foundry’s kind: hosted protocol is powerful but under-documented. The Responses protocol v1 is the right approach for bringing your own agent infrastructure — but the exact contract between Foundry and your container (which paths it calls, which metadata it sends, which fields it requires) is not fully spelled out in the public docs. Fortunately for me Claude Code was able to read the DevServer source code and filled in the gaps.
Pure ASGI middleware is the right tool for this job. Any time you need to intercept streaming HTTP — whether to rewrite a path, inject a header, or modify a request body — reach for a pure ASGI class. BaseHTTPMiddleware looks simpler but will silently break anything that streams.
The CIS benchmark is a solid target. The CIS Windows 11 Benchmark v4.0 has 300+ controls covering Security Options, User Rights, Firewall, Credential Guard, and more. Having those controls as structured data that an LLM can query gives the agent a credible, externally validated baseline to reason from — much better than asking the model to rely on training-time knowledge of what “secure” means. So a big thanks to Claude Code for offering a manageable solution to translate the PDF content to a structured JSON format.
I’m fully aware that right now, my additions make a great demo, but is nowhere near production ready.
Here are a few things I want to add:
The full code can be found in this repository.
You will need:
DeviceManagementManagedDevices.Read.All and DeviceManagementConfiguration.Read.All Graph permissionsgit clone https://github.com/cloud-devops-ninja/Foundry-Intune-CIS-Compliant-Agent.git
cd Foundry-Intune-CIS-Compliant-Agent
.env.example to .env and fill in your credentialscopy .env.example .env
python -m venv venv
venv\Scripts\activate
python -m pip install --upgrade pip
pip install -r requirements.txt
python main.py
<Ctrl>+<Shift>+PMicrosoft Foundry: Deploy Hosted Agent to Deploy the Agent to FoundryOnce more a big thank you to Jannik Reinhard for the original IntuneAgent concept and codebase — this project would not exist without that starting point.
]]>Covered Topics
Esther Barthel will present together with Freek Berson on Infrastructure-as-Code, using Bicep (a StarterKit & Masterclass session) at the Workplace Ninja Summit event. Esther Barthel will join Anton van Pelt in his session on how GO-EUC implemented Infrastructure-as-Code to automatically deploy lab environments at the Workplace Ninja Summit event.
]]>The EUC Masters Retreat gives you the time you need to ask, learn, explore and share. The weekend retreat format provides flexible timing, inspiring spaces and like minded individuals.
]]>When it comes to deploying resources on Azure, defining infrastructure can be a complex and time-consuming process. Fortunately, there’s a new tool available that simplifies the process and saves time and resources in the process: Bicep.
Bicep is a domain-specific language (DSL) used to describe and deploy Azure resources. It is a declarative language that provides a simplified way of defining Azure resources in comparison to traditional JSON or YAML templates.
Bicep is open source and is developed and maintained by Microsoft.
Bicep simplifies the process of deploying Azure resources by allowing users to write more concise code. It also provides a simplified syntax that is easier to read and understand than traditional JSON or YAML templates.
In addition, Bicep provides features like parameterization, reusable modules, and better error messages that make it easier to build and maintain infrastructure.
Bicep files have a .bicep file extension and are compiled into ARM templates before deployment. This means that any Azure resource that can be defined using ARM templates can also be defined using Bicep.
Here’s an example of what Bicep code looks like:
param storageAccountName string
param location string
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' = {
name: storageAccountName
location: location
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
}
This code creates an Azure storage account using the Microsoft.Storage/storageAccounts@2021-04-01 resource type. The param statements at the top of the file define two parameters that can be passed in when the Bicep file is deployed.
To get started with Bicep, you’ll need to install the Bicep CLI. The CLI is available for Windows, macOS, and Linux.
Once you have the Bicep CLI installed, you can create a new Bicep file using your favorite text editor or IDE.
Note: I personally recommend using VS Code, combined with the Bicep Extension for VS Code, as your code editor to use the extension supporting features, like scaffolding, snippets and linter to make create your first .bicep file a breeze!
You can also use the bicep new command to generate a basic Bicep file.
After you’ve created your Bicep file, you can use the bicep build command to compile it into an ARM template. You can then use the az deployment group create command to deploy the ARM template.
Note: As of Azure CLI version 2.20.0 and Azure PowerShell 5.6.0 you no longer need to compile the bicep template to an ARM template, but can use the bicep template as direct input for the resource deployment commands. Azure CLI and Azure PowerShell will automatically compile your bicep template before and offer the compiled ARM template to the Azure Resource Manager
Bicep is a powerful tool for deploying Azure resources. It simplifies the process of defining infrastructure by providing a more concise syntax and additional features like parameterization and reusable modules.
If you’re new to Bicep, I recommend checking out the official Bicep documentation and experimenting with some sample code to get a feel for how it works.
With Bicep, you can create and manage your Azure infrastructure in a more streamlined and efficient way, saving time and resources in the process. So why not give it a try and see how it can help you with your Azure deployments?
]]>Take two. Welcome to the summer edition of the Amsterdam Ruby meetup! Let’s talk about hosting and how our hobby projects are going.
We are doing this live at WeTravel in Amsterdam. WeTravel will not just host our event, they will also provide us with food 🥦 and drinks 🧃. We have added an attendee limit this time. We may change this before the event itself, so keep an eye on this space if you don’t secure a spot right away!
It goes without saying that we have a great set of speakers again. Our first guest is the marvelous, Esther Barthel who will talk to us about using your dev skils to transition Ops to the Cloud.
Our second guest is the astonishing Aidan Rudkovskyi who will talk about his NotForSale project.
This location is completely (wheelchair) accessible. Don’t feel like joining in person? The live stream can be found on YouTube, and it will stay up after the event. See you there! Can’t wait ✨ 🌈
Floor, Arno, Tom, Rayta
Esther Barthel will share how she transitioned from an Ops role to a DevOps role at the Amsterdam Ruby Meetup.
]]>
Esther Barthel will start this series with an introduction to DevOps and the transition to DevOps from an Ops perspective at this online TechDays event.
]]>Covered Topics
Esther Barthel will present solo on advanced AVD deployment scenarios using Bicep at the Workplace Ninja Summit event.
]]>She has many years experience in architecting and building virtual desktop environments with Citrix and Microsoft and was awarded as Citrix CTP and Microsoft MVP.
Transitioning Ops to the Cloud, adding Dev skills to the mix This session offers tips and tricks to add core Developer skills to your skillset, so you can transition from (on-premises) Operations to a Cloud DevOps role. This session will zoom in on some basic knowledge and terminology that will make it easier to understand the shift in work and competences for DevOps engineers.
Keep in mind that this session is not a technical deep dive that helps you pick the right tool for the job at hand, but it focuses on some basic knowledge of DevOps processes that will help you to plan the next steps in your career and pick those DevOps competences that will put the fun back into your work.
We plan this meetup again as in-person event and will bring futher information in January.
]]>
In 2022 our learning and development sessions span two whole days to cater for huge demand and an influx of highly talented speakers looking to inspire an entire community.
This is your chance to hear the latest and greatest in Microsoft technology trends, innovations and partner initiatives from professionals in the field with vast knowledge and experience.
Esther Barthel will present, together with Freek Berson, an advanced Bicep masterclass at the Scottish Summit 2022.
]]>