Das Ergebnis, das ich in der Praxis immer wieder sehe, ist eine Art Flaschenhals-Effekt: es gibt zwei oder drei Leute im Unternehmen, die wissen, wie man in Azure Automation ein Runbook manuell auslöst und die Parameter richtig setzt, und alle anderen im IT-Team müssen bei diesen Personen anfragen, wenn sie einen automatisierten Prozess starten wollen, den es eigentlich schon gibt. Das automatisierte Skript ist da, aber der Zugang dazu ist genauso ein Flaschenhals wie die manuelle Arbeit, die es eigentlich ersetzen sollte.

Warum native RBAC in Azure hier nicht wirklich hilft

Man könnte jetzt denken, dass sich das über Azure RBAC lösen lässt, also über eine Rolle, die nur das Recht hat, Runbook-Jobs zu starten, ohne die Runbooks selbst bearbeiten zu können. Das gibt es tatsächlich, die Rolle heißt in etwa Automation Job Operator. Das Problem in der Praxis ist aber, dass diese Rolle immer noch vollen Zugriff auf das Azure Portal voraussetzt, inklusive der ganzen Navigation durch Ressourcengruppen, Abonnements und die für einen Nicht-Cloud-Menschen ziemlich unübersichtliche Oberfläche von Azure Automation selbst. Für einen Help-Desk-Mitarbeiter oder einen Fachbereichsleiter, der einfach nur “Bitte alle inaktiven Benutzerkonten der letzten 90 Tage deaktivieren” ausführen will, ist das eine viel zu hohe Hürde, unabhängig davon, welche RBAC-Rolle im Hintergrund zugewiesen ist.

Dazu kommt noch ein zweiter, oft unterschätzter Punkt: Wer im Azure Portal auf Automation Account Ressourcen zugreifen darf, sieht in der Regel auch andere Ressourcen im selben Abonnement oder in derselben Ressourcengruppe. Man müsste also entweder sehr fein granulare, aufwendig gepflegte RBAC-Zuweisungen bauen, oder man nimmt in Kauf, dass Leute mehr sehen, als sie eigentlich sehen sollten, nur um ein einziges Runbook starten zu können.

Wie ich das bei au2mator angegangen bin

Die Lösung, die sich für mich als sinnvoll herausgestellt hat, war, eine Ebene über Azure Automation zu bauen, die genau eine Sache macht: bestehende Runbooks als einfache, formularbasierte Aktionen zugänglich machen, ohne dass der ausführende Mitarbeiter jemals das Azure Portal selbst sieht. In au2mator läuft das so, dass ein Runbook einmal technisch angebunden und mit klar definierten Eingabeparametern versehen wird, zum Beispiel “Zeitraum in Tagen” oder “Zielgruppe”, und danach als Formular im Self-Service-Portal erscheint.

Ein IT-Teammitglied, das nicht Cloud-Admin ist, öffnet also nicht Azure, sondern ein simples Webformular mit vielleicht drei oder vier Eingabefeldern, klickt auf Ausführen, und im Hintergrund übernimmt ein dediziertes Service-Principal mit exakt den Berechtigungen, die für dieses eine Runbook nötig sind, die eigentliche Ausführung. Der Mitarbeiter selbst bekommt zu keinem Zeitpunkt Zugriff auf das Azure-Abonnement, die Ressourcengruppe oder andere Runbooks, die er nicht sehen soll.

Ein konkretes Beispiel aus der Praxis

Bei einem Kunden ging es konkret darum, monatlich alle Benutzerkonten zu deaktivieren, die seit mehr als 90 Tagen nicht mehr angemeldet waren, ein klassischer Compliance-Task, der vorher manuell von einem einzelnen AD-Administrator per Skript ausgeführt wurde, meistens irgendwann verspätet, weil er auch noch andere Sachen zu tun hatte. Nach der Umstellung konnte die HR-Abteilung, die eigentlich am besten weiß, welche Konten wirklich inaktiv sein sollten, dieses Runbook selbst mit einem Klick pro Monat anstoßen, ohne jemals mit Azure in Berührung zu kommen. Der AD-Administrator musste sich nur noch einmalig um die technische Anbindung kümmern, nicht mehr um die monatliche Wiederholung.

Was ich Unternehmen empfehle

Wenn ich mit Unternehmen über Azure Automation spreche, ist der häufigste Fehler, den ich sehe, dass Runbooks zwar geschrieben werden, aber als reines Cloud-Admin-Werkzeug betrachtet werden, statt als Prozess, den auch Fachabteilungen selbst anstoßen könnten. Der pragmatischste erste Schritt ist, sich die bereits existierenden Runbooks anzuschauen und zu fragen, wer im Unternehmen eigentlich der natürliche Owner dieses Prozesses wäre, wenn Azure kein Thema wäre. Meistens ist die Antwort nicht der Cloud-Admin, sondern jemand aus HR, aus dem Help Desk oder aus einer Fachabteilung, und genau dieser Person sollte man den Zugriff geben, ohne dass sie dafür Azure lernen muss.

Ich schreibe hier regelmäßig über IT-Automatisierung, Azure und alles, was mir beim Bauen von au2mator so unterkommt. Wenn du Fragen zu deiner eigenen Umgebung hast, meld dich einfach.

The post Azure Automation Workflows für IT-Teams zugänglich machen, ohne dass jeder Zugriff aufs Runbook braucht appeared first on TechGuy.

And yet, every few months, someone asks me a version of the same question:

“We have Intune. Can you tell me what our hardware costs per department?”

The answer is no. Not because Intune is doing something wrong, but because that was never its job. This article is about where that line runs, what sits on the other side of it, and what people usually do about it.

What Intune tracks, and tracks well

Let us be fair to the product first. For every device it manages, Intune gives you:

• A current hardware inventory — manufacturer, model, serial number, storage, memory, processor
• Enrolment and ownership state — corporate or personal, when it enrolled, when it last checked in
• Compliance and configuration — which policies apply and whether the device meets them
• Installed applications and the ability to deploy more
• The assigned user

That data is accurate and it is current, which is more than most asset databases can claim. If your question is “what is this laptop and is it healthy”, Intune answers it better than a spreadsheet ever will.

Five things Intune does not do

1. It does not know what anything costs

There is no cost centre on an Intune device. No monthly rate, no chargeback, no way to tell the finance department that the marketing team is running forty laptops. Intune models devices, not money.

This is the gap I get asked about most often, and it is usually solved once a year, in a spreadsheet, by someone reconstructing twelve months of device movements from memory and email.

