NilsK

Moin,

für sowas brauchst du gar kein kompliziertes Skript. Suchmaschinen lassen sich (meist) gut direkt über den URL steuern. Wie das geht, kannst du einfach selbst rausfinden.

Suche bei Google (oder was du halt nutzt) nach irgendwas. Wechsle manuell auf die zweite Seite. Dann schau dir den URL an. Da ist einiges Beiwerk drin, aber du wirst zwei Parameter finden: q= gibt den Suchbegriff an und start= steuert die Ergebnisseite. Die anderen Parameter kannst du einfach weglassen. 

Folgender URL zeigt dir die dritte Ergebnisseite zu "hurz":

https://www.google.com/search?q=hurz&start=20

Das könntest du dann sogar in die Adressleisten-Suche integrieren und brauchst dann überhaupt kein Skript.

Gruß, Nils

Moin,

prima, danke für die Rückmeldung.

Sowas kommt beim Scripting vor. Schön, dass es jetzt funktioniert.

Gruß, Nils

Moin,

und das sagt uns jetzt was?

Gruß, Nils

Moin,

ich habe "mein Skript" (das ja Olafs ist) mal um eine Ausgabe in eine Datei erweitert (also im Prinzip Olafs Ausgabezeile wieder eingefügt). Da funktioniert es genauso und tut, was es soll: Der Inhalt der Datei ist ohne die erste Zeile drin.

Allerdings: Die Dateigröße ist verdoppelt. Ich nehme mal an, dass die PowerShell den ANSI-Text meiner Beispieldateien implizit in Unicode wandelt. Das wird man sicher auch beeinflussen können, dazu fehlt mir aber die Zeit.

Kann es sein, dass es bei dir in Wirklichkeit auch so ist?

Gruß, Nils

Moin,

hier tut Olafs Code, was er soll. Vielleicht kommen wir den Dingen auf die Spur, wenn du einen Trockenlauf machst und die Inhalte erst mal nur im Fenster ausgibst:

Get-ChildItem -Path $Test_ROOT -Filter *.txt |
    ForEach-Object {
      $ContentOhneErsteZeile = Get-Content -Path $_.FullName | Select-Object -Skip 1
      $_.FullName  
      $ContentOhneErsteZeile 
      '****** '
    }

Gruß, Nils

Moin,

man behalte dabei im Auge, dass diese Fassung nur exakt den einen String prüft. Das ist hier die Aufgabe, dann ist das okay. Das wird aber scheitern (oder zumindest viel umständlicher werden), wenn sich die Aufgabe ändert. Spätestens dann sind die Mittel der PowerShell deutlich überlegen.

Dabei allerdings sollte man auch aufpassen: Der Weg, das über die Registry auszulesen, hat auch so seine Tücken. Da kommt dann ein String raus ... da können numerische Vergleiche fehlschlagen. Und es ist auch nicht gesagt, dass der Registrywert dauerhaft das ausgibt, was man davon erwartet. Gerade bei Windows-Versionsnummern hat Microsoft da schon eine ganze Menge an Permutationen durch.

[Windows und der Fluch der Versionsnummer | faq-o-matic.net]
https://www.faq-o-matic.net/2015/05/18/windows-und-der-fluch-der-versionsnummer/

Zu dem Thema aufschlussreich ist ein Blick auf ein verwandtes Thema: In Hyper-V gibt es eine Schnittstelle, um die Version der Integrationsdienste einer VM auszulesen (per (Get-VM <Name>).IntegrationServicesVersion) ). Seit Windows 2016 gibt diese aber immer 0.0 zurück, und eine neue Methode gibt es schlicht nicht.

Gruß, Nils

Moin,

mag sein, dass das in eurem speziellen Fall hilft - aber man sollte hier schon noch erwähnen, dass man mit dem Abschalten dieser Option verhindert, dass der Host die VM über eine Sicherung informieren kann. Dadurch kann diese ihre Applikationen nicht in Konsistenz bringen. Das kann erhebliche Folgen haben, wenn das Recovery-Konzept darauf beruht.

Das ist also keinesfalls ein Tipp "für alle".

Gruß, Nils

Moin,

das Web bietet einige Informationen dazu. Ich sehe keine Einschränkungen für die geplante Nutzung.

https://www.qwant.com/?q=sql server compact&t=web

Gruß, Nils

Moin,

