MurdocX

Du musst das Verteilen von DHCPv6 an der Fritzbox unterbinden. DNS macht nur der erste DC, bis der zweite erfolgreich promotet wurde.

Das hier hat mir Google ganz schnell geliefert https://www.tecchannel.de/a/windows-server-2012-hochverfuegbarkeits-setup-fuer-remote-desktop-connection-broker,2039444,4 https://www.petri.com/configure-rds-collections-using-powershell Du darfst gerne mitarbeiten für Deine Lösung.

Irgendwie verstehe ich dein Problem nicht ganz. Könntest du es in Ruhe nochmal bitte erklären?

Wenn du mehr als 1 RD Sessionhost hast, dann ja.

Hallo Daish, ich habe folgende Fragen an Dich: Wann und wo kommt der Fehler? Benötigst du den Verbindungsbroker überhaupt? Was ist beim RDS eine Standardinstallation für dich? Um welches Betriebssystem handelt es sich?

Gibt es denn DEN Standard um ein AD zu kompromittieren? Neee Das ist nicht wie bei einem Client einfach von USB/CD/DVD booten und die Viren entfernen. Das ist wie mit Schimmel an der Wand. Man weiß zwar wie man ihn los wird, aber erst mal nicht wie tief er schon in der Wand ist und damit immer wieder kommt. Ich bin der gleichen Ansicht. Laut einer Statistik von Microsoft wird ein unbemerkter Zugriff erst im Schnitt nach einem Jahr bemerkt/aufgedeckt. Wer weiß wie lange der Zugriff schon besteht.

Ich hatte letztens eine Triade von Installationen hinter mir, die im Setup oder danach abgeschmiert sind. Unter Anderem auch mit diesem Fehler des öfteren. Bei dem Computer waren die RAM-Riegel defekt. Nimm einen RAM-Test deines Vertrauens.

Hänge mal bitte bei Olafs "Out-File" ein "-Encoding utf8" dahinter. Funktioniert es dann? Edit: Microsoft unterscheidet zwischen "UTF8NoBOM" und "UTF8". Mir erschließt sich der Unterschied nicht. // Powershell 6.0 + Die Powershell 5.1 hat default ein Encoding: Out-File -> Unicode Set-Content -> Default -> ANSI Die Powershell 6.0 + Out-File -> UTF8NoBOM Set-Content -> UTF8NoBOM Das sollte hier Klarheit in das Verhalten bringen.

Set-Content und Out-File nehmen default, laut Microsoft Zitat: "The default value is UTF8NoBOM". Das bestätigt deine Annahme. @epsodus Welche Kodierungen haben deine XML-Dateien?

Wie sieht es aus, wenn du mein Skript verwendest?

Schneller ist nicht immer besser. Ich hab schon einen Fehler bei mir gefunden

Get-ChildItem -Path $Test_ROOT -File -Filter *.xml | ForEach-Object { (Get-Content -Path $_.FullName | Select-Object -Skip 1) | Set-Content -Path $_.FullName -Encoding UTF8 } Ich würde hier mal mit ForEach-Objekt arbeiten und für die Auflistung der Dateien Get-ChildItem. Edit: Ausgebessert

Das Skript bezieht sich auf diesen Artikel: https://docs.microsoft.com/de-de/sharepoint/administration/back-up-a-farm Das Wesentliche sind folgende Befehle: Add-SPShellAdmin Backup-SPFarm -Directory <BackupFolder> -BackupMethod {Full | Differential} [-Verbose]

Wie du hier siehst und ich auch schon oben erwähnt habe, ist das Skript schlecht geschrieben. Ich bin mir sicher das ist nicht das einzige Skript zum Sichern von SharePoints und möchte Dir raten ein Anderes zu suchen.

oh.. Doch nur so wenig Text.. An die Kürze komme ich in der PS nicht ran. Jetzt hat er die Qual der Wahl

Mit einer Batch kann ich Dir nicht weiterhelfen. Viel einfacher geht das mit der Powershell. Füllen musst du die Variablen noch. Das Skript frägt die Betriebssystemversion ab und wenn die Version kleiner als 1909 ist, dann wird der Upgrade-Prozess durchgeführt. [string]$SetupPath = 'Hier kommt der UNC-Pfad zu der Setup-Datei herein' [string]$SetupArgs = 'Hier kommen die Argumente /upgrade etc. herein' [int]$CurrentOsVersion = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\" -Name ReleaseID -ErrorAction SilentlyContinue).ReleaseId if ($CurrentOsVersion -lt 1909) { # Start Upgrade Start-Process -FilePath $SetupPath -ArgumentList $SetupArgs -Verb RunAs -Wait }

