none
Netzwerkdrucker lassen sich nicht verbinden RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo an alle,

     

    folgendes Problem: Wir haben momentan Netzwerkdrucker auf einem Windows Server 2003 freigegeben. Nun möchte ich den Druckserver auf Server 2008 32bit einrichten. Die Umgebung ist eine 2008-Domäne. Testweise installiere ich nun alles, bevor wir den neuen Druckserver in Betrieb nehmen.

     

    Die Clients laufen auf Windows 7 Professional 32 / 64bit. Die freizugebenden Drucker sind OKI C5950DN und C8800N und bereits in der aktuellsten PCL-Treiberversion auf dem neuen Druckserver installiert und auch freigegeben, allerdings nur für bestimmte Benutzer. Der Benutzer, der sich am Windows 7-Client anmeldet, hat keine Zugriffsrechte. Dahinter steckt, dass wir eine Hochschule betreiben und die Studenten sich für die Ausdrucke erst authentifizieren müssen.

     

    Ansatz 1: Ich melde mich an Win7 mit dem Standarduser an. Ich verbinde zunächst einen der Netzwerkdrucker. Da keine Authentifizierung vorliegt, wird diese korrekterweise abgefragt. Ich gebe die Anmeldedaten für einen User aus der freigegebenen AD-Gruppe an, bekomme dann aber folgende Fehlermeldung:

    Die angegebenen Anmeldeinformationen beinhalten keine ausreichenden Zugriffsrechte auf den Drucker. Sollen neue Anmeldeinformationen eingegeben werden?

     

    Problem: Die Daten sind absolut in Ordnung, der User darf drucken, zumindest, wenn es nach den Freigabeeinstellungen auf dem Druckserver geht. Kurios auch: Gebe ich als Anmeldeinformationen die Daten des Domänen-Admins ein, bekomme ich trotzdem dieselbe Fehlermeldung.

     

    Ansatz 2: Ich hinterlege die Anmeldeinformationen des berechtigten Users in der Anmeldeinformationsverwaltung des Win7-Clients. Jetzt kann ich alle Netzwerkdrucker problemlos verbinden und auf die Drucker wie gewünscht zugreifen. So weit, so gut, nur: Diese Daten muss ich wieder löschen, da sonst ja alle Studenten kostenlos ohne Authentifizierung drucken können. Vorgesehen ist, dass die Studenten sich über ein selbstgebautes Powershell-Skript authentifizieren und dann drucken können. In der Kombination Win7-Client und 2003-Druckserver klappt das auch super, in der gewünschten Kombination Win7-Client und 2008-Druckserver hingegen nicht. Melde ich mich hier mit dem Powershell-Skript und entsprechenden Anmeldedaten an, bekomme ich folgende Meldung, sobald ich drucken will:

     

    Die Testseite konnte nicht gedruckt werden. Soll die Druckproblembehandlung angezeigt werden? Der serverseitige Druckspoolerdienst wird nicht ausgeführt. Starten Sie den Spooler auf dem Server neu, oder starten Sie den Servercomputer neu.

     

    Der serverseitige Druckspoolerdienst läuft und Neustarts bringen auch nix.

     

     

    Bin absolut ratlos, kann mir jemand helfen?

     

    Gruß

    Coreknabe

     

     

    Microsoft MCITP Server Administrator

    Donnerstag, 8. Dezember 2011 13:45
    |