2. It does not see what it does not manage

Monitors. Docking stations. Printers. Phones that were never enrolled. The spare laptops in the cupboard. Conference room equipment.

None of it appears in Intune, because none of it is a managed device. In most organisations this is a surprisingly large share of the hardware budget — and it is precisely the part nobody can account for.

3. It does not carry manufacturer warranty dates

Intune knows the serial number. It does not know that Dell’s warranty on that serial expires in March. Warranty data lives with the manufacturer, and getting it out means asking them, device by device, or paying someone to do it.

Which means the question “how many devices fall out of warranty next quarter” — a reasonable budget planning question — has no answer inside Intune.

4. It does not let you delegate by scope

You can delegate in Intune through role-based access control, and it works. But modelling “the site manager in Linz may maintain the devices at their location, and only those, and may not touch anything else” is a scoping exercise that gets awkward fast.

What most organisations actually want is simpler than RBAC: let the person closest to the hardware correct what they can see, without turning them into an administrator.

5. End users cannot act on their own device

The Company Portal shows a user their devices. It does not let them say “this laptop is not mine any more”, or “I handed this back in March”, or “someone stole this yesterday” in a way that updates your records and triggers a process.

So those corrections arrive as tickets, or as emails, or not at all. Usually the third one.

None of this is a flaw

I want to be clear, because this is where these articles usually turn into a sales pitch: Intune is not failing at asset management. It is not attempting asset management.

Device management and asset management are different disciplines with different questions. Device management asks “is this machine configured, compliant and patched”. Asset management asks “who owns this, who pays for it, when does it expire, and who is allowed to maintain its record”.

Expecting one to cover the other is like expecting the navigation system in your car to handle the depreciation schedule.

What people actually do

In my experience there are three paths, in descending order of popularity:

The spreadsheet. Export from Intune, paste into Excel, add columns for cost centre and warranty, maintain it by hand. It is accurate for about two weeks. One person owns it, usually between two other jobs, and when they leave it becomes archaeology.

The enterprise platform. ServiceNow, or something in that class. These genuinely solve the problem — and they bring a project, a budget and a consultant with them. For a few thousand devices, the effort frequently outweighs the question being answered.

A layer on top. Keep Intune as the system of record for devices, and add something above it that models ownership, cost and responsibility — importing from Intune rather than replacing it.

What to look for, whichever path you take

If you go looking for that third option, these are the criteria I would apply — and they are worth checking regardless of which vendor you end up with:

• Does it import from Intune, or does it want to replace it? If a tool asks you to deploy its own agent to discover devices you already manage, you are paying twice for the same inventory.
• Can it model your cost structure? Cost centres, locations, companies — whatever your organisation actually uses, not a fixed schema.
• Does it cover assets Intune never sees? If it only shows managed devices, it has not solved the part that hurts.
• Can maintenance be delegated with a real scope? Site, department, team — read-only or full edit, without portal admin rights.
• Can end users see and correct their own devices? This is the only mechanism I have seen that keeps asset data honest over time. The people who use the hardware are the ones who know the truth about it.
• Where does warranty data come from? If the answer is “you type it in”, you will not be typing it in for long.

The honest disclosure

I build au2mator, which does exactly the third thing on that list — it imports devices from Intune and adds ownership, cost allocation, delegated maintenance and self-service on top. So I am not a neutral observer, and you should read the list above with that in mind.

I have tried to write the criteria so they are useful even if you pick something else. If you want to see how we approach it, the details are on the Intune asset import page, and the import scripts themselves will be published on GitHub, so you can read exactly what runs in your tenant before it runs.

But the point of this article stands without any of that: Intune gives you an accurate list of devices. It does not give you an asset management system, and it was never supposed to. Knowing where that line runs saves a lot of time arguing with the wrong tool.

The post Intune Asset Management: What Intune Tracks – And What It Doesn’t appeared first on TechGuy.

In one project I actually counted how many tickets per month were pure password resets and account unlocks. At a mid-sized company with roughly 300 employees, that was over 60 percent of all first-level tickets. The rest was split between software requests, hardware issues, and group memberships. Once you see how much time and how many escalations to the second tier come purely from these simple, repetitive tasks, it becomes obvious why this is worth fixing.

Why standard AD delegation does not go far enough

Microsoft’s native answer to this is delegating permissions in Active Directory, using the Delegation of Control Wizard to let certain groups reset passwords or unlock accounts without granting Domain Admin rights. That works technically, no argument there. But in practice I keep running into two recurring issues.

First, delegation in AD is granular at the OU level, but not really granular at the level of a traceable, logged self-service process. When a help desk agent resets a password through the native AD console, there is a security event log, but not a business-readable record with a ticket reference, a reason, and a history an auditor can actually read. Second, and this is the bigger point in my view, native AD delegation only covers on-premises Active Directory. As soon as a company also has Entra ID accounts that are not covered by hybrid sync, or accounts in both worlds need to be managed through different processes, the unified delegation model falls apart.

How I approached this at au2mator

The first time I worked on a self-service portal for help desk agents, the starting point was exactly this observation: support staff need a limited set of clearly defined actions, not admin rights in general. Reset a password, unlock an account, reset an MFA method, add someone to a specific distribution list, those are maybe ten to fifteen actions that cover ninety percent of daily demand.

In au2mator, this runs through a web portal where exactly these actions are built as self-contained, individual building blocks. A help desk agent signs in with their own normal account, which itself has no elevated AD or Entra rights whatsoever. They search for the affected user, pick the action, enter a ticket number and a short reason, and the action gets executed through a runbook process using a separate, dedicated service account in the background. The agent never has direct access to a privileged account, they only trigger a predefined, controlled action.

The effect is twofold. On one side, the help desk gets immediate self-service access to exactly the tasks that previously had to be escalated, without anyone needing personal admin rights. On the other side, a clean, searchable history is created automatically: who performed which action, for which user, with which reason, and when. That is exactly the kind of evidence an ISO 27001 audit or an internal review asks for, and it is not something a classic admin-rights delegation model provides on its own.

How this changes escalation numbers

At one customer that rolled this model out, the number of tickets escalated to the second tier for exactly these standard tasks dropped by roughly 70 percent within a few weeks. That is not a surprising number once you consider that previously, every account unlock outside the limited AD delegation rights of the first tier got passed on automatically. What I found more interesting was a side effect: response time for employees who genuinely needed fast help, say a locked account on a Monday morning, dropped from an average of forty minutes to under five minutes, because the first tier could resolve the request directly instead of putting it into a queue for the second tier.

