Arbeitsordner unter WIN 2012 R2 konfigurieren
Hallo liebes Forum,
ich versuche die Arbeitsordnerfunktion unter Win2012 R2 einzurichten. Es reicht mir im ersten Schritt, wenn sich die Clients innerhalb der Domäne mit dem Arbeitsordnerspeicherplatz auf dem Server verbinden können.
Ich hänge an dem Punkt „Zertifikat richtig verknüpfen“ und „Arbeitsordner von der Workstation anbinden“.
Es wäre super, wenn mir Jemand einen Denkanstoß liefern könnte.
Was habe ich bisher getan:
Auf einem Win2012 R2 Server die Rollen Arbeitsordner und IIS installiert, über den Servermanager / Datei/Speicherdienste einen Arbeitsordner angelegt und die entsprechenden Berechtigungen konfiguriert.
Mein Arbeitsordner liegt auf dem Server auf Laufwerk F: und heißt Arbeitsordner.
Ich habe einen DNS-Eintrag in der Forward-Lookupzone der domäne erstellt Aliasname „workfolders“, vollqualifizierter Name „workfolders.unsere_domäne.local, Domänenname des Zielhosts: „Servername.unsere_domäne.local.
Dann habe ich auf dem Server ein Zertifkat erstellt. Gemeinsamer Name „workfolders.unsere_domäne.local“ ausgestellt für „workoflders.unsere_domäne.local“ Anzeigename „Arbeitsordner“.
Dann bin ich im IIS auf die default Web Site des Servers und habe das erstellte SSL-Zertifikat per https an Port 443 zugewiesen.
Das Zertifikat habe ich per GPO an den Clienten verteilt bzw für Testzwecke auch manuell in eigene Zertifikate importiert.
Wenn ich jetzt auf dem Client versuche, über Systemsteuerung den Arbeitsordner einzurichten, findet das System meine Mailadresse nicht. Wenn ich dann auf „Speicherort direkt wählen“ gehe und https://workfolders.unsere_domäne.local eingebe, bekomme ich auch nur eine Fehlermeldung „überprüfen Sie Namen und Schreibweise“.
Was habe ich falsch gemacht, oder vergessen ?
ich versuche die Arbeitsordnerfunktion unter Win2012 R2 einzurichten. Es reicht mir im ersten Schritt, wenn sich die Clients innerhalb der Domäne mit dem Arbeitsordnerspeicherplatz auf dem Server verbinden können.
Ich hänge an dem Punkt „Zertifikat richtig verknüpfen“ und „Arbeitsordner von der Workstation anbinden“.
Es wäre super, wenn mir Jemand einen Denkanstoß liefern könnte.
Was habe ich bisher getan:
Auf einem Win2012 R2 Server die Rollen Arbeitsordner und IIS installiert, über den Servermanager / Datei/Speicherdienste einen Arbeitsordner angelegt und die entsprechenden Berechtigungen konfiguriert.
Mein Arbeitsordner liegt auf dem Server auf Laufwerk F: und heißt Arbeitsordner.
Ich habe einen DNS-Eintrag in der Forward-Lookupzone der domäne erstellt Aliasname „workfolders“, vollqualifizierter Name „workfolders.unsere_domäne.local, Domänenname des Zielhosts: „Servername.unsere_domäne.local.
Dann habe ich auf dem Server ein Zertifkat erstellt. Gemeinsamer Name „workfolders.unsere_domäne.local“ ausgestellt für „workoflders.unsere_domäne.local“ Anzeigename „Arbeitsordner“.
Dann bin ich im IIS auf die default Web Site des Servers und habe das erstellte SSL-Zertifikat per https an Port 443 zugewiesen.
Das Zertifikat habe ich per GPO an den Clienten verteilt bzw für Testzwecke auch manuell in eigene Zertifikate importiert.
Wenn ich jetzt auf dem Client versuche, über Systemsteuerung den Arbeitsordner einzurichten, findet das System meine Mailadresse nicht. Wenn ich dann auf „Speicherort direkt wählen“ gehe und https://workfolders.unsere_domäne.local eingebe, bekomme ich auch nur eine Fehlermeldung „überprüfen Sie Namen und Schreibweise“.
Was habe ich falsch gemacht, oder vergessen ?
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 316860
Url: https://administrator.de/forum/arbeitsordner-unter-win-2012-r2-konfigurieren-316860.html
Ausgedruckt am: 30.04.2025 um 08:04 Uhr
26 Kommentare
Neuester Kommentar
Hallo AX2012,
entweder du machst die Workfolder URL den Rechnern per GPO bekannt.
Oder du setzt alternativ das entsprechende AD-Attribut msDS-SyncServerUrl in den Useraccounts auf deine Workfolder-URL.
Deploying Work Folders
Sollte aber auch ohne (dann aber nur über manuelle Einrichtung am Client) funktionieren.
Grüße Uwe
entweder du machst die Workfolder URL den Rechnern per GPO bekannt.
Benutzerkonfiguration > Administrative Vorlagen > Windows Komponenten > Arbeitsordner > Arbeitsordner-URL
Oder du setzt alternativ das entsprechende AD-Attribut msDS-SyncServerUrl in den Useraccounts auf deine Workfolder-URL.
Deploying Work Folders
Sollte aber auch ohne (dann aber nur über manuelle Einrichtung am Client) funktionieren.
Grüße Uwe
Danke für die Tipps. Das mit den Gruppenrichtlinien habe ich auch schon probiert. Leider bekomme ich auf dem Clienten auch damit die Fehlermeldung "Problem beim Einrichten, wenden sie sich an den technischen Support".
Noch mal für mein Verständnis. Wenn ich einen Arbeitsordner "Willi" auf dem Server erstelle, ist die Adresse des Arbeitsordners httpswilli.meine.domäne ? Oder in jedem Fall immer httpsworkfolders.meine.domäne?
Übers dns sage ich dann das der Ordnerpfad zu Server 123 gehört?
Noch mal für mein Verständnis. Wenn ich einen Arbeitsordner "Willi" auf dem Server erstelle, ist die Adresse des Arbeitsordners httpswilli.meine.domäne ? Oder in jedem Fall immer httpsworkfolders.meine.domäne?
Übers dns sage ich dann das der Ordnerpfad zu Server 123 gehört?
Zitat von @AX2012:
Danke für die Tipps. Das mit den Gruppenrichtlinien habe ich auch schon probiert. Leider bekomme ich auf dem Clienten auch damit die Fehlermeldung "Problem beim Einrichten, wenden sie sich an den technischen Support".
Dann hast du schon beim Einrichten einen Fehler gemacht. Folge meiner oben verlinkten Anleitung dann klappt das 100%ig. Vergewissere dich ob die GPO richtig zieht (gpresult) und ob Zertiikatsfehler beim Aufruf der IIS Webseite kommen. Wenn du keine Windows CA betreibst muss das selbstsignierte CA Zertifikat in die vertrauenswürdigen Stammzertifikate im Computerstore, nicht das Zertifikat des Workfolder-Servers.Danke für die Tipps. Das mit den Gruppenrichtlinien habe ich auch schon probiert. Leider bekomme ich auf dem Clienten auch damit die Fehlermeldung "Problem beim Einrichten, wenden sie sich an den technischen Support".
Die URL die man den Clients per GPO pusht sagt diesen wo sie den Workfolder-Server finden. Das kannst du wie oben geschrieben entweder per GPO machen oder die URL direkt im Useraccount hinterlegen, wobei die erstere Variante besser wartbar ist.
Das Eventlog des Clients verrät dir bei Fehlern dazu auch einiges.
Noch mal für mein Verständnis. Wenn ich einen Arbeitsordner "Willi" auf dem Server erstelle
Du erstellst ihn nicht das macht der Server automatisch bei der Einichtung über den Assi. Die Userverzeichnisse darin erstellt der Server dann ebenfalls automatisch anhand des Musters das du im Workfolder-Einrichtungs-Assistenten angeben hast, ist die Adresse des Arbeitsordners httpswilli.meine.domäne ?
Nein! Die Workfolder URL ist immer gleich.Oder in jedem Fall immer httpsworkfolders.meine.domäne?
Ja, wenn es ein einzelner Server ist.Übers dns sage ich dann das der Ordnerpfad zu Server 123 gehört?
Die Zuordnung der User zu deren Verzeichnissen macht dann der Workfolder-Server anhand der Credentials.
Vielen Dank für die Hilfe, aber ich muss weiternerven 
Ich habe ein Problem mit dem SSl-Zertifikat. Irgendwas mache ich beim Ausstellen/Freigeben falsch. Wenn ich mit dem Internetexplorer auf den Server schaue (https Servername:443) bekomme ich "Es besteht ein Problem mit dem Sicherheitszertifikat der Webseite / zu meiner HP / fortsetzen (nicht empfohlen)
Ich erstelle ein Domänenzertifikat.
Bei der Erstellung: "gemeinsamer Name" kommt der Servername des betreffenden Servers rein (servername.donäne.local)oder workfolders.domäne.local ?
Auf Seite 2 wähle ich dann meine Zertifizierungsstelle aus. (Der Server auf dem der Arbeitsordner soll, ist auch gleichzeitig meine Domänen-Zertifizierungsstelle)
Sind die Angaben im Punkt Anzeigename zu beachten? Also kann ich da einfach eine Bezeichung fürs Zertifikat reinschreiben oder muss da der Servername oder workfolders.domäne ... drinn stehen?
das Zertifikat verknüpfe ich dann über den IIS mit der Default Web Site über Bindungen https Port 443
Wie müsste meine Default web site im Server jetzt aussehen?
Ich habe ein Problem mit dem SSl-Zertifikat. Irgendwas mache ich beim Ausstellen/Freigeben falsch. Wenn ich mit dem Internetexplorer auf den Server schaue (https Servername:443) bekomme ich "Es besteht ein Problem mit dem Sicherheitszertifikat der Webseite / zu meiner HP / fortsetzen (nicht empfohlen)
Ich erstelle ein Domänenzertifikat.
Bei der Erstellung: "gemeinsamer Name" kommt der Servername des betreffenden Servers rein (servername.donäne.local)oder workfolders.domäne.local ?
Auf Seite 2 wähle ich dann meine Zertifizierungsstelle aus. (Der Server auf dem der Arbeitsordner soll, ist auch gleichzeitig meine Domänen-Zertifizierungsstelle)
Sind die Angaben im Punkt Anzeigename zu beachten? Also kann ich da einfach eine Bezeichung fürs Zertifikat reinschreiben oder muss da der Servername oder workfolders.domäne ... drinn stehen?
das Zertifikat verknüpfe ich dann über den IIS mit der Default Web Site über Bindungen https Port 443
Wie müsste meine Default web site im Server jetzt aussehen?
Zitat von @AX2012:
Ich habe ein Problem mit dem SSl-Zertifikat. Irgendwas mache ich beim Ausstellen/Freigeben falsch. Wenn ich mit dem Internetexplorer auf den Server schaue (https Servername:443) bekomme ich "Es besteht ein Problem mit dem Sicherheitszertifikat der Webseite / zu meiner HP / fortsetzen (nicht empfohlen)
Normal wenn im Common Name oder in den SANs der Servername nicht drin steht Ich habe ein Problem mit dem SSl-Zertifikat. Irgendwas mache ich beim Ausstellen/Freigeben falsch. Wenn ich mit dem Internetexplorer auf den Server schaue (https Servername:443) bekomme ich "Es besteht ein Problem mit dem Sicherheitszertifikat der Webseite / zu meiner HP / fortsetzen (nicht empfohlen)
Ich erstelle ein Domänenzertifikat.
Das sagt überhaupt nichts was das sein soll, du hast eine Windows CA ? Dann erstellle ein Webserverzertifikat.Bei der Erstellung: "gemeinsamer Name" kommt der Servername des betreffenden Servers rein (servername.donäne.local)oder workfolders.domäne.local ?
Natürlich der unter dem du den Server ansprichst also workfolders.domäne.local, wenn du Ihn mit noch anderen Namen ansprechen willst diese als SANs eintragen.Wenn du eine eigene CA hast kannst du auch gleich ein Wildcard-Cert in der CA ausstellen (*.domäne.local) dann sind alle Subdomains enthalten.
Sind die Angaben im Punkt Anzeigename zu beachten? Also kann ich da einfach eine Bezeichung fürs Zertifikat reinschreiben oder muss da der Servername oder workfolders.domäne ... drinn stehen?
Bezeichnung kannst du wählen wie du willst, die Beschreibung wird dann in den Auswahldialogen angezeigt. Das hat keine Relevanz.das Zertifikat verknüpfe ich dann über den IIS mit der Default Web Site über Bindungen https Port 443
Ja.Wie müsste meine Default web site im Server jetzt aussehen?
Na dein Zertifikat muss an Port 443 gebunden sein, https aktiviert sein und der Aufruf im Browser mit https://workfolders.domäne.local muss dein Zertifikat als Vertrauenswürdig anerkennen, sowohl auf dem Client als auch am Server.https://4sysops.com/archives/work-folders-part-3-setting-up-ssl/
Zum DNS Eintrag noch folgende Info, wie der Assi auf dem Client arbeitet:
Auszug aus https://4sysops.com/archives/work-folders-part-2-server-installation/
The Work Folders client uses a user’s email address to determine the name of the Work Folders server. It would be really nice if it determined the server name by performing a DNS query; unfortunately, that isn’t exactly how it works.
The Work Folders set up Wizard uses the domain specified in the email address and adds “workfolders” to the beginning. For example, if your email address is username@4sysops.com, then the set up Wizard will try to connect to https://workfolders.4sysops.com. If your email address is username@na.4sysops.com, then it will try to connect to https://workfolders.na.4sysops.com. So, keep that in mind since many organizations use a sub-domain instead of the root domain for their Active Directory environments.
Ah, ich komme der Lösung näher. Danke für den Link. Die Anleitung ist sehr gut. Ich hatte das Zertifikat falsch ausgestellt.
Nun gut, mein neues wurde eben auch von der Zertifizierungsstelle als fehlgeschlagen eingestuft "die Anforderung enthält keine Zertifikatsvorlageinformationen ..."
An der Baustelle baue ich dann morgen weiter
Nun gut, mein neues wurde eben auch von der Zertifizierungsstelle als fehlgeschlagen eingestuft "die Anforderung enthält keine Zertifikatsvorlageinformationen ..."
An der Baustelle baue ich dann morgen weiter
Dann solltest du dich doch erstmal noch etwas eindringlicher mit den Grundlagen einer CA und Zertifikaten auseinandersetzen
Das ist wohl war. Mit Zertifikaten hatte ich mich noch nie beschäftigt, außer mal ein selbsterstelltes für den Exchange. Bin jetzt seit einigen Tagen erstmal stolzer Besitzer eine offiziellen Zertifizierungsstelle in der Domäne.
Ansonsten ist an der Einrichtung des Arbeitsordners ja nicht viel drann bzw. falsch zu machen.
Ich bin bei der Zertifikatserstellung auch nach einer Anleitung im Netz gegangen, die aber offensichtlich nicht korrekt ist. Ich gehe die Schritte gleich noch mal durch.
ich hänge in der Anleitung bei:
"Take the certificate request (CSR) to any of the public Certificate Authorities and purchase your SSL certificate. Once you’ve got the signed certificate, you can go back into the IIS Manager and click Complete Certificate Request to finish the process."
Da ich nur eine Zertifizierungsstelle habe, mache ich auch nur eine Anfrage, richtig?
Da die Zertifizierungsstelle das Zertifikat als fehlgeschlagen einstuft mit dem Statuscode: Die Anforderung enthält keine Zertifikatsvorlageninformationen 0x80094801 (-2146875391 CERTSRV_E_NO_CERT_TYPE), muss ich meiner frischen Zertifizierungsstelle diese Zertifikatsvorlage erst noch hinzupacken? Webserver ist ja eigentlich schon als Vorlage da.
Ansonsten ist an der Einrichtung des Arbeitsordners ja nicht viel drann bzw. falsch zu machen.
Ich bin bei der Zertifikatserstellung auch nach einer Anleitung im Netz gegangen, die aber offensichtlich nicht korrekt ist. Ich gehe die Schritte gleich noch mal durch.
ich hänge in der Anleitung bei:
"Take the certificate request (CSR) to any of the public Certificate Authorities and purchase your SSL certificate. Once you’ve got the signed certificate, you can go back into the IIS Manager and click Complete Certificate Request to finish the process."
Da ich nur eine Zertifizierungsstelle habe, mache ich auch nur eine Anfrage, richtig?
Da die Zertifizierungsstelle das Zertifikat als fehlgeschlagen einstuft mit dem Statuscode: Die Anforderung enthält keine Zertifikatsvorlageninformationen 0x80094801 (-2146875391 CERTSRV_E_NO_CERT_TYPE), muss ich meiner frischen Zertifizierungsstelle diese Zertifikatsvorlage erst noch hinzupacken? Webserver ist ja eigentlich schon als Vorlage da.
Da ich nur eine Zertifizierungsstelle habe, mache ich auch nur eine Anfrage, richtig?
Das mit dem CSR ist erforderlich wenn du das Zertifikat von einer externen CA bekommst, oder wenn deine CA nicht automatisch Zertifikate ausstellt.Du hast wahrscheinlich nicht die Option Domänenzertifikat benutzt, das ist die einfachste Variante für Anfänger. Damit wird das Zertifikat bei der CA angefordert und automatisch ausgestellt.
Man kann zwar auch über die Webregistrierung(Browser) oder die MMC benutzerdefinierte Zertifikate anfordern, aber dazu solltest du dich erst einlesen.
Ich mach später ein paar Screenshots wie du es am einfachsten machst.
Jetzt alles tutti
?
danke für deine Zeit / Geduld
Ja genau so habe ich es ja auch schon tagelang gemacht. Das meinte ich mit Domänenzertifikat erstellen weiter oben im Text.
Dann bin ich jetzt wieder am Anfang des Threats. Also ich habe mein Domänenzertifikat korrekt erstellt und mit 443 verknüpft. Jetzt möchte ich mal prüfen, ob das Zertifikat geht und gebe im Browser https localhost:443 ein (oder alternativ Name oder IP des Servers)
dann bekomme ich
wenn ich dann auf "laden dieser Seite fortsetzen" gehe kommt:
und jetzt bin ich raus. Gleiches Fenster kommt auch, wenn ich den Arbeitsordner händisch beim Clienten verbinden will. Wenn ich mich dann da mit meinen Anmeldedaten anmelde, kommt
Ja genau so habe ich es ja auch schon tagelang gemacht. Das meinte ich mit Domänenzertifikat erstellen weiter oben im Text.
Dann bin ich jetzt wieder am Anfang des Threats. Also ich habe mein Domänenzertifikat korrekt erstellt und mit 443 verknüpft. Jetzt möchte ich mal prüfen, ob das Zertifikat geht und gebe im Browser https localhost:443 ein (oder alternativ Name oder IP des Servers)
dann bekomme ich
wenn ich dann auf "laden dieser Seite fortsetzen" gehe kommt:
und jetzt bin ich raus. Gleiches Fenster kommt auch, wenn ich den Arbeitsordner händisch beim Clienten verbinden will. Wenn ich mich dann da mit meinen Anmeldedaten anmelde, kommt
Jetzt möchte ich mal prüfen, ob das Zertifikat geht und gebe im Browser https localhost:443 ein (oder alternativ Name oder IP des Servers)
FALSCH. Hier musst du immer mit dem FQDN (https://workfolders.domäne.local) arbeiten. Das ist ja das eigentlich Prinzip von Zertifikaten, diese sind immer nur dann für die Site gültig wenn der eingegebene/angesprochene Hostname in der URL mit dem Common Name oder eines der SANs auf dem Zertifikat des jeweiligen Servers übereinstimmt!Wenn ich mich dann da mit meinen Anmeldedaten anmelde, kommt
Logisch weil am Client localhost der eigene Rechner (des Clients) ist und nicht der Workfolder-Server auf dem der IIS läuft Wo wir wieder beim Thema Netzwerkgrundlagen und DNS wären.
Tutorials stur abarbeiten schön und gut, aber man sollte vorher die Arbeitsweise der einzelnen Systeme wie DNS, Zertifikate, etc. grundlegend verstanden haben, sorry.
Wow du wohl nur online?
Habe mich falsch ausgedrückt. Natürlich gebe ich am Client https://workfolders.domäne.local ein. Leider bekomme ich da dann "diese Seite kann nicht angezeigt werden" Die gleiche Meldung bekomme ich auf dem Server des Arbeitsordners, wo ich eigentlich erwarte, das es funktioniert. Deshalb habe ich es auch mal mit localhost .... probiert.
Das ist genau wieder der Ausgangspunkt, wo ich nicht weiterkam und weshalb ich hier schreibe. Mit dem FQDN bekomme ich auf dem Server die Benutzer / Kennwortabfrage und wenn ich diese dann ausfülle, Webseite nicht gefunden.
Was ich nun weiß, ist das mein Zertifikat korrekt installiert und verbunden ist. Danke für deine Hilfe bis dahin.
Also muss ich jetzt weiter an der Workfolder-Installation suchen
Habe mich falsch ausgedrückt. Natürlich gebe ich am Client https://workfolders.domäne.local ein. Leider bekomme ich da dann "diese Seite kann nicht angezeigt werden" Die gleiche Meldung bekomme ich auf dem Server des Arbeitsordners, wo ich eigentlich erwarte, das es funktioniert. Deshalb habe ich es auch mal mit localhost .... probiert.
Das ist genau wieder der Ausgangspunkt, wo ich nicht weiterkam und weshalb ich hier schreibe. Mit dem FQDN bekomme ich auf dem Server die Benutzer / Kennwortabfrage und wenn ich diese dann ausfülle, Webseite nicht gefunden.
Was ich nun weiß, ist das mein Zertifikat korrekt installiert und verbunden ist. Danke für deine Hilfe bis dahin.
Also muss ich jetzt weiter an der Workfolder-Installation suchen
Mit dem FQDN bekomme ich auf dem Server die Benutzer / Kennwortabfrage und wenn ich diese dann ausfülle, Webseite nicht gefunden.
Das ist OK denn hinter der URL ist nichts was der Browser anzeigen könnte (diese wird intern auf einen Application-Pool umgeleitet, zum Anzeigen gibts da nichts), es darf nur kein Zertifikatsfehler kommen, den Passwortdialog kannst du abbrechen, das Zertifikat oben in der Addressleiste darf nur nicht angemeckert werden, dann ist mit dem Zertifikat alles in Ordnung.Ich kann dir das gerne bei Zeiten mal per Teamviewer in einer VM-Umgebung zeigen wenn du Lust und Zeit hast.
Ja das wäre prima.
Also jetzt, da ich nicht (wie bei "localhost") als erstes die Seite mit dem Sicherheitszertifikatproblem (siehe oben) angezeigt bekomme, weiß ich das das Zertifikat ok ist.
Dieses Zertifikat exportiere ich jetzt mit Hilfe der MMC und verteile es per Gruppenrichtlinie an die Clients, bzw importiere es erstmal manuell bei einem Client zum Testen. So weit korrekt gedacht?
Also jetzt, da ich nicht (wie bei "localhost") als erstes die Seite mit dem Sicherheitszertifikatproblem (siehe oben) angezeigt bekomme, weiß ich das das Zertifikat ok ist.
Dieses Zertifikat exportiere ich jetzt mit Hilfe der MMC und verteile es per Gruppenrichtlinie an die Clients, bzw importiere es erstmal manuell bei einem Client zum Testen. So weit korrekt gedacht?
Zitat von @AX2012:
Dieses Zertifikat exportiere ich jetzt mit Hilfe der MMC und verteile es per Gruppenrichtlinie an die Clients, bzw importiere es erstmal manuell bei einem Client zum Testen. So weit korrekt gedacht?
Nein das ist nicht richtig. Die Clients vertrauen deiner CA bereits sofern der Rechner ein Domänenmitglied ist (sie bekommen das CA-Zertifikat automatisch von der CA). Sind die Clients das nicht verteilst du nicht das Serverzertifikat sonder das öffentliche Zertifikate der CA in den "Computerstore" des Clients in die "vertrauenswürdigen Stammzertifizierungsstellen".Dieses Zertifikat exportiere ich jetzt mit Hilfe der MMC und verteile es per Gruppenrichtlinie an die Clients, bzw importiere es erstmal manuell bei einem Client zum Testen. So weit korrekt gedacht?
Deswegen gibt es den Ausdruck Certificate Chain of Trust, vertraust du einer CA vertraut der Client allen von ihr ausgestellten Zertifikate außer sie sind abgelaufen oder zurückgezogen worden.
Ja das Zertifikat der CA wurde korrekt an die Domänen-Cients verteilt und liegt dort in den "vertrauenswürdigen Stammzertifizierungsstellen / Zertifikate". Muss der Zertififizierungsserver auch bei "vertrauenswürdige Herausgeber" eingetragen sein?
Wenn ich workfolders.domäne ... anpinge, bekomme ich auch die korrekte Server IP angzeigt.
Dann müsste doch eigentlich alles funktionieren
Wenn ich workfolders.domäne ... anpinge, bekomme ich auch die korrekte Server IP angzeigt.
Dann müsste doch eigentlich alles funktionieren
Zitat von @AX2012:
Muss der Zertififizierungsserver auch bei "vertrauenswürdige Herausgeber" eingetragen sein?
Nein.Muss der Zertififizierungsserver auch bei "vertrauenswürdige Herausgeber" eingetragen sein?
Wenn ich workfolders.domäne ... anpinge, bekomme ich auch die korrekte Server IP angzeigt.
OK, gut.Dann müsste doch eigentlich alles funktionieren
Ja.Noch was wichtiges was mit der Digest-Auth zu tun hat: Wurde der Alias des Users den du zum Verbinden benutzt schon mal umbenannt? Wenn ja, dann setze das Password des Users am DC zurück, und versuche erneut die Einrichtung.
https://social.technet.microsoft.com/Forums/en-US/ef5b024d-463f-4697-9a4 ...
Welche Fehlermeldung bekommst du nun exakt am Client bei der Einrichtung (Fehlerdialog nach unten aufklappen und Screenshot machen)?
unbekannter Fehler
wenn ich nach mailadresse gehe:
wenn ich den Orderspeicherort eingebe:
Der Alias (ich selbst) wurde noch nie umbenannt.
wenn ich nach mailadresse gehe:
wenn ich den Orderspeicherort eingebe:
Der Alias (ich selbst) wurde noch nie umbenannt.
Das ist ein generischer Fehler der bedeutet Access Denied.
Beim installieren der Workfolders brauchst du den IIS nicht manuell hinzufügen die abhängigen Rollen wählt der Assi automatisch wenn man Die Arbeitsordner Rolle hinzufügt..
- Welches OS hat der Client?
- Sind alle Updates am Client installiert?
- Wurde der User einer Gruppe zugewiesen und diese im Assi am Server berechtigt?
- Wurde der User nach dem hinzufügen zur Gruppe abgemeldet und neu angemeldet?
- War der User jemals in Administrativen Gruppen?
Beim installieren der Workfolders brauchst du den IIS nicht manuell hinzufügen die abhängigen Rollen wählt der Assi automatisch wenn man Die Arbeitsordner Rolle hinzufügt..
Das ist ein generischer Fehler der bedeutet Access Denied.
•Welches OS hat der Client?
Win10 Pro (mein erster Win 10 Client in der Domäne, sonst nur Win 7)
•Sind alle Updates am Client installiert?
Ja außer 1607
•Wurde der User einer Gruppe zugewiesen und diese im Assi am Server berechtigt?
Der User wurde einer Gruppe "Arbeitsordner" zugewiesen. Die Gruppe ist im Assi dem Arbeitsordner zugeordnet. Aber was ich gerade sehe, unter Benutzer werden gar keine Benutzer angezeigt. Ist das normal so? Ich hätte jetzt erwartet, das da die Benutzer aus der Gruppe Arbeitsordner stehen. (Oder stehen die da erst nachdem sie sich erstmalig verbunden haben?) siehe Bild unten.
•Wurde der User nach dem hinzufügen zur Gruppe abgemeldet und neu angemeldet?
Ja mehrmals
•War der User jemals in Administrativen Gruppen?
Ja
•Welches OS hat der Client?
Win10 Pro (mein erster Win 10 Client in der Domäne, sonst nur Win 7)
•Sind alle Updates am Client installiert?
Ja außer 1607
•Wurde der User einer Gruppe zugewiesen und diese im Assi am Server berechtigt?
Der User wurde einer Gruppe "Arbeitsordner" zugewiesen. Die Gruppe ist im Assi dem Arbeitsordner zugeordnet. Aber was ich gerade sehe, unter Benutzer werden gar keine Benutzer angezeigt. Ist das normal so? Ich hätte jetzt erwartet, das da die Benutzer aus der Gruppe Arbeitsordner stehen. (Oder stehen die da erst nachdem sie sich erstmalig verbunden haben?) siehe Bild unten.
•Wurde der User nach dem hinzufügen zur Gruppe abgemeldet und neu angemeldet?
Ja mehrmals
•War der User jemals in Administrativen Gruppen?
Ja
Zitat von @AX2012:
•Wurde der User einer Gruppe zugewiesen und diese im Assi am Server berechtigt?
Der User wurde einer Gruppe "Arbeitsordner" zugewiesen. Die Gruppe ist im Assi dem Arbeitsordner zugeordnet. Aber was ich gerade sehe, unter Benutzer werden gar keine Benutzer angezeigt. Ist das normal so?
Nein, dort sollten die User aufgelistet werden auch wenn sie noch keine Verbindung hergestellt haben.•Wurde der User einer Gruppe zugewiesen und diese im Assi am Server berechtigt?
Der User wurde einer Gruppe "Arbeitsordner" zugewiesen. Die Gruppe ist im Assi dem Arbeitsordner zugeordnet. Aber was ich gerade sehe, unter Benutzer werden gar keine Benutzer angezeigt. Ist das normal so?
- Ist die Gruppe Global und eine Sicherheitsgruppe?
- Wurde überprüft ob die Gruppe im Userobjekt auftaucht?
- Sind mehrere DCs im Einsatz dann überprüfe die Synchronisierung dieser untereinander.
Ich hätte jetzt erwartet, das da die Benutzer aus der Gruppe Arbeitsordner stehen.
Korrekt•War der User jemals in Administrativen Gruppen?
Ja
Dann erstelle einen ganz neuen Benutzer.Ja
Ansonsten hilft nur noch TeamViewer um dir hier weiterhelfen zu können.
Melde dich per PM wann du Zeit dazu hast.
Die Gruppe ist globale Sicherheitsgruppe, Gruppe taucht im User auf, sind mehrere DCs im Einsatz. Syncronisation läuft.
Ich habe einen neuen User angelegt. Zumindest taucht der dann schon mal automatisch bei dem Benutzern auf.
Leider habe ich beim Verbinden mit dem Arbeitsordner und dem neuen User den gleichen Fehler. Ich denke, es ist nur eine ganz kleine Sache an der es hakt.
Ich melde mich morgen früh per PM.
Ich habe einen neuen User angelegt. Zumindest taucht der dann schon mal automatisch bei dem Benutzern auf.
Leider habe ich beim Verbinden mit dem Arbeitsordner und dem neuen User den gleichen Fehler. Ich denke, es ist nur eine ganz kleine Sache an der es hakt.
Ich melde mich morgen früh per PM.
Ohne Logs (Eventlogs, etc.) ist das hier leider alles Glaskugel polieren.
Ich melde mich morgen früh per PM.
OK.
Ich hab die Lösung gefunden.
Wir nutzen einen Proxy ins I-Net. Bei "lokale Adressen umgehen" muss explizit auch workfolders.domäne.endung eingetragen sein. Ich hatte da nur den Server eingetragen, auf dem der Workfolder läuft.
Bin auch nur durch Zufall drauf gekommen, das das System zur Config des Arbeitsordners die "Standartinterneteinstellungen" abruft. Ich hatte eine DSL-Störung und 2 Tage kein Internet. In der Zeit hab ich es noch mal versucht und bekam nach einer längeren Wartezeit eine etwas andere Fehlermeldung, die da sagte "kann momentan keine Verbindung zum Server bekommen". Server und Testworkstation sind in der gleichen LAN. Da kam mir die Idee das ganze mal ohne Proxy zu testen und Bingo.
Also konfigurations / einrichtungstechnisch hatte ich das mit dem Arbeitsordner alles korrekt. Vielen Dank für deine Geduld und Denkanstöße Colinardo.
Was mir noch aufgefallen ist:
wie oben schon mal erwähnt, wenn der User, den ich einrichten will, schon mal Admin war, oder in seinen Rechten groß umhergesprungen ist, greift der Zugriff nicht über die AD-Gruppe die ich für Worfolder-User eingerichtet habe. Ich muss den User selbst im Workfoldersmenü als zugriffsberechtigt hinzufügen.
Bei neuen (sauberen) Usern, genügt es, sie in die enstprechende AD-Gruppe zu schieben.
Jetzt habe ich den Arbeitsordner in der Domäne verfügbar. Wenn ich mich jetzt von extern mit einem VPN in mein Firmennetzwerk wähle, müsste die Syncronisation doch auch klappen oder? Dann brauche ich die externe Zertifikatsgeschichte doch gar nicht, oder?
Wir nutzen einen Proxy ins I-Net. Bei "lokale Adressen umgehen" muss explizit auch workfolders.domäne.endung eingetragen sein. Ich hatte da nur den Server eingetragen, auf dem der Workfolder läuft.
Bin auch nur durch Zufall drauf gekommen, das das System zur Config des Arbeitsordners die "Standartinterneteinstellungen" abruft. Ich hatte eine DSL-Störung und 2 Tage kein Internet. In der Zeit hab ich es noch mal versucht und bekam nach einer längeren Wartezeit eine etwas andere Fehlermeldung, die da sagte "kann momentan keine Verbindung zum Server bekommen". Server und Testworkstation sind in der gleichen LAN. Da kam mir die Idee das ganze mal ohne Proxy zu testen und Bingo.
Also konfigurations / einrichtungstechnisch hatte ich das mit dem Arbeitsordner alles korrekt. Vielen Dank für deine Geduld und Denkanstöße Colinardo.
Was mir noch aufgefallen ist:
wie oben schon mal erwähnt, wenn der User, den ich einrichten will, schon mal Admin war, oder in seinen Rechten groß umhergesprungen ist, greift der Zugriff nicht über die AD-Gruppe die ich für Worfolder-User eingerichtet habe. Ich muss den User selbst im Workfoldersmenü als zugriffsberechtigt hinzufügen.
Bei neuen (sauberen) Usern, genügt es, sie in die enstprechende AD-Gruppe zu schieben.
Jetzt habe ich den Arbeitsordner in der Domäne verfügbar. Wenn ich mich jetzt von extern mit einem VPN in mein Firmennetzwerk wähle, müsste die Syncronisation doch auch klappen oder? Dann brauche ich die externe Zertifikatsgeschichte doch gar nicht, oder?
Zitat von @AX2012:
Wir nutzen einen Proxy ins I-Net. Bei "lokale Adressen umgehen" muss explizit auch workfolders.domäne.endung eingetragen sein. Ich hatte da nur den Server eingetragen, auf dem der Workfolder läuft.
Da hätten wir hier ja noch lange rumwurschteln können Wir nutzen einen Proxy ins I-Net. Bei "lokale Adressen umgehen" muss explizit auch workfolders.domäne.endung eingetragen sein. Ich hatte da nur den Server eingetragen, auf dem der Workfolder läuft.
. "Ente gut alles gut".Was mir noch aufgefallen ist:
wie oben schon mal erwähnt, wenn der User, den ich einrichten will, schon mal Admin war, oder in seinen Rechten groß umhergesprungen ist, greift der Zugriff nicht über die AD-Gruppe die ich für Worfolder-User eingerichtet habe. Ich muss den User selbst im Workfoldersmenü als zugriffsberechtigt hinzufügen.
Kann ich hier nicht nachvollziehen, was meinst du mit "umhergesprungen" wie oben schon mal erwähnt, wenn der User, den ich einrichten will, schon mal Admin war, oder in seinen Rechten groß umhergesprungen ist, greift der Zugriff nicht über die AD-Gruppe die ich für Worfolder-User eingerichtet habe. Ich muss den User selbst im Workfoldersmenü als zugriffsberechtigt hinzufügen.
. Zur Info: Gruppenmitgliedschaften sind erst im Token des Users wenn sich dieser nach der Änderung neu anmeldet.Jetzt habe ich den Arbeitsordner in der Domäne verfügbar. Wenn ich mich jetzt von extern mit einem VPN in mein Firmennetzwerk wähle, müsste die Syncronisation doch auch klappen oder? Dann brauche ich die externe Zertifikatsgeschichte doch gar nicht, oder?
Wenn die Clients über das VPN deinen internen DNS verwenden bzw. die Workfolders-Domain auflösen können, dann ja. Aber eigentlich sind die Workfolders ja gerade deswegen interessant das man sie von überall auch ohne VPN nutzen kann.Wenns das dann war, den Beitrag bitte noch auf gelöst setzen, und Lösungen markieren. Merci.
Grüße Uwe
