cascade

Vielen Dank für Deine Antwort. So ähnlich habe ich es jetzt lösen können. Die vollständige Lösung steht hier: https://stackoverflow.com/questions/27361418/how-to-get-powershell-object-properties-in-the-same-order-that-format-list-does So sieht der Abschnitt im Code jetzt aus (die nicht gewollte Lösung mit alphabetischer Sortierung ist auskommentiert). #$colheads = ($defs | get-member -type NoteProperty) $colheads = $defs[0].psobject.Properties | select name

Hallo, ich importiere aktuell Inhalte aus CSV-Dateien mit beliebigem Inhalt und beliebig vielen Spalten in ein Word-Dokument. Das klappt soweit gut, aber ich möchte nicht, dass die Spaltennamen alphabetisch sortiert werden sondern so erscheinen, wie sie in der CSV-Datei angeordnet sind. Die Spaltennamen kenne ich zur Laufzeit des Scriptes nicht. Kann da jemand helfen? Hier der Codeabschnitt: $path = $GlobalPathCsv + $name + ".csv" $defs = Import-CSV $path -Delimiter ';' $row = $defs.Count $col = ($defs | Get-Member -type NoteProperty).count # Tabelle erzeugen if($rw -eq 0) {$rw=1} $Table = $Selection.Tables.add($Selection.Range,$row+1,$col) # Style der Tabelle festlegen $Table.Style = "Einfache Tabelle 1" $sel = $Table.Range $sel.Style = "Standard" ## Überschriften ausschneiden und in Tabelle eintragen $colheads = ($defs | get-member -type NoteProperty) $i = 1 ForEach($colhead in $colheads) { $Table.Cell(1,$i).Range.text = $colhead.Name $i++ } ## Inhalte der Spalten/Zeilen auslesen und eintragen $i = 0 $j = 0 ForEach($def In $defs) { for ($j=0; $j -le $colheads.Count-1; $j++) { $Table.Cell($i+2,$j+1).Range.text = $defs[$i].($colheads[$j].Name) } $i++ } Das hier ist die Zeile, in der die Spaltennamen ausgelesen werden. Hier liegt sicher der Hase im Pfeffer: $colheads = ($defs | get-member -type NoteProperty) Vielen Dank schon mal!

Ich hab jetzt mal im Forum und www die Runde gemacht und (nochmal) gesucht. Weiß nicht, ob meine Suchworte jetzt die richtigen waren - in der Konsequenz sehen aber alle Threads doch fast gleich aus. Es wird eine Frage ähnlich meiner gestellt und als erste Antwort kommt eine Gegenfrage: "Warum machst Du das überhaupt?". An der Diskussion darüber verlaufen die meisten Threads dann im Sand. Ich bitte, mich nicht falsch zu verstehen - Diese Gegenfrage ist natürlich berechtigt, weil es tatsächlich kaum (technische) Gründe gibt, welche gegen eine klassische Migration sprechen - Konkrete Aussagen, was denn nun eigentlich aus technischer Sicht gegen einen "Neuanfang mit Datenübernahme" in kleiner Umgebung spricht (vom reinen Aufwand mal abgesehen), hab ich aber auch leider in fast keinem Thread gefunden. Und nur das wollte ich eigentlich wissen.

Hallo Nils, danke für die konstruktive Antwort. Zu den nichttechnischen Gründen für die Bevorzugung eines "Neuanfangs" kann und möchte ich mich in einem öffentlichen Forum nicht äußern. Natürlich ist eine klassische Migration das Mittel der Wahl. Auch ein neuer Firmen- bzw. Domainname (um jetzt mal ein nicht zwangsläufig damit zusammenhängendes Beispiel zu nennen) kann im DNS/AD schon länger geändert werden. Meine Frage habe ich gestellt, da ich eine solche "nichtklassiche" Migration eben nicht jeden Tag mache und die Auswirkungen der Anforderung prüfen möchte. Sorry, dass ich damit einer von diesen "Wieder einer" bin.