What I actually recommend to companies

The most pragmatic starting point I recommend is not building a full self-service portal for every conceivable AD action right away. Instead, I would start with the three to five ticket categories that actually make up the bulk of the volume, usually password resets, account unlocks, and simple group memberships. Delegating just these few actions to the first tier cleanly, in a controlled way, with logging attached, typically delivers the biggest effect for the least effort before you tackle more complex scenarios.

I write regularly about IT automation, Azure, and whatever comes up while building au2mator. If you have questions about your own environment, feel free to reach out.

The post How Help Desk Teams Can Handle Password Resets and Account Unlocks Without Being Domain Admins appeared first on TechGuy.

Ich hab in einem Projekt mal genau nachgezählt, wie viele Tickets im Monat reine Passwort-Resets und Kontoentsperrungen waren. Bei einem mittelgroßen Unternehmen mit ungefähr 300 Mitarbeitern waren das über 60 Prozent aller Tickets am First-Level-Support. Der Rest verteilte sich auf Softwareanfragen, Hardwareprobleme und eben Gruppenmitgliedschaften. Wenn man sich anschaut, wie viel Zeit und wie viele Eskalationen an die zweite Ebene allein durch diese simplen, sich wiederholenden Aufgaben entstehen, wird schnell klar, warum das ein Thema ist, das sich lohnt anzugehen.

Warum Standard-Delegation in Active Directory nicht reicht

Die native Antwort von Microsoft auf dieses Problem heißt Delegation von Berechtigungen in der Active Directory, also über die Delegation of Control Wizard bestimmten Gruppen erlauben, Passwörter zurückzusetzen oder Konten zu entsperren, aber eben nicht Domain-Admin-Rechte zu haben. Das funktioniert technisch, keine Frage. Aber in der Praxis stoße ich hier auf zwei wiederkehrende Probleme.

Erstens ist die Delegation in der AD granular auf OU-Ebene, aber nicht wirklich granular auf Aktions-Ebene im Sinne eines nachvollziehbaren, protokollierten Self-Service-Prozesses. Wenn ein Help-Desk-Mitarbeiter über die native AD-Verwaltungskonsole ein Passwort zurücksetzt, gibt es zwar ein Sicherheitsereignis-Log, aber keinen im Business-Sinn nachvollziehbaren Vorgang mit Ticket-Referenz, Begründung und einer für einen Auditor lesbaren Historie. Zweitens, und das ist aus meiner Sicht der größere Punkt, deckt native AD-Delegation nur On-Premises Active Directory ab. Sobald ein Unternehmen auch Entra ID Konten hat, die nicht über eine Hybrid-Synchronisierung laufen, oder wenn Konten in beiden Welten mit unterschiedlichen Prozessen verwaltet werden müssen, bricht die einheitliche Delegation auseinander.

Wie ich das Problem für au2mator gelöst hab

Als ich das erste Mal an einem Self-Service-Portal für Help Desk Mitarbeiter gearbeitet hab, war der Ausgangspunkt genau diese Beobachtung: Support-Mitarbeiter brauchen eine begrenzte Anzahl klar definierter Aktionen, nicht Admin-Rechte im Allgemeinen. Passwort zurücksetzen, Konto entsperren, MFA-Methode zurücksetzen, jemanden zu einer bestimmten Verteilerliste hinzufügen, das sind vielleicht zehn bis fünfzehn Aktionen, die neunzig Prozent des täglichen Bedarfs abdecken.

In au2mator läuft das über ein Web-Portal, in dem genau diese Aktionen als einzelne, in sich geschlossene Bausteine hinterlegt sind. Ein Help-Desk-Mitarbeiter meldet sich mit seinem eigenen, normalen Konto an, das selbst keinerlei erhöhte AD- oder Entra-Rechte hat. Er sucht den betroffenen Nutzer, wählt die Aktion aus, gibt eine Ticketnummer und kurze Begründung ein, und die Aktion wird über einen Runbook-Prozess mit einem separaten, dedizierten Service-Konto im Hintergrund ausgeführt. Der Mitarbeiter selbst hat also nie direkten Zugriff auf ein privilegiertes Konto, er triggert nur eine vordefinierte, kontrollierte Aktion.

Der Effekt ist doppelt: Auf der einen Seite bekommt der Help Desk sofortigen Self-Service-Zugriff auf genau die Aufgaben, die vorher eskaliert werden mussten, ohne dass irgendjemand persönliche Admin-Rechte braucht. Auf der anderen Seite entsteht automatisch eine saubere, durchsuchbare Historie: wer hat wann welche Aktion für welchen Nutzer mit welcher Begründung ausgeführt. Das ist genau die Art von Nachweis, die bei einem ISO-27001-Audit oder einer internen Revision gefragt wird, und die bei einer klassischen Admin-Rechte-Delegation so nicht ohne Weiteres existiert.

Wie sich das auf Eskalationen auswirkt

Bei einem Kunden, der dieses Modell eingeführt hat, ist die Zahl der an die zweite Ebene eskalierten Tickets für genau diese Standardaufgaben innerhalb weniger Wochen um etwa 70 Prozent gesunken. Das ist keine überraschende Zahl, wenn man bedenkt, dass vorher jede Kontoentsperrung, die außerhalb der begrenzten AD-Delegationsrechte des First-Level lag, automatisch weitergereicht wurde. Interessanter fand ich einen Nebeneffekt: die Reaktionszeit für Mitarbeiter, die tatsächlich schnell Hilfe brauchten, zum Beispiel bei einem gesperrten Konto am Montagmorgen, sank von im Schnitt vierzig Minuten auf unter fünf Minuten, weil der First-Level die Anfrage sofort selbst lösen konnte, statt sie in eine Warteschlange zur zweiten Ebene zu stellen.

Was ich Unternehmen empfehle, die das angehen wollen

Der pragmatischste Einstieg, den ich empfehle, ist nicht, gleich ein komplettes Self-Service-Portal für jede denkbare AD-Aktion zu bauen. Stattdessen würde ich mit den drei bis fünf Ticket-Kategorien anfangen, die tatsächlich das Gros des Volumens ausmachen, meistens sind das Passwort-Resets, Kontoentsperrungen und einfache Gruppenmitgliedschaften. Diese wenigen Aktionen sauber, kontrolliert und mit Protokollierung an den First-Level zu delegieren, bringt in aller Regel den größten Effekt für den geringsten Aufwand, bevor man sich an komplexere Szenarien wagt.