Alle Antworten

  • Discussion
    Anmelden
    0
    Anmelden

    Am 08.12.2011 schrieb Coreknabe:

    Die Clients laufen auf Windows 7 Professional 32 / 64bit. Die freizugebenden Drucker sind OKI C5950DN und C8800N und bereits in der aktuellsten PCL-Treiberversion auf dem neuen Druckserver installiert und auch freigegeben, allerdings nur für bestimmte Benutzer. Der Benutzer, der sich am Windows 7-Client anmeldet, hat keine Zugriffsrechte. Dahinter steckt, dass wir eine Hochschule betreiben und die Studenten sich für die Ausdrucke erst authentifizieren müssen.

     

    Ansatz 1: Ich melde mich an Win7 mit dem Standarduser an. Ich verbinde zunächst einen der Netzwerkdrucker. Da keine Authentifizierung vorliegt, wird diese korrekterweise abgefragt. Ich gebe die Anmeldedaten für einen User aus der freigegebenen AD-Gruppe an, bekomme dann aber folgende Fehlermeldung:

    Die angegebenen Anmeldeinformationen beinhalten keine ausreichenden Zugriffsrechte auf den Drucker. Sollen neue Anmeldeinformationen eingegeben werden?

    Evtl. hilft dir dieser Artikel weiter:
    http://www.faq-o-matic.net/2009/10/08/drucken-unter-windows-7-in-der-domne/

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Freitag, 9. Dezember 2011 12:23
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Winfried,

     

    danke für die Rückmeldung. Den Link kenne ich schon, hilft mir leider nicht.

     

    Was noch merkwürdig ist: Vom Win7-Client kann ich problemlos in der alten Weise auf die Drucker des 2003-Druckservers zugreifen, nur eben auf 2008 nicht. Und: Ich gebe die Daten in der Anmeldeinformationsverwaltung ein. Installiere testweise einen der freigegebenen Drucker des 2008-Servers. Alles gut. Jetzt lösche ich die Anmeldeinformationen wieder. Rechtsklick auf den Drucker --> Eigenschaften. Können nicht angezeigt werden, weil Zugriffsrechte fehlen. Neustart. Rechtsklick auf den Drucker --> Eigenschaften. Druckereigenschaften werden angezeigt. Das dürfte doch überhaupt nicht möglich sein?

     

    MCITP Server Administrator MCTS 2008R2 Server Virtualization
    Freitag, 9. Dezember 2011 12:37
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Poste bitte die Ausgabe des Kommandos

    net share "<Name der Druckerfreigabe>"

    und des Kommandos

    net user <Benutzername>

    wobei <Benutzername> der Name des Benutzers ist, unter dem du dich in der 2008er Domäne anmeldest.

    Die 2008er und 2003er Domäne heißen doch hoffentlich unterschiedlich?

    Gibt es eine Vertrauensstellung zwischen den Domänen oder sind sie im gleichen Forest?
    Sonntag, 11. Dezember 2011 19:43
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Poste bitte die Ausgabe des Kommandos

    net share "<Name der Druckerfreigabe>"

    --> net share drucker
    Freigabename          drucker
    Pfad                  PAPERCUT_192.168.100.80
    Beschreibung          A4-Drucker #1
    Max. Benutzer         Unbegrenzt
    Benutzer              testuser
    Zwischenspeichern     Manuelle Zwischenspeicherung von Dokumenten
    Berechtigung          DOMAENE\standarduser, FULL VERWEIGERN
                          DOMAENE\testuser, FULL
                          DOMAENE\admin, FULL
                          DOMAENE\admin2, FULL
                          VORDEFINIERT\Administratoren, FULL
                          VORDEFINIERT\Hauptbenutzer, FULL

    Der Befehl wurde erfolgreich ausgeführt.

     

    net user <Benutzername>

    --> Verstehe nicht ganz, was das bringen soll?  Meines bescheidenen Wissens gibt es mit diesem Befehl keine brauchbaren Optionen, da ich den Benutzer weder löschen noch modifizieren will?

     

    wobei <Benutzername> der Name des Benutzers ist, unter dem du dich in der 2008er Domäne anmeldest.

    Die 2008er und 2003er Domäne heißen doch hoffentlich unterschiedlich?

    --> Missverständnis. Es ist eine Windows Server 2008 Domäne und diese ist die einzige.

      Hinweis: Der "testuser" soll die Drucker nutzen dürfen, der "standarduser" soll sich an der Domäne anmelden, aber nicht die Drucker nutzen.

     

    Habe noch ein wenig weitergetestet, es scheint, als ob die Drucker immer mit dem Standarduser verknüpft sind. Verweigere ich diesem wie oben angegeben die Druckrechte, kommt es zur obskuren Fehlermeldung, dass der Spooler auf dem Druckserver nicht läuft, wenn ich mit dem (angemeldeten) Testuser drucken will. Ist der Druckserver mit Windows Server 2003 ausgestattet, funktioniert alles wie gewünscht. Der Standarduser wird also in Bezug auf die Drucker immer vorgezogen und auch dann verwendet, wenn er gar keine Rechte hat.

    Möglicher Workaround: Ich könnte die Anmeldedaten des Testusers per Powershell in der Anmeldeinformationsverwaltung hinterlegen. Wenn die Anmeldedaten des Testusers dort hinterlegt sind, funktioniert es auch. Der Ablauf birgt dann für uns allerdings unschöne Fehlerquellen, deshalb möchte ich diesen Weg vermeiden. Habe jetzt bei Microsoft einen Call eröffnet, mal sehen, was dabei rauskommt, vielleicht ist das ja auch ein Bug, den noch niemand bemerkt hat...

     

    Bin trotzdem für weitere Anregungen und Hilfe dankbar!

     

    MCITP Server Administrator MCTS 2008R2 Server Virtualization

    • Bearbeitet Coreknabe Montag, 12. Dezember 2011 08:51
    Montag, 12. Dezember 2011 08:40
    |
  • Discussion
    Anmelden
    0
    Anmelden
    Das ist frustrierend! Erst bittest du hier im Forum um Hilfe, man versucht dir zu helfen, obwohl die Problembeschreibung nur vage Angaben enthält ("Standarduser" - gibt es nicht, "User aus der freigegebenen AD-Gruppe" - man kann keine Gruppen freigeben, man weiß nicht, mit welchen Konten du testest), bittet dann um nähere Informationen und bekommt: "Verstehe nicht ganz, was das bringen soll?" und "Habe jetzt bei Microsoft einen Call eröffnet"!
    Montag, 12. Dezember 2011 09:50
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Am 12.12.2011 schrieb Coreknabe:

      Hinweis: Der "testuser" soll die Drucker nutzen dürfen, der "standarduser" soll sich an der Domäne anmelden, aber nicht die Drucker nutzen.

    Du kannst dich mit dem Testuser über die Commandline am Server
    anmelden.
    net use \\deinDC "passwort" /user:deinedom\Testuser

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Montag, 12. Dezember 2011 12:19
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Sorry, ich weiß, das ist teils alles recht wirr...

     

    Ich versuche es noch einmal von vorn.

    Wir sind eine Hochschule. Studenten können bei uns gegen Gebühr Netzwerkdrucker verwenden.

    Umsetzung ALT:

    Student setzt sich an einen PC in einem Lehrsaal. An diesem Rechner ist der Standardbenutzer "student" an der Windows-Anmeldung vorgeblendet. Die Netzwerkdrucker (eingerichtet auf Server 2003) sind vorhanden, dürfen aber vom Benutzer "student" nicht verwendet werden, da sonst jeder an diesem Rechner kostenlos drucken kann. Also: Die Studenten müssen sich an den Druckern authentifizieren. Dies passiert über Ihr eigenes AD-Konto mittels eines Powershell-Skriptes, das nicht anderes macht, als den Kontonamen des Studenten samt Passwort in einem "net use"-Aufruf zu verwursten. Danach sind die Drucker gemappt und können verwendet werden. Kontrolliere ich das Mapping mittels "net use" in der Kommandozeile, ist auch alles korrekt.

    Besonderheit bei Windows 7: Ich muss die Drucker unter "Geräte und Drucker" erst einmal hinzufügen (nur bei der allerersten Installation!). Dies gelingt nur, wenn ich in der Anmeldeinformationsverwaltung Anmeldedaten eingebe, die Zugriff auf die Drucker haben. Nach dem Hinzufügen der Drucker lösche ich die Daten aus der Anmeldeinformationsverwaltung wieder heraus, damit niemand ohne Berechtigung die Drucker nutzen kann. Resultat: Die Drucker erscheinen unter "Geräte und Drucker", können aber ohne Authentifizierung mit Powershell-Skript nicht verwendet werden!  Melde ich mich mit dem Powershell-Skript an, werden die Drucker gemappt und alles ist gut.

     

    Umsetzung NEU:

    Der oben beschriebene Weg funktioniert nicht mehr, wenn die Drucker auf einem Druckserver mit Windows Server 2008 installiert sind. Zwar kann ich die Drucker immer noch mit dem Powershell-Skript mappen, jedoch kann der Student nicht mehr drucken. Versucht er es trotzdem, bekommt er nach der (scheinbar erfolgreichen) Authentifizierung folgende Fehlermeldung (im Beispiel sollte eine Testseite gedruckt werden):

    Die Testseite konnte nicht gedruckt werden. Soll die Druckproblembehandlung angezeigt werden? Der serverseitige Druckspoolerdienst wird nicht ausgeführt. Starten Sie den Spooler auf dem Server neu, oder starten Sie den Servercomputer neu.

     

    Fazit: Das Mapping der Drucker scheint hier nicht mehr auszureichen. Wenn ich dieselben Daten in der Anmeldeinformationsverwaltung hinterlege, die ich im Powershell-Skript verwende, kann ich problemlos drucken. Letzteres ist jedoch nicht gewünscht, da extrem unschöne Fehlerquelle....

    MCITP Server Administrator MCTS 2008R2 Server Virtualization

    • Bearbeitet Coreknabe Montag, 12. Dezember 2011 13:35
    Montag, 12. Dezember 2011 13:33
    |
  • Discussion
    Anmelden
    0
    Anmelden
    Verräts du uns noch das
    Powershell-Skriptes, das nicht anderes macht, als den Kontonamen des Studenten samt Passwort in einem "net use"-Aufruf zu verwursten.
    Inzwischen stelle ich deine Umgebung in einer Testumgebung nach.
    Montag, 12. Dezember 2011 16:11
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Danke Dir,

     

    hier das PS-Skript:

     

    $matnr=Read-Host -Prompt "     Bitte geben Sie Ihre Matrikelnummer ein"
    write-host ""
    $password=Read-Host -Prompt "     Bitte geben Sie Ihr Kennwort ein" -AsSecureString
    write-host ""
    $pwcl=[System.Runtime.InteropServices.marshal]::PtrToStringAuto([System.Runtime.InteropServices.marshal]::SecureStringToBSTR($password))

    #Credentials an Netzwerkdrucker übergeben und verbinden
    net use lpt2: \\SERVER\DRUCKER /user:domaene\$matnr $pwcl /persistent:no

    #Laden benoetigter Bibliotheken fuer Rueckmeldungen
    $bib=""
    $bib=[reflection.assembly]::LoadWithPartialName("System.Windows.Forms")

    #Auswertung Exitcodes und Anzeige Rueckmeldungen
    if ($lastexitcode -eq 0)
    {
        [System.Windows.Forms.Messagebox]::Show("Verbindung OK!
        Die Drucker können jetzt genutzt werden.",("Druckerkonto") )
    }

    else
    {
        [System.Windows.Forms.Messagebox]::Show(" Verbindung fehlgeschlagen!
     
        Haben Sie Matrikelnummer und Passwort korrekt eingegeben?
        Beachten Sie auch den Fehlertext in der Eingabemaske.
        Bitte versuchen Sie es erneut.
        Ggf. melden Sie sich an Windows ab und wieder an.",("Druckerkonto") )
    }

    MCITP Server Administrator MCTS 2008R2 Server Virtualization
    Dienstag, 13. Dezember 2011 09:39
    |
  • Discussion
    Anmelden
    0
    Anmelden

    So, nun habe ich eine Testumgebung aufgebaut:

    • Alle Computer sind Mitglied er selben Domäne.
    • DC: Windows Server 2008 R2 EE SP1
    • DFL 2008 R2
    • Druckserver1: Windows Server 2003 SE SP2 (x86)
    • Druckserver2: Windows Server 2008 R2 EE SP1
    • Client1: Windows 7 Professional x86
    • Client2: Windows 7 Professional x64
    • mittels der Druckverwaltung (printmanagement.msc) wurden auf beiden Druckservern die beiden Drucker OKI C5950 (PCL) (Treiberversion 1.0.7.0) und OKI C8800 (PCL) (Treiberversion 3.1.0.0) installiert, freigegeben, im AD veröffentlicht und mittels einer Gruppenrichtlinie für Benutzer bereitgestellt
    • in den Druckerberechtigungen aller vier Drucker wurde "Jeder" entfernt und die domänenlokale Gruppe "LG darf drucken" mit der Berechtigung "Drucken" hinzugefügt
    • Auf Druckserver1 wurden die x64-, auf Druckserver2 die x86-Treiber hinzugefügt.
    • im AD wurden zwei Benutzer angelegt: "student" und "testuser"
    • "student" ist Mitglied der globalen Gruppe "GG Alle Studenten"
    • "testuser" ist Mitglied der globalen Gruppe "GG Authentifizierte Studenten"
    • "GG Authentifizierte Studenten" ist Mitglied von "LG darf drucken"

    Meldet man sich nun als "testuser" auf einem Client an, werden sofort alle vier Drucker verbunden und es kann erfolgreich auf jeden Drucker gedruckt werden.

    Meldet man sich dagegen als "student" an, stehen keine Drucker zur Verfügung. Sie sind zwar sichtbar, lassen sich aber nicht hinzufügen, wenn der Druckserver unter Windows Server 2008 läuft. Es nützt auch nichts, sich beim Hinzufügen als "testuser" zu authentifizieren. Da "testuser" kein Mitglied der Gruppe "Administratoren" ist, es unter Windows 7 aber nur Administratoren ohne weiteres erlaubt ist, Druckertreiber zu installieren, scheitert es an der Authentifizierung, wenn versucht wird, einen Drucker vom 2008er Druckserver hinzuzufügen. Auch das Ändern der Treiberinstallationssicherheit für über Gruppenrichtlinien bereitgestellte Drucker hilft nicht.

    Bleibt also die Frage, warum meldet sich der Benutzer nicht gleich mit seinem berechtigten Konto an?

    Dienstag, 13. Dezember 2011 10:49
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Erst einmal vielen Dank für Deine Mühe!

     

    Zur Problematik "Drucker hinzufügen". Ganz einfach und funktionierte mit einem 2003-Druckserver auch noch:

    1. Anmelden mit dem rechtlosen Benutzer "student"
    2. Hinzufügen der Anmeldeinformationen in der Anmeldeinformationsverwaltung mit IRGENDEINEM Benutzer, der Zugriffsrechte auf die Drucker hat
    3. Löschen der Anmeldeinformationen aus der Anmeldeinformationsverwaltung
    4. Authentifizierung an den Druckern mittels PS-Skript

    Mit einem 2008-Druckserver funktioniert dieser Weg nicht mehr, weil scheinbar die Windows-Anmeldeinformationen über allem stehen. Umweg, wie schon mehrfach beschrieben: Die Anmeldedaten müssen in die Anmeldeinformationsverwaltung. Will ich aber nicht, wenn's nicht sein muss.

     

    Warum meldet sich der Benutzer nicht gleich mit seinem berechtigten Konto an?

    Ganz einfach, wir haben gut 600 Studenten. Wenn das Drucken über eine direkte Anmeldung erfolgen soll, also über jedes AD-Konto, habe ich zwei Möglichkeiten:

    1. Serverbasierte Profile. Ich muss alle Profile vorhalten, es wird ein saumäßiger, unnötiger Netzwerkverkehr erzeugt und es dauert ewig, bis der Student seinen Desktop sieht. Dann will ich eine Sekretärin, die das Gemecker von mir abhält.
    2. Lokale Profile. Es dauert ewig, bis der Student seinen Desktop sieht, vor allem bei der allerersten Anmeldung mit seiner Kennung an diesem Rechner. Dazu kommt, dass die Rechner mit PC-Wächter geschützt sind. Es werden also alle Änderungen nach einem Neustart verworfen. Resultat: Ich will ne Sekretärin, besser noch nen Bodyguard.

    Was noch erschwerend hinzukommt: Die Software zu Lehrzwecken und Office... Jede Anwendung ist profilgebunden. Spätestens hier haut's mir die Füße weg.

     

    Der Call bei Microsoft ist mittlerweile eröffnet, ich warte noch auf Rückmeldung...

    MCITP Server Administrator MCTS 2008R2 Server Virtualization
    • Bearbeitet Coreknabe Dienstag, 13. Dezember 2011 12:17
    Dienstag, 13. Dezember 2011 12:16
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Am 13.12.2011 schrieb Coreknabe:

    Zur Problematik "Drucker hinzufügen". Ganz einfach und funktionierte mit einem 2003-Druckserver auch noch:

    1. Anmelden mit dem rechtlosen Benutzer "student" 2. Hinzufügen der Anmeldeinformationen in der Anmeldeinformationsverwaltung mit    IRGENDEINEM Benutzer, der Zugriffsrechte auf die Drucker hat
    3. Löschen der Anmeldeinformationen aus der Anmeldeinformationsverwaltung 4. Authentifizierung an den Druckern mittels PS-Skript

    Mit einem 2008-Druckserver funktioniert dieser Weg nicht mehr, weil scheinbar die Windows-Anmeldeinformationen über allem stehen. Umweg, wie schon mehrfach beschrieben: Die Anmeldedaten müssen in die Anmeldeinformationsverwaltung. Will ich aber nicht, wenn's nicht sein muss.

    Wie machen es andere Universitäten?

    Warum meldet sich der Benutzer nicht gleich mit seinem berechtigten Konto an?

    Ganz einfach, wir haben gut 600 Studenten. Wenn das Drucken über eine direkte Anmeldung erfolgen soll, also über jedes AD-Konto, habe ich zwei Möglichkeiten:

    1. Serverbasierte Profile. Ich muss alle Profile vorhalten, es wird ein    saumäßiger, unnötiger Netzwerkverkehr erzeugt und es dauert ewig, bis der    Student seinen Desktop sieht. Dann will ich eine Sekretärin, die das    Gemecker von mir abhält.

    Mit einer Ordnerumleitung hält sich der Netzwerkverkehr in Grenzen.

    2. Lokale Profile. Es dauert ewig, bis der Student seinen Desktop sieht, vor    allem bei der allerersten Anmeldung mit seiner Kennung an diesem Rechner.    Dazu kommt, dass die Rechner mit PC-Wächter geschützt sind. Es werden also    alle Änderungen nach einem Neustart verworfen. Resultat: Ich will ne    Sekretärin, besser noch nen Bodyguard.

    Weshalb soll das ewig dauern bis er seinen Desktop sieht? Lokale
    Profile in Verbindung mit einer Ordnerumleitung reduziert den
    Netzwerkverkehr.

    Was noch erschwerend hinzukommt: Die Software zu Lehrzwecken und Office... Jede Anwendung ist profilgebunden. Spätestens hier haut's mir die Füße weg.

    Ihr werdet sicher nicht die einzigen sein, die diese SW benutzen, wie
    machen das die anderen Universitäten?

    Der Call bei Microsoft ist mittlerweile eröffnet, ich warte noch auf Rückmeldung...

    Es wäre schön wenn Du hier das Ergebnis posten würdest.

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Dienstag, 13. Dezember 2011 12:37
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Ich kann Winfried nur beipflichten. Es ist doch völlig egal, ob sich AD-User1 (student) oder AD-User2 (testuser) anmelden. Was soll das mit Profilen zu tun haben?

    Hier geht es doch um ein Authentifizierungsproblem! Druckerberechtigungen haben nichts mit Profilen, weder mit servergespeicherten noch mit lokalen, zu tun.

    Dienstag, 13. Dezember 2011 16:29
    |
  • Discussion
    Anmelden
    0
    Anmelden

    @mlux: Aha.

     

    @Winfried: Mir ist keine Uni / Hochschule bekannt, die an den Lehrsaal-Rechnern Anmeldungen der Studenten-AD-Konten benutzt. Teils mögen hier selbst gestrickte Lösungen zum Einsatz kommen, denkbar an größeren Unis. Muss aber auch zugeben, dass ich es bisher versäumt habe, entsprechende Kontakte zu knüpfen.

    Was die Ordnerumleitung angeht, wäre das trotz allem eine für mich unschöne Lösung wegen der Vielzahl an Profilordnern. Ich denke, dass der jetzige Weg praktikabler und wenger fehlerbehaftet ist. Was die Zeit angeht, die es dauert, bis der Student den Desktop sieht, das habe ich noch nicht ausprobiert, Microsoft selbst sagt ja, dass "längere Wartezeiten der Vergangenheit angehören", was immer das heißen mag.

     

    Der Microsoft-Support gibt mir innerhalb der nächsten beiden Tage eine Rückmeldung, die ich hier auf jeden Fall noch kundtun werde.

     

     

     

    MCITP Server Administrator MCTS 2008R2 Server Virtualization
    • Bearbeitet Coreknabe Mittwoch, 14. Dezember 2011 10:32
    Mittwoch, 14. Dezember 2011 10:31
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Am 14.12.2011 schrieb Coreknabe:

    @Winfried: Mir ist keine Uni / Hochschule bekannt, die an den Lehrsaal-Rechnern Anmeldungen der Studenten-AD-Konten benutzt. Teils mögen hier selbst gestrickte Lösungen zum Einsatz kommen, denkbar an größeren Unis. Muss aber auch zugeben, dass ich es bisher versäumt habe, entsprechende Kontakte zu knüpfen.

    Ich weiß es nicht, deshalb ja die Frage. Auch kann ich mir nicht
    vorstellen, dass Du der einzigste und erste bist der das so macht.

    Was die Ordnerumleitung angeht, wäre das trotz allem eine für mich unschöne Lösung wegen der Vielzahl an Profilordnern.

    Wieviele Ordner willst/mußt Du umleiten? 10, 20 oder 100?

    Ich denke, dass der jetzige Weg praktikabler und wenger fehlerbehaftet ist. Was die Zeit angeht, die es dauert, bis der Student den Desktop sieht, das habe ich noch nicht ausprobiert, Microsoft selbst sagt ja, dass "längere Wartezeiten der Vergangenheit angehören", was immer das heißen mag.

    Ich finde es einfach unfair hier von "dauert ewig" zu sprechen ohne es
    selbst ausprobiert zu haben. Solange Du nicht ein 1 Mbit Netzwerk
    hast, wirst Du vermutlich gar keinen Unterschied feststellen. Wie
    auch? Die Ordnerverknüpfung auf dem Desktop ist doch nur eine
    Verknüpfung wie jede andere auch.

    Der Microsoft-Support gibt mir innerhalb der nächsten beiden Tage eine Rückmeldung, die ich hier auf jeden Fall noch kundtun werde.

    Gut.

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Mittwoch, 14. Dezember 2011 20:07
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hi Winfried,

     

    zu Deinem Posting...

     

    Es müssten über 600 Ordner umgeleitet werden. Bei der üblichen Fluktuation der Studenten ist die Umleitung aus meiner Sicht sehr unschön. Wenn ich ein großes Unternehmen mit entsprechender Anzahl von Mitarbeitern habe, mag das was anderes sein. Du hast recht, ich habe behauptet, es "dauert ewig". Ob das deshalb jetzt von mir "unfair" ist, sowas zu behaupten, ohne es getestet haben, sei jetzt mal dahingestellt. Microsoft trifft so eine Behauptung sicher hart ;-)  Fakt: Siehe oben, Microsoft war sich der alten Problematik mit der Wartezeit (und nur die kenne ich aus der Praxis) bewusst, deshalb heisst es in einem Buch von MS Press (Windows Server 2008 R2 - Das Handbuch) auch: "längere Wartezeiten gehören der Vergangenheit an". Mag sich geändert haben oder nicht, für mich ist dieser Weg eh unpraktikabel.

     

    Dann habe ich eine Antwort von Microsoft bekommen. Der Support kann sich dieses Verhalten nicht erklären. Das deutet für mich auf einen Bug hin, der bisher niemanden interessiert / den niemand bemerkt hat. Es kann aber auch sein, dass dieses Verhalten erwünscht und Teil eines Sicherheitsmechanismus ist. Es ist unklar und müsste weiter analysiert werden. Problem dabei: Wenn es kein Bug ist, kostet es verständlicherweise Geld. Weiteres und größeres Problem: Die Analyse kostet Zeit, die ich nicht habe. Ich bekomme vom Support jetzt noch alle Hotfixe, die für Printserver erhältlich sind. Stellt sich heraus, dass einer der Hotfixe das Problem löst, werde ich hier noch einmal etwas dazu posten.

     

    Meine Lösung:

    Wir haben die Software Papercut entdeckt und werden diese wohl auch kaufen. Neben der komfortablen Druckerkontenverwaltung bietet diese Software auch die Möglichkeit, mein Problem zu umgehen. Es wird ein eigener Druckerport angelegt, der Benutzer "student" muss nach wie vor Zugriff auf den entsprechenden Netzwerkdrucker haben. Soll der Drucker nun von einem Client angesteuert werden, der mit dem Standardbenutzer "student" angemeldet ist, schaltet sich Papercut auf den Port und verlangt trotzdem Authentifizierungsdaten der Studenten. Klappt einwandfrei.

     

    Eine weitere Möglichkeit wäre es, wie oben schon beschrieben, die Anmeldedaten mit dem Powershellskript in die Anmeldeverwaltung zu schreiben. Auch das funktioniert einwandfrei. Problem dabei: Fehlerquellen. So müssen wir bei der Rechnerinstallation / -konfiguration immer daran denken, die Anmeldedaten wieder zu löschen, wenn wir sie benutzt haben. Und: Meldet sich der Student am PC einfach nur ab, verbleiben die Anmeldedaten in der Verwaltung, da PC-Wächter die Änderungen nur nach einem Neustart des PCs zurücksetzt.

     

    Das soll es gewesen sein, ich schließe diesen Thread hiermit. Ggf. melde ich mich hier wieder, wenn ein Hotfix etwas ändern sollte. Danke Euch für die Hilfe und Mühe!

     

    MCITP Server Administrator MCTS 2008R2 Server Virtualization
    Freitag, 16. Dezember 2011 13:52
    |