JuppDietz

KB947821 ist das CheckSUR. Dies konnte ich installieren und erhalte keine Fehler (mehr). Es läuft keine Sicherheitssoftware. Ich habe die Installation des SP auch im Safe Mode machen wollen und laufe auch dort in 0x800f081f... Danke für deine Unterstützung!!

Und weiter gehts: Jetzt habe ich bei der SP-Installation den Fehler 0x800f081f. Zwischenzeitlich habe ich das MS-Fix KB910336 durchlaufen lassen und den Fehler nach wie vor. So langsam bin ich reif für die Klappse!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Ergänzung: Bei der Installation des SP2 bekomme ich nun einen direkten Abbruch mit dem Fehler 0x80248014...

Moin. Ich bin mit dem Problem ein wenig weiter (?!?) gekommen: Nachdem ich ein weiteres Mal via sfc und CheckSUR die Fehler ausgelesen habe, hatte ich ein wenig die Schnauze voll und habe mir die Mühe gemacht, von nahezu allen Paketen die msu's runter zu laden, um im windows\servicing\packages die entsprechenden Files zu tauschen. Nun habe ich es so weit, dass weder sfc, noch CheckSUR Fehler ausgeben. Nun habe ich mir im Weiteren die Mühe gemacht, die 69 vom Update-Dienst heruntergeladenen Patches einzeln zu installieren und jeden verlangten Reboot zu machen. Bei 11 Updates bekomme ich den Fehler 8024200D. Manche Pakete konnte ich manuell runter laden und installieren. Bei anderen bekomme ich die Meldung, dass das Update nicht für mein System nicht gilt. Kennt jemand diesen Fehler? Es handelt sich um Sicherheitsupdates (KB958623, KB982214, KB982666). Danke (einmal mehr!!) und Gruß Jupp

Ich hoffe ich habe alles richtig verstanden und versuche mal zu antworten (auch wenn ich schon längere Zeit eine stabile Produktivumgebung administriere und nicht mehr soooo viel mit dcpromos machen muss): Nach dem dcpromo sollte man den ehemaligen DC noch seinen Reboot machen lassen. Danach kannst du ihn aus dem Netz nehmen. Ich habe in der Zeit, als ich noch häufiger DC ins Netz bzw. aus dem Netz nehmen musste (besonders über langsamere MAN-/WAN-Strecken) nach jedem dcpromo immer mit den verbleibenden Kisten eine manuelle Replikation und eine Replikationsprüfung via replmon gemacht. Ich würde den alten DC keinesfalls noch einmal hochstufen. Dann hast du in jedem Fall Inkonsistenzen in der Datenbank. Wenn es nach manuellen Replikationen immer noch keinen sauberen Abgleich gibt und es keine Hoffnung auf automatisierte Besserung mehr gibt, würde ich die Replikation mal manuell auf den fehlerhaften DCs einrichten und dann wieder replizieren. Ich hoffe, ich konnte dir ein wenig weiter helfen...

Oder etwas verschnörkelter (wer lieber damit arbeitet) in der PowerShell mit den Quest-Erweiterungen: $temp = Get-QADComputer foreach ($i in $temp){(Get-QADComputer $i).sid | fw value}

Jepp. Die Option Upgrade ist dummerweise aufgegraut und nicht auswählbar, da ich eine W2k8-CD mit SP2 verwenden soll.........

Moin. Einer meiner W2k8_X86 bringt mich so langsam um den Rest des Verstandes: Ich habe mit der Kiste Probleme bei der Installation von Updates. Ich erhalte immer wieder die Fehlermeldung 80070490. Mache Patches lassen sich installieren, der Großteil jedoch nicht. Installiere ich das SP2, installiert der Hobel, startet neu, konfiguriert bis 100% und macht dann die Installation rückgängig. Im Weiteren konnte ich eine Reihe mmc's nicht mehr öffnen (Servermanager, eventvwr). Diese Fehler habe ich in Kleinarbeit wieder hin bekommen. Die Fehler traten irgendwann ohne Vorwarnung auf. Ein Zusammenhang zu einer sonstigen Softwareinstallation kann somit leider nicht hergestellt werden. Das im KB-Artikel 976920 vorgeschlagene Tool hilft leider nicht. Ich habe nun versucht, eine Updateinstallation zu machen. Leider sagt mir die Installationsroutine, dass ich hierzu eine CD mit integriertem SP2 benötige (die ich übrigens verwende!!). Die MS KB habe ich schon rauf und runter gelesen und habe alle Lösungsansätze probiert. Ich habe auch schon sämtliche dll's des Update-Service bereits neu registriert etc... Hat jemand - gerade zum Fehler 80070490 - noch ein paar Ideen? Gruß Jupp