Ich schreibe hier regelmäßig über IT-Automatisierung, Azure und alles, was mir beim Bauen von au2mator so unterkommt. Wenn du Fragen zu deiner eigenen Umgebung hast, meld dich einfach.

The post Wie der Help Desk Passwort-Resets und Account-Freigaben lösen kann, ohne Domain Admin zu sein appeared first on TechGuy.

That is exactly the problem Privileged Identity Management, or PIM, is supposed to solve. Access only when it is needed, time-limited, with a reason attached and ideally an approval step. Microsoft built a genuinely good tool for this with Entra PIM. The catch is that it lives inside the Entra ID P2 license, and that license costs a per-user, per-month amount that simply does not make sense for a lot of mid-sized companies if you only need PIM for a handful of IT people.

Why the licensing question matters so much

I have talked to a number of IT managers who get stuck exactly at this point. They know permanent admin rights are a risk, any auditor will flag that immediately. They also know Microsoft offers the technically cleanest solution with PIM. But if a company has 15 people in IT and only 5 of them actually need privileged roles, almost nobody wants to justify upgrading the entire workforce to P2 just so those 5 people get just-in-time access.

There is a second problem that I think gets overlooked in this discussion: in practice, Entra PIM mostly covers cloud roles, meaning Entra ID roles and Azure resource roles. For classic on-premises Active Directory permissions, say a time-limited membership in a Domain Admin group or a delegated OU admin group, the native tooling does not really reach that far. And that is exactly where a lot of mid-sized companies still live, with a hybrid environment of on-prem AD and Entra ID side by side.

How just-in-time access actually works

The basic idea behind just-in-time admin access is actually simple, even if the implementation has a few pitfalls. A user who needs a privileged action, say membership in an AD security group, submits a request. That request can be auto-approved if certain criteria are met, or it goes to an approver who confirms it quickly. Once approved, the permission is granted, but with an expiration attached. Once that time runs out, the membership is automatically removed again, without anyone needing to remember to undo it manually.

The part that gets missed most often in practice is exactly that last step: automatic removal. I have seen in several audits that companies had a process for granting time-limited rights, but no reliable automated mechanism to actually take them away again. In the end, the “temporary” permissions just stuck around because nobody put a reminder in the calendar or the person responsible for the ticket was on vacation. At that point, the whole security benefit is gone.

How I approached this at au2mator

When I kept seeing this need across multiple customers, it was clear to me that I did not want to build this as a pure Entra ID add-on, but as something that covers both worlds. In au2mator, this runs through a time-limited group membership model that works against both on-prem Active Directory and Entra ID groups, through the same process. An employee requests a time-limited permission through a simple form, picks the duration, say two hours or until end of day, and gives a short reason. Depending on configuration, that goes through directly or needs sign-off from a defined approver.

The key difference from a manual process built on tickets and good intentions is the technical guarantee at the end: a runbook runs in the background, watches the expiration times, and reliably removes the group membership, whether that is on-prem AD through a local agent or Entra ID directly through the Graph API. That happens regardless of whether someone is in the office, on vacation, or simply forgets. That automation is exactly the point where a nice idea turns into an actual security control you can rely on.

What that means for cost

The practical effect for a lot of customers is that they do not need a company-wide license upgrade just to properly secure a handful of administrative accounts. You can roll the principle out specifically for the people and groups it actually applies to, whether the permission lives in the cloud or on-premises. For companies that are primarily in the Microsoft cloud and already have P2 licenses for other reasons, native Entra PIM is often still the right call for pure cloud roles. But for anyone running a hybrid environment, or who does not want a license upgrade for cost reasons, that is exactly the gap I wanted to close.

What I actually recommend to companies

If you are currently thinking about how to reduce permanent admin rights in your organization, I would start by simply counting. How many accounts currently hold permanent privileged roles, whether in AD or Entra ID, and how often is that access actually used. In most cases I have seen, the answer is sobering: far less often than the permanent grant would suggest. Once that number is on the table, the decision to move to just-in-time access usually becomes obvious on its own, the only remaining question is which tool to use, depending on what your environment looks like and what you already have licensed.

I write regularly about IT automation, Azure, and whatever comes up while building au2mator. If you have questions about your own environment, feel free to reach out.

The post Privileged Identity Management Without a Microsoft P2 License: How I Handle Just-in-Time Admin Access in Hybrid Environments appeared first on TechGuy.

Genau das ist das Problem, das Privileged Identity Management, kurz PIM, eigentlich lösen soll. Zugriff nur dann, wenn er gebraucht wird, zeitlich befristet, mit Begründung und im Idealfall mit Genehmigung. Microsoft hat mit Entra PIM ein sehr gutes Werkzeug dafür gebaut. Das Problem ist nur: es steckt in der Entra ID P2-Lizenz, und die kostet pro Nutzer und Monat einen Betrag, der sich für viele mittelständische Unternehmen einfach nicht rechnet, wenn man PIM nur für eine Handvoll IT-Leute braucht.

Warum die Lizenzfrage überhaupt so wichtig ist

Ich hab mit einigen IT-Leitern gesprochen, die genau an diesem Punkt hängen bleiben. Sie wissen, dass dauerhafte Admin-Rechte ein Risiko sind, das checkt jeder Auditor sofort ab. Sie wissen auch, dass Microsoft mit PIM die technisch sauberste Lösung anbietet. Aber wenn ein Unternehmen 15 Mitarbeiter in der IT-Abteilung hat und nur 5 davon tatsächlich privilegierte Rollen brauchen, will sich kaum jemand rechtfertigen, warum plötzlich für die komplette Belegschaft auf P2 upgegradet werden soll, nur damit diese 5 Leute Just-in-Time-Zugriff bekommen.

Dazu kommt ein zweites Problem, das aus meiner Sicht in der Diskussion oft untergeht: Entra PIM deckt in der Praxis primär Cloud-Rollen ab, also Entra ID Rollen und Azure Ressourcen-Rollen. Für klassische On-Premises Active Directory Berechtigungen, zum Beispiel eine zeitlich befristete Mitgliedschaft in einer Domain-Admin-Gruppe oder in einer delegierten OU-Admin-Gruppe, greift das native Tooling nicht wirklich. Genau da leben aber noch sehr viele mittelständische Unternehmen, mit einer hybriden Umgebung aus On-Prem AD und Entra ID nebeneinander.