mein Verdacht ist, dass auf dem "ersten", also derzeit wohl einzigen DC die Replikation abgeschaltet ist. Dann kann ein zusätzlicher DC auch nichts replizieren. Genaueres lässt sich aus meiner Sicht nicht sagen, weil ich große Teile des Threads im Detail nicht verstehe (sehr viele Dreifachpunkte, Ausrufezeichen und Großbuchstaben, aber wenig strukturierte Information).

Allerdings scheint mir hier so viel vergurkt zu sein, dass ich - wäre ich in deiner Situation - nicht mit Forensupport weitermachen würde. Ich riefe mir jetzt einen Berater vor Ort, der sich mit der Materie auskennt und systematisch und in Ruhe die Fehlerbehebung durchführt.

Gruß, Nils

Moin,

SQL Server Express wird ja nicht separat lizenziert und hat keine Lizenzkosten, daher stellt sich das Problem dort gar nicht, denke ich. Die "Hochverfügbarkeit" liegt in dem Konstrukt unterhalb des Betriebssystems, weil ihr ja anscheinend die VMs über vSphere HA absichern wollt.

Euch muss nur bewusst sein, dass der SQL Express dann auch ein SQL Express bleibt. Auf Applikationsebene habt ihr keine erhöhte Ausfallsicherheit.

Hier findest du die Lizenzbedingungen:

https://www.microsoft.com/de-DE/download/details.aspx?id=29693

Dort heißt es unter 1. gleich:

Zitat

Sie sind berechtigt, eine beliebige Anzahl von Kopien der Software auf Ihren Geräten zu installieren und zu verwenden.

Damit dürfte euer Fall abgedeckt sein.

Gruß, Nils

Moin,

dann spricht das für Tier-1.

Gruß, Nils

Moin,

wer meldet sich auf dem WSUS an? User oder Admins?

Gruß, Nils

Moin,

Der Beschreibung nach ist ein USN-Rollback aufgetreten und von den DCs bemerkt worden. Die schalten die Replikation dann ab.

Die Behauptung, die Replikation würde wieder funktionieren, lässt sich zumindest anzweifeln: wenn es nur einen DC gibt, kann man das gar nicht feststellen.

Es kann also gut sein, dass die Replikation immer noch aus ist. Ich würde jetzt systematisch vorgehen und nicht einfach wilde Dinge ausprobieren.

Gruß, Nils

Moin,

Dafür dass du die Umgebung und die Anforderungen nicht kennst, lehnst du dich aber weit aus dem Fenster ...

Zwischen "1 Account für alle" und "1000 separate Accounts" ist eine Menge Platz für ein angepasstes Konzept.

Gruß, Nils

Moin,

erst mal langsam. Sprichst du von einer Partition in einer VM (einer virtuellen Maschine) oder auf dem Host (dem physischen Server, der die VMs betreibt)?

Gruß, Nils

Moin,

ah, OK, dann verstehe ich. Du meinst, wenn der zweite Host nur beim Recovery genutzt wird und sonst nicht. In dem Fall müsste man aber die Lizenzen sowieso logisch übertragen. Dann könnte man den Host auch gleich richtig installieren, statt sich mit der "kostenlosen" Variante zu plagen. Einen Host hat man meist in einer Stunde fertig installiert (oder auch weniger).

Den TO hatte ich so verstanden, dass beide Hosts im Normalbetrieb verwendet werden. Dann müssen die Lizenzen auf den Hosts vorliegen.

Gruß, Nils

Moin,

vor 40 Minuten schrieb testperson:

es wäre evtl. noch eine Idee den Windows Server 2016 mit Hyper-V Rolle durch einen kostenlosen Windows Hyper-V Server 2019 zu ersetzen. Dann hättest du auf beiden Hosts die Config Version 9.

das würde Null Euro sparen. Die Lizenzen müssen auf dem Host für die VMs vorliegen, die darauf laufen. Wenn also Windows-Server-VMs darauf laufen, ist für den Host dieselbe Lizenzierung für den "kostenlosen" Hyper-V nötig wie für einen "vollwertigen" Windows Server 2019.

Ich habe hier im Board schon ein paarmal ein Video verlinkt, in dem ich das erkläre.

Gruß, Nils

Moin,

die Methode PromptForChoice() gibt immer nur die Indexnummer der Auswahl zurück. Dein Code müsste diese also noch auswerten. Ein Beispiel dafür findest du hier, sehr simpel mit "switch":

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-powershell-1.0/ff730939(v=technet.10)