Vielleicht lernt Tom ja "am lebenden Objekt" und braucht deshalb auch bei recht trivialen Dingen mal Hilfe :-)

Moin. Ich habe da mal wieder ein Problem, dass jedoch auch in den Bereich Scripting passen könnte: Ich muss über die Konndozeile herausfinden, auf welchem Terminal Server der XenApp 5-Farm ein User gerade angemeldet ist (sprich: ein lesender Zugriff auf den Datastore). Kennt jemand ein entsprechendes Kommando oder hat jemand eine Idee, wie ich dies realisieren kann? Danke und Gruß Jupp

Danke an alle Leser - aber ich habe die Lösung bei Citrix selbst gefunden!! CTX120831 - When launching a Published Application, Terminal Server Desktop, Explorer.exe Launches - Citrix Knowledge Center Auch wenn es scheint, dass das Konto in Ordnung ist, das Script trotzdem ausführen. Ich bin beim ersten Mal auch rein gefallen und habe dummerweise meinen Augen getraut...

Moin. Ich kämpfe gerade mit einem meiner Admin-Accounts: Bis Sonntag habe ich die veröffentlichten Anwendungen alle ganz normal via Online Plugin starten können. Seit ich am Sonntag den File-Server, auf dem die TS-Profile liegen, gepatcht und neu gestartet habe, starten alle meine Applikationen in einem Seamless-Fenster bzw. als Desktop und nicht mehr als "normale" Anwendung. Ich ging von einem defekten Profil aus, da auch bei der Anmeldung per RDP auf den Terminal Servern ein neues Profil geladen wurde und habe einfach ein neues Profil erstellt. Leider hat dies den Fehler nicht behoben. In einem anderen Forum habe ich eine ähnlich lautende Fehlerbeschreibung gefunden. Verffentlichte Anwendung startet nicht Anwendung sondern Desktop - Windows - administrator Die Ansätze haben leider nicht zum Erfolg geführt. Der Fehler ist ganz klar auf diesen einen Admin-User einzugrenzen. Andere (auch Admin-)Accounts funktionieren problemlos. Das Problem tritt auch auf jedem Rechner auf, an dem sich der Admin anmeldet. Den Account neu zu erstellen ist leider nicht möglich. Hat jemand eine Idee? Umgebung: Client (auch wenn es am User-Account liegt): Win7x64 Server: W2k8x64 mit XenApp 5 Danke!!!!!!!!!!!!!!!!!!

Nein. Die Lizenzserver laufen ab. Ich hatte 90 Tage im Kopf. Es können aber auch 120 Tage sein. Sind die Zugriffe vielleicht nur noch von Admins? Zwei Admins können ja gleichzeitig zu administrativen Zwecken zugreifen...

Jetzt habe ich es auch von der Konsole aus: Man sollte nicht vergessen, das SnapIn in die Konsole zu laden bzw. im Profil zu hinterlegen :-) Add-PSSnapin quest.activeroles.admanagement

Perfekt!!! Ich habe das Ganze auf meinem Win7-Client ausgeführt und da funktioniert es nicht. Nun habe ich es auf dem DC selbst gemacht und - wie bereits von dir getestet - funktioniert es. Anmerkung: Mit der PowerGUI kann ich die Änderung auch auf meinem Client machen. Nur über die Konsole tut er es nicht... Eigentlich sollte das Script aus Gründen der Portierbarkeit nicht auf einem Server laufen müssen, sondern von einem Client aus, aber egal :-)) Vielen Dank!! Grüße aus dem Westerwald Jupp

Hallo Nils, so hart würde ich es jetzt auch nicht sehen :-) Aber du hast schon recht. Mit den älteren Kisten ist die Arbeit manchmal ein bisschen schwierig. Leider bin ich nicht so der VB-Scripter und mit Batches macht es noch weniger Spaß :-)) Gruß Jupp

