Jump to content

kirschi68

Members
  • Gesamte Inhalte

    134
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von kirschi68

  1. Die Antwort aus dem Link hat bei mir geholfen. Von einem intakten RDS habe ich den Zweig
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications
    exportiert, auf der Problemmaschine gesichert, gelöscht und importiert. Danach Neustart und die Aufgabenplanung funktioniert wieder.  Danke für Eure Begleitung, nun kann es in den Urlaub gehen :-).

     

  2. Aufgabe neu erstellt habe ich auch schon. Es ist der einzige Server der zickt.

    In der Ereignisanzeige gibt es die Warnungen mit Event 325, wie in der Aufgabenplanung selber.
    Unbenannt.png.a452c22b67337ce6e889b01f884486bb.png

    Die Instanz "{xxxx}" der Aufgabe "\Microsoft\Windows\Shell\CreateObjectTask" wurde von der Aufgabenplanung in die Warteschlange eingereiht.

    Eine Sache habe ich heute gefunden, die werde ich am Abend probieren:

    https://serverfault.com/questions/1051464/all-tasks-in-task-scheduler-are-going-to-queued-state-when-triggered
     

  3. Hallo zusammen,

    bei unseren Servern führe ich eine Batch per Aufgabenplanung bei Anmeldung aus, diese aktualisiert bginfo am Bildschirm. Die Aufgabe habe ich exportiert und seit Jahren bei neuen Servern importiert und sie läuft auf allen ca. 20 Servern (2008R2 bis 2019), mit einer Ausnahmen: ein RDS 2019. Ich kann die Aufgabe per Rechtsklick ausführen, dann läuft sie. Startet sie per Trigger, dann wird die Aufgabe in die Warteschlange eingereiht, weiter passiert nichts.

    Letzter Status: TaskScheduler, Ereignis 325, Startanforderung in Warteschlange eingereiht. Auf einem weiteren RDS 2019 läuft die Aufgabe auch.

    Habt ihr eine Idee, was ich hier tun kann, außer den Server neu aufsetzen?

  4. Hallo zusammen,

     

    unser WSUS aktualisiert keine Statusberichte mehr von meinen verbliebenen 2 XP-Clients, wenn Office 2007 mit SP3 installiert ist. Letzter Kontaktzeitpunkt ist aktuell. Im Windowsupdatelog steht, daß der Client den Bericht erfolgreich hochgeladen hat, offenbar wird der aber vom WSUS nicht verarbeitet. Deinstalliere ich Office, werden die Statusberichte wieder korrekt verarbeitet und in der MMC angezeigt. Auch ein Office 2007 ohne SP3 zeigt normales Verhalten, erst mit SP3 kommen die Probleme, vermutlich in Zusammenhang mit einem der außerplanmäßgen Updates für XP dieses Jahr.

    Habt ihr das bei euch auch beobachten können? Als Lösung bleibt wohl nur der Wechsel auf Office 2010 (SP2).

    Gruß

    Andreas

  5. Probier es doch mal mit:

    %Logonserver%\Netlogon\con2prt.exe /f
    %Logonserver%\Netlogon\con2prt.exe /c "\\printerserver\printername"
    %Logonserver%\Netlogon\con2prt.exe /cd "\\printerserver\printername2"
    

    /f = löschen

    /c= zuweisen

    /cd= Standarddrucker

     

    Wir haben zumindest keine verschwindenden Standarddrucker mehr (Lösch-Script auf den TS). Nun mein Prescribe-Problem ist noch da.

  6. Hallo,

    da unser WSUS heute unerklärlicherweise alte UR als neu gefunden hat, prüfte ich mal den Versionsstand und war überrascht, 2 unterschiedliche Angaben zu erhalten.

    In der Verwaltungsshell mittels

    Get-ExchangeServer | ft Name,ExchangeVersion,AdminDisplayVersion
    

    Version 14.3 (Build 123.4) = 2010 SP3 ohne jegliches UR ...

    und über die Verwaltungskonsole 14.03.0319.002 = 2010 SP3UR15

     

    Welche Angabe ist nun richtig? Warum schlägt der WSUS ausgerechnet heute UR 9 - UR11 vor (klar, anderes Thema), wenn doch schon viele Wochen das UR15 installiert sein sollte?

     

    Gruß

    Andreas

  7. blöde Frage: Windows Firewall-Dienst testweise mal deaktivert?

     

    Bei mir hakte mal die Treiberinstallation wegen fehlender GPO-Einstellung: GPO -> Computerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Drucker -> Richtlinie "Point-and-Print-Einschränkungen" aktiviert ohne Benachrichtigungen.

    Wir verwenden allerdings herstellerspez. Treiber und klassiches Mapping über Loginscript via con2prt.exe.

  8. Hallo Leute,

    unser System:

    • 2012R2 Printerserver
    • 2012R2 Terminalserverfarm (2 Server)
    • Kyocera-Drucker mittels Loginscript eingebunden ala %Logonserver%\Netlogon\con2prt.exe /c "\\mgmt\K3920-G"
    • großteils IGEL, teilweise PC als Client

    2 Probleme:

    1. verschwindende Standard-Drucker und das teilweise Fehlen der Drucker bei den Benutzern (im Word aber da)
    2. Problem mit Kyocera Prescribe: Drucker eingebunden wie oben genannt, sowohl beim Benutzer mit PC als auch beim Login über den Terminalserver. Wir benötigen die Kyocera Prescribe-Sprache, um aus verschiedenen Schächten Kopien unserer Dokumente zu drucken. Das klappt auch soweit vom PC aus. Die Prescribe-Kommandos werden aber komplett ignoriert, wenn derselbe Benutzer am TS angemeldet ist und auf demselben Drucker dasselbe Dokument druckt. Nur Office-Dokumente und unser NAV sind betroffen. PDF und aus dem Editor heraus kann ich problemlos mit Prescribe mein Original + automatische Kopie drucken. Ebenso kommt die Testseite vom Printserver mit Kopie.

     

    zum Problem 1 bezüglich Verzeichnisfreigabe für system32\spooler. Mach ich das auf den Terminalservern oder/und dem Printerserver?

     

    Zum Problem 2: habt ihr eine Idee? Office Einstellungen scheinen gleich, GPO-Einstellungen wirken ebenso auf TS-Benutzer und PC-Benutzer (andere Richtlinien aber gleicher Inhalt, was Office betrifft)

     

    Gruß

    Andreas

  9. Hallo nochmal,

     

    keiner eine Idee?

    Hab den Pool folgendermaßen eingerichtet:

    die Anschlüsse wurden angelegt als Standard-TCP/IP

    Drucker hinzufügen -> lokaler Drucker -> ersten Anschluß ausgewählt

    Treiber ausgewählt ... fertig stellen

    eben erstellten Drucker auswählen -> Eigenschaften -> Anschlüsse Haken rein bei Druckerpool und den 2. Anschluß angehakt.

    Protokoll der Anschlüsse: RAW, SNMP nicht aktiviert

    Stell ich mich zu doof an?

    Gruß

    Andreas

  10. Hallo,

     

    habe aus 2 Kyocera 1920 über integrierten IB-21 einen Druckerpool gebildet und wollte diesen jetzt testen, indem ich einen Ausdruck mache und jeweils einen der beiden Drucker dabei ausgeschaltet lasse. Das funktioniert so aber nicht.

    KX und PCL-Treiber probiert, einzelne Drucker drucken auch, aber wenn ich den Pool mit 2 IP-Adressen bilde, dann druckt nur einer der beiden Drucker. Wenn ich den anderen einschalte und drucke passiert nichts, Dokument bleibt in der Warteschlange.

    Habt ihr für mich Tipps zur Fehlersuche? Server läuft unter VMWare 4.1.

     

    Gruß

    Andreas

  11. Guten Morgen Markus,

     

    mit der Testseite meinte ich die Windows-Testseite. Auf den funktionierenden Clients wird beim Ausdruck der Testseite durch die Prescribe-Befehle aus beiden Schächten die Testseite gedruckt.

    Worüber ich gestern Abend noch gestaunt habe ist: wenn ich den Pfad zu den Prescribe-Steuerdateien im Windows-Explorer des Problemclients aufrufe und erst dann den Drucker verbinde, klappt das. Konnte das aber bis jetzt nicht verifizieren.

    Das würde aber für Deinen Vorschlag sprechen, die Dateien grundsätzlich im Drucker zu speichern. Danke für den Tipp!

     

    Gruß

    Andreas

  12. Hallo zusammen,

     

    bei uns gibt es immer wieder mal das Problem, daß einige Clients die per Prescribe zugewiesenen Kommandos ignorieren.

     

    W2K3 Server als Printserver, 2K8 DC, XP-Clients, Kyo KX-Treiber, PCL5, versucht die Drucker sowohl per "Drucker hinzufügen" als auch per con2prt im Loginscript zu verbinden. Beim Verbinden keine Fehlermeldungen, wie Zugriff verweigert o.ä.

     

    Kyocera FS1920, der mittels Prescribe ein Dokument aus 2 Fächern drucken soll (also 2 Seiten). Richte ich den Drucker auf dem Server ein und drucke die Testseite, klappt das (2 Testseiten werden gedruckt). Auch auf einem weiteren Client. Auf anderen Clients druckt er zwar die Testseite aber er ignoriert das Prescribe, es wird also nur eine Seite ausgedruckt. Diese Prescribe-Steuerdateien liegen auf einer Freigabe und auf die können die Clients auch zugreifen. Alle PCs in der Domäne/OU, eigentlich gleiche Voraussetzungen.

    Bereits gemacht: Drucker auf dem Server gelöscht, neu erstellt, Benutzerkonto des Clients gelöscht, lokal die Treiber deinstalliert (Drucker > Servereigenschaften...) und neu verbunden. Komischerweise klappt das nicht mal als Admin in jedem Fall.

    Habt ihr Ideen, was ich hier noch machen könnte?

     

    Gruß

    Andreas

  13. Hallo,

     

    wir haben von SBS 2003 auf dedizierte Server migriert und betreiben jetzt einen Exchange 2010 mit Outlook 2003/2007 Clients.

     

    Früher war es möglich, einen beliebigen Termin aus einem öffentlichen Kalender mit Hilfe der Schaltfläche "in Persönlichen Kalender kopieren" in den persönlichen Kalender zu übertragen. Der Versuch wird jetzt mit einer Zugriffsverweigerung quittiert:

    Sie besitzen nicht das erforderliche Recht, um diesen Vorgang auszuführen. Wenden Sie sich an die Kontaktperson dieses Ordners oder an Ihren Administrator.

    Es ist nur noch möglich, selbst erstellte Termine auf diese Art zu kopieren.

    Die Rechte sind, soweit der Vergleich überhaupt zulässig ist, gleich gesetzt (betreffende OU Stufe 4 bzw. Autor).

    Habt ihr eine Idee, wie ich diesem Rechteproblem auch die Schliche komme, ohne jedem die volle Berechtigung auf den ÖO zu geben?

     

    Gruß

    Andreas

  14. Nachdem ich mich heute den halben Tag mit diesem Update gequält habe, möchte ich euch meine Vorgehensweise schildern:

     

    Download (nach)

    D:\Software\Adobereader940\AdbeRdr940_de_DE.exe

    D:\Software\Adobereader940\AdbeRdr940_de_DE.msi

    D:\Software\Adobereader942\AdbeRdrUpd942_all_incr.msp

    D:\Software\Adobereader943\AdbeRdrUpd943_all_incr.msp

     


    msiexec /a D:\Software\adobereader940\AdbeRdr940_de_DE.msi


    „installieren“ nach D:\Software\adobereader943neu\

     


    • Patchen des Paketes
    msiexec /a D:\Software\adobereader943neu\AdbeRdr940_de_DE.msi /p D:\Software\adobereader942\AdbeRdrUpd942_all_incr.msp


     
    Netzwerkspeicherort: D:\Software\adobereader943neu\

     


    msiexec /a D:\Software\adobereader943neu\AdbeRdr940_de_DE.msi /p D:\Software\adobereader943\AdbeRdrUpd943_all_incr.msp


     
    Netzwerkspeicherort: D:\Software\adobereader943neu\

     


    • Damit wir später mit Hilfe des Adobe Customization Wizard die Installation voranpassen können, brauchen wir die setup.ini…
      Entpacken der AdbeRdr940_de_DE.exe
    D:\Software\adobereader940\AdbeRdr940_de_DE.exe -nos_ne -nos_o"D:\Software\Adobereader943neu"


    Die Data1.cab und die AcroRead.msi löschen
    Jetzt existiert im Ordner D:\Software\adobereader943neu folgender Inhalt:
    <DIR> Common
    <DIR> CommonAppData
    <DIR> program files
    <DIR> Windows
    abcpy.ini
    AdbeRdr940_de_DE.msi
    Setup.exe
    setup.ini

     


    • Nun kann man seine msi mit dem Adobe Customization Wizard anpassen, z.B. die Registryeinträge zum Aufruf von Adobe ARM etc. entfernen und den ganzen Update- und Onlinequark, den Inhalt des Ordners dann verteilen.

×
×
  • Neu erstellen...