elzag

Der trägt den Namen "Router", leider. :(

Hallo, der Remotedesktoplizenzierungs-Manager auf einem "Win Server 2008 R2" zeigt mir unter "Windows Server 2008 oder Windows Server 2008 R2: Installierte Client Zugriffslizenzen vom Typ "Pro Gerät" für Terminaldienste oder Remote..." immer die ursprünglichen Computernamen an, auch wenn diese geändert werden. Selbst wenn eine Lizenz gesperrt wurde, die Sperre abgelaufen ist und man das Gerät neu einbindet, wird es immer mit dem Namen angezeigt, mit dem es beim ersten mal Verbunden wurde. Leider hat man in dieser Umgebung nicht wirklich darauf geachtet das ein sauberes Namenskonzept besteht, sondern teils die Rechner einfach eingebunden mit dem Namen den sie bei Auslieferung hatten. Zumindest hab ich da jetzt mehr als einen "User-PC" in der Lizenz-Liste. Weitere Angaben als den PC-Namen (Spalte "Ausgestellt für" im Lizenzierungs-Manager) konnte ich nicht ausfindig machen. Wäre z.Bsp die Mac-Adresse ersichtlich könnte ich das Gerät ja auch eindeutig ermitteln. Zusätzlich kommt, das man genau so viele "pro Gerät"-Lizenzen hat, wie effektiv benötigt werden. Muss ich jetzt einen "User-PC" ersetzen, so kann ich diesen nicht mit dem TS verbinden bevor ich eine alte Lizenz gesperrt habe. Aber ich kann nicht eindeutig erkennen welche Lizenz im Remotedesktoplizenzierungs-Manager gesperrt werden muss, da ich keine eindeutige Kennung habe. Mir gehen zwei Möglichkeiten durch den Kopf um das Problem in den Griff zu kriegen, leider bis jetzt beide erfolglos: - mehr Details zum Lizenzierten Gerät finden - im Remotedesktoplizenzierungs-Manager den aktuellen Gerätenamen angezeigt bekommen Kennt jemand für eine der zwei Vorschläge die Lösung? Details zum Server: - Windows Server 2008 R2 (physisch, nicht virtuell) - kein AD, nur lokale Benutzer - Terminalserverdienste installiert - Terminalserver-Lizenzierung "pro Gerät" Details zu den Clients: - "Normale" PC's - Windows-Betriebssysteme in unterschiedlichen Versionen (XP, 7, 10), jeweils mindestens "Pro" - Verbindung zum TS via Standard MS-Programm "Remotedesktopverbindung" Danke, elzag

Hallo zusammen, wir nehmen gerade einen neuen Plotter in Betrieb und nun kommen da ein paar generelle Fragen zu Windows Druckertreibern auf. Falls jemand eine Quelle kennt wo der Windows-Druckdienst gut beschrieben wird würd' ich mir das gerne mal durchlesen. Zum einen stellt sich die Frage wozu die Formulare bei den Druckservereingenschaften sind. Ich bin davon ausgegangen das ich bei den Formularen Papier-Abmessungen definieren kann und die dann in jedem Druckertreiber zur Verfügung stehen. Dort sind etliche Formulare definiert, im Druckertreiber des Plotters erscheinen aber andere "Papierdimensionen" mit anderen Namen zur Auswahl. Für mich scheint es, als ob der Plotter-Treiber die Formulare selber verwaltet und keine Windows-Formulare anzeigt. Kann das sein? Oder sind diese Formulare für etwas komplett anderes? Dann kann man den Drucker ja auch mit der rechten Maustaste auswählen und den Menüpunkt "Druckereigenschaften" selektieren. Dort hat man ein Fenster welches "verfügbares Papier" anzeigt. Beim Plotter steht da einfach nur A4. Auch beim alten Plotter steht dort nur "ISO A4". Trotzdem interessiert mich jetzt wo diese Information Auswirkungen hat. Gruss, elzag

Es ist weniger so das die Umstellung übers Weekend beim Chef gut ankommt als vielmehr das es schlecht ankommt wenn der Betrieb steht. Und wenns am Samstag nicht reicht arbeitet man am So mit 100% Zeitzuschlag :D

Vielen Dank für deine rasche Antwort. Das die Client-Rechner zur neuen Domäne hinzugefügt und die Benutzerkonten und Gruppen (Serverseitig im AD sowie die Client-seitigen Profile) komplett neu eingerichtet werden müssen ist mir bewusst. Ich denke für die ca. 30 Clients sollte ein Weekend ausreichen. Da ich aber sowieso das bisherige "Sicherheits-Gebastel" durch ein richtiges Sicherheitskonzept ablösen will und in diesem Zuge ebenfalls eine neue Ordnerhirarchie für die Datenablage erstellen werde, habe ich da so oder so einiges zu tun. Die Anwendungen auf dem betroffenen Server (sind zum Glück nur zwei, Buchhaltung und Anti-Virus) werde ich nach Rücksprache mit den Herstellern der Einfachheit halber vermutlich vor der Herabstufung deinstallieren und nach dem hinzufügen in die neue Domäne wieder neu installieren. Damit sollten die von dir erwähnten Probleme nicht auftreten. Danke für den Tipp. Anleitungen zum Wiederherstellen der Default-GPOs hab ich vor einiger Zeit schon mal ein paar durchgespielt, leider alle ohne Erfolg. Das ist eben ein weiterer Grund für die neue Domäne.

Mit geht es dabei hauptsachlich darum das all die "verbastelten" (da wurden unter anderem die Default-Richtlinien so verbastelt das ich den "original"-Zustand nicht wiederherstellen konnte) und undokumentierten Einstellungen in den Gruppenrichtlinien der aktuellen Domäne weg sind und ich ein "sauberes" AD habe. Unter anderem war da z.Bsp. auch mal ein Exchange in Betrieb welcher aber inzwischen nicht mehr benötigt wird. Der wurde zwar "normal" deinstalliert, trotzdem werde ich bei jedem löschen eines Users oder einer Gruppe jedesmal gefragt ob ich die dazugehörigen Postfächer auch entfernen möchte. Entweder flicke ich da nun lange rum und habe trotzdem noch eine "alte" Umgebung oder ich mach da mal was "ganz neues". Wieso denkst du das es nicht klappt? Siehst du ein konkretes Problem oder spricht da die Erfahrung (die mir leider fehlt) aus dir? mfG, elzag

Hallo zusammen, bin gerade einen neuen 2008R2-Server am einrichten und werde damit gleich eine komplett neue Domäne erstellen. Situation ist folgende: Bestehend sind zwei Windows Server 2003 Standard-Server, beide funktionieren als Domänencontroller. Einer der beiden, Server1, ist Domänencontroller und so alt (bzw. Leistungsschwach) das er komplett abgelöst wird. Server2 ist in der gleichen (alten) Domäne ebenfalls als Domänencontroller aktiv. Nun installiere ich einen Windows Server 2008 R2 Standard welcher als DC der neuen Domäne funktionieren soll. Den alten Server2 möchte ich aufgrund der dort installierten Anwendungen noch weiter in Betrieb lassen, muss ihn dazu aber natürlich in die neue Domäne "übergeben". Kann ich den alten 2003er ganz normal mit dcpromo aus der alten Domäne entfernen und dann als Member-Server der neuen (2008 R2-er) Domäne hinzufügen oder stellt das ein Problem dar? Meines Wissens laufen auf diesem keine Dienste (mehr) welche das AD erweitern / benötigen (wie z.Bsp. Exchange) mfG, elzag

Dachte auch das ich nicht der einzige sein kann bei dem dieses Problem auf praktisch jedem Rechner (mit mehreren Usern) vorkommt, habe aber keine weiteren betroffenen im WWW gefunden. Deshalb schliesse ich eine "spezielle" Richtlinie in unserer Domäne nicht aus. Habe zwar keinen gezielten Verdacht, aber die Domäne hab ich auch nur übernommen und nicht von grund auf selber konfiguriert. Google hat mir leider nicht mehr geholfen als ihr im Link zu den Google-Chrome-Hilfeforen welchen ich im ersten Beitrag dieses Threads gepostet habe, nachlesen könnt. mfG, elzag

Nach diversen Tests kann ich mitteilen dass das Problem nicht mehr auftritt sobald die "Geplanten Tasks" deaktiviert / gelöscht sind. Die Google-Software wird sich so vermutlich nicht mehr automatisch aktualisieren, aber für uns ist dass das kleinere Übel. mfG, elzag

Aber genau das ist der Fall. Auch wenn er seit dem letzten PC-Neustart noch nie angemeldet war, wird die NTUSER.DAT oft gesperrt. Es reicht wenn "irgendjemand" an einem der betroffenen Rechner angemeldet war. Wenn sich danach der nächste einloggen will erhält er die am Thread-Anfang erwähnte Fehlermeldung. Da hast du recht, die Google Update Services werden mit installiert. Bei der Installation hab ich dem Updater allerdings mitgeteilt das ich Updates nur manuell ausführen möchte. Ich hab das jetzt nochmals kontrolliert und gesehen das die Dienste eigentlich auch nicht ausgeführt werden. Habe den Updater jetzt aber mal deinstalliert und die (trotzdem noch vorhandenen) Dienste komplett deaktiviert. Die möchten noch ganz viel mehr installieren wenn man sich ein "Google Pack" zusammenstellen will, bald wird bei der Installation von Google Software vermutlich die primäre Festplatte formatiert und ChromeOS installiert wenn der entsprechende Hacken nicht entfernt wird ;) Aber ich bin mir sicher das in meinem Pack kein zusätzlicher Anti-Virus war. Den Autostart hab ich schon mal gecheckt, aber noch nicht mit Sysinternals Autoruns. Das werd ich noch machen. Und den Process Explorer hab ich im temporären Profil noch nicht gestartet, da schau ich auch mal noch nach. Bei uns ist ein Norman Endpoint Protection [1] im Einsatz. Und das schon seit eh und jeh. Aber es kann natürlich nicht ausgeschlossen werden das ein Update von diesem das Problem ins Haus brachte. Vielen Dank schon mal für deine wertvollen Tipps. [1] Endpoint Protection | Norman — Proactive IT security

Google-Dienste laufen bei uns keine, "Google Apps for Business" wird komplett via Webbrowser bedient. Der einzige zusätzliche "Dienst" den wir dazu verwenden ist der Webbrowser Chrome da man mit diesem den Komfort ein bisschen erweitern kann. Aber auch wenn man explizit darauf achtet das Chrome (und auch alle anderen Programme) geschlossen sind tritt der Fehler trotzdem auf. Die Meldung mit der "gesperrten" NTUSER.DAT kannte ich bis anhin noch nicht, im Normalfall sollte man sich ja ohne Probleme als Benutzer A abmelden und als Benutzer B wieder anmelden können ohne das ein Neustart zwingend wird.

Hallo miteinander, wir haben nun schon länger ein Problem mit "gesperrten" Dateien wenn sich ein Benutzer auf einem Rechner anmelden will auf welchem zuvor ein anderer Benutzer angemeldet war. Ich bin mir eigentlich sicher dass das Problem von Google Chrome verursacht wird und habe desshalb auch schon ein Beitrag im Google Hilfeforum geschrieben [1]. Leider konnte man mir dort auch (noch) nicht weiterhelfen, desshalb mache ich von diesem Beitrag mal ein Copy/Paste und erweitere den Text noch ein bisschen: Wir sind vor wenigen Monaten komplett auf Google Apps for Business umgestiegen. Damit unsere Nutzer den maximalen Komfort geniessen können, habe ich auf allen Rechnern ein Google-Pack installiert welches Google Chrome und die Google Apps (was nur ein paar Links sind die Chrome mit speziellen Parametern aufrufen) beinhaltet. Seit ich dieses Google-Pack installiert habe, haben wir auf allen Rechnern welche von mehreren Domänenbenutzern verwendet werden, das Problem dass Domänen-Profile (die Profile sind lokal gespeichert, aber es sind Profile für Benutzer aus der Domäne) oft nicht geladen werden können. Das heisst, am Morgen kommt Mitarbeiter A und meldet sich am Rechner an, erledigt kurz seine Mails und Pendenzen, meldet sich dann ab und ist den Rest des Tages ausser Haus unterwegs. Nun kommt am späteren Morgen noch Mitarbeiter B und meldet sich am selben Rechner an wie zuvor Mitarbeiter A. B erhält mit grosser Wahrscheinlichkeit eine Meldung das sein Profil nicht korrekt geladen werden konnte und ein "leeres" alternativ-Profil geladen wird. Das ist dann auch so, es wird ein neues, temporäres Profil erstellt / geladen. Die einzige Möglichkeit, dieses Problem zu umgehen ist anstelle von ab/anmelden ein Neustart durchzuführen. Ich vermute, das Chrome einige Dateien nicht korrekt freigibt wenn sich ein Benutzer abmeldet, da Chrome ja so einiges ins Profil speichert (sonst könnten meine Domänen-User welche lokal keine Administratoren sind auch kein Update von Chrome durchführen) (wie erwähnt, das sind bis jetzt alles Vermutungen). Von Microsoft habe ich das Tool "User Profile Hive Cleanup Service" [2] gefunden und installiert. Leider hat das keine Abhilfe gebracht. Inzwischen kann ich euch auch noch mitteilen, das nach einer fehlgeschlagenen Anmeldung in der Ereignisanzeige die Quelle "Userenv" immer die vier Fehler-IDs 1508, 1502, 1515 und 1511 ausgibt (in dieser Reihenfolge). Der erste Eintrag, also der mit der ID 1508 gibt eine Meldung aus das die Datei C:\Dokumente und Einstellungen\Benutzername\ntuser.dat bereits von einem anderen Prozess verwendet wird und desshalb nicht geöffnet werden kann. Interessant finde ich dabei, das die Benutzerbezogene Registry-Datei (..\Benutzername\ntuser.dat) gesperrt ist obwohl dieser Benutzer in der Regel seit dem letzten Neustart nie am betroffenen Rechner angemeldet war. Die anderen Meldungen sind sehr "universal", also nur Hinweise darauf dass das Profil nicht geladen werden konnte und ein temporäres Profil verwendet wird. Das bestätigt mir auch Eventid [3]. Zusätzlich macht uns das Tool "runas" ebenfalls Probleme seit Google Chrome (Programme die sich nur darüber starten lassen funktionieren sporadisch nicht -> ein Neustart behebt das Problem), ich vermute dass das Problem das gleiche ist, runas also Probleme hat, das andere Profil zu laden. Habt ihr noch einen weiteren Tipp? Betriebssystem ist übrigens auf allen PCs Windows XP Pro (32-bit). [1] Chrome verursacht das Windows-Profil nicht geladen werden kann - Google Chrome-Hilfe [2] Download Details - Microsoft Download Center - User Profile Hive Cleanup Service [3] Troubleshooting Microsoft Windows Event Logs mfG, elzag

