Selbstgehostete Windows-Agents

Azure DevOps Services

Zum Erstellen und Bereitstellen von Windows-, Azure- und anderen Visual Studio-Lösungen benötigen Sie mindestens einen Windows-Agent. Windows-Agents können auch Java- und Android-Apps erstellen.

Dieser Artikel enthält Anleitungen für die Verwendung der 3.x-Agent-Software mit Azure DevOps Services und aktuellen Versionen von Azure DevOps Server. Eine Liste der Azure DevOps Server-Versionen, die den 3.x-Agent unterstützen, finden Sie unter Wird der 3.x-Agent von Azure DevOps Server unterstützt?.

Hinweis

In diesem Artikel wird beschrieben, wie Sie einen selbstgehosteten Agent konfigurieren. Wenn Sie Azure DevOps Services verwenden und ein von Microsoft gehosteter Agent Ihre Anforderungen erfüllt, können Sie die Einrichtung eines selbstgehosteten Windows-Agents überspringen.

Weitere Informationen zu Agents

Wenn Sie bereits wissen, was ein Agent ist und wie er funktioniert, können Sie direkt mit den folgenden Abschnitten fortfahren. Wenn Sie jedoch mehr Hintergrundinformationen zu ihren Aufgaben und ihrer Funktionsweise benötigen, lesen Sie Azure Pipelines-Agents.

Überprüfen der Voraussetzungen

Stellen Sie sicher, dass Ihr Computer die folgenden Voraussetzungen erfüllt:

• Betriebssystemversion
  • Clientbetriebssystem
    • Windows 7 SP1 ESU
    • Windows 8.1
    • Windows 10
    • Windows 11
  • Serverbetriebssystem
    • Windows Server 2012 oder höher
• Die Agent-Software installiert eine eigene Version von .NET, wodurch keine vorherige .NET-Installation erforderlich ist.
• PowerShell 3.0 oder höher
• Subversion: Wenn Sie für die Erstellung ein Subversion-Repository verwenden, müssen Sie den Subversion-Client auf dem Computer installieren.
• Empfohlen: Visual Studio-Buildtools (2015 oder höher)

Sie sollten das Agentsetup beim ersten Mal manuell ausführen. Nachdem Sie ein Gefühl dafür bekommen haben, wie Agents funktionieren, oder wenn Sie die Einrichtung vieler Agents automatisieren möchten, können Sie die unbeaufsichtigte Konfiguration verwenden.

Hardwarespezifikationen

Die Hardwarespezifikationen für Ihre Agents variieren je nach Ihren Anforderungen, Ihrer Teamgröße und ähnlichen Faktoren. Daher ist es nicht möglich, eine allgemeingültige Empfehlung zu geben. Als Referenz erstellt das Azure DevOps-Team den Code für gehostete Agents mithilfe von Pipelines, die gehostete Agents verwenden. Andererseits wird der Großteil des Azure DevOps-Codes von Computern der Serverklasse mit 24 Kernen erstellt, auf denen vier selbstgehostete Agents ausgeführt werden.

Vorbereiten von Berechtigungen

Informationssicherheit für selbstgehostete Agents

Der Benutzer, der den Agent konfiguriert, benötigt Pooladministratorberechtigungen, der Benutzer, der den Agent ausführt, jedoch nicht.

Die Ordner, die vom Agent gesteuert werden, sollten auf so wenige Benutzer wie möglich beschränkt werden, da sie Geheimnisse enthalten, die entschlüsselt oder exfiltriert werden können.

Der Azure Pipelines-Agent ist ein Softwareprodukt, das zum Ausführen von Code entwickelt wurde, der aus externen Quellen heruntergeladen wird. Es kann von Natur aus ein Ziel für RCE-Angriffe (Remote Code Execution, Remotecodeausführung) sein.

Daher ist es wichtig, das Bedrohungsmodell zu berücksichtigen, das jede einzelne Verwendung von Pipelines-Agents zum Ausführen von Aufgaben umgibt, und zu entscheiden, welche Mindestberechtigungen dem Benutzer, der den Agent ausführt, dem Computer, auf dem der Agent ausgeführt wird, den Benutzern, die Schreibzugriff auf die Pipelinedefinition haben, den Git-Repositorys, in denen die YAML-Datei gespeichert ist, oder der Gruppe von Benutzern, die den Zugriff auf den Pool für neue Pipelines steuern, erteilt werden können.

Es empfiehlt sich, die Identität, mit der der Agent ausgeführt wird, von der Identität mit Berechtigungen zum Verbinden des Agents mit dem Pool zu unterscheiden. Der Benutzer, der die Anmeldeinformationen (und andere Agent-bezogene Dateien) generiert, unterscheidet sich von dem Benutzer, der sie lesen muss. Daher ist es sicherer, den Zugriff auf den Agent-Computer selbst und die Agent-Ordner, die vertrauliche Dateien wie Protokolle und Artefakte enthalten, sorgfältig zu prüfen.

Es ist sinnvoll, nur DevOps-Administratoren und der Benutzeridentität, die den Agent-Prozess ausführt, Zugriff auf den Agent-Ordner zu gewähren. Administratoren müssen möglicherweise das Dateisystem untersuchen, um Buildfehler zu verstehen, oder Protokolldateien abrufen, um Azure DevOps-Fehler melden zu können.

