Marco31

Bist du dir denn sicher dass die gpo Einstellungen auf den Clients überhaupt abgewendet werden? Das liest sich für mich nicht so... Bei mir werden Updates um 12:00 installiert und nicht neu gestartet. Und das seit Jahren ohne Probleme...

Ich glaube das Kammergericht ist eher das negativ Beispiel schlechthin. Da sollen ja nicht mal funktionierende Backups vorhanden gewesen sein.

Gerade hier liegt ein Problem - man erkennt nicht mehr am Absender bzw am Betreff ob die Mail seriös ist. Sonst könnte man ja "seriöse" Absender in eine Whitelist einpflegen. Grundsätzlich muss man mittlerweile ja grundsätzlich jeder Email mit Links und/oder Dateianhängen misstrauen.

Hallo Forum, ich habe mich die letzten Tage mit dem Einrichten des Attachment Blocking bei externen Mails auf unserem Exchange 2016 (mit Trendmicro SMEX14) beschäftigt. Die üblichen Verdächtigen habe ich gesperrt - ausführbare Dateien, PDF mit Javascript, Office-Dokumente mit Makro. Da bisher alle .doc, docx, xls, xlsx etc. durchgegangen sind, möchte ich das natürlich im Hinblick auf die Sicherheit optimieren. Die Empfehlung lautet ja auch, die "alten" Office-Formate zu blocken, .doc, .xls etc. Das habe ich auch umgesetzt. Jetzt ist aber die letzte Frage die ich mir stelle: Kann ich die Formate .docx und .xlsx freigeben? Welche Gefahren können hier lauern und wie wird das in eurer Umgebung gehandhabt?

Da scheinst du wohl recht zu haben. Mal schauen was sich noch so findet. Aber auf jeden Fall schon mal vielen Dank für deine Mühe!!!

Ok, der alte Fehler ist weg, zwei neue tauchen auf Jetzt kommt "The reason of the failure was: Die Benennung "" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.." Und das Script scheint in eine Endlosschleife zu laufen (...was ziemlich b***d war, da meine SharePoint Site Collection auf schreibgeschützt war und sich weder über GUI noch PowerShell wieder aktvieren ließ - konnte ich aber beheben, andere Geschichte.)