Wie Just-in-Time-Zugriff technisch funktioniert

Das Grundprinzip hinter Just-in-Time-Admin-Zugriff ist eigentlich simpel, auch wenn die Umsetzung ein paar Fallstricke hat. Ein Nutzer, der eine privilegierte Aktion braucht, zum Beispiel Mitgliedschaft in einer AD-Sicherheitsgruppe, stellt eine Anfrage. Diese Anfrage kann automatisch genehmigt werden, wenn bestimmte Kriterien erfüllt sind, oder sie geht an einen Genehmiger, der kurz bestätigt. Nach der Genehmigung wird die Berechtigung vergeben, aber mit einem Ablaufdatum. Nach Ablauf der Zeit wird die Mitgliedschaft automatisch wieder entfernt, ganz ohne dass jemand manuell daran denken muss, das rückgängig zu machen.

Der Teil, der in der Praxis am häufigsten übersehen wird, ist genau dieser letzte Schritt: die automatische Entfernung. Ich hab in mehreren Audits gesehen, dass Unternehmen zwar einen Prozess für die Vergabe befristeter Rechte hatten, aber keinen zuverlässigen automatisierten Mechanismus, um sie auch wieder zu entziehen. Am Ende blieben die “temporären” Berechtigungen einfach bestehen, weil niemand einen Kalendereintrag gemacht hatte oder der Ticketverantwortliche im Urlaub war. Damit ist der ganze Sicherheitsgewinn dahin.

Wie ich das Thema bei au2mator angegangen bin

Als ich diesen Bedarf bei mehreren Kunden gesehen hab, war für mich klar, dass ich das nicht als reines Add-on für Entra ID bauen will, sondern als etwas, das beide Welten abdeckt. In au2mator läuft das über ein zeitlich befristetes Gruppenmitgliedschafts-Modell, das sowohl gegen On-Prem Active Directory als auch gegen Entra ID Gruppen funktioniert, über denselben Prozess. Ein Mitarbeiter beantragt eine befristete Berechtigung über ein einfaches Formular, wählt die Dauer, zum Beispiel zwei Stunden oder bis Ende des Tages, und gibt eine kurze Begründung an. Je nach Konfiguration geht das direkt durch oder braucht eine Freigabe durch einen definierten Genehmiger.

Der entscheidende Unterschied zu einem manuellen Prozess mit Ticket und gutem Willen ist die technische Garantie am Ende: Ein Runbook läuft im Hintergrund, überwacht die Ablaufzeiten und entfernt die Gruppenmitgliedschaft zuverlässig, egal ob im On-Prem AD über einen lokalen Agent oder in Entra ID direkt über die Graph API. Das passiert unabhängig davon, ob gerade jemand im Büro ist, im Urlaub ist oder es schlicht vergisst. Genau dieser Automatismus ist der Punkt, an dem aus einer netten Idee tatsächlich ein belastbarer Sicherheitsmechanismus wird.

Was das für die Kosten bedeutet

Der praktische Effekt für viele Kunden ist, dass sie kein flächendeckendes Lizenz-Upgrade für die gesamte Belegschaft brauchen, nur um eine Handvoll administrativer Konten sauber abzusichern. Man kann das Prinzip gezielt für genau die Personen und Gruppen einführen, die es wirklich betrifft, egal ob die Berechtigung in der Cloud oder On-Premises liegt. Für Unternehmen, die primär in der Microsoft-Cloud unterwegs sind und ohnehin schon P2-Lizenzen für andere Zwecke haben, ist natives Entra PIM oft weiterhin die richtige Wahl für die reinen Cloud-Rollen. Aber für alle, die eine hybride Umgebung haben oder aus Kostengründen kein Lizenz-Upgrade wollen, ist genau das die Lücke, die ich schließen wollte.

Was ich Unternehmen tatsächlich rate

Wenn du gerade überlegst, wie du dauerhafte Admin-Rechte in deinem Unternehmen reduzierst, würde ich als ersten Schritt einfach mal zählen. Wie viele Konten haben aktuell dauerhaft privilegierte Rollen, egal ob in AD oder Entra ID, und wie oft werden diese Rechte tatsächlich gebraucht. In den meisten Fällen, die ich gesehen hab, ist die Antwort ernüchternd: deutlich seltener, als die dauerhafte Vergabe suggeriert. Sobald diese Zahl auf dem Tisch liegt, wird die Entscheidung für Just-in-Time-Zugriff meistens von selbst klar, die Frage ist dann nur noch, mit welchem Werkzeug man es umsetzt, abhängig davon, wie deine Umgebung aussieht und was du bereits lizenziert hast.

Ich schreibe hier regelmäßig über IT-Automatisierung, Azure und alles, was mir beim Bauen von au2mator so unterkommt. Wenn du Fragen zu deiner eigenen Umgebung hast, meld dich einfach.

The post Privileged Identity Management ohne Microsoft P2-Lizenz: Wie ich Just-in-Time-Adminrechte in hybriden Umgebungen löse appeared first on TechGuy.

The real problem is rarely “managing AD”

Almost nobody is genuinely searching for a tool to manage Active Directory in some abstract sense. The native Microsoft tools, ADUC, PowerShell, the Microsoft Entra admin center, already handle that reasonably well. What actually pushes people toward these third-party tools is almost always one of a handful of very specific problems.

The helpdesk needs to reset passwords without getting handed domain admin rights along the way. Onboarding and offboarding drags on forever because it all depends on one specific person who happens to be on vacation this week. There’s no clean audit trail showing who changed which group and when, which turns into a real problem the moment an ISO audit or a security review shows up. And more and more often, business departments want self-service themselves, like a team lead who wants to add a new hire to the right distribution list without filing a ticket and waiting three days for IT to get to it.

That’s the actual core behind most of these searches. “Active Directory management tool” is, in most cases, really just “delegation without the risk” wearing a different search term. If you ask yourself that question first, picking the right tool gets a lot easier, because you stop sorting by feature count and start sorting by how well a tool solves that one specific problem.

The usual suspects, in detail

ManageEngine ADManager Plus is a solid, very broadly built tool. The feature list is genuinely impressive: reporting, provisioning, compliance templates, it’s all in there somewhere. The price for that breadth is a correspondingly complex setup. If your IT department is big enough to actually invest the time into a full configuration, you get a very capable tool out of it. Licensing historically scaled per domain controller, which can get unnecessarily expensive for smaller environments running several DCs, so it’s worth running the numbers before committing.