Je nachdem, was ihr vorhabt, könnte man die Werte in ein Array schreiben und damit dann die gewählte Option leichter zuordnen als per "switch".

Gruß, Nils

Moin,

nein, läuft sie nicht. Du müsstest die VM dann innerhalb von deren Betriebssystem noch mal neu anpassen. So erhält sie eine neue Netzwerkkarte, die unkonfiguriert ist. Die alte Konfig kannst du aber auch nicht einfach so zuweisen, weil diese noch an die ehemalige, inaktive Karte gebunden ist. Also ein wenig manueller Aufwand. Es könnten auch noch weitere Punkte dieser Art dazukommen.

Das wäre höchstens eine Notlösung, aber kein sinnvoller Recovery-Weg.

Gruß, Nils

Moin,

sprechen wir wirklich von einer PST-Datei oder von OST-Dateien?

Unabhängig davon und auch wenn es "früher" ging - so ein Volumen ist in einer Mailbox nicht gut. Die Probleme, über die ihr jetzt stolpert, werden nicht die letzten sein, wenn ihr bei solchen Volumina bleibt. Archivierung wäre hier in der Tat sehr zu erwägen.

(Wobei wir jetzt die Dinge auch nicht vermischen sollten. Wir reden hier von Verdrängungs-Archivierung, das hat mit der Sorte Archivierung, zu der man evtl. rechtlich verpflichtet sein kann, erst mal nichts zu tun.)

Gruß, Nils

Moin,

findest du nicht, dass es langsam an der Zeit ist, jemanden ins Haus zu holen, der sich mit der Materie auskennt?

Solange der BSERVER noch im AD stand, ging das AD natürlich davon aus, dass es versuchen muss, ihn zu erreichen. In Wirklichkeit gab es den ja nicht mehr, also keine Antwort, daher die Fehlermeldung. Da steht aber nicht, dass deswegen das Löschen des Computerobjekts fehlschlug.

Da es hier um die Grundfunktion des Windows-Netzwerks geht, rate ich, einen Fachmann hinzuzuholen. Forensupport ist an der Stelle nicht sinnvoll.

Gruß, Nils

Moin,

vielleicht sollten wir das Problem noch mal beschreiben. Ich habe verstanden: Es ist auf dem Client eine PST-Datei vorhanden, und die soll in die Exchange-Mailbox importiert werden. Falls das gar nicht so ist, bitte noch mal klären, worum es eigentlich geht.

Gruß, Nils

Moin,

okay, die ntdsutil-Kommandos können keine Wirkung gezeigt haben, weil das so nicht funktioniert. Meines Erachtens ist die Darstellung unter docs.microsoft.com nicht richtig. Ich habe jetzt leider keine Zeit, das auszuprobieren, aber ntdsutil ist da etwas eigen. Man muss erst mit "select operations target" den DC auswählen, den man dann in einem separaten Kommando mit "remove selected server" löscht. Bei diesem Kommando einen Namen anzugeben, ist nicht vorgesehen. (Vielleicht hat sich das über die Jahre geändert, aber da es ja bei dir auch keinen Erfolg gebracht hat, nehme ich an, dass es immer noch so ist wie früher.)

Hier eine Beschreibung des (meiner Meinung nach) korrekten Verfahrens:

https://www.petri.com/delete_failed_dcs_from_ad

Was dann die angebliche Fehlermeldung zum Global Catalog angeht: Die kann ich nicht nachvollziehen. In deinen Screenshots ist nirgends davon die Rede. Was passiert denn, wenn du in dem Dialog im zweiten Screenshot auf "Löschen" klickst?

Gruß, Nils

Moin,

naja, vermutlich musst du im Exchange-Server die Mailboxgröße anpassen. Den interessiert ja nicht, wie groß auf einem Client eine PST-Datei werden darf.

Gruß, Nils

Moin,

den zweiten Screenshot willst du sicher noch mal entfernen ...

Deine Angaben sind leider nicht ausreichend klar. Was genau hast du beim "Metadatcleanup" gemacht? Wie bist du vorgegangen? Und was waren die Meldungen dabei? Wenn das richtig gelaufen wäre, müsste der DC ja nun aus dem AD entfernt sein, was offenbar nicht der Fall ist.

Und was heißt 

Zitat

nur meckert er zwecks des Globalen Katalogs

Was genau machst du und was genau passiert dabei?

Gruß, Nils