Leider war auch das nicht erfolgreich. Ich habe aber eines herausgefunden: in der spbrtoc.xml wird die StartTime im Format MM/dd/yyyy HH:MM:SS (01/29/2020 15:34:00) gespeichert. Ändere ich in der XML die Starttime in dd/MM/yyyy HH:MM:SS (29/01/2020 15:34:00), dann löscht das Script wie gewünscht die Backups. Es dürfte also daran liegen, dass das Script aus der spbrtoc.xml ein Datum im US Format erhält, das ganze aber als deutsches Format verarbeiten möchte. Oder unterliege ich da jetzt einem Denkfehler? Leider reichen meine PS-Kenntnisse nicht mal annähernd für die Änderung des Scripts :-(

@MurdocX: Habe die von dir im letzten Teil vorgeschlagene Änderung durchgeführt, bringt jetzt folgenden Fehler: The reason of the failure was: Ausnahme beim Aufrufen von "Parse" mit 1 Argument(en): "Die Zeichenfolge wurde nicht als gültiges DateTime erkannt.". Keine Angst, ich sichere NICHT auf den gleichen Server. Ich habe nur das Script in der Originalform ohne Namen/Pfadanpassungen gepostet

Sorry, das mit dem Code formatieren zu spät gelesen.... Wurde geändert! Die Frage ist da nur wo... Wenn ich $today = (Get-Date -Format yyyy-MM-dd) auf dd-MM-yyyy umstellen kommt der gleiche Fehler.

Hallo liebe PowerShell-Kundige, ich möchte mit dem PowerShell-Script von http://sharepoint4newbie.blogspot.com/2011/02/sharepoint-farm-backup-and-cleanup.html meine Sharepoint-Farm sichern und die Sicherungen aufräumen. Es gibt da aber ein kleines Problem mit dem Script - führe ich es aus, bekomme ich den Fehler "Der Parameter "Date" kann nicht gebunden werden. Der Wert "01/29/2020 08:54:02" kann nicht in den Typ "System.DateTime" konvertiert werden. Fehler: "Die Zeichenfolge wurde nicht als gültiges DateTime erkannt."." Ich vermute mal es hat mit dem Datumsformat zu tun da das System auf Deutsch installiert wurde. Leider bin ich aber in PowerShell nicht wirklich bewandert, daher möchte ich um Hilfe bitten um das Script so anzupassen, dass das Script das Datum verarbeiten kann. Hier noch mal das Script: ##==================================================================## ## PowerShell SharePoint 2010 Farm Backup, Cleanup and Email Script ## ## Version: 2.0 ## ## Last updated: 04 Jan, 2012 ## ## Description: This script will perform the following ## ## 1) Backup Site Collection ## ## 2) Backup SharePoint Farm ## ## 3) Cleanup old backup and old farm backup ## ## 4) Log deleted file in cleanup.log ## ## 5) Send out status email ## ##==================================================================## $snapin = Get-PSSnapIn -name "Microsoft.SharePoint.PowerShell" -registered if(!$snapin) { Add-PSSnapIn Microsoft.SharePoint.PowerShell } $today = (Get-Date -Format yyyy-MM-dd) $collectionBackupPath ="\\SP2010\E$\Scheduled_Backups\Site-80\" $farmBackupPath = "\\SP2010\E$\Scheduled_Backups\Farm\" $webSite = "http://SP2010" ##Cleanup Backup that is older then x day. $days = 7 ##Variables for Email $emailFrom = "SP2010@SharePoint4Newbie.com" $emailTo = "administrator@SharePoint4Newbie.com" $smtpServer = "MailServer.SharePoint4Newbie.com" ## Send Mail Function Function sendEmail { param($from,$to,$subject,$smtphost,$body) $smtp= New-Object System.Net.Mail.SmtpClient $smtphost $msg = New-Object System.Net.Mail.MailMessage $from, $to, $subject, $body #$msg.isBodyhtml = $true $smtp.send($msg) } Try { $backupFile = $collectionBackupPath + $today + ".Bak" ## Backing up SharePoint Collection Backup-SPSite -Identity $webSite -Path $backupFile -Force -ea Stop ## Backing up SharePoint Farm Backup-SPFarm -directory $farmBackupPath -backupmethod Full ## Location of spbrtoc.xml $spbrtoc = $farmBackupPath + "spbrtoc.xml" ## Import the Sharepoint backup report xml file [xml]$sp = gc $spbrtoc ## Find the old backups in spbrtoc.xml $old = $sp.SPBackupRestoreHistory.SPHistoryObject | Where { (Get-Date $_.SPStartTime) -lt ((get-date).adddays(-$days)) } 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) { Add-Content $farmBackupPath"cleanup.log" "$date - Farm BK Script - No reports of backups older than $days days found in spbrtoc.xml. spbrtoc.xml isn't changed and no files are removed.`n"; } else { ## Delete the old backups from the Sharepoint backup report xml file $old | % { $sp.SPBackupRestoreHistory.RemoveChild($_) } ## Delete the physical folders in which the old backups were located $old | % { Remove-Item $_.SPBackupDirectory -Recurse } ## Save the new Sharepoint backup report xml file $sp.Save($spbrtoc) ##Write-host "Backup(s) entries older than " + $portalRecycleDays + " days are removed from spbrtoc.xml and harddisc." Add-Content $farmBackupPath"cleanup.log" "$date - Farm BK Script - Backup(s) entries older than $portalRecycleDays days are removed from spbrtoc.xml and harddisc."; } ## Remove Previous Site Collection Backup $LastWrite = [DateTime]::Now.AddDays(-$days) $Files = get-childitem $collectionBackupPath"*.bak" | Where {$_.LastWriteTime -le "$LastWrite"} if (!$Files) { Add-Content $collectionBackupPath"cleanup.log" "$date - Farm BK Script - No backup file is older than $LastWrite "; } else { foreach ($File in $Files) { ##Deleting old backup file Remove-Item $File -Force Add-Content $collectionBackupPath"cleanup.log" "$date - Farm BK Script - Deleted file $File ..."; } } ## Composed a status update email for administration $emailSubject = "SharePoint Farm Backup is completed" $emailBody = "SharePoint Farm Backup is completed successfully on "+ $today + "`r`n`r`nFarm backup can be found at $webSite:9999/_admin/BackupHistory.aspx`r`n`r`nBackup files are located at $collectionBackupPath"; sendEmail $emailFrom $emailTo $emailSubject $smtpServer $emailBody } Catch { ## Composed a status update email for administration $ErrorMessage = $_.Exception.Message $emailSubject = "SharePoint Farm Backup Job failed on "+$today $emailBody = "SharePoint Farm Backup Job failed on "+ $today + "`r`n`r`nThe reason of the failure was: $ErrorMessage." sendEmail $emailFrom $emailTo $emailSubject $smtpServer $emailBody } Finally { ## Unlock the site Set-SPSite -Identity $webSite -LockState "Unlock" } ##==================================================================##

Das mag für die Admins Realität sein, aber nicht für die meisten User.

Ok, also Cache deaktivieren. Das sind nicht viele User, pro Mailbox zwischen 2 und 4. Also alles sehr überschaubar

Ok... Bei unseren Usern ist das so ne Sache mit Anleitungen... Die tun sich schon schwer ne SharePoint Liste einzubinden Dumme Frage: Warum sollte ich den Cache separat einstellen oder ausschalten?

Hallo Forum, wir sind gerade an der Migration von Exchange 2010 auf 2016. Dabei sollen auch unsere Öffentliche Ordner zu Shared Mailboxes migriert werden. Ein erster Test war auch erfolgreich. Nun habe ich aber folgendes Problem: die Berechtigungen der Öffentlichen Ordner war über Verteilerlisten gelöst. Ich kann zwar auch bei den Shared Mailboxes Berechtigungen über Verteilerlisten setzen, dann wird das Postfach aber nicht automatische bei den entsprechenden Benutzern eingebunden. Das funktioniert anscheinend nur, wenn man explizit Benutzern den Zugriff erteilt. Das wäre ja ziemlich blöde wenn das so gedacht ist... Ist das ein Bug, habe ich was falsch gemacht oder....?

Scheint sich erledigt zu haben, MoveRequest läuft jetzt. Das Problem war wohl dass am Zielserver die maximale Postfachgröße geringfügig zu klein war, nach Erhöhung des Limits läuft es jetzt. Sieht auf jeden Fall schon mal ganz gut aus. Wie immer die Kleinigkeiten...

Also wenn ich das cmdlet ausführe kommt keine Ausgabe. Arbeitet einen Moment und ist dann wieder bei der Eingabeaufforderung.

Werde ich gleich morgen testen. Was mache ich wenn es tatsächlich in der Quarantäne gelandet ist?

Hallo Forum, ich habe hier ein Problem mit dem ich nicht weiterkomme. Migration Exchange 2010 zu 2016, fast alle Postfächer sind schon am 2016er. Leider macht mir ein Postfach Probleme - es ist ein Postfach mit Archiv. Da das Archiv (von mir erst unbemerkt) eine Größe von 34 Gbyte hat schlug der erste MoveRequest wegen Platzmangel fehl. Ich habe dann den MoveRequest entfernt (Remove-MoveRequest), den Plattenspeicher erhöht und das ganze noch mal versucht. Leider nicht erfolgreich - es kommt folgender Fehler: Das Postfach /o=domain/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCHANGESERVER/cn=Microsoft System Attendant kann nicht geöffnet werden. + CategoryInfo : NotSpecified: (:) [New-MoveRequest], RemoteTransientException + FullyQualifiedErrorId : [Server=EXCHANGESERVER,RequestId=781c85a3-5a17-4ebc-a2dd-5211aa7a9d97,TimeStamp=16.12.2019 1 7:52:37] [FailureCategory=Cmdlet-RemoteTransientException] 9272D5A,Microsoft.Exchange.Management.Migration.Mailbox Replication.MoveRequest.NewMoveRequest + PSComputerName : EXCHANGESERVER.domain.local Google hat nichts wirklich passendes ausgeworfen, oder ich habe was übersehen. Alle anderen Postfächer, auch welche mit Archiv, haben keine Probleme gemacht. Vielleicht hat jemand eine zündende Idee. Auf dem 2016er sind auf der DB-Platte noch 64 GByte frei, auf dem 2010er 20 GByte.

Wenn ich ftp hätte würde ich das tun Und extra deswegen, neee… Muss ich weiter auf Veeam vertrauen.

Heute vcsa auf 6.7.0.42000 upgedatet und immer noch nix mit SMB >1. Mann mann….

Ja, bei 1909 gibt's keine "Neuinstallation" wie man es von der vorherigen Builds kennt. Ist ein simples Update und geht auch entsprechend schnell.

Na ja, seit 1909 nicht mehr so ganz ?

Heute habe ich gesehen dass Marc Heitbrink das Thema auf gruppenrichtlinien.de hat - es ist wohl tatsächlich so dass mehr als 14 Zeichen von Haus aus nicht geht... ? https://www.gruppenrichtlinien.de/artikel/active-directory-security-breach-15-zeichen-kennwortrichtlinie-nicht-moeglich/

Wir haben dafür Drivelock im Einsatz, da kann man alle möglichen Arten von Geräten sperren, mit Whitelist und vielen anderen Funktionen.

"Am angeschalteten Server zu schaffen machen" hat ja wenig mit Verschlüsselung zu tun! Da kommt es dann eher auf die Passwörter an. Wenn sich eine unbefugte Person erfolgreich Zugang zu einem Server verschafft nützt ja die Verschlüsselung nix mehr...