Adaxes is technically impressive. The automation engine, with its business rules and custom commands, lets you build workflows of almost arbitrary complexity. The catch is the learning curve. If you’re hoping your junior helpdesk hire will be productive with it in an hour, that’s not going to happen, and that’s simply not who Adaxes is built for. It’s more of a tool for the AD architect in your organization who wants to build genuinely complex workflows and has the time to get deep into it. For quickly delegating standard tasks, it’s honestly overkill.

One Identity Manager plays in a completely different league, the classic enterprise Identity Governance and Administration category, IGA for short. It’s powerful, covers governance and compliance at a corporate scale, but comes with a price tag and an implementation project to match, usually stretching over several months. For a company with 100 or 200 employees, that’s almost always massive overkill, both in budget and in ongoing operational effort.

What all three have in common is their origin story: they were built primarily for on-premises Active Directory, and Azure AD or Entra ID got bolted on as an afterthought somewhere along the way, rather than being treated as an equal part of the architecture from day one. You feel that in daily use the moment you try to model a genuinely hybrid scenario.

Where I saw an actual gap

The point where I started building something myself came from exactly that hybrid reality. Most mid-sized companies I’ve dealt with over the past few years are hybrid today, whether they planned it that way or not. On-prem AD is usually still running, often for historical reasons or because of some legacy application nobody wants to touch, but Entra ID or Azure AD has long since become the actual identity hub for the business, and Azure Automation is quietly taking over more and more of the real automation work behind the scenes. The classic AD tools come from an era when Active Directory meant on-premises, full stop, and you can still feel that baked into their interfaces and their architecture today.

That’s why I built au2mator from day one to treat both worlds as first-class citizens. On-prem AD connects through a local agent, Azure Automation and Entra ID are integrated directly with no detour. The real difference compared to ManageEngine or Adaxes isn’t really about raw feature count, it’s about who the tool is actually built for. I wanted a helpdesk employee with zero PowerShell knowledge to understand how to kick off an approved process within five minutes, and I wanted the IT team, on the other side, to be able to build a new self-service workflow in ten minutes, without needing a multi-day training course to get there.

What the architecture actually looks like

Visually, it comes down to something fairly simple. On one side sits your existing identity backend: on-prem Active Directory and Entra ID side by side, plus Azure Automation handling the actual execution logic. On the other side is the person who needs to get something done, a helpdesk agent or a manager, for example. In between sits au2mator as the mediation layer. It knows the permissions, it knows which processes are approved, and it runs, using its own service account, exactly what’s been authorized. Nothing more, nothing less.

A quick side-by-side

To make this a bit more concrete, here’s how the four tools stack up against each other, with their core strength and who I’d actually recommend each one to, based on real experience.

ManageEngine wins on sheer feature breadth and detailed reporting, but it’s really built for larger IT teams that can afford to invest the time in a full configuration. Adaxes has the most powerful automation engine of the three classic tools, which also means it’s aimed squarely at AD architects with complex, highly customized workflow requirements. One Identity Manager is the right call if enterprise governance and comprehensive compliance requirements are the priority, and you’ve got an implementation project budgeted in. And au2mator is deliberately built around the hybrid reality of on-prem AD and Azure Automation together, with an intentionally simple self-service interface for teams that want to get started fast without a big project behind it.

What I’d actually recommend

If you’re planning an AD governance project with serious enterprise-scale compliance requirements, I’d honestly point you toward One Identity, that’s exactly the category it was built for. If you need deeply customized, complex automation rules and you have the time to build and maintain them yourself, Adaxes is a genuinely good choice. And if you’ve got a larger IT department that’s after the broadest possible all-in-one tool anyway, ManageEngine ADManager Plus is a solid option.

But if you’re like most of the mid-sized companies I talk to, and what you actually want is for your helpdesk to be able to start handling password resets and basic group management themselves, this week, without signing up for a three-month implementation project, that’s the exact gap I originally built au2mator to fill. That’s not a knock on the other three tools. They’re just deliberately aimed at a different problem and a different audience than I am.

I write here regularly about IT automation, Azure, and whatever crosses my path while building au2mator. If you’ve got questions about your own AD setup, feel free to reach out.

The post Active Directory Management Tools in 2026: My Honest Take After 10+ Years of AD Admin Work appeared first on TechGuy.

Das eigentliche Problem ist selten “AD verwalten”

Kaum ein Admin sucht ernsthaft nach einem Tool, um Active Directory grundsätzlich zu verwalten. Die nativen Microsoft Boardmittel wie ADUC, PowerShell oder das Microsoft Entra Admin Center können das schon ziemlich gut. Was die Leute wirklich zu diesen Tools treibt, ist fast immer eines von diesen Problemen hier.

Der Helpdesk soll Passwort-Resets selbst machen können, aber bitte ohne dafür Domain-Admin-Rechte zu bekommen. Onboarding und Offboarding dauert viel zu lange und hängt oft an genau einer Person, die zufällig gerade im Urlaub ist. Es gibt kein sauberes Audit-Log, aus dem hervorgeht, wer wann welche Gruppe geändert hat, was spätestens bei der nächsten ISO-Zertifizierung oder einem Security-Audit zum echten Problem wird. Und immer öfter wollen Fachabteilungen selbst Self-Service haben, zum Beispiel wenn eine Teamleiterin neue Mitarbeiter selbst in die richtige Verteilerliste eintragen möchte, ohne dafür ein Ticket zu schreiben und drei Tage zu warten.

Das ist der eigentliche Kern hinter der Suche. Active Directory Management Tool ist in den meisten Fällen eigentlich Delegation ohne Risiko, nur eben unter einem anderen Suchbegriff verpackt. Wenn du dir diese Frage vorher stellst, wird die Auswahl des richtigen Tools deutlich einfacher, weil du dann nicht nach Funktionsumfang sortierst, sondern danach, wie gut ein Tool genau dieses eine Kernproblem löst.

Die drei üblichen Verdächtigen im Detail

ManageEngine ADManager Plus ist ein solides und sehr breit aufgestelltes Tool. Der Funktionsumfang ist wirklich beeindruckend: Reporting, Provisioning, Compliance-Templates, alles ist irgendwie dabei. Der Preis dafür ist eine entsprechend komplexe Einrichtung. Wenn deine IT-Abteilung groß genug ist, um sich die Zeit für eine vollständige Konfiguration zu nehmen, bekommst du hier ein sehr mächtiges Werkzeug. Das Lizenzmodell war historisch pro Domain Controller aufgebaut, was für kleinere Umgebungen mit vielen DCs unnötig teuer werden kann, das lohnt sich also vorher genau durchzurechnen.

