Jump to content

olc

Expert Member
  • Gesamte Inhalte

    3.978
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von olc

  1. Hi,

     

    das "/force" kann in einigen Situationen zur Abmeldung oder zum Neustart des Rechners auffordern bzw. danach fragen.

     

    Hintergrund: Bestimmte CSEs werden nur synchron verarbeitet - und um in diesen synchronen Modus zu kommen, muß eine Anmeldung bzw. bei Computereinstellungen ein Neustart her.

     

    Das "/force" erzwingt ein erneutes Anwenden von diesen Einstellungen und weist dann darauf hin, daß die Einstellungen erst nach der Anmeldung / dem Neustart gezogen werden können.

     

    Haben Benutzer also eine oder mehrere dieser CSEs aktiviert (Beispiel "Folder Redirection") oder sind für Computer (Gott bewahre ;) ) Softwareverteilungen per GPO aktiv, kann es zu der Meldung in der CMD kommen.

     

    GPP Netzlaufwerke zählen meines Wissens auch dazu, bei den Druckern bin ich mir nicht sicher.

     

    Viele Grüße

    olc

  2. Hi Daniel,

     

    mit TCP Chimney deaktivieren meinst Du alle drei Werte, korrekt?

    EnableTCPChimney

    EnableTCPA

    EnableRSS

     

    Was sagt der folgende Wert?

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters --> DisableTaskOffload. Enthält er den Wert "1"?

     

    Beide Maschinen nach den TCP-Änderungen neu gestartet? Im Regelfall ist das übrigens eher nur für 2003 relevant, unter 2008 läuft das Offloading stabiler.

     

    Du hattest bei den Tests ganz oben Avira wirklich auf beiden Systemen testweise deinstalliert, korrekt? Nicht nur deaktiviert?

     

    Ist auf den Systemen irgend eine Art von NIC-Teaming aktiv?

     

    Ggf. könntest Du noch einen Netzwerktrace mitlaufen lassen um zu prüfen, von welchem System ggf. TCP Resets kommen oder ob es wirklich einfach "Verbindungsabbrüche" sind.

     

    P.S.: Nimm einmal die firmen-spezifischen Daten aus den Exports oben raus. :)

     

    Viele Grüße

    olc

  3. Hi,

     

    die Anwendungsreihenfolge der Gruppenrichtlinien ist vermutlich falsch herum. Da in der Default Domain Policy vermutlich andere Einstellungen definiert sind, überschreibt diese die Kontensperrungs-GPO:

     

    Angewendete Gruppenrichtlinienobjekte

    --------------------------------------

    EDV

    Default Domain Policy

    Kontosperrung

     

    Du müßtest also die Priorität der "Kontosperrung" GPO hochsetzen.

     

    Ansonsten noch der Hinweis, daß für Domänenkonten irrelevant ist, ob die Richtlinie auf den Mitglieds-Computern angewendet wurde. Sie muß auf den Domain Controllern angewendet werden, denn dort werden die Account geprüft / gesperrt usw.

     

    P.S.: Ein besseres Namenskonzept für die GPOs (z.B. mit Versionsnummer, Hinweis ob Computer oder Benutzereinstellungen usw.) ist auch meist langfristig sinnvoll. ;)

     

    Viele Grüße

    olc

  4. Hi,

     

    Geht das mit x-beliebigen USB-Sticks von %Elektromarkt%-Grabbeltisch?

     

    Würde ich nicht machen. 1. ist USB 3.0 notwendig/sinnvoll und außerdem werden die Sticks sehr heiß im Dauerbetrieb, was einen Stick mit ausreichend passiver Kühlung (großer ableitender Korpus) sinnvoll werden läßt.

     

    Ich habe den hier, und damit funktioniert es sehr gut und zügig: http://www.amazon.de/Kingston-DataTraveler-Ultimate-32GB-USB-Stick/dp/B005039I32/ref=sr_1_3?ie=UTF8&qid=1349017355&sr=8-3

     

    Viele Grüße

    olc

  5. Hallo Beetlejuice,

     

    Du hast mit dem Bearbeiten des Eintrags einen statischen Eintrag aus einem dynamischen Eintrag gemacht. Der NETLOGON Dienst des 2003er DCs hat dann nach einiger Zeit seinen SRV Eintrag erneut geschrieben und es kam zu der Konstellation.

     

    Warum möchtest Du dem DC eine geringere Priorität geben? Wenn Du ihn ausphasen möchtest, verschiebe ihn einfach in eine eigene Site. Ggf. kannst Du ihn zusätzlich "verstecken", siehe dazu: How to optimize the location of a domain controller or global catalog that resides outside of a client's site .

     

    Wenn Du dennoch beim Ändern der Priorität bleiben möchtest, muß die Änderung nicht direkt auf dem DNS Eintrag erfolgen, sondern über den NETLOGON Dienst: Change the priority for DNS SRV records in the registry: Active Directory

     

    Zusätzlich die Gewichtung: Change the weight for DNS SRV records in the registry: Active Directory .

     

    Viele Grüße

    olc

  6. Und warum machst Du das nicht einfach anstatt hier nur zu meckern? ;)

     

    Beim Tablet klar mit Fingern, klassisch mit Maus mittels STRG + Mausrad.

    Ein wenig **** ist, daß man mit der Maus nach dem zoomen nur mit den Balken nach links und rechts schieben kann.

     

    Per Kontext unten (mit der Maus rechts-klick) hast Du noch weitere Optionen und kannst z.B. TechNet Beschreibungen öffnen.

     

    Viele Grüße

    olc

  7. Hi,

     

    das Problem kann auch nach Log-Lage aus meiner Sicht aus vielerlei Gründen auftreten.

    Mir scheint, daß bis zum aktuellen Status eine Menge Aktionen erfolgt sind, die das Fehlerbild verwässern können.

     

    Kurz Rückmeldung zu Deinen Anmerkungen:

    a) RDC zu deaktivieren ist nicht sinnvoll.

    b) die AD-Replikation reicht leider nicht aus - der DFSR Dienst muß die Änderungen auch erst aus der AD abrufen. Das erfolgt standardmäßig jede Stunde 1x. Beschleunigen kannst Du das mittels "dfsrdiag pollad" auf den Zielmaschinen.

    c) Du schriebst, daß Du alle möglichen Hotfixes schon installiert hast - welche genau?

    d) Wie ist der Status von SNP auf dem 2003er Server? Sind die SNP Features deaktiviert oder alternativ auf dem neuesten Stand? A Scalable Networking Pack (SNP) hotfix rollup package is available for Windows Server 2003

    e) Kannst Du ggf. das Quota einmal auf 20 GB hochdrehen und die Replikationsgruppe neu einrichten? Datensicherung nicht vergessen und richtigen Primary Member wählen. ;)

    f) Dabei bitte keine Bandbreiteneinschränkung konfigurieren wie oben beschrieben, das macht es nicht besser.

    g) Nach der Einrichtung der Replication Group das System einmal 24h "in Ruhe" lassen - keine Änderungen an der Konfiguration, kein Neustart der DFSR Dienste usw.

     

    BTW: Hardware oder virtuelle Maschinen?

     

    Viele Grüße

    olc

  8. Hi,

     

    + [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 4732 C The content set is not ready]

    Das bedeutet, dass der Initial Sync noch nicht abgeschlossen ist.

     

    Ja, wurde ja auch vom TO angegeben :) ... :

     

    Aktuell sollte eine Initial Replikation vom Primary Member zu einem Außenstandort stattfinden.

     

    Neben den Hinweisen von LarryLaffler:

     

    Auch bei Verwendung eines anderen Gruppentyps (Multipurpose und Data Collection) ändert sich nicht.

     

    • Wie lange wartest Du nach Anpassung der Struktur oder DFSR-Dienst Neustart?
    • Wie viele Systeme sind Teil der Replikationsgruppe? Wie stabil sind die WAN-Leitungen?
    • Sind Anpassungen unterhalb von HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters auf den Systemen durchgeführt worden?
    • Werden "WAN-Optimierer" (etwa von Riverbed) auf den Strecken eingesetzt?

     

    Viele Grüße

    olc

  9. Hi,

     

    ok, ich habe es gerade auch noch einmal getestet - geht nicht. Als Admin oder mit delegierten Berechtigungen in der Remote Domäne klappt es, also fehlt vermutlich irgend ein Privileg beim Setzen des Kennworts.

     

    Wie sieht es hiermit aus? How to Change a User's Active Directory Password with PowerShell - Hey, Scripting Guy! Blog - Site Home - TechNet Blogs

     

    Viele Grüße

    olc

  10. Hi Chakoe,

     

    dann nimm dsquery / dsmod - mit den Parametern "-s" und "-d" kannst Du einen DC der anderen Domäne bzw. die remote Domäne selbst angeben und somit den remote Benutzer ändern.

     

    dsquery user -?

    [...]

    {-s <Server> | -d <Domain>}

    -s <Server> connects to the AD DC/LDS instance

    with name <Server>.

    -d <Domain> connects to an AD DC in domain <Domain>.

    Default: an AD DC in the logon domain.

    [...]

     

    Du legst Dir die verschiedenen Kommandozeilen in eine Batchdatei und rufst sie bei Bedarf auf.

     

    Change a domain account’s password from the command line « ITnsomnia

     

    Viele Grüße

    olc

  11. Da hast du grundsätzlich Recht, weshalb die Cloud (mit Ausnahme meiner eigenen private Clid in meinem Rechenzentrum) auch indiskutabel ist.

     

    Ich finde nur gerade interessant wie alle Cloudanbieter argumentieren dass es rechtssicher ist Daten in die Cloud zu geben, aber vollkommen ausklammern dass die Daten dann halt "rechtssicher" in fremden Händen landen.

     

    Genau, es geht um alle Cloud Anbieter und weniger um die Frage, wo die Daten liegen. Das ist nur ein Teilaspekt. Dieses Blendfeuer haben die Kollegen der Telekom und Konsorten geschickt mit ihren Lobbyverbänden gestreut, um sich gegen ausländische Konkurrenten zu positionieren. (Was natürlich nicht heißt, daß es sinnvoll ist, die Daten etwa in den USA oder China zu hosten - schon merkwürdig, die beiden Länder in einem Satz zu nennen ;)...).

     

    Und Du denkst, daß "Deine" Cloud in allen Aspekten "sicherer" ist als die der Anbieter? ;) Meine Erfahrung ist da eine andere. Privat als auch beruflich.

     

    Bei dem Thema gibt es verschiedene Ebenen - technische Angriffsmöglichkeiten, Möglichkeiten des staatlichen Zugriffs, Fragestellungen der Datenweitergabe usw. - und auch wenn Deine Daten vielleicht "rechtssicher" bei Dir liegen (was ja so auch nicht stimmt, spätestens wenn das BKA zum Festplatte-kopieren bei Dir vor der Tür steht ;)), sind sie unter Umständen doch "weniger sicher" in Bezug auf andere Aspekte.

     

    Was ich damit sagen will: Es hat Sinn alle Aspekte zu beleuchten oder sich ganz konkret auf einen Bereich zu konzentrieren. Alles andere wirft vieles durcheinander und verwässert die Diskussion.

     

    Aber gut, das ist alles etwas off topic. Also zurück zum Thema: Es ist vorbei, bye, bye TMG. :)

     

    Viele Grüße

    olc

  12. Ja genau...

     

    "Das US-amerikanische Anti-Terror-Gesetz erlaube einen Zugang zu Bits und Bytes in den Rechnerwolken nur unter "ganz engen Voraussetzungen". " sagt Herr Löffler von Microsoft.

     

    Zu den "engen" Voraussetzungen gehört auch alles was irgendwie mit "terrorgefahr" zu tun hat. Was die USA damit alles rechtfertigt hat wissen wir und das der Begriff weich wie Kaugummi ist auch. Im Zweifel war es halt terrorgefahr die da abgewendet werden musste.

     

    Ach komm schon, als ob es hier mit dem "Rechtsstaat" besser bestellt wäre.

     

    Egal wo die Daten liegen, "Staaten" werden immer ran kommen, wenn sie es denn begründen können. Mit welchen Argumenten auch immer. Auch die Telekom wird sich nicht dagegen wehren können, wenn der Verfassungsschutz anklopft und "Deine" Daten aus der "Telekom Cloud" kopieren möchte.

     

    Aber bevor die da dran sind, haben geschätzte 3 Millionen Privatunternehmen eh schon auf die Daten direkt oder indirekt zugegriffen.

     

    Ich finde beides nicht schön.

     

    Viele Grüße

    olc

  13. Hi,

     

    wenn ich schlecht gelaunt wäre würde ich sagen, es ist kein Problem der PKI, sondern ein Problem mangelhafter Anforderungsdefinition bei der Evaluierung der PKI Deinerseits. ;)

     

    Insgesamt hat die MS PKI einen anderen Funktionsumfang und einen anderen Fokus als einige andere Implementierungen (Open Source oder andere Hersteller) - Du mußt also vorher genau schauen, was Du mit welcher Lösung erreichen kannst.

     

    Viele Grüße

    olc

×
×
  • Neu erstellen...