NilsK

Moin, das Löschen der Exchange-Attribute ist in der Exchange-Löschroutine enthalten. Dass dies auch die Werte in den Custom Attributes umfasst, war mir zwar bislang nicht bewusst, es ist aber durchaus nicht unlogisch: Es sind ja schließlich Exchange-Attribute. Dass diese oft (zu Unrecht) für alles Mögliche empfohlen werden, ist ja nicht der Fehler von Exchange. Zudem ist es in den meisten Umgebungen nicht üblich, dass einem User die Mailbox entfernt wird, der User als solcher aber weiter arbeitet - daher fällt dieser Umstand meist gar nicht erst auf. AD verhält sich so, dass es Attribute ohne Wert gar nicht erst zurückgibt. Das hängt damit zusammen, dass es aufgrund der Objekthierarchie bei vielen Objektklassen hunderte von optionalen Attributen gibt, in denen ein Wert stehen könnte. Würde man für jedes die Information "leer" zurückgeben, so führte das zu völlig unnötigem Datenverkehr. Gruß, Nils

Moin, die Bootdisk muss bei Hyper-V per IDE angebunden sein. SCSI kannst du nur für zusätzliche Disks nehmen. Aber warum willst du direkt auf Passthrough installieren? Meist belässt man das Bootvolume einfach als VHD und bindet nur Datenplatten per Passthrough ein, um SAN-Funktionen oder (geringe) Performance-Vorteile zu nutzen. Gruß, Nils

Moin, weil das Feld im ADUC als "Job Title" bzw. "Position" angezeigt wird. So ist es auch definiert: Title attribute "Anrede" wäre eher "salutation", und ein solches Feld scheint im AD zu fehlen. Sicher kann man ein anderes Feld dafür hernehmen, aber das muss man dann auf der organisatorischen Ebene und ggf. auch im Code einer zugreifenden Applikation durchziehen. Gruß, Nils

Moin, bevor wir weiter mutmaßen, sollte der TO klären, was Sache ist. Handelt es sich bei dem virtuellen DC um eine Testumgebung? Oder ist das bereits das produktive AD? Gruß, Nils

Moin, wenn ich dich richtig verstehe, ist der Server gleichzeitig DC und Hyper-V-Host. Das ist nicht gut. faq-o-matic.net » Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte Gruß, Nils

Moin, ich sehe das als ausschließlich organisatorische Frage an, die auch auf der organisatorischen Ebene gelöst werden muss. Damit könnt ihr das nur intern lösen. Technische Aspekte, zu denen das Board etwas Sinnvolles beitragen könnte, sehe ich dabei praktisch keine. Gruß, Nils

Moin, sowas ist meist darauf zurückzuführen, dass die Felder im Kontakt nicht richtig ausgefüllt sind. Gruß, Nils

Moin, was genau meinst du damit? Gruß, Nils

Moin, wenn du die Daten im Sharepoint darstellen willst, haben sie im AD nichts zu suchen. Streng genommen gehören sie ohnehin nicht ins AD. Selbstverständlich kannst du im Sharepoint Daten aus mehr als einer Quelle darstellen und miteinander verbinden. Von dem AD-Import, gleich in welcher Form, rate ich entschieden ab. Gruß, Nils

Moin, in jeder VM ist für jede ihrer virtuellen Netzwerkkarten hinterlegt, mit welchem vSwitch sie verbunden ist. Damit das auch nach einem Failover funktioniert, müssen die vSwitches auf allen Clusterknoten genau gleich heißen (inkl. Groß-/Kleinschreibung) und natürlich mit den passenden LANs/vLANs verbunden sein. Gruß, Nils

Moin, du sprichst in Rätseln. Sind mehrere Exchange-Server im Spiel? Bitte beschreibe die Umgebung, die bisherigen Vorgehensweisen und das Fehlerbild genau und umfassend. Gruß, Nils

Moin, kannst du das bitte noch mal der Reihenfolge nach beschreiben? Was ich verstanden habe: Du willst zu einem AD-Account den aktuellen Status aus der Zeiterfassung heraussuchen, um ihn im Sharepoint anzuzeigen. Was ich nicht verstanden habe: Warum willst du den Status ins AD schreiben? Gruß, Nils

Moin, also ... ich glaube, dem TO wird Unrecht getan. Im Kontext des ursprünglichen Threads war der Beitrag dann doch eher als ironischer Kommentar zu verstehen ... ... aber wo wir dabei sind: Bei einem Kunden habe ich neulich Windows 1.01 entdeckt, mit Originalschuber und allem Drum und Dran. Diente als Bildschirmerhöhung ... Gruß, Nils