Adaxes ist technisch gesehen richtig beeindruckend. Die Automatisierungs-Engine mit Business Rules und Custom Commands erlaubt praktisch beliebig komplexe Workflows. Das Problem dabei ist die Lernkurve. Wenn du willst, dass dein Helpdesk-Azubi in einer Stunde produktiv damit arbeitet, wird das eng, das ist einfach nicht der Zielanwender von Adaxes. Adaxes ist eher ein Werkzeug für den AD-Architekten im Unternehmen, der komplexe Workflows selbst bauen will und die Zeit dafür hat, sich tief einzuarbeiten. Für die schnelle Delegation von Standardaufgaben ist das eher zu viel des Guten.

One Identity Manager spielt nochmal in einer anderen Liga, nämlich der klassischen Enterprise Identity Governance and Administration Kategorie, kurz IGA. Das Tool ist mächtig, deckt Governance und Compliance auf Konzernniveau ab, hat aber auch ein entsprechendes Preisschild und vor allem ein eigenes Implementierungsprojekt im Gepäck, das meistens mehrere Monate dauert. Für einen Betrieb mit 100 oder 200 Mitarbeitern ist das in aller Regel komplett überdimensioniert, sowohl vom Budget als auch vom Betriebsaufwand her.

Was alle drei gemeinsam haben, ist ihre Herkunft: Sie sind primär für On-Premises Active Directory gebaut worden und haben Azure AD beziehungsweise Entra ID im Lauf der Zeit eher als Zusatzfeature drangeflanscht, statt es von Anfang an als gleichwertigen Teil der Architektur mitzudenken. Das merkt man in der Praxis vor allem an der Bedienung, sobald man versucht, hybride Szenarien abzubilden.

Wo ich eine echte Lücke gesehen habe

Der Punkt, an dem ich angefangen habe, selbst etwas zu bauen, war genau diese hybride Realität. Die meisten mittelständischen Unternehmen, mit denen ich in den letzten Jahren zu tun hatte, sind heute hybrid aufgestellt. On-Prem AD läuft in aller Regel noch, oft aus historischen Gründen oder wegen Legacy-Anwendungen, aber Entra ID beziehungsweise Azure AD ist längst der eigentliche Identitäts-Hub im Unternehmen geworden, und Azure Automation übernimmt im Hintergrund immer mehr der eigentlichen Automatisierungsarbeit. Die klassischen AD-Tools stammen aus einer Zeit, in der Active Directory gleichbedeutend mit On-Premises war, und genau das merkt man ihrer Bedienoberfläche und ihrer Architektur bis heute an.

Deshalb habe ich au2mator von Anfang an so gebaut, dass beide Welten nativ funktionieren. On-Prem AD wird über einen lokalen Agenten angebunden, Azure Automation und Entra ID sind direkt und ohne Umweg integriert. Der eigentliche Unterschied zu ManageEngine oder Adaxes liegt dabei weniger im schieren Funktionsumfang, sondern in der Zielgruppe. Ich wollte, dass ein Helpdesk-Mitarbeiter ohne jede PowerShell-Kenntnis innerhalb von fünf Minuten versteht, wie er einen freigegebenen Prozess startet, und dass die IT-Abteilung im Gegenzug innerhalb von zehn Minuten einen neuen Self-Service-Workflow bauen kann, ohne dafür eine mehrtägige Schulung zu benötigen.

So sieht die Architektur in der Praxis aus

Grafisch lässt sich das ganz gut zusammenfassen. Auf der einen Seite steht dein bestehendes Identitäts-Backend, also On-Prem Active Directory und Entra ID nebeneinander, plus Azure Automation für die eigentliche Ausführungslogik. Auf der anderen Seite steht der Mensch, der eine Aufgabe erledigen will, zum Beispiel ein Helpdesk-Mitarbeiter oder eine Führungskraft. Dazwischen sitzt au2mator als Vermittlungsschicht: Es kennt die Berechtigungen, kennt die freigegebenen Prozesse, und führt im Hintergrund mit einem eigenen Service Account genau das aus, was freigegeben wurde, nicht mehr und nicht weniger.

Kurzer Überblick zur Einordnung

Um das Ganze etwas greifbarer zu machen, hier die vier Tools nochmal kompakt nebeneinander, mit ihrer jeweiligen Kernstärke und für wen sie sich meiner Erfahrung nach wirklich eignen.

ManageEngine punktet mit einem riesigen Funktionsumfang und ausführlichem Reporting, eignet sich aber vor allem für größere IT-Teams, die auch die Zeit für eine vollständige Konfiguration investieren können. Adaxes bietet die mächtigste Automatisierungs-Engine der drei klassischen Tools, richtet sich damit aber klar an AD-Architekten mit komplexen, individuellen Workflow-Anforderungen. One Identity Manager ist die richtige Wahl, wenn Enterprise-Governance und umfassende Compliance-Anforderungen im Vordergrund stehen und ein eigenes Implementierungsprojekt eingeplant ist. Und au2mator zielt bewusst auf die hybride Realität von on-premises AD und Azure Automation gemeinsam, mit einer bewusst einfach gehaltenen Self-Service-Oberfläche für Teams, die schnell und ohne großes Projekt starten wollen.

Was ich tatsächlich empfehlen würde

Wenn du gerade ein AD-Governance-Projekt mit umfassenden Compliance-Anforderungen im Enterprise-Maßstab planst, würde ich dir ehrlich zu One Identity raten, das ist genau die Kategorie, für die das Tool gebaut wurde. Wenn du komplexe, tief individualisierte Automatisierungsregeln brauchst und auch die Zeit hast, sie selbst zu bauen und zu pflegen, ist Adaxes eine sehr gute Wahl. Und wenn du eine größere IT-Abteilung hast, die ohnehin ein möglichst breites Vollsortiment-Tool sucht, ist ManageEngine ADManager Plus eine solide Option.

Wenn du aber, wie die meisten mittelständischen Unternehmen, mit denen ich rede, eigentlich einfach nur willst, dass dein Helpdesk noch in dieser Woche anfangen kann, Passwort-Resets und einfache Gruppenverwaltung sicher selbst zu übernehmen, ohne dass du dafür ein drei Monate langes Implementierungsprojekt einplanen musst, dann ist genau das die Lücke, für die ich au2mator ursprünglich gebaut habe. Das ist kein Vorwurf an die anderen drei Tools, sie zielen einfach ganz bewusst auf ein anderes Problem und eine andere Zielgruppe als ich.