Entscheiden, welchen Benutzer Sie verwenden möchten

In einem einmaligen Schritt müssen Sie den Agent registrieren. Jemand mit Berechtigung zum Verwalten der Agent-Warteschlange muss diese Schritte ausführen. Der Agent verwendet die Anmeldeinformationen dieser Person nicht im täglichen Betrieb, sie sind aber erforderlich, um die Registrierung abzuschließen. Erfahren Sie mehr über die Kommunikation von Agents.

Vergewissern Sie sich, dass der Benutzer über die Berechtigung verfügt

Vergewissern Sie sich, dass das Benutzerkonto, das Sie verwenden möchten, über die Berechtigung zum Registrieren des Agents verfügt.

Ist der Benutzer ein Azure DevOps-Organisationsbesitzer- oder TFS- oder Azure DevOps Server-Administrator? Dann müssen Sie nichts weiter tun: Sie verfügen über die nötige Berechtigung.

Andernfalls:

1. Öffnen Sie einen Browser, und navigieren Sie zur Registerkarte Agent-Pools für Ihre Azure Pipelines-Organisation oder Azure DevOps Server- oder TFS-Server:

   1. Melden Sie sich bei Ihrem organization (https://dev.azure.com/{yourorganization}) an.

   2. Wählen Sie Azure DevOps, Organisationseinstellungen aus.

      

   3. Wählen Sie Agentpools aus.

      

2. Wählen Sie rechts auf der Seite den Pool aus, und klicken Sie dann auf Sicherheit.

3. Sollte das Benutzerkonto, das Sie verwenden möchten, nicht angezeigt werden, bitten Sie einen Administrator, es hinzuzufügen. Der Administrator kann ein Agent-Pooladministrator, Azure DevOps-Organisationsbesitzer oder TFS- oder Azure DevOps Server-Administrator sein.

   Wenn es sich um einen Bereitstellungsgruppen-Agent handelt, kann der Administrator ein Bereitstellungsgruppenadministrator, Azure DevOps-Organisationsbesitzer oder TFS- oder Azure DevOps Server-Administrator sein.

   Sie können der Administratorrolle der Bereitstellungsgruppe in Azure Pipelines auf der Seite Bereitstellungsgruppen auf der Registerkarte Sicherheit einen Benutzer hinzufügen.

Hinweis

Wenn eine Meldung wie „Die Identität konnte leider nicht hinzugefügt werden. Versuchen Sie es mit einer anderen Identität.“ angezeigt wird, haben Sie wahrscheinlich die oben genannten Schritte für einen Organisationsbesitzer- oder TFS- oder Azure DevOps Server-Administrator ausgeführt. Sie müssen nichts weiter tun – Sie verfügen bereits über die Berechtigung zum Verwalten des Agentpools.

Herunterladen und Konfigurieren des Agents

Azure Pipelines

1. Melden Sie sich beim Computer mit dem Konto an, für das Sie Berechtigungen wie oben erläutert vorbereitet haben.

2. Melden Sie sich in Ihrem Webbrowser bei Azure Pipelines an, und navigieren Sie zur Registerkarte Agent-Pools:

   1. Melden Sie sich bei Ihrem organization (https://dev.azure.com/{yourorganization}) an.

   2. Wählen Sie Azure DevOps, Organisationseinstellungen aus.

      

   3. Wählen Sie Agentpools aus.

      

3. Wählen Sie den Pool Standard, die Registerkarte Agents und anschließend Neuer Agent aus.

4. Wählen Sie im Dialogfeld Agent abrufen die Option Windows aus.

5. Wählen Sie im linken Bereich die Prozessorarchitektur der installierten Windows-Betriebssystemversion auf Ihrem Computer aus. Die x64-Agent-Version ist für 64-Bit-Windows vorgesehen, während die x86-Version für 32-Bit-Windows vorgesehen ist. Falls Sie nicht sicher sind, welche Version von Windows installiert ist, erfahren Sie hier, wie Sie die Version ermitteln.

6. Klicken Sie im rechten Bereich auf die Schaltfläche Herunterladen.

7. Befolgen Sie die Anweisungen auf der Seite, um den Agent herunterzuladen.

8. Entpacken Sie den Agent in ein Verzeichnis Ihrer Wahl. Stellen Sie sicher, dass der Pfad des Verzeichnisses keine Leerzeichen enthält, da Tools und Skripts Leerzeichen nicht immer ordnungsgemäß escapen. Ein empfohlener Ordner ist C:\agents. Das Extrahieren im Downloadordner oder in anderen Benutzerordnern kann zu Berechtigungsproblemen führen.

Wichtig

Es wird dringend empfohlen, den Agent über ein PowerShell-Fenster mit erhöhten Rechten zu konfigurieren. Wenn Sie ihn als Dienst konfigurieren möchten, ist dies erforderlich.

Verwenden Sie nicht Windows PowerShell ISE, um den Agent zu konfigurieren.

Wichtig

Aus Sicherheitsgründen wird dringend empfohlen, sicherzustellen, dass der Agents-Ordner (C:\agents) nur von Administrator*innen bearbeitet werden kann.

Hinweis

Vermeiden Sie die Verwendung mintty-basierter Shells wie Git Bash für die Agent-Konfiguration. Mintty ist nicht vollständig kompatibel mit der nativen Input/Output-Windows-API (hier finden Sie einige Informationen dazu) und wir können nicht garantieren, dass das Setupskript in diesem Fall ordnungsgemäß funktioniert.

Installieren des Agents

1. Starten Sie ein Fenster mit erhöhten Rechten (PowerShell), und legen Sie den Speicherort fest, an dem Sie den Agent entpackt haben.

   cd C:\agents 
   
   

2. Führen Sie config.cmd aus. Daraufhin werden Ihnen einige Fragen zum Konfigurieren des Agents gestellt.

   .\config.cmd
   
   

Server-URL

Wenn Sie im Rahmen der Einrichtung aufgefordert werden, Ihre Server-URL anzugeben, geben Sie für Azure DevOps Services Folgendes an: https://dev.azure.com/{your-organization}.

Agent-Einrichtungsauthentifizierungstyp

Wenn Sie einen Agent registrieren, wählen Sie einen der folgenden Authentifizierungstypen aus, und das Installationsprogramm wird Sie dazu auffordern, die spezifischen zusätzlichen Informationen einzugeben, die für jeden Authentifizierungstyp erforderlich sind. Weitere Informationen finden Sie unter Authentifizierungsoptionen für selbstgehostete Agents.

• Persönliches Zugriffstoken
• Gerätecodeflow
• Dienstprinzipal

Die zum Registrieren des Agents verwendete Authentifizierungsmethode wird lediglich während der Agent-Registrierung verwendet. Weitere Informationen dazu, wie Agents nach der Registrierung mit Azure Pipelines kommunizieren, finden Sie unter Kommunikation mit Azure Pipelines oder TFS.

Auswählen des interaktiven Modus oder des Dienstmodus

Informationen dazu, ob der Agent im interaktiven Modus oder als Dienst ausgeführt werden muss, finden Sie im Artikel „Azure Pipelines-Agents“ unter Interaktiv vs. Dienst.

Wenn Sie sich für die Ausführung als Dienst entscheiden (was empfohlen wird), sollte der für die Ausführung verwendete Benutzername maximal 20 Zeichen umfassen.

Ausführen des Agents

Interaktive Ausführung

Wenn Sie den Agent so konfiguriert haben, dass er interaktiv ausgeführt wird, führen Sie den folgenden Befehl aus, um den Agent zu starten.

.\run.cmd

Drücken Sie zum Neustarten des Agents die Tastenkombination STRG+C, um ihn zu beenden, und führen Sie dann run.cmd aus, um ihn neu zu starten.

Hinweis

Wenn Sie den Agent von PowerShell Core ausführen, um Windows PowerShell-Aufgaben auszuführen, schlägt Ihre Pipeline möglicherweise mit einem Fehler wie Error in TypeData "System.Security.AccessControl.ObjectSecurity": The member is already present fehl. Dies liegt daran, dass Windows PowerShell die PSModulePath Umgebungsvariable erbt, die PowerShell Core-Modulspeicherorte enthält, von seinem übergeordneten Prozess.

Als Problemumgehung können Sie den Knopf AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL true des Agents in der Pipeline festlegen. Dadurch kann der Agent vor dem Ausführen von Aufgaben zurücksetzen PSModulePath .

variables:
 AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL: "true"

Wenn dieses Problem durch diese Problemumgehung nicht behoben wird, oder wenn Sie benutzerdefinierte Modulspeicherorte verwenden müssen, können Sie die $Env:PSModulePath Variable im PowerShell Core-Fenster nach Bedarf festlegen, bevor Sie den Agent ausführen.

Einmalige Ausführung

Sie können auch festlegen, dass der Agent nur einen Auftrag akzeptiert. Anschließend können Sie den Befehl beenden. Verwenden Sie zum Ausführen dieser Konfiguration den folgenden Befehl.

.\run.cmd --once

Agents in diesem Modus akzeptieren nur einen einzelnen Auftrag und werden dann ordnungsgemäß heruntergefahren. (Dies ist nützlich für die Ausführung in Docker unter einem Dienst wie Azure Container Instances.)

Ausführung als Dienst

Wenn Sie den Agent für die Ausführung als Dienst konfiguriert haben, wird er automatisch gestartet. Sie können den Ausführungsstatus des Agents über das Dienste-Snap-In anzeigen und steuern. Führen Sie services.msc aus, und suchen Sie nach einem der folgenden Einträge:

• „Azure Pipelines-Agent (Name Ihres Agents)“
• „VSTS-Agent (Name Ihres Agents)“
• „vstsagent.(Name der Organisation).(Name Ihres Agents)“

Hinweis

Um mehr Flexibilität bei der Zugriffskontrolle eines Agenten, der als Dienst läuft, zu ermöglichen, ist es möglich, den SID-Typ des Agentendienstes als [SERVICE_SID_TYPE_UNRESTRICTED] über ein Flag oder eine Eingabeaufforderung während des interaktiven Konfigurationsablaufs festzulegen. Standardmäßig ist der Agentendienst mit SERVICE_SID_TYPE_NONE konfiguriert.

Weitere Einzelheiten über SID Typen finden Sie in dieser Dokumentation.

Klicken Sie zum Neustarten des Agents mit der rechten Maustaste auf den Eintrag, und wählen Sie Neu starten aus.

Hinweis

Verwenden Sie nicht das Dienste-Snap-In, wenn Sie das Anmeldekonto des Agents ändern müssen. Lesen Sie stattdessen die folgenden Informationen, um den Agent neu zu konfigurieren.

Um Ihren Agent zu verwenden, führen Sie einen Auftrag mithilfe des Agent-Pools aus. Wenn Sie keinen anderen Pool ausgewählt haben, befindet sich Ihr Agent im Pool Standard.

Ersetzen eines Agents

Um einen Agent zu ersetzen, führen Sie die Schritte unter Herunterladen und Konfigurieren des Agents erneut aus.

Wenn Sie einen Agent konfigurieren und dabei den Namen eines bereits vorhandenen Agents verwenden, werden Sie gefragt, ob Sie den vorhandenen Agent ersetzen möchten. Wenn Sie mit Y antworten, stellen Sie sicher, dass Sie den Agent entfernen (siehe unten), den Sie ersetzen. Andernfalls wird einer der Agents nach einigen Minuten des Konflikts heruntergefahren.

Entfernen und erneutes Konfigurieren eines Agents

So entfernen Sie den Agent

.\config remove

Nachdem Sie den Agent entfernt haben, können Sie ihn erneut konfigurieren.

Unbeaufsichtigte Konfiguration

Der Agent kann ohne menschliche Interaktion über ein Skript eingerichtet werden. Sie müssen --unattended und die Antworten auf alle Fragen übergeben.

Um einen Agent zu konfigurieren, muss er die URL zu Ihrer Organisation oder Sammlung sowie die Anmeldeinformationen einer Person kennen, die zum Einrichten von Agents autorisiert ist. Alle anderen Antworten sind optional. Befehlszeilenparameter können stattdessen mithilfe einer Umgebungsvariablen angegeben werden: Geben Sie den Namen in Großbuchstaben ein, und stellen Sie VSTS_AGENT_INPUT_ voran. Geben Sie also beispielweise VSTS_AGENT_INPUT_PASSWORD anstelle von --password an.

Erforderliche Optionen

• --unattended: Bei der Einrichtung des Agents werden keine Informationen angefordert, und alle Einstellungen müssen über die Befehlszeile bereitgestellt werden.
• --url <url>: URL des Servers. Beispiel: https://dev.azure.com/myorganization oder http://my-azure-devops-server:8080/tfs.
• --auth <type>: Authentifizierungstyp. Gültige Werte sind:
  • pat (Persönliches Zugriffstoken)
  • SP (Dienstprinzipal) (Erfordert Agent Version 3.227.1 oder höher)
  • negotiate (Kerberos oder NTLM)
  • alt (Standardauthentifizierung)
  • integrated (Windows-Standardanmeldeinformationen)

Authentifizierungsoptionen

• Wenn Sie --auth pat ausgewählt haben:
  • --token <token>: gibt Ihr persönliches Zugriffstoken an
  • Sie können auch ein OAuth 2.0-Token als --token Parameter übergeben.
• Wenn Sie --auth negotiate oder --auth alt ausgewählt haben:
  • --userName <userName>: gibt einen Windows-Benutzernamen im Format domain\userName oder userName@domain.com an
  • --password <password>: gibt ein Kennwort an
• Wenn Sie --auth SP ausgewählt haben:
  • --clientID <clientID> ‑ gibt die Client-ID des Dienstprinzipals mit Zugriff auf die Registrierung von Agents an.
  • --tenantId <tenantID> - Gibt die Mandanten-ID an, in der der Dienstprinzipal registriert ist
  • --clientSecret <clientSecret> - gibt den geheimen Clientschlüssel des Dienstprinzipals an
  • Weitere Informationen finden Sie unter Einen Agenten über einen Dienstprinzipal registrieren.

Pool- und Agent-Namen

• --pool <pool>: Name des Pools, dem der Agent beitreten soll
• --agent <agent>: Agent-Name
• --replace: Option zum Ersetzen des Agents in einem Pool. Wenn ein anderer Agent mit dem gleichen Namen lauscht, tritt ein Konflikt auf

Einrichtung des Agents

• --work <workDirectory>: Arbeitsverzeichnis, in dem Auftragsdaten gespeichert werden. Der Standardwert _work befindet sich im Stammverzeichnis des Agent-Verzeichnisses. Das Arbeitsverzeichnis gehört einem bestimmten Agent und darf nicht von mehreren Agents gemeinsam genutzt werden.
• --acceptTeeEula: Option zum Akzeptieren des Endbenutzer-Lizenzvertrags für Team Explorer Everywhere (nur macOS und Linux)
• --disableloguploads: legt fest, dass die Ausgabe des Konsolenprotokolls nicht an den Server gestreamt oder gesendet werden soll. Stattdessen können Sie sie nach Abschluss des Auftrags aus dem Dateisystem des Agent-Hosts abrufen.

Nur Windows-Start

• --runAsService: dient zum Konfigurieren des Agents für die Ausführung als Windows-Dienst (erfordert Administratorberechtigung)
• --runAsAutoLogon: dient zum Konfigurieren der automatischen Anmeldung und zum Ausführen des Agents beim Start (erfordert Administratorberechtigung)
• --windowsLogonAccount <account>: wird mit --runAsService oder --runAsAutoLogon verwendet, um den Windows-Benutzernamen im Format domain\userName oder userName@domain.com anzugeben
• --windowsLogonPassword <password>: wird mit --runAsService oder --runAsAutoLogon verwendet, um das Windows-Anmeldekennwort anzugeben (nicht erforderlich für gruppenverwaltete Dienstkonten und integrierte Windows-Konten wie NT AUTHORITY\NETWORK SERVICE)
• --enableservicesidtypeunrestricted – wird zusammen mit --runAsService verwendet, um den Agenten mit dem Dienst-SID-Typ SERVICE_SID_TYPE_UNRESTRICTED zu konfigurieren (Administratorberechtigung erforderlich)
• --overwriteAutoLogon: wird mit --runAsAutoLogon verwendet, um die vorhandene automatische Anmeldung auf dem Computer zu überschreiben
• --noRestart: wird mit --runAsAutoLogon verwendet, um festzulegen, dass der Host nach Abschluss der Agent-Konfiguration nicht neu gestartet werden soll

Behandeln von Problemen beim Konfigurieren des Agents mit der Option runAsAutoLogon

Wenn Sie den Agent mit der Option runAsAutoLogon konfigurieren, wird der Agent nach jedem Neustart des Computers ausgeführt. Führen Sie die nächsten Schritte aus, wenn der Agent nach dem Neustart des Computers nicht ausgeführt wird.

Wenn der Agent bereits auf dem Computer konfiguriert war

Bevor Sie den Agent neu konfigurieren, müssen Sie die alte Agent-Konfiguration entfernen. Führen Sie daher den folgenden Befehl im Agent-Ordner aus:

.\config.cmd remove --auth 'PAT' --token '<token>'

Überprüfen Sie nach Ausführung des Befehls, ob der Agent aus Ihrem Agent-Pool entfernt wurde:

<Azure DevOps organization> / <Project> / Settings / Agent pools / <Agent Pool> / Agents

Entfernen Sie den Agent manuell aus Ihrem Agent-Pool, wenn er nicht durch Ausführen des Befehls entfernt wurde.

Versuchen Sie anschließend, den Agent neu zu konfigurieren, indem Sie den folgenden Befehl im Agent-Ordner ausführen:

.\config.cmd --unattended --agent '<agent-name>' --pool '<agent-pool-name>' --url '<azure-dev-ops-organization-url>' --auth 'PAT' --token '<token>' --runAsAutoLogon --windowsLogonAccount '<domain\user-name>' --windowsLogonPassword '<windows-password>'

Geben Sie den Agent-Namen (einen beliebigen eindeutigen Namen) an und überprüfen Sie, ob dieser Agent nach der Neukonfiguration in Ihrem Agent-Pool angezeigt wird.

Es empfiehlt sich, ein Agent-Archiv (das hier heruntergeladen werden kann) zu entpacken und diesen Befehl im neuen entpackten Agent-Ordner auszuführen.

Überprüfen, ob der Windows-Registrierungsschlüssel ordnungsgemäß aufgezeichnet und gespeichert wurde

Führen Sie den Befehl whoami /user aus, um <sid> abzurufen. Öffnen Sie Registry Editor, und folgen Sie dem Pfad:

Computer\HKEY_USERS\<sid>\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Überprüfen Sie, ob der VSTSAgent-Schlüssel vorhanden ist. Löschen Sie diesen Schlüssel, sofern vorhanden, und schließen Sie Registry Editor. Konfigurieren Sie dann den Agent, indem Sie den Befehl .\config.cmd (ohne Argumente) im Agent-Ordner ausführen. Öffnen Sie Enter Restart the machine at a later time? erneut und überprüfen Sie, ob der Registry Editor-Schlüssel angezeigt wird, bevor Sie die Frage VSTSAgent beantworten. Drücken Sie die EINGABETASTE (Enter), um die Frage zu beantworten, und überprüfen Sie, ob sich der VSTSAgent-Schlüssel nach dem Neustart des Computers weiterhin an seinem Platz befindet.

Überprüfen, ob Windows-Registrierungsschlüssel auf Ihrem Computer ordnungsgemäß funktionieren

Erstellen Sie eine Datei vom Typ autorun.cmd, die die folgende Zeile enthält: echo "Hello from AutoRun!". Öffnen Sie den Registrierungs-Editor (Registry Editor), und erstellen Sie unter dem obigen Pfad ein neues Schlüssel-Wert-Paar mit dem Schlüssel AutoRun und dem Wert.

C:\windows\system32\cmd.exe /D /S /C start "AutoRun" "D:\path\to\autorun.cmd"

Starten Sie den Computer neu. Sie haben ein Problem mit Windows-Registrierungsschlüsseln, wenn kein Konsolenfenster mit der Meldung Hello from AutoRun! angezeigt wird.

Nur für die Bereitstellungsgruppe

• --deploymentGroup: Konfiguriert den Agent als Bereitstellungsgruppen-Agent
• --deploymentGroupName <name>: wird mit --deploymentGroup verwendet, um die Bereitstellungsgruppe anzugeben, der der Agent beitreten soll
• --projectName <name>: wird mit --deploymentGroup verwendet, um den Projektnamen festzulegen
• --addDeploymentGroupTags: wird mit --deploymentGroup verwendet, um anzugeben, dass Bereitstellungsgruppentags hinzugefügt werden sollen
• --deploymentGroupTags <tags>: wird mit --addDeploymentGroupTags verwendet, um die durch Trennzeichen getrennte Liste von Tags für den Bereitstellungsgruppen-Agent anzugeben (beispielsweise „web, db“)

Nur für Umgebungen

• --addvirtualmachineresourcetags: wird verwendet, um anzugeben, dass Umgebungsressourcentags hinzugefügt werden sollen
• --virtualmachineresourcetags <tags>: wird mit --addvirtualmachineresourcetags verwendet, um die durch Trennzeichen getrennte Liste von Tags für den Umgebungsressourcen-Agent anzugeben (beispielsweise „web, db“)

.\config --help: listet immer die neuesten erforderlichen und optionalen Antworten auf.

Diagnose

Wenn Sie Probleme mit Ihrem selbstgehosteten Agent haben, können Sie versuchen, Diagnosen auszuführen. Nach dem Konfigurieren des Agents:

.\run --diagnostics

Dadurch wird eine Diagnosesuite ausgeführt, die Ihnen bei der Problembehandlung helfen kann. Das Diagnosefeature ist ab Agent-Version 2.165.0 verfügbar.

Netzwerkdiagnose für selbstgehostete Agents

Legen Sie den Wert von Agent.Diagnostic auf fest true, um zusätzliche Protokolle zu sammeln, die zur Behandlung von Netzwerkproblemen für selbstgehostete Agents verwendet werden können. Weitere Informationen finden Sie unter Netzwerkdiagnose für selbstgehostete Agents.

Hilfe zu anderen Optionen

So erfahren Sie mehr über andere Optionen

.\config --help

Die Hilfe enthält Informationen zu Authentifizierungsalternativen und zur unbeaufsichtigten Konfiguration.

Funktionen

Die Funktionen Ihres Agents werden katalogisiert und im Pool angekündigt, sodass ihm nur die Builds und Releases zugewiesen werden, die er bewältigen kann. Weitere Informationen finden Sie unter Funktionen von Build- und Release-Agents.

In vielen Fällen müssen Sie nach der Bereitstellung eines Agents Software oder Hilfsprogramme installieren. Im Allgemeinen sollten Sie alle Softwarekomponenten und Tools, die Sie auf Ihrem Entwicklungscomputer verwenden, auf Ihren Agents installieren.

Wenn Ihr Build beispielsweise die npm-Aufgabe enthält, wird der Build nur ausgeführt, wenn im Pool ein Build-Agent mit einer npm-Installation vorhanden ist.

Wichtig

Zu den Funktionen gehören alle Umgebungsvariablen und die Werte, die bei der Ausführung des Agents festgelegt werden. Wenn sich einer dieser Werte ändert, während der Agent ausgeführt wird, muss der Agent neu gestartet werden, um die neuen Werte zu übernehmen. Nachdem Sie neue Software auf einem Agent installiert haben, müssen Sie den Agent neu starten, damit die neue Funktion im Pool vorhanden ist und der Build ausgeführt werden kann.

Sie können Umgebungsvariablen als Funktionen ausschließen, indem Sie die Umgebungsvariable VSO_AGENT_IGNORE mit einer durch Trennzeichen getrennten Liste der zu ignorierenden Variablen festlegen.

Häufig gestellte Fragen

Welche Version von Git führt mein Agent aus?

Standardmäßig verwendet der Windows-Agent die Git-Version, die im Lieferumfang der Agentsoftware enthalten ist. Microsoft empfiehlt, die im Lieferumfang des Agents enthaltene Git-Version zu verwenden. Sie haben jedoch verschiedene Möglichkeiten, dieses Standardverhalten außer Kraft zu setzen und die Git-Version zu verwenden, die im Pfad auf dem Agentcomputer installiert ist.

• Legen Sie eine Pipelinevariable mit dem Namen System.PreferGitFromPath in Ihren Pipelines auf true fest.
• Auf selbstgehosteten Agents können Sie eine ENV-Datei im Stammverzeichnis des Agents erstellen und der Datei die Zeile System.PreferGitFromPath=true hinzufügen. Weitere Informationen finden Sie unter Wie lege ich verschiedene Umgebungsvariablen für jeden einzelnen Agent fest?.

Um die von einer Pipeline verwendete Git-Version zu ermitteln, können Sie sich die Protokolle für einen checkout-Schritt in Ihrer Pipeline ansehen, wie im folgenden Beispiel gezeigt.

Syncing repository: PathFilter (Git)
Prepending Path environment variable with directory containing 'git.exe'.
git version
git version 2.26.2.windows.1

Wie kann ich sicherstellen, dass ich über die neueste Version des Agents verfüge?

1. Navigieren Sie zur Registerkarte Agent-Pools:

   1. Melden Sie sich bei Ihrem organization (https://dev.azure.com/{yourorganization}) an.

   2. Wählen Sie Azure DevOps, Organisationseinstellungen aus.

      

   3. Wählen Sie Agentpools aus.

      

2. Klicken Sie auf den Pool, der den Agent enthält.

3. Stellen Sie sicher, dass der Agent aktiviert ist.

4. Navigieren Sie zur Registerkarte „Funktionen“:

   1. Wählen Sie auf der Registerkarte Agent-Pools den gewünschten Agent-Pool aus.

      

   2. Wählen Sie Agents und dann den gewünschten Agent aus.

      

   3. Wählen Sie die Registerkarte Funktionen aus.

      

      Hinweis

      Von Microsoft gehostete Agents zeigen keine Systemfunktionen an. Eine Liste der auf von Microsoft gehosteten Agents installierten Software finden Sie unter Verwenden eines von Microsoft gehosteten Agents.

5. Suchen Sie nach der Agent.Version-Funktion. Sie können diesen Wert anhand der neuesten veröffentlichten Agent-Version überprüfen. Weitere Informationen finden Sie unter Azure Pipelines-Agent. Suchen Sie auf der Seite nach der höchsten Versionsnummer.

6. Jeder Agent aktualisiert sich automatisch, wenn er eine Aufgabe ausführt, die eine neuere Version des Agents erfordert. Wenn Sie einige Agents manuell aktualisieren möchten, klicken Sie mit der rechten Maustaste auf den Pool, und wählen Sie Alle Agents aktualisieren aus.

Ich führe eine Firewall aus und mein Code befindet sich in Azure Repos. Mit welchen URLs muss der Agent kommunizieren?

Wenn Sie einen Agent in einem sicheren Netzwerk hinter einer Firewall ausführen, stellen Sie sicher, dass der Agent die Kommunikation mit folgenden URLs und IP-Adressen einleiten kann.

Domänen-URL	BESCHREIBUNG
https://{organization_name}.pkgs.visualstudio.com	Azure DevOps-Paket-API für Organisationen, die die Domäne {organization_name}.visualstudio.com verwenden
https://{organization_name}.visualstudio.com	Für Organisationen, die die Domäne {organization_name}.visualstudio.com verwenden
https://{organization_name}.vsblob.visualstudio.com	Azure DevOps-Telemetriedaten für Organisationen, die die Domäne {organization_name}.visualstudio.com verwenden
https://{organization_name}.vsrm.visualstudio.com	Release Management-Dienste für Organisationen, die die Domäne {organization_name}.visualstudio.com verwenden
https://{organization_name}.vssps.visualstudio.com	Azure DevOps Platform Services für Organisationen, die die Domäne {organization_name}.visualstudio.com verwenden
https://{organization_name}.vstmr.visualstudio.com	Azure DevOps Test Management Services für Organisationen, die die Domäne {organization_name}.visualstudio.com verwenden
https://*.blob.core.windows.net	Azure Artifacts
https://*.dev.azure.com	Für Organisationen, die die Domäne dev.azure.com verwenden
https://*.vsassets.io	Azure Artifacts über CDN
https://*.vsblob.visualstudio.com	Azure DevOps-Telemetriedaten für Organisationen, die die Domäne dev.azure.com verwenden
https://*.vssps.visualstudio.com	Azure DevOps Platform Services für Organisationen, die die Domäne dev.azure.com verwenden
https://*.vstmr.visualstudio.com	Azure DevOps Test Management Services für Organisationen, die die Domäne dev.azure.com verwenden
https://app.vssps.visualstudio.com	Für Organisationen, die die Domäne {organization_name}.visualstudio.com verwenden
https://dev.azure.com	Für Organisationen, die die Domäne dev.azure.com verwenden
https://login.microsoftonline.com	Microsoft Entra-Anmeldung
https://management.core.windows.net	Azure-Verwaltungs-APIs
https://vstsagentpackage.azureedge.net	Agent-Paket

Um zu gewährleisten, dass Ihre Organisation mit vorhandenen Firewall- oder IP-Einschränkungen funktioniert, stellen Sie sicher, dass dev.azure.com und *dev.azure.com geöffnet sind, und aktualisieren Sie Ihre zugelassenen IP-Adressen basierend auf Ihrer IP-Version so, dass sie die folgenden IP-Adressen enthalten. Wenn sich die IP-Adressen 13.107.6.183 und 13.107.9.183 derzeit in der Positivliste befinden, lassen Sie sie dort, da sie nicht entfernt werden müssen.

IPv4-Bereiche

• 13.107.6.0/24
• 13.107.9.0/24
• 13.107.42.0/24
• 13.107.43.0/24

IPv6-Bereiche

• 2620:1ec:4::/48
• 2620:1ec:a92::/48
• 2620:1ec:21::/48
• 2620:1ec:22::/48

Hinweis

Weitere Informationen zu zulässigen Adressen finden Sie unter Listen zulässiger Adressen und Netzwerkverbindungen.

Wie kann ich den Agent mit einem selbstsigniertem Zertifikat ausführen?

Hinweis

Das Ausführen des Agents mit einem selbstsignierten Zertifikat gilt lediglich für Azure DevOps Server.

Ausführen des Agents mit selbstsigniertem Zertifikat

Wie kann ich den Agent hinter einem Webproxy ausführen?

Ausführen des Agents hinter einem Webproxy

Wie kann ich den Agent neu starten?

Wenn Sie den Agent interaktiv ausführen, lesen Sie die Neustartanweisungen unter Interaktives Ausführen. Wenn Sie den Agent als Dienst ausführen, starten Sie den Agent neu, indem Sie die Schritte unter Ausführung als Dienst ausführen.

Wie lege ich verschiedene Umgebungsvariablen für jeden einzelnen Agent fest?

Erstellen Sie eine .env-Datei im Stammverzeichnis des Agents, geben Sie die Umgebungsvariablen, die Sie festlegen möchten, in folgendem Format in die Datei ein, und starten Sie dann den Agent neu.

MyEnv0=MyEnvValue0
MyEnv1=MyEnvValue1
MyEnv2=MyEnvValue2
MyEnv3=MyEnvValue3
MyEnv4=MyEnvValue4

Wie konfiguriere ich den Agent so, dass er einen Webproxy umgeht und eine Verbindung mit Azure Pipelines herstellt?

Wenn der Agent Ihren Proxy umgehen und eine direkte Verbindung mit Azure Pipelines herstellen soll, müssen Sie Ihren Webproxy so konfigurieren, dass der Agent auf die folgenden URLs zugreifen kann.

Für Organisationen, die die Domäne *.visualstudio.com verwenden:

https://login.microsoftonline.com
https://app.vssps.visualstudio.com 
https://{organization_name}.visualstudio.com
https://{organization_name}.vsrm.visualstudio.com
https://{organization_name}.vstmr.visualstudio.com
https://{organization_name}.pkgs.visualstudio.com
https://{organization_name}.vssps.visualstudio.com

Für Organisationen, die die Domäne dev.azure.com verwenden:

https://dev.azure.com
https://*.dev.azure.com
https://login.microsoftonline.com
https://management.core.windows.net
https://vstsagentpackage.azureedge.net
https://vssps.dev.azure.com

Um zu gewährleisten, dass Ihre Organisation mit vorhandenen Firewall- oder IP-Einschränkungen funktioniert, stellen Sie sicher, dass dev.azure.com und *dev.azure.com geöffnet sind, und aktualisieren Sie Ihre zugelassenen IP-Adressen basierend auf Ihrer IP-Version so, dass sie die folgenden IP-Adressen enthalten. Wenn sich die IP-Adressen 13.107.6.183 und 13.107.9.183 derzeit in der Positivliste befinden, lassen Sie sie dort, da sie nicht entfernt werden müssen.

IPv4-Bereiche

• 13.107.6.0/24
• 13.107.9.0/24
• 13.107.42.0/24
• 13.107.43.0/24

IPv6-Bereiche

• 2620:1ec:4::/48
• 2620:1ec:a92::/48
• 2620:1ec:21::/48
• 2620:1ec:22::/48

Hinweis

Mit diesem Verfahren kann der Agent einen Webproxy umgehen. Ihre Buildpipeline und Skripts müssen weiterhin die Umgehung Ihres Webproxys für jede Aufgabe und jedes Tool verarbeiten, die bzw. das Sie in Ihrem Build ausführen.

Wenn Sie beispielsweise eine NuGet-Aufgabe verwenden, müssen Sie Ihren Webproxy so konfigurieren, dass er die Umgehung der URL für den Server unterstützt, der den verwendeten NuGet-Feed hostet.

Ich verwende TFS, und die URLs in den obigen Abschnitten funktionieren bei mir nicht. Wo finde ich Hilfe dazu?

Websiteeinstellungen und Sicherheit

Was bedeutet das Aktivieren von SERVICE_SID_TYPE_UNRESTRICTED für den Agent-Dienst?

Beim Konfigurieren der Agent-Software unter Windows Server können Sie die Dienstsicherheits-ID über die folgende Eingabeaufforderung angeben:

Enter enable SERVICE_SID_TYPE_UNRESTRICTED for agent service (Y/N) (press enter for N)

In früheren Versionen der Agent-Software wurde der Typ der Dienstsicherheits-ID auf SERVICE_SID_TYPE_NONE festgelegt. Dies ist der Standardwert für die aktuellen Agent-Versionen. Um den Typ der Dienstsicherheits-ID auf SERVICE_SID_TYPE_UNRESTRICTED festzulegen, drücken Sie die Taste Y.

Weitere Informationen finden Sie unter SERVICE_SID_INFO-Struktur sowie unter Sicherheits-IDs.