kirschi68

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 .

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. 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

Moin, hat keiner eine Idee? Es betrifft übrigens fast alle Aufgaben, also auch die, welche nicht von mir erstellt wurden. Sie befinden sich in der Warteschlange und werden nicht ausgeführt. Kann man die Aufgabenplanung "reparieren"? Gruß Andreas

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?

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

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.

Vielen Dank, auch anderweitig eine sehr hilfreiche Seite.

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

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.

Für alle, die hier immer noch mit dem Problem kämpfen (bei einer Kollegin verstellt es fast täglich den Standarddrucker): ein erster Test nach dieser Prozedur (Beitrag von Scott798) war erfolgreich.

Wohl zu früh gefreut, das mit dem Prescribe funktionierte nur einen Tag.

Danke an alle, meine beiden Probleme von oben scheinen seit dem Abarbeiten dieses Threads gelöst.

Wurde das Problem gelöst? Sonst ggf. hiernach http://wu.krelay.de/ vorgehen (Updatecache leeren, neuesten WU-Client downloaden, updaten) Gruß Andreas

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: verschwindende Standard-Drucker und das teilweise Fehlen der Drucker bei den Benutzern (im Word aber da) 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

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

Nein, ich meinte eine "richtige", synchrone Leitung. 10MBit Up- und Download. 0,05MBit x 40 Benutzer = 2 MBit, wir hatten zur "Sicherheit" die nächsthöhere Leitung, also 5 MBit genommen. Im Durchschnitt war die Leitung zu 40% ausgelastet. In Spitzenzeiten ist das aber wegen des Fileservices zuwenig. Deshalb jetzt 10MBit. Gruß Andreas

Hallo, ich glaube es waren 50k je Sitzung. Bei uns hat sich diese Rechnung aber als zu knapp erwiesen, wir hatten 5 MBit CompanyConnect. Nun haben wir die Standorte (je 40 User) mit 10MBit CC verbunden. Haben aber VM-Ware und Citrix im Einsatz, große Dokumente (pdf, ppt, jpg) auf dem Fileserver haben hier die Probleme verursacht. Gruß Andreas

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

Hallo, danke, ihr habt Recht, wenn man den Link von mir auf englisch umstellt, steht Iterims-Update, auf deutsch lautet es: Das ist schon etwas verwirrend. Gruß Andreas

Mahlzeit, in der Beschreibung zum UR6 steht, man solle alle vorher installierten Updates entfernen :confused:. Habt ihr das gemacht? Gruß Andreas

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

Hallo, so wie es aussieht, existiert noch ein weiterer Eintrag, ich vermute mal, einer für die Karte und dann an anderer Stelle die Ports. Ich benutze gerne das hier, um alte Einträge zu entfernen. Gruß Andreas

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

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

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.