Tatsächlich nimmt Windows nur das Format der jeweiligen Sprache an. Auch die amerikanischen Beispiele funktionieren bei mir nicht. Hier sollte eine Konvertierung in ein deutsches Format vorher erfolgen. EDIT: Interessant war hier der Punkt die Sprache beim Parsen mit einzubinden. Hab ich vorher auch noch nie gemacht. ## Find the old backups in spbrtoc.xml $old = $sp.SPBackupRestoreHistory.SPHistoryObject | Where-Object -FilterScript { $UsCulture = [cultureinfo]::GetCultureInfo('en-US') $StartTime = $_ | Select-Object -ExpandProperty 'SPStartTime' $StartTimeDate = [datetime]::Parse($StartTime,$UsCulture) $SevenDaysAgo = (Get-Date).adddays(-$days) $StartTimeDate -lt $SevenDaysAgo }

Powershell bietet die Möglichkeit zu gruppieren über: Group-Object | docs.microsoft.com https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/group-object?view=powershell-7 Vielleicht hilft Dir das weiter.

Damit ist jeder Datensatz eindeutig. Meiner Meinung nach schließt sich dann "-unique" aus. Vielleicht ist Format-Table etwas für Dich. Dort kann man die einzelnen Eigenschaften in den Expression für sich verändern. Format-Table Name, @{ Label=”Folder”; Expression={$_.Path} }, Description –AutoSize

## Find the old backups in spbrtoc.xml $old = $sp.SPBackupRestoreHistory.SPHistoryObject | Where-Object -FilterScript { $StartTime = $_ | Select-Object -ExpandProperty 'SPStartTime' $StartTimeDate = [datetime]::Parse($StartTime) $SevenDaysAgo = (Get-Date).adddays(-$days) $StartTimeDate -lt $SevenDaysAgo } Das hier wäre ein Vorschlag. Leider kenne ich nur die Werte die von MS vorgegeben wurden. https://docs.microsoft.com/en-us/previous-versions/office/developer/sharepoint-2010/ms414604(v%3Doffice.14) Wenn hier natürlich keine Werte oder Fehlerhafte vorhanden sind, muss das von Dir kontrolliert werden.

if ($old -eq $Null) { write-host "No reports of backups older than " + $days + " days found in spbrtoc.xml.`nspbrtoc.xml isn't changed and no files are removed.`n" break } if ($old -eq $Null) ..... Diese Zeilen geben keinen Sinn, denn wenn $old = $null dann wird das Skript durch break abgebrochen und beendet. Damit wäre die zweite Abfrage unsinnig, denn sie wird nie aufgerufen. Falls 2 das break wäre falsch, dann kann man die zwei if - Abfragen zu einer formulieren. In Beiden Fällen gibt es Verbesserungspotential Hier wird die Variable $date aufgerufen, bevor ihr ein Wert zugewiesen wurde. Dort kann nie etwas drin stehen. Hier das Gleiche. Die Variable $date und $portalRecycleDays wurde vorher nicht definiert. Können also nie einen Wert enthalten. $sp = gc $spbrtoc $old = $sp.SPBackupRestoreHistory.SPHistoryObject | Where { (Get-Date $_.SPStartTime) -lt ((get-date).adddays(-$days)) } Ich vermute den Fehler in der XML-Datei, denn dort wird eine Startzeit verarbeitet. Lösche doch mal die Uhrzeit aus der XML-Datei und probiere es neu. Alternative zum Probieren (ich hab es nicht getestet) Where { (Get-Date $_.SPStartTime) ändern zu: Where-Object -FilterScript { (([Datetime]::Parse($_.SPStartTime)).ToShortDateString()) EDIT: Eine Anmerkung sei mir noch erlaubt. Das Backup wird auf dem gleichen Server gesichert, auf dem sich auch der SharePoint befindet. Im Falle eines Serverausfalls ist das die denkbar schlechteste Option

Ich nimm an, dass du solche Sachen schon durch hast, oder? https://www.makeuseof.com/tag/5-tips-fix-windows-store-app-issues-windows-10/ Alternativ, wenn der Pfad noch stimmt, mal die Konfig unter die Lupe nehmen.

Wenn der Netzwerkpfad nicht gefunden wird, kann das auch DNS-Thema sein. Ich komme gleich auf den Punkt. Befindet sich beim Client oder beim DC ein DNS-Eintrag der NICHT auf den/die Domaincontroller zeigt? Hier wird oft fälschlicherweise der Router/Firewall eingetragen.

Du könntest es auch mit einem Pipe Clip probieren | Clip Dann ist die Ausgaben in der Zwischenablage.

Die Frage die ich mir stellen würde wäre, ob ich ein produktiv Netzwerk für das aktive Experimentieren hernehmen möchte. Um die Basics zu verstehen, solltest du an einem funktionierenden AD üben, um die Funktionsweise und Abhängigkeit der Dienste zu erlernen. Was lernen kannst du besser von einem Servicetechniker, der dir die AD-Landschaft repariert und erklärt. Ich wünsche ein frohes Gelingen.