Drücke "Enter", um den Text zu überspringen.

Schlagwort: Fehler

Azure Virtual Desktop – ein merkwürdiger Fehler und seine banale Lösung

Vor kurzem kam mir in einer frisch aufgebauten Azure Virtual Desktop (AVD) Umgebung ein merkwürdiger Fehler unter. Nach dem Login und der Auswahl der gewünschten App startet der Verbindungsaufbau. Dieser schlägt dann jedoch mit folgender Fehlermeldung fehl:

Wir konnten leider keine Verbindung mit „Outlook“ herstellen.

Mit dem Gateway konnte aufgrund eines Fehlers keine Verbindung hergestellt werden. Sollte das Problem wiederholt auftreten, wenden Sie sich an Ihren Administrator oder an den technischen Support.

Auf englischsprachigen Systemen sieht es dann so aus:

Oops, we couldn’t connect to „Outlook“

We couldn’t connect to the gateway because of an error. If this keeps happening, ask your admin or tech support for help.

Meine Suche im Internet zu möglichen Ursachen brachte leider nichts passendes. Da ich den Grund des Fehlers dann aber kurz darauf selber bemerkt habe, dachte ich, ich dokumentiere das Ganze hier kur, falls noch andere Nutzer in diese „Falle“ tappen:

Die Ursache des Fehlers hat nichts mit Netzwerk oder anderen Verbindungsproblemen zu tun, wie die Meldung zunächst vermuten lässt.

Ich hatte mich schlichtweg am AVD Webclient mit einem User angemeldet, den es in der Windows Server Domäne (ADDS / NTDS) nicht gibt, sondern nur im Azure AD. Die Anmeldung am Host des Hostpools erfolgt aber gegen einen regulären Domänencontroller! Der cloud-only User kann sich noch problemlos am AVD Webclient anmelden, dieser gibt auch keine Warnung o.ä., aus. Nur das Starten der Apps geht dann eben nicht…

Wenn ihr also auch auf diesen Fehler stoßt: Stellt sicher, dass der verwendete Benutzer in der Domäne bekannt und das Passwort dort identisch ist!

Schreibe einen Kommentar...

SCCM 2012 R2: Timeout bei OSD-Fehlern von 15 Minuten auf beliebigen Wert erhöhen

Wenn es während einer Tasksequenz im System Center Configuration Manager 2012 R2 zu einem Fehler kommt, so wird die Fehlermeldung standardmäßig für 15 Minuten angezeigt – danach wird der Client neugestartet. Wenn man nun eine längere Tasksequenz laufen lässt, wird man selten die gesamte Zeit vor dem betroffenen Rechner verbringen und so auch die Fehlermeldung verpassen. Noch schlimmer wird es, wenn der Fehler noch vor dem Abschluss der Formatierung des Laufwerkes geschieht – denn bis zu diesem Punkt ist das Logfile lediglich in einer Ram-Disk abgelegt – und die ist beim Neustart natürlich weg!

Diese Fehlermeldungen sehen dann in etwa so aus:

Dieses Verhalten lässt sich glücklicherweise abändern – mit einem nicht all zu hohem Aufwand! Dazu muss lediglich in der betreffenden Tasksequenz (es geht leider nicht pauschal) eine Tasksequenzvariable gesetzt werden.

Dazu wird die Tasksequenz geöffnet und direkt an erster Stelle ein weiterer Schritt “Tasksequenzvariable festlegen” eingefügt:

Der Name der Variable lautet “SMSTSErrorDialogTimeout” – der Wert ist in Sekunden anzugeben:

Damit ist die gewünschte Änderung auch schon gemacht. Beim nächsten Start der Tasksequenz ist die gemachte Änderung auch schon wirksam… Und dann kann man im Falle eines Fehler mittels F8 die DOS-Box öffnen und beispielsweise mit “cmtrace.exe” die Logfiles analysieren.

1 Kommentar

SCCM2012: Fehler 0x80070002 während OSD / PXE

Mal wieder ein Fehler, den ich hier festhalten möchte, obwohl diesmal recht trivial.

Während einer PXE-gestützten Betriebssysteminstallation (OSD) trat nach der Partitionierung und Formatierung der Festplatte der Fehler 0x80070002 auf:

 

Ein Blick in das Log-File war leider nur mäßig hilfreich:

 

Da der nächste Schritt, der nun also nicht erfolgreich bearbeitet wurde, das Kopieren der WIM-Datei gewesen wäre, vermutete ich ein Problem beim Zugriff auf dem DP, und meine Vermutung fand ihre Bestätigung:

Es war einfach kein Network Access Account (Netzwerkzugriffskonto) angegeben!

Dies lässt sich recht einfach erreichen, ich denke die Bilder sind aussagekräftig genug:

 

UPDATE: Ich habe eben festgestellt, dass dieser Fehler auch trotz korrekt konfiguriertem NAA auftreten kann. In meinem Fall war die Fehlerursache dann auch eine ganz andere: Es fehlte einer Bedingungen für Distribution Points, nämlich die „Windows-Authentifizierung“ des IIS!

Die vollständigen Vorbedingungen lassen sich im Übrigen hier nachlesen: http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_SupConfigSiteSystemReq 

Schreibe einen Kommentar...