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!

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.

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