MurdocX

Es liest sich so, als hättest du eine Evaluation-Edition. https://windowswizardry.wordpress.com/2016/11/18/fixing-the-automatic-shutdown-annoyance-of-windows-server-20162012/

Wir nehmen für Backups ein einfaches NAS. Eine Bandsicherung lohnt sich da nicht. Die Geräte (Synology,QNAP) können die Daten auch in andere Gebäude spiegeln. Unser Backup (Veeam) könnte das das z.B. auch.

Hallo Sumimasen, willkommen an Board. Siehe: Quelle: https://docs.microsoft.com/de-de/windows-server-essentials/migrate/step-2--install-windows-server-essentials-as-a-new-replica-domain-controller Für 21 Tage wird er zugelassen, dann nicht mehr. Das betrifft deine beiden vorhanden Versionen. Mit der Standard sollte es gehen, wenn der Foundation der Inhaber aller Rollen bleibt, was hier ja kein Thema ist.

Also verstehen kann ich das Ansinnen schon, durch die regelmäßige Vergabe von neuen Passwörtern das Account-Sharing einzudämmen. Das müsste dann aber m.M.n. sehr oft passieren. Im Endeffekt ist es eine Sache der Gewöhnung bei den Mitarbeitern. Der Effekt wird über die Zeit seinen "Schrecken" verlieren und der gewünschte Effekt bleibt aus. Ich kenne auch Fälle in dem das Account-Sharing gewünscht/benötigt wird. Der Tipp von Mark auf der Cim war gut. Passwörter auf mehr Zeichen erhöhen und gleichzeitig dem Mitarbeiter erklären, dass er sich einen Satz ausdenken soll. Seit dem gibt es keine Diskussion mehr über lange Passwörter. Dann muss das Passwort auch nicht so oft gewechselt werden. Das sich das BSI vom Passwortwechsel entfernt ist auch gut, denn die Vorschriften basieren auf einer falschen Annahme.

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