Also auch im kleinen besser ADMT + Mailmig? Oder den Neuanfang komplett sein lassen? Edit: Es gibt keine technischen Gründe. Die Anforderung kommt vom Kunden und ist organisatorischer Natur.

Die Gründe sind zumeist organisatorischer Natur - zum Beispiel der Wechsel des Dienstleisters einhergehend mit der Migration. Ein weiterer Grund ist, dass man keinen "Ballast" mitnehmen möchte. Wie sähe denn eine bevorzugte Migration in diesem kleinen Maßstab aus, ohne Ballast mitzunehmen?

Hallo Forum, eine kleine Organisation (15 User) wird mit neuer Hardware ausgestattet und will in diesem Aufwasch einen Neuanfang (neue/frische Domäne) machen. Ich hab mir gedacht, dass ich die Konten in der neuen AD anlege und an jedem PC einen PST-Export und im neuen Profil entsprechend einen Import mache. Nun habe ich gelesen, dass es dabei zu ein paar "Effekten" kommen kann - die ich noch nicht so im Blick hatte (zum Beispiel fehlende Besitzer von Terminen oder Einladungen, die nochmal rausgehen). Gibt es mit meiner radikalen Methode Wege, das zu verhindern - oder hab ich mich verlesen? Wie würdet ihr das alternativ machen? Quelle ist übrigens ein SBS 2008 - Ziel Server 2012 R2 mit Exchange 2013. Grüße und Danke schon mal!