Moin, jedes Speichergerät, das sich per iSCSI ansprechen lässt, arbeitet in dem Fall blockbasierend. Gruß, Nils

Moin, ja, das wäre eines der Szenarien. Gruß, Nils

Moin, nein, im Gegenteil. Es ist fast immer von Vorteil. Bei Aktivieren der Richtlinie geht in Wirklichkeit nichts langsamer, nur der Anmeldedialog kommt erst, wenn das System so weit ist. Im anderen Fall kann man sich zwar eine Idee früher anmelden, aber dann wird man noch nichts machen können, weil Windows ohnehin noch rödelt. Gruß, Nils

Moin, dieses "ja" ist ein verstecktes "nein". :D Yusuf hat völlig Recht, aber trotzdem noch mal ausdrücklich hier erwähnt (weil viele ja ungern gepostete Links lesen): Nein, man kann eine Subdomäne nicht aus dem AD herauslösen. Gruß, Nils

Moin, DFS-R dürfte für dein Szenario nicht geeignet sein, denn da hast du "Last Writer Wins": Jemand öffnet das XLS auf Server1, parallel öffnet es jemand von Server2. Der auf Server1 ändert es nun auf 100.000 Zeilen und speichert. Der auf Server2 ändert seine unabhängige Kopie auf 100 Zeilen und speichert eine Minute später. Rat mal, welche Version dann auf beiden Servern liegt ... Für die Unabhängigkeit von Servernamen kann in deinem Szenario DFS-N hingegen durchaus geeignet sein - vorausgesetzt die Anwender nutzen nur DFS-Links und keine direkten Serverlinks. Ein Datenbanksystem wäre wirklich besser. :D Vielleicht ist dies hier auch interessant für dich: Fix broken links with LinkFixerPlus. WordPipe Search and Replace for Word Gruß, Nils

Moin, warum? Weil eure Daten doch nicht so wichtig sind, dass ihr Geld für eine sichere Migration und ein vernünftiges Systemdesign ausgeben wollt? Dann kann das mit den Verfügbarkeitsanforderungen ja auch nur ein Missverständnis sein: Ihr braucht offenbar keinen Cluster. Kopfschüttelnd, Nils

Moin, falls du die Stelle suchst, an der man einen weiteren UPN-Suffix hinterlegen kann: Unter "AD Domains and Trusts", Rechtsklick auf den Root-Knoten der Konsole. Gruß, Nils

Moin, schön, danke für die Rückmeldung! Gruß, Nils

Moin, es müsste ausreichen, den Namen des lokalen Users manuell einzutippen. Gruß, Nils

Moin, wenn noch andere DCs vorhanden sind, entfernst du den kaputten DC aus dem AD und installierst ihn neu. In Win2008 R2 reicht es aus, das Objekt aus dem AD zu löschen. Gruß, Nils

Moin, die Abarbeitungsreihenfolge entscheidet: Schaltest du das Licht erst ein, dann aus, dann wieder ein, dann ist es am Ende an. Bei GPOs ist die Abarbeitungsreihenfolge grundsätzlich immer: Lokales GPO - Standort-GPO(s) - Domänen-GPO(s) - OU-GPO(s) Nur bei den OU-GPOs kannst du die Reihenfolge dann manipulieren (durch Forcing, Blocking usw.) - naja, nicht ganz korrekt, aber als Grundlinie. Da lokale GPOs immer zuerst dran sind (es könnte ja sein, dass keine weiteren mehr kommen), werden ihre Einstellungen bei Konflikten (!) immer überschrieben. Konflikt heißt: Lokales GPO sagt "blau", OU-GPO sagt "gelb", dann ist die Einstellung "gelb". Sagt aber das lokale GPO "blau" und das OU-GPO "nicht gesetzt", dann bleibt es bei "blau". Bei Domänen-Rechnern sollte man daher nie mit lokalen GPOs arbeiten, weil es sonst zu unerwünschten Effekten kommt. Mehr dazu: .: www.kaczenski.de :. » Suchergebnisse » gruppenrichtlinien tutorial Gruß, Nils

Moin, wenn du da nichts eintragen kannst, wird der Wert über eine Gruppenrichtlinie (GPO) aus dem AD gesteuert. Über gpresult sollte sich herausfinden lassen, welches GPO das ist, dort kannst du das dann bearbeiten. Gruß, Nils