Ich schreibe hier regelmäßig über IT-Automatisierung, Azure und alles, was mir beim Aufbau von au2mator so über den Weg läuft. Wenn du Fragen zu deinem konkreten AD-Setup hast, meld dich einfach.

The post Active Directory Management Tools 2026: Was ich nach über 10 Jahren AD-Administration wirklich empfehlen würde appeared first on TechGuy.

What Does IT Workflow Automation Mean?

IT workflow automation means recurring IT processes are standardized, automated, and, crucially for the SMB market, made accessible to non-technical teams as well. The goal is not just writing scripts that run automatically. It is ensuring that the right people can initiate the right processes at the right time, securely and with full control.

Typical Workflows in an SMB That Can Be Automated

• User onboarding: New employee triggers automatic creation of AD account, email, groups, and license
• User offboarding: Departing employee triggers account deactivation, group removal, and mailbox archiving
• Password management: Self-service reset without an IT ticket
• VM management: Start or stop VMs via web portal instead of Azure access
• Reporting: Automated reports on licenses, groups, and access rights
• Compliance checks: Regular review of AD groups and permissions

au2mator as a Workflow Platform: How Does It Work?

In au2mator, workflows are defined as “services.” Each service is a configured process that starts a PowerShell script, an Azure Automation Runbook, or a System Center Orchestrator Runbook. IT admins build the service once. From that point, authorized users can start it with a click. Execution is fully automated and logged.

Comparison: au2mator vs. Ansible vs. RunDeck

Criterion	au2mator	Ansible	RunDeck
Target audience	Helpdesk & end users	DevOps / sysadmins	Ops teams
Microsoft stack	Native (AD, Azure, SCO)	⚠️ Via modules	⚠️ Via plugins
No-code for end users	Yes	❌ YAML knowledge required	⚠️ Limited
DACH SMB	Specialized	❌ Enterprise-focused	❌ Enterprise-focused
Managed service	Available	❌ Self-hosted	❌ Self-hosted
Audit trail	Complete	⚠️ Logs	Available

Integration with Existing Tools

au2mator complements existing Microsoft infrastructure instead of replacing it. Active Directory remains the source of truth, Azure Automation handles cloud workloads, and System Center Orchestrator manages On-Premises automation. au2mator is the frontend that ties everything together and makes it usable for non-technical teams.

Getting Started: What Do I Need to Start with au2mator?

For an On-Premises installation: Windows Server, IIS, and SQL Server, with a typical implementation time of one to two days with support from the au2mator team. Alternatively, the managed service option has au2mator hosting and operating the platform while the company only configures the desired processes. This is ideal for teams that want to start quickly without tying up internal IT capacity.

Workflow automation that actually works in SMBs. No DevOps team required. Request a demo →

The post IT Workflow Automation for SMBs: Simple, Secure, No Coding Required appeared first on TechGuy.

Was bedeutet IT Workflow-Automatisierung?

IT Workflow-Automatisierung bedeutet: Wiederkehrende IT-Prozesse werden standardisiert, automatisiert und — entscheidend für den Mittelstand — auch für nicht-technische Teams zugänglich gemacht. Es geht nicht nur darum Skripte zu schreiben die automatisch laufen, sondern darum dass die richtigen Personen zur richtigen Zeit die richtigen Prozesse anstoßen können — sicher und kontrolliert.

Typische Workflows im Mittelstand die sich automatisieren lassen

• User Onboarding: Neuer Mitarbeiter → AD-Account, E-Mail, Gruppen, Lizenz automatisch anlegen
• User Offboarding: Mitarbeiter verlässt Unternehmen → Account deaktivieren, Gruppen entfernen, Mailbox sichern
• Passwort Management: Self-Service Reset ohne IT-Ticket
• VM Management: VMs starten/stoppen über Web-Portal statt Azure-Zugriff
• Reporting: Automatische Berichte zu Lizenzen, Gruppen, Zugriffsrechten
• Compliance Checks: Regelmäßige Überprüfung von AD-Gruppen und Berechtigungen

au2mator als Workflow-Plattform: Wie funktioniert’s?

In au2mator werden Workflows als “Services” definiert. Jeder Service ist ein konfigurierter Prozess der ein PowerShell-Skript, ein Azure Automation Runbook oder einen System Center Orchestrator Runbook startet. IT-Admins bauen den Service einmalig — danach können autorisierte Benutzer ihn per Klick starten. Die Ausführung ist vollständig automatisiert und protokolliert.

Vergleich: au2mator vs. Ansible vs. RunDeck

Kriterium	au2mator	Ansible	RunDeck
Zielgruppe	Helpdesk & Endbenutzer	DevOps / Sysadmins	Ops-Teams
Microsoft-Stack	Native (AD, Azure, SCO)	Via Module	Via Plugins
No-Code für Endbenutzer	Ja	YAML-Kenntnisse nötig	Eingeschränkt
DACH Mittelstand	Spezialisiert	Enterprise-fokussiert	Enterprise-fokussiert
Managed Service	Verfügbar	Self-hosted	Self-hosted
Audit-Trail	Vollständig	Logs	Vorhanden

Integration mit bestehenden Tools

au2mator ergänzt bestehende Microsoft-Infrastruktur statt sie zu ersetzen: Active Directory bleibt die Quelle der Wahrheit, Azure Automation übernimmt die Cloud-Workloads, System Center Orchestrator die On-Premises-Automatisierung. au2mator ist das Frontend das alles zusammenbringt und für nicht-technische Teams nutzbar macht.

Einstieg: Was brauche ich um mit au2mator zu starten?

Für eine On-Premises Installation: Windows Server, IIS, SQL Server — typische Implementierungszeit 1-2 Tage mit Unterstützung des au2mator-Teams. Alternativ: Managed Service — au2mator hostet und betreibt die Plattform, das Unternehmen konfiguriert nur die gewünschten Prozesse. Ideal für Teams die schnell starten wollen ohne interne IT-Kapazität zu binden.

Workflow-Automatisierung die im Mittelstand wirklich funktioniert — kein DevOps-Team nötig. Jetzt Demo anfordern →

The post IT Workflow-Automatisierung im Mittelstand: Einfach, sicher, ohne Code-Kenntnisse appeared first on TechGuy.