Velius

Kill doch einfach den Wert "DefaultPassword"="" komplett aus dem Schlüssel und probier nochmal.;)

Ich halte mich ja eher da dran: https://www.mcseboard.de/windows-forum-ms-backoffice-31/print-migrator-3-1-scheduling-106022.html?nojs=1#links Kannst ja ne zweit VM mitlaufen lassen und im Notfall das Printer-Backup einspielen, anschliessend den Rechner umbennen. cheers Velius P.S.: VMs runterfahren und weg kopieren klingt nach einer feinen Sache theoretisch - ABER, es verhält sich ähnlich wie bei einem Image. D.h.: Sollte das Computer Passwort ablaufen ist ertsmal nix mit Anmleden an der Domäne.

Steht ja auch ganz schick in der Dienst Beschreibung (lesen können vorausgesetzt:cool: ): :D :D ;)

Reden wir hier von einem Member oder einem DC? Bei einem DC sollte das Ding eher auf automatsich stehen - beim Rest ist's nur manuell nötig.:D

Dann müsste jeder Webserver, bzw. jede URL & dazugehöriger FQDN eine eigene öffentliche IP haben. Sinn und Zweck eines Reverse Proxy ist gerade eben, dass alle Anfragen über diesen statt finden.

Ja ok, wenn du weisst was du machst - ich warne nur. BTW: Innerhalb eines Forest gibt es keine doppelten Accounts - das ist nur scheinabr so, aber in wirklichkeit unterscheiden sie sich nicht nur in der GUID, sondern auch im UPN, der proxy address (Echange), in der LDAP Syntax, usw.:wink2:

Sorry, auch wenn es etwas mehr arbeit macht, in beiden Forests ein Wert anzureichern - das was du vor hast geht bei mir unter Gebastel in dieser Grössenordnung gar nicht. Aber du musste es wissen.:wink2:

Versteh ich nicht: Du hast zwei forests, beide mit dem Extensionsattribute14 und beide haben 'unicode string' als Feldwert oder Typ. Vergiss doch die ObjectGUID als Wert - mach dir einen eigenen.

Eben - wozu erst den Feldwert ändern des Attributs. Kannst ja schon so benutzen...

Also es gehört zu den EX Attributen, sind aber default nicht angefüllt. EX2K3 hatte das auch schon in's Schema gekleistert.

Nicht 'Datenbank', sondern 'Files' - da müsste es eine Auswahl geben!

Das ExtensionsAttribute14 ist soweit ich mich erinnere doch ungenutzt - macht doch eine Benennungskonvention, wie dieses Attribut in beiden Forests anzureichern ist und schon hast du deinen eindeutigen Wert. Ist IMHO besser als das Schema des einen zu ändern und die Werte das anderen darin einzupflegen.:wink2:

Also: Am besten wenn da gerade keine Transaktionen laufen - Backup machen und anschliessend Rechte Maustaste -> all tasks -> shrink -> files, und die DB auswählen. Wenn das beim ersten nicht klappt dann gleich nochmals machen. gruss Velius

Im Schema - hoffe dir ist bewusst, was das bedeutet.:wink2: Gruss Velius

Frage ist, ob man Roaming Profiles an sich überhaupt noch braucht - wir leben bei uns ganz gut ohne und Folder Redirections gäbe es ja auch noch. Gruss Velius

Off-Topic: @fischer-denkt Ich weiss, wechen Thread du meinst, und 'auseinander genommen' find ich aber doch etwas übetrieben - das war doch ne normal Diskussion:wink2: Ich persöhnlich würde nur Gäste und Interne trennen wollen über MAC Listen - schicker wäre natürlich 801.x was aber vom Aufwand her auch nicht ohne ist. Der Grund: Auf diesem Layer geht es mehr darum, dass möglicherweise kompromitierte Rechner keinerlei TCP/IP Zugang zum prod. Netz haben sollen. Für alles andere, also Zugriffe auf Resourcen für Mitarbeiter gibt's IMHO geeignetere Wege (z.B.: ACLs, Policies, usw.)

Wenn da nix is, und noch ein Domänen Controller 'rum steht, dann versuch doch mal die FSMO Rolle PDCe auf den anderen zu verschieben (Backup machen vorher!):Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben

@fischer-denkt Es gibt Switche, die eine dynamische VLAN-Zuordnung machen, je nachdem in welcher Liste die MAC geplegt wurde. Aber auch da müsste man verschiedene Subnetze verwenden um was sinnvolles damit anstellen zu können. Bleibt die Frage nach dem Ziel des Vorhabens...

Ich sag ja auch nicht, es gäbe keine FWs die IPs nicht nach Namen auflösen können (z.B. für Logfiles usw.), nur ist es eine total andere Geschichte, ob die Firewall ihre Rulebase nach Namen oder nach der IP anwendet, sprich ob sie in der Rulebase zuerst versucht den Namen der IP aufzulösen. Ausserdem wäre sowas schwer fehleranfällig. Man stelle sich vor, die FW hat einen falschen DNS-Server abgesetzt oder der DNS wurde von DNS-Poisoning befallen.... Abgesehen werden damit ganze Routing/Spoofing Geschichten ausgehebelt. Ein solches Ruleset wäre praktisch nicht brauchbar. Die IP ist da schon sicherer, es theoretisch nur eine aktive geben kann, und diese auch nicht erst aufgelöst werden muss - sie ist direkt an die MAC gebunden.

Genau, wie Daim bereits erkannt hat, zeigt DCdiag, dass der PDCe Rollenhalter nicht verfügbar (down) ist. Somit können alle Clients vor W2K keine Passwörter ändern, nicht der Domäne beitreten, usw. Zuerst musst du das Problem mit dem PDCe fixen...

Hmmm.. Bist du sicher, dass es der PDCe ist (****e Frage ich weiss, aber es muss damit zu tun haben)? Wurde vielleicht die Firewall eingeschaltet auf dem PDCe? Kannst du auf dem NT 4.0 Client den NetBIOS Domänennamen pingen?

Wo steht der PDC-Emulator? Stimmen die Einträge im WINS (1b muss auf die IP des PDCe zeigen). Wenn möglich sollte der PDCe im selben Subnetz wie der NT 4.0 Client sein - teil uns mit ob das der Fall ist. Gruss Velius P.S.: Auch nützlich: How to Verify the Domain Records in Windows 2000 Windows Internet Name Service

Schnall ich jetzt nicht diese Aussage - ISA 2006 kann QoS und VoIP Geräte haut man üblicherweise in eigene Subnetze/VLANs. Wo liegt das Problem? Gruss Velius

Das ist mir alles bekannt - haben selber BB Enterprise.;) Und was stimmt jetzt an meiner Aussage nicht?:suspect: Man braucht eben einen BB Enterprise fähigen Vertrag beim Mobile Provider, nicht mehr nicht weniger (abgesehen vom zusätzlichen BB Enterprise Server im Firmenetzwerk). Wann und wie die Mail & SIM an die BB Farm übergeben wird hab ich ja gar nicht erwähnt.

Das einizge was spezieller an BB genenüber anderen Mobile-Sync Softies ist, ist dass RIM eine eigene Farm an Servern hat, die das 'Push' ermöglichen. Die BB Enterprise Server in den Unternehmen kommunizieren mit diesen Farmen. Deswegen muss RIM auch wissen, welchen e-mail zu welcher SIM gehört - da kommt der Provider in's Spiel. Anders wäre ein 'echter' Push nicht möglich.:wink2: Also, woher das BB kommt ist sekundär - der Vertag mit dem Provider ist ausschlaggebend!