Falls es noch für jemanden relevant sein sollte: Ich habe die Lingeringobjects entfernt, indem ich einen DC zu einem Referenz-DC (refDC) gemacht, indem ich repadmin /removelingeringobjects refDC DCxGUID <NC> gegen jeden DC in der Gesamtstruktur (DCxGUID) ausgeführt habe. Damit habe ich alle Objekte auf diesem refDC gelöscht, welche auf den anderen DC noch herumlungerten. Dies habe ich für jeden Namenskontext (<NC>) mit fehlerhaften Objekten wiederholt. Im nächsten Schritt habe ich den Befehl repadmin /removelingeringobjects DCx refDC_GUID <NC> für jeden DC in der Struktur ausgeführt. Damit wurde der "Zustand" des Referenz-DC mit den anderen DC angeglichen. Die Replikation der DC untereinander funktioniert nun wieder normal. Für die Prüfung der Replikation habe ich übrigens neben repadmin das "AD Replication Status Tool" ( http://www.microsoft.com/en-us/download/details.aspx?id=30005) genutzt. Danke nochmal für eure Antworten.

Hi Norbert, alles in allem reden wir über 20 DC. Davon 2, mit denen nicht mehr repliziert wird, weil die Tombstonezeit abgelaufen ist. Andere replizieren derzeit nicht, weil es lingering objects gibt und "strict replication consistency" an ist. Kein sauberes Entfernen, weil der entsprechende DC ja ohne Verbindung zu den anderen DC runtergestuft werden muss (weil keine Replikation) und damit potentiell Reste des runtergestuften DC verbleiben.

Hallo Blub, mit größerer Installation meinte ich eher die Komplexität. Ein paar Kollegen habe ich hier also leider nicht. Tatsache ist, dass an den Standorten neu installierte Firewalls längere Zeit die Replikation verhindert haben. Die Firewalls sind mittlerweile offen und damit wurde das Problem dann auch erkannt. Der Stand ist, dass nahezu alle DCs auseinander laufen. Die Events 1988 usw. findet man auf ziemlich allen DC. Und ich brauche einen Weg, die Replikation wieder hinzubekommen. Wäre denn eine Lösung, mir einen Referenz-DC herauszusuchen (im Hauptstandort zB) und Repadmin /removelingeringobjects von allen Außenstellen gegen diesen Referenz-DC auszuführen? Damit müssten die DC doch auf einen Stand (den des Referenz-DC) zu bringen sein? Oder sehe ich das falsch? Die Option, einen (oder mehrere) DC zu depromoten, habe ich natürlich immer noch. Dies erschien mir jedoch zu fehleranfällig (kein sauberes Entfernen). Vielen Dank für die Antworten!

Danke schon mal für die Antworten. Ich hab ja das Problem, dass mit mindestens einem DC nicht mehr repliziert wird. Durch das Rehosten mit einem sauberen DC, wie von blub beschrieben, macht man diesen wieder zu einem Mitglied der Gemeinde? Ich hatte ursprünglich den Ansatz, auf allen DC den Registrykey unter services/ntds zu setzen, der die Replikation mit "tombstoned" DC zulässt. Wäre das Ergebnis vergleichbar? Edit: Hier http://technet.microsoft.com/en-us/library/cc757610(v=ws.10).aspx ist der Registrykey beschrieben.

Hallo zusammen, ich sitze gerade vor einer größeren Installation mit mehreren "Struktur"-Domänen unter einem Stamm und entsprechend vielen DCs. Alle DCs halten DNS (AD-integriert). Exchange-Server existieren mehrere. Windows Server ab 2003R2 bis hin zu 2012R2 ist im Einsatz. Sowohl als Member als auch DC. Problem, weswegen ich eigentlich hier bin (dieses Problem ist das derzeit einzig "spürbare"): Ein DNS-Eintrag eines Servers wird nicht an alle Standorte repliziert. DAS ist aber nicht das einzige Problem hier. Wie auch immer: repladmin /showrepl /repsto an einem der Standorte gibt mir sowohl den Fehler 8606 (Es wurden nicht genügend Attribute übergeben, um ein Objekt zu erstellen ...) als auch Fehler 8614 (Der Verzeichnisdienst kann mit diesem Server nicht replizieren, da die ...) zurück. Wiederhole ich die Abfrage an anderen Standorten, bekomme ich ähnliche Fehler. Tatsache ist also wohl, dass ich hier zumindest einen "getombstoneden" DC + lingering objects habe. Ich hab dazu schon ein bissel gelesen - aber richtig sicher bin ich noch nicht: Wie geht man in so einem Fall strukturiert vor? Wie bekomme ich die Gesamtstruktur wieder dazu, sauber zu replizieren? Runter- und wiederhochstufen des/der DC ist ja wohl ein ziemlicher Aufwand, oder sehe ich das falsch? Und wie bekomme ich den Übeltäter sicher heraus? Vielen Dank schon mal für die Antworten!

Hallo Robert, danke schon mal für die Antwort. Zur Implementierung von DA hinter einer Firewall habe ich in den offiziellen Dokumenten immer nur von einem pauschalen Portforward von 443 direkt auf die Schnittstelle des DA-Servers gelesen. Von einem Verzeichnis habe ich noch nichts gehört / gelesen.

Hallo zusammen, bei uns wird Exchange 2010 mittels ActiveSync mit den mobilen Clients (Windows Phone/iOS) synchronisiert. Wir setzen dafür eine Sophos UTM mit Reverseproxy ein. Nun besteht die Anforderung, Direct Access unter Server 2012 zu nutzen, um eine einfache Einbindung der Laptops ohne klassisches VPN zu ermöglichen. Beide Technologien nutzen den Port 443 und wir haben nur eine öffentliche IP. Weiß jemand einen Rat, wie man beide Technologien parallel zum laufen bekommt? Irgendwo habe ich einen Tipp gefunden, wie man DirectAccess zu einem anderen Port gebogen bekommt - das hat aber dort nicht dauerhaft funktioniert. Vielen Dank schon einmal, Carsten

Danke für den Tipp. Wie schon erwähnt, handelt es sich hier um eine NT4-DOMÄNE und um ca.450 Rechner (NT 4 WORKSTATION) auf denen kein ScriptingHost etc. läuft und auch nicht laufen soll. vbs geht also leider nicht. Ansonsten wäre das ganze auch kein Problem gewesen ... Danke trotzdem, cascade