Jump to content

maik.de

Members
  • Gesamte Inhalte

    74
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von maik.de

Fellow

Fellow (7/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Hallo zusammen, ich grabe den Uralt-Thread von mir mal aus. Das problem besteht immer noch, ist nur entschärft da die Kollegen über Terminalserver arbeiten sollen und das Problem da nicht auftritt. Ich bin da nun aber glaube ich der Lösung auf der Spur, zumindest hoffe ich das... Das Problem tritt mittlerweile an zwei Standorten auf. Beide Standorten nutzen einen Server 2012 als DC. Mit diesem wurde ja die SID Compression eingeführt. Das Storage (NetApp) hat möglicherweise ein Problem mit dieser SID Compression und es kommt deshalb zu dem Fehler. Nun findet man im Web ja an vielen Stellen die ANleitung, wie ich diese deaktivieren kann (in der Registry). Bis zum Schlüssel System ist alles toll, Kdc gibt es dann aber nicht. Lege ich die folgenden Schlüssel dann auch einfach an oder macht das hier keinen Sinn? Weiß das jemand? Danke im Voraus! Viele Grüße Maik Nach dem Motto "Versuch macht klug" hab ich es probiert - funktioniert. Problem damit endlich gelöst :-)
  2. Hallo zusammen, folgendes Problem tritt bei uns auf. Auf dem zentralen Storage ist ein Ordner für eine bestimmte Gruppe von Mitarbeitern an einem Standort freigegeben. Freigabe ist nach AGDLP sauber durchgeführt. Das funktionierte bis heute gut, jetzt nicht mehr. Breche ich die AGDLP-Regel und gebe die Berechtigungen entweder dem User direkt oder aber der globalen Gruppe, funktioniert der Zugriff. Nur mit der DL klappt es nicht. Ein paar weitere Infos: Wir hatten mit dem DC an dem Standort (Server 2012) zuletzt einige Probleme (AD-Objekte waren zum Schluss komplett veraltet, es wurde nicht mehr repliziert) und waren gestern dann endgültig gezwungen diesen komplett herunterzustufen, aus der Domäne zu nehmen und dann im Anschluss neu einzubinden. Die Replikationsprobleme scheinen laut Ereignisanzeige weg zu sein. Das problem tritt nicht nur bei diesem einen Ordner auf, sondern wohl nun auch bei anderen, aber eben auch erst seit heute. Da ich mittlerweile den Wald vor lauter Bäumen nicht mehr sehe, wollte ich mir hier mal Rat aus neutraler Perspektive holen :-) habe ich Infos vergessen? Dann fragt einfach aber schimpft nicht :-) Danke im Voraus! Besten Gruß Maik Ergänzung: Die anderen Standorte von uns haben diese Probleme bisher noch nicht, dort sind aber auch keine Server 2012 im Einsatz, sofern es da evtl. irgendwelche Zusammenhänge geben KÖNNTE.
  3. Hm, mir ist jetzt erst aufgefallen dass die neu erstellte Richtlinie für SMB-Signing genauso streikt (gleiche Fehlermeldung) wie die anderen beiden. Dann brauch ich wohl kaum kontrollieren, oder? Vermutlich muss ich wohl erstmal die Replikation abwarten. Einfach weil ich gerade erstmal die eine Baustelle beseitigen wollte :-) Einfach um da sicher zu sein, dass ich von jeden DC aus darauf zugreifen kann. Hätte genauso gut jedes andere Share sein können. Hatte also keinen besonderen Grund. Alles weitere habe ich ja dann auch so getan. Hatte ich kurz nach meinem Post auch getan, es sind 2 Stunden. Im SYSVOL Share ist die Policy ja vorhanden, das sehe ich. Eigenartigerweise steht in der GPT.ini aber displayName=Neues Gruppenrichtlinienobjekt Ist das normal? hab da bisher nie drauf geachtet...
  4. Okay, SMB-Signing habe ich mal gemäß des Artikels eingestellt. Danke dafür. Central Store ist generell recht interessant, würde ich aber eher zu einem späteren Zeitpunkt drauf zurück kommen. Ich hatte jetzt einfach mal eine neue Policy erstellt mit den gleichen Einstellungen fürs Office. Die ADMs hatte ich im Voraus neu heruntergeladen und neu eingebunden, einfach um das Problem hier auszuschließen. Abgelegt habe ich diese nun unter \\domain.local\sysvol\domain.local\policies\adm. So sollte ja jeder DC Zugriff darauf haben, sobald die Replikation durch ist, oder? Die Fehlermeldung erscheint leider immer noch, nun jedoch mit der neu erstellen Policy. Schlag bitte nicht die Hände überm Kopf zusammen falls ich nun etwas komplett falsch gemacht habe :-) ....Default Replikationsintervall zwischen zwei Standorten waren 3 Stunden, oder?
  5. Danke, das war schon mal hilfreich. Es sind aber wirklich die GPOs, die ich schon im Verdacht hatte. Bei der einen geht es wie schon gesagt um Office Einstellungen über ADMs. Da ich was ADMs angeht nicht ganz fit bin, kannst du mir da vielleicht auch nochmal kurz helfen... Wenn ich die Richtlinie auf einem DC erstelle (mit eingebundenen ADMs), muss ich diese ADMs dann auf jedem DC explizit einbinden oder wie darf ich mir das vorstellen? Sobald ich die Richtlinie lösche tauchen die Fehler nicht mehr auf. Dann fehlen mir aber natürlich die Einstellungen im Office bei den Clients. ich gehe also einfach davon aus, dass ich beim Erstellen der Richtlinie bzw. beim Einbinden der ADMs Fehler gemacht habe...
  6. Hallo zusammen, ich habe da ein kleines Problem in unserem Gruppenrichtlinienkonstrukt. Vorweg: Das Ganze ist über die Jahre stark gewachsen, viele DIenstleister haben rumgebastelt und ich denke einiges ist auch nicht so wie es sein soll. Generell funktioniert aber eigentlich fast alles. Aufgrund von Problemen mit unserem WSUS habe ich mich heute mal auf die Suche nach der Ursache in unseren Gruppenrichtlinien gemacht. Um Änderungen zu testen habe ich auf 2 Clients gpupdate /force durchgeführt und dabei erhielt ich den folgenden Fehler: Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\...\ \{495A38CC-28CB-4E1E-9883-9B88804B4F24}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Das Gleiche kommt auch nochmal für eine weitere Policy. Unter \\domain.local\sysvol\domain.local\Policies finde ich diese beiden Objekte aber auch gar nicht. Sonst scheint aber alles vorhanden zu sein. Wie schaffe ich es, dass die Clients diese Policies nicht mehr ausführen wollen? Generelles zur Domain: Wir haben pro Standort jeweils einen DC mit verschiedensten OS-Versionen. Das älteste ist jedoch Server 2003. Die Domain wurde vor einiger Zeit (ca. 1 Jahr) auf 2008 R2 hochgestuft. Ich möchte Replikationsprobleme nun nicht gänzlich ausschließen, konnte aber ansonsten keinerlei Probleme in dieser Hinsicht feststellen. Für ein paar Tipps wäre ich sehr dankbar :-) Vielen Dank. Gruß Maik Ich bin jetzt noch einen Schritt weiter. Unter \\domain.local\sysvol\domain.local\Policies sind die beiden Objekte ja wie gesagt nicht auffindbar, auf einigen DCs existieren sie allerdings. Auf anderen wiederum nicht. Scheint so, als hätte da doch was bei der Replikation gehakt. Wie gehe ich da am besten vor? Bisher weiß ich ja nicht mal welche Richtlinie sich dahinter verbirgt bzw. ob ich diese überhaupt noch brauche... Und noch etwas... Habe jetzt mal auf einem der wenigen DCs wo die Objekte exisitieren in die Ordner geschaut. In der GPT.ini steht als Name Neues Gruppenrichtlinienobjekt, in beiden Fällen. Über die Unterordner konnte ich auch schon einmal herausfinden welche Richtlinien das ungefähr sein müssten, da in dem einen Unterordner Office ADMs enthalten sind und in dem anderen ein Befehl zum Ausführen beim Systemstart. Was empfehlt ihr mir? Die Objekte löschen und sauber neu anlegen oder wie ist in solch einem Fall die beste Vorgehensweise?
  7. Hallo zusammen, ich habe Google nun schon viel bemüht und auch viel gefunden - leider viel Gegensätzliches dabei aus dem ich letztendlich dann nicht schlau geworden bin. Früher gab es ja die .nk2-Datei, in der der Verlauf für eMail-Empfänger gespeichert wurde. Das war wohl (nach allem was ich nun gelesen habe) bis 2007 so und wurde mit 2010 geändert. Hier soll dieser Verlauf im Ordner Vorgeschlagene Kontakte, also direkt im Postfach des Nutzers, liegen. Ist das bis hierhin so richtig? Ist die .nk2 wirklich gänzlich weg? Ich habe zwei Nutzer bei denen der Verlauf am nächsten Tag immer wieder bei 0 beginnt und weiß leider nicht warum. Sie nutzen beide Outlook 2010 auf Windows 7, angebunden an einben aktuell gepatchten Exchange 2003. Die Profile sind nicht server-gespeichert sondern liegen lokal. Es verhält sich wirklich so, dass die Kollegen über einen Tag hinweg den Verlauf normal nutzen können. Am nächsten Tag ist aber wohl wieder alles weg. Der Ordner Vorgeschlagene Kontakte soll auch unnvollständig sein. Was kann ich hier machen? Kann man das Teil irgendwie zurücksetzen? Vielleicht habt ihr ja einen Tipp und könnt Licht ins Dunkel bringen :-) Danke im Voraus, Gruß Maik
  8. Cleanrules war das magische Zauberwort :-) Danke!
  9. Das Problem beschränkt sich intern bisher auf die beiden Kollegen. Weitere sind bisher nicht bekannt, wobei das ja nicht heißen muss, dass es nicht mehr gibt :-) EMails sind in OWA nicht vorhanden, so dass ich das mit dem Caching Modus gar nicht erst probiert habe.
  10. Nein, den Versuch hatte ich auch schon gestartet weil ich den Cache Modus im Verdacht hatte :(
  11. Hallo zusammen, wir haben hier ein eigenartiges Phänomen. Vielleicht hat der eine oder andere einen Tipp. Unser Mail-Server ist ein aktuelle gepatchter Exchange 2003. Als Mail-Client ist Outlook 2010 im Einsatz. (OS ist Win7) Eine Mitarbeiterin beklagt nun, dass sie von zwei Kollegen (also alles interne Mail-Verkehr) keine eMails erhält. Die beiden Kollegen erhalten jedoch keinerlei Meldung, dass die eMails nicht zugestellt werden konnten. Ein Blick in den System Manager sagt, dass die eMail (habe danach gesucht) korrekt in der Speichergruppe abgelegt wurde. Wir finden sie jedoch nicht. Es sind keinerlei Regeln aktiv, so dass wir hier wirklich keinerlei Ahnung haben wo die eMails hin sind. Hat jemand von euch einen Tipp? Vielen Dank bereits im Voraus. Gruß Maik
  12. Hallo zusammen, nach erfolglosen Google- und Forensuchen wende ich mich nun an euch, vielleicht könnt ihr mir helfen. Wir haben bei uns einen BlackBerry Express Server in Version 5.0.3.41 am laufen. Angebunden ist dieser an einen aktuell gepatchten Exchange 2003. Es gibt soweit keinerlei Probleme mit dem Server oder den Handhelds. Das hat sich heute aber bei einem User geändert. Die Vorgeschichte: Aufgrund einiger Fehlinformationen wurde ein Benutzerkonto bei uns im AD falsch eingerichtet. Bevor das große Umbenennen und ähnliches nun losging, bat der Mitarbeiter mich, den Account einfach zu löschen und neu anzulegen. Er ist neu und das Ganze war deshalb kein großes Problem. Ich habe seinen Account also inkl. Exchange Postfach gelöschtk, 2-3 Minuten gewartet und dann neu angelegt. Er hat seine bis dahin erhaltenen eMails im Voraus in ein PST-File exportiert und nun wieder importiert. Alles schien zu laufen. Dann fiel uns ein, dass dass wir sein BlackBerry neu aktivieren müssen. Er hat das Gerät also zurückgesetzt (vollständig), ich habe ihn vom BES als User entfernt, wir haben 2 Stunden (!) gewartet und ihn dann wieder als User hinzugefügt. Nun wollte er das Gerät aktivieren, doch leider war das nicht so einfach wie angenommen. Anstatt dass die Aktivierung durchläuft, landet die bekannte Aktivierungsmail im Postfach des Kollegen, wird aber vom BES nicht abgeholt. Normal soll das ja mit den fehlenden "Send as" und "Receive as" Rechten zusammenhängen. Das ist aber hier nicht so. Unser BESAdmin ist Mitglied der Gruppe Domänen-Admins und diese hat entsprechende Rechte (keine Ahnung wer das eingerichtet hat, war vor meiner Zeit...). Wie dem auch sei, die Rechte sollten passen da alle anderen User (mich eingeschlossen) ja auch keinerlei Probleme bei der Kommunikation haben. Hat irgendjemand von euch eine Idee woran es jetzt noch scheitern könnte? War ich zu schnell nach dem Löschen des AD-Accounts, so dass das Postfach noch nicht ganz gelöscht war und er sich nun bei den Rechten verhaspelt hat? Bevor ich es vergesse, ich habe die Rechte mal mit der IEMSTest.exe getestet. Der Test ergibt No Send As permission for the {Domain\BESAdmin} account operator. Aber wie gesagt, die Rechte sollten passen! ich weiß nicht weiter, hat jemand von euch eine Idee? Bin für jeden Tipp dankbar! Gruß Maik
  13. Problem hing wohl mit Problemen in der AD Replikation zusammen. Citrix selbst war nicht Schuld. Kann geschlossen werden ;-)
  14. Hallo zusammen, vorab: falls ich hier falsch bin, bitte entsprechend verschieben. Ich habe leider nichts passenderes für dieses Thema gefunden. Folgendes Problem: Ein User hat nach längerer Zeit mal wieder sein Kennwort für seinen Domänen Account geändert. Das hat soweit auch funktioniert. Er kann sich mit dem neuen Kennwort an seinem lokalen Client (Windows 7 x64) anmelden. Probleme bereitet jedoch das Citrix Online Plugin. Dieses meldet nun, dass das Konto gesperrt ist. Dabei ist es egal ob es über Passthrough oder die manuelle Eingabe der Benutzerdaten läuft. Auf dem Domain Controllers ist das Konto aber nicht gesperrt. Das Kennwort haben wir nun testweise auch schon wieder auf das nalte zurückgesetzt, führte jedoch auch nicht zum gewünschten Erfolg. Der User soll auf eine Citrix XenApp 6.5 Farm zugreifen die auf Windows Server 2008 R2 läuft. Gibt es da irgendwo noch einer extra Benutzerverwaltung? Eigentlich kommen die User doch aus dem Active Directory, oder nicht? Kann mir hier jemand einen Tipp geben? Falls noch Informationen fehlen lasst es mich bitte einfach wissen! Vielen Dank bereits im Voraus! Gruß Maik
  15. Gibt es diese .nk2 Datei dafür denn noch? Wie verhält es sich wenn ich die lösche? Wird die neu angelegt? Das wäre dann ja vielleicht erstmal einen Versuch wert bevor ich das ganze Profil lösche.
×
×
  • Neu erstellen...