Moin. Ich habe bereits befürchtet, den komplizierten Weg über das ADSI gehen zu müssen. Dann muss ich mich jetzt wohl damit ein wenig befassen... Mit den Quest-Tools geht es leider nicht. Der Pfad des TS-Profils steht leider nicht im Feld "TsProfilePath". Das Feld gibt es zwar ab W2k8 im AD-Schema, wird jedoch meines Wissens selbst dort noch nicht genutzt. Der Profilpfad steht leider im Schema-Attribut "userParameters" - und das Attribut ist verschlüsselt bzw. nicht lesbar :-(( Zudem habe ich einen W2k3-Domain... Beispiel: [PS] C:\>Get-QADUser -Identity testuser | ft name,TsProfilePath Name TsProfilePath ---- ------------- _Test Account Im Userkonto sehe ich den Pfad... Gruß Jupp

Ich habe es auch kürzlich gemacht und folgende Patches (auch in der Reihenfolge) installiert: - SP2 - KB969429 - KB969166 - KB968934 Danach geht es wie das Katzen machen :-))

Hallo. Ich muss aus dem W2k3-AD den TerminalServer-Profilpfad auslesen und in Abhängigkeit einer ganzer Reihe von Faktoren ggf. neue Pfade setzen. Nun habe ich die entsprechende Schnittstelle ins AD eingerichtet und kann auch mit dem "Get-ADUser"-Kommando die User abfragen. Nach einer Suche im Schema habe ich herausgefunden, dass der TS-Profilpfad im Attribut "userParameters" steht - was ein Binärfeld ist. Hat jemand eine Idee, wie ich über die Powershell trotzdem an das Feld herankomme? Danke und Gruß Jupp

Es ist leider eine Windows-Komponente. Der Besitzer und einzige User mit full control ist der TrustedInstaller. Dieser "Gruppe" kann ich leider nur schlecht beitreten :-)) Den Besitz zu übernehmen reicht leider nicht. Trotz durchreplizieren auf untergeordnete Objekte, kann ich die Berechtigungen nicht nach unten durchreichen :-( Wäre ich ein religiöser Mensch, würde ich mit dieser Arbeit von allen meinen Sünden rein waschen :-))

Hallo. Ich versuche in der Registry einige Keys inkl. Subkeys zu löschen. Leider haben die Administratoren nur read-Rechte und sind nicht Besitzer der Objekte. Das Übernehmen des Besitzes (und das Replizieren auf die untergeordneten Objekte) klappt problemlos. Nun setze ich die Berechtigungen auf dem übergeordneten Key und sage dem Hobel auch, dass er die Berechtitungen der untergeordneten Objekte ersetzen soll. Dies tut er allerdings nicht. Meldung: Sicherheit konnte im gewählten Schlüssel oder in einigen Unterschlüsseln nicht gesetzt werden. Hat jemand eine Idee? Danke!!

Ich kenne das Problem. Eine Lösung habe ich noch nicht gefunden (außer die TS-Sitzung schließen, connect neu connecten und schon gehts wieder). Ich arbeite mit Citrix und hatte das Problem sowohl in der alten Farm (W2k3, MF XPa) und kenne es auch aus der Neuen (W2k8_x64 mit XenApp 5). Meine Vermutung: Wenn du in deinem lokalen Zwischenspeicher Daten hast und im Zwischenspeicher deiner TS-Sitzung ebenfalls, kommen sich die beiden ab und an in die Quere. Ich kann den Fehler aber leider auch nicht 100%ig reproduzieren. Am RDP sollte es nicht liegen, da ich mit ICA arbeite...

Moin. Man mag es kaum glauben, aber es war mal wieder der tolle Symantec Virenscanner. Der procmon hat mir zwar nicht wirklich weiterhelfen können, ich kam jedoch über einen hängenden Citrix-Prozess, der sich auffallend ähnlich daneben benahm drauf. So einfach und doch so wirkungsvoll...

Leider nichts hilfreiches. Ich habe mir den Client, auf dem die Scripts laufen, einmal angesehen. Es liegt wohl an einer bestimmten Datei. Wenn ich sie manuell per TotalCommander kopiere, friert mir auch dieser ein. Kopiere ich die Datei auf einem älteren XP-Client, geht es problemlos. Warum der Win7_x64-Client nun das Problem verursacht, habe ich noch nicht feststellen können :-((

Hallo, ja, habe ich. Ich sehe, dass er im State Wait:WrResource ist und nichts tut. Die Quelle und das Ziel, auf das der Prozess greift, sind beide verfügbar. Er hat nur einen Thread mit der Start-Adresse 0x0. Will ich auf den Thread, bekomme ich die Meldung "Error Accessing Thread". Auch das entsprechende Modul ist nicht vorhanden. Der Performance Graph zeigt, dass den Prozess statisch im RAM liegt und keinerlei CPU-Aktivität verursacht...