Hmmm, nun hat sich das Problem fast wie von alleine gelöst...? Und zwar dachte ich, das ev. neue "brauchbare" Einträge in der Ereignisanzeige aufgelistet werden, wenn ich zuerst auf dem Server und dann auf dem Client ein "gpupdate /force" ausführe. Fehler in der Ereignisanzeige wurden allerdings keine gelistet, dafür zeigte aber auch der "Gruppenrichtlinienergebnissatz" keine Fehler mehr an. Und siehe da, nach einem Neustart läuft alles tadellos, auch das Startscript wird korrekt geladen...?! Ich war eigentlich der Meinung das die GPO's regelmässig neu geladen werden (mindestens bei jedem Neustart komplett, und dann in regelmässigen Abständen die Änderungen), anscheinend macht aber "gpupdate /force" doch noch etwas mehr. Danke euch allen. mfG, elzag

Hallo Kraftzwerg, vielen Dank für diesen Tipp. Musste mich zuerst mal schlau machen was "Gruppenrichtlinienergebnissatz" ist, habe ich noch nie gebraucht (bis jetzt lief auch alles mehr oder weniger ;)) Wenn ich den "Ergebnissatz" anschaue, habe ich auf betroffenem Rechner unter "User Configuration Summaryhide / Component Status" tatsächlich Fehlermeldungen die folgendermassen ausschauen: ------ Registrierung: Registrierung failed due to the error listed below. Unbekannter Fehler Additional information may have been logged. Review the Policy Events tab in the console or the application event log for events between 04.11.2009 17:58:20 and 04.11.2009 17:58:20. ------- ------- Skripts: Skripts failed due to the error listed below. Das Handle ist ungültig. Additional information may have been logged. Review the Policy Events tab in the console or the application event log for events between 04.11.2009 17:58:20 and 04.11.2009 17:58:20. ------- Leider habe ich die Events der Übersicht halber mal gelöscht, die in den Fehlern erwähnten Events sind dementsprechend nicht mehr vorhanden. Ich werde dann wohl oder übel mal weitergoogeln. Für Tipps bin ich natürlich weiterhin dankbar ;) mfG, elzag

@olc: aufgrund dessen, das der betroffene Benutzer an anderen Rechnern korrekt angemeldet wird (mit abarbeiten des Skripts), sowie andere Benutzer am betroffenen Rechner korrekt angemeldet werden, und alle "Standard-Benutzer" die gleichen GPO's nutzen, schliesse ich ein GPO-Rechte-Problem aus. Naja, ich werde trotzdem noch ein "Debugging" "einbauen", aber verm. wird mir bereits ein "echo skriptstart >> \\netzlaufwerk\skriptsart.txt" sagen das das Skript nicht ausgeführt wird. Sollte wieder meinen Erwartungen ein anderes Resultat dabei herauskommen, werde ich das natürlich posten. Zudem habe ich dem betroffenen Benutzer das Startskript nun auf den Desktop kopiert, von wo er es momentan manuell startet. Dies funktioniert ohne Probleme, und da auch alle Benutzer dasselbe Startskript (per GPO konfiguriert) verwenden, kann ich ein Fehler in diesem ebenfalls ausschliessen. @schlingo: vielen Dank für deine Links, habe sie mal angeschaut und am Schluss das Tool "UPHC" installiert welches mir Sunny61 in seinem Beitrag vorgeschlagen hat. Ob das Problem damit gelöst ist, kann ich noch nicht sagen da der Fehler in der Ereignisanzeige nur sporadisch aufgetreten ist, also öfters mal einige Tage vergingen ohne das ich einen 1517 in der Ereignisanzeige hatte. @Sunny61 Die beiden Einstellungen gem. GPO-FAQ Nr. 36 habe ich seit längerem aktiviert (war damals ein Problem das den Benutzern öfters die Netzlaufwerke fehlten, welches damit behoben werden konnte). Und wie oben bereits angesprochen, war "UPHC" nicht installiert, habe ich jetzt noch gemacht und schaue in den kommenden Tagen öfters mal in die Ereignisanzeige. Das eigentliche Problem mit dem (nicht) ausführen des Startskripts ist jedoch damit nicht behoben. Vielen Dank, elzag