massaraksch

Hi, Abwesenheitsregel konfiguriert? Siehe Pig... (dummerweise tauchen diese nicht im normalen Regel-Assi auf, auch nicht mit Get-InboxRule)

Hi, bei MSXFAQ recht gut beschrieben: http://www.msxfaq.de/e2007/autodiscover.htm#autodiscover_als_srv_record Den DNS-Eintrag muß natürlich der jeweilige Domaininhaber/Provider machen (so wie der schon den MX auf euch gelegt hat). Ach so, es geht nur um internen Zugriff...

Hi, die Aktualisierung der Quota kann man beschleunigen (normalerweise alle 2h). https://technet.microsoft.com/en-us/library/bb684892%28v=EXCHG.80%29.aspx (dort für Ex2007 beschrieben, soll aber auch für Ex2010/13 gelten) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem "Reread Logon Quotas Interval" (DWORD in Sekunden) "Mailbox Cache Age Limit" (DWORD in Minuten) Also z.B. auf 1800 (Sek.) sowie 30 (Min.) setzen (man beachte die Wertebasis Hex/Dez im Regedit). Ansonsten halt (max. 2h) warten oder Dienstneustart des "MSExchangeIS" (naja, Datenbanken mehr oder weniger kurz offline). Das Setzern/Änderung obiger Werte erfordert allerdings auch einen Restart des "MSExchangeIS" zum Wirksamwerden.

Hi, wie kommst du eigentlich auf die Annahme, daß es die Transaktionsprotokolle sind, die dir den Platz wegnehmen? Ich meine, du kannst die Anzahl/Größe der Transaktionsprotokolle doch SEHEN und weißt, ob sie während der Sicherung gelöscht werden. Wenn das so ist, dann sind es vielleicht irgendwelche anderen Files/Logs, die da wachsen. Kannst dir auch mal ein Tool zum Directory-Scanning (GetFolderSize, TreeSize o.ä.) besorgen und schauen, in welchen Verzeichnissen sich so viel Daten befinden.

Und damit ist sein Problem gelöst?

Hi, die Exchange-Version dürfte zwar nichts mit deine Anfrage zu tun haben, aber du solltest diese über den Outlook-Verbindungsstatus herausbekommen: STRG + Rechtsklick auf das Outlook-Symbol im Systray-Bereich der Taskleiste - Verbindungsstatus... In den Verbindungen findest du fast ganz rechts die Spalte mit der Serverversion. Übrigens... Diese Funktion, die du suchst (Adressvorschläge aus Kontakte/Adressbuch), gibt es bei Outlook so erstmal nicht. Es gibt eben nur dieses Autovervollständigen mit Adressen, an die man schon einmal gesendet hat. Eine VBA-Makrolösung scheint mir recht aufwendig zu sein. Vielleicht gibt es ja sowas als Outlook-Add-In von irgendeinem Hersteller? Fällt mir aber gerade nichts ein...

Hi, RU13 geht direkt auf SP3. Ist ja von MS explizit so beschrieben. Ich habe das auch selbst kürzlich bei einem Kunden auf mehreren ewig nicht gepatchten Servern gemacht (SP3 installiert - Neustart - RU13). Die aktuelle Powershell-Executionpolicy kannst du dir anschauen: Get-ExecutionPolicy -List | ft -a Scope ExecutionPolicy ----- --------------- MachinePolicy Undefined UserPolicy Undefined Process Undefined CurrentUser Undefined LocalMachine RemoteSigned MachinePolicy/UserPolicy sollten auf Undefined stehen. Wenn nicht, dann ist eine GPO aktiv.

Hi, hast du das MSP-Paket per Doppelklick gestartet? Öffne mal explizit eine CMD-Box als Admin ("Als Administrator ausführen") und in dieser CMD dann die MSP aufrufen. Habe mal so einen ähnlichen Abbruch gehabt. War zwar Error 1603 vom Installer, aber Versuch macht klug... Noch was: Es gab mal Probleme, wenn die Powershell-ExectionPolicy per GPO gesetzt war (soll aber eigentlich mit SP3 erledigt sein). Kannst ja mal rsop.msc starten und schauen, ob da so eine Einstellung auf den Server angewendet wird.

Hi, gwmi -namespace root\cimv2 -class win32_volume | select @{ label="DeviceID"; exp={ "{" + $_.DeviceID.Split("{}")[1] + "}" } } Wenn die DeviceIDs ohne {} reichen, dann kann man das "{" + und + "}" natürlich weglassen. (Getestet mit Powershell 2.0)

Hi, was sagt Get-InboxRule -Mailbox POSTFACH bzw. Get-InboxRule -Mailbox POSTFACH | fl

Hm, ich weiß ja nicht, was du eigentlich willst... Dieser Vergleich von Online-Scannern und lokaler Prüfung ist rein akademisch. Du schreibst ja selbst, daß bei VT wohl nicht "irgendwelche anderen Funktionen der Scanner" geprüft werden. Was kann man also dann bezüglich des aktuellen Schutzes der lokalen Scanner sagen? Eben: Nichts genaues weiß man nicht. Virustotal (und andere) sind Hilfsmittel. Nicht mehr und nicht weniger. Ich will hier auch keinen Vergleich von Virenscannern anstellen. Ja, das machen gerne irgendwelche Home-User, die sich ganz doll darüber freuen, daß ihr gerade genutzter Scanner A ungefähr 0,3% mehr Samples erkennt als Scanner B und C. Das ist für mich relativ uninteressant. Nächste Woche sieht das vielleicht anders aus. Ich selbst nutze übrigens auch ein kommerzielles AV-Produkt und nicht die Windows-eigene Lösung.

Was erwartest du? Daß dir jemand das Nachdenken abnimmt? Willst du eine "einfache eindeutige" Antwort? Die gibt es nicht. Es geht nicht darum, ob man Virenscannern "vertraut" (was meinst du damit eigentlich?). Es geht um die Bewertung der Ergebnisse solcher Scan-Tests. Und die sind eben nicht immer 100% korrekt. Positiv wie negativ. Niemand ist "unfehlbar". Menschen nicht. Virenscanner nicht. Und die Ergebnisse solcher Tests können sich halt stündlich ändern. Liegt in der Natur der Sache. Was heißt "nicht stimmen"? Es ist ganz einfach ein Windows 10 mit Standard-Einstellungen des Defenders. Ich sagte doch, daß die Ergebnisse dieser Online-Scanner wohl nicht immer 1:1 auf die jeweils aktuelle lokale Version übertragbar sein müssen. Vielleicht erkennt ihn der Defender heute auch als "Ransom:Win32/Locky.A"? Keine Ahnung.

Eben deshalb ist das reine Schauen auf die Scan-Ergebisse solcher Seiten wie Virustotal auch nicht der Weisheit letzter Schluß. Es kann gut sein, daß bei Virustotal der jeweilige Scanner nichts findet, die lokal installierte Variante aber sehr wohl. Und umgekehrt (was ja noch ärgerlicher wäre).

Bezüglich Virenscanner... Ich bin gerade etwas (positiv) überrascht: Habe versucht, die EXE in meiner Test-VM mit Windows 10 herunterzuladen: Der Standard-Defender (mit den Signaturen von gestern) hat den Download sofort geblockt und als "Trojan:Win32/Hacowi.B!plovk" gemeldet. https://www.microsoft.com/security/portal/threat/encyclopedia/Entry.aspx?Name=Trojan:Win32/Hacowi.B!plock Eventuell Heuristik/Verhaltenserkennung durch den Defender? Scheint jedenfalls nicht so schlecht wie oft behauptet. Die Online-Scanner (Virustotal usw.) machen ja wohl keine Heuristik o.ä., sondern reine Signaturprüfung (hab ich irgendwo mal gelesen). Nachtrag: Verhaltenserkennung entfällt eigentlich. Hab die Datei ja nicht ausgeführt, sondern nur runtergeladen.

Hi, die Wartezeit könnte mit dem altbekannten Wert "Mailbox Cache Age Limit" zusammenhängen (ebenso wie die Mailbox Quotas verzögert wirken). http://blogs.technet.com/b/pakaloge/archive/2009/08/21/send-as-permissions-are-not-enforced-immediately.aspx

Ich hatte doch die funktionierende Zeile in A15 geschrieben? :confused: PS: Dein SKIP ist trotzdem unsinnig. Oder liest du mehrere Zeilen aus einer Datei? Und reg query gibt auch nicht mehrere Zeilen aus, sondern nur eine.

Hi, Batch und FOR-Gefrickel ist ja sowas von Gestern... ;) for /f "tokens=3*" %%i in ('reg query "%REG%" /v Pfad') do set VAR=%%i%%j Was soll eigentlich das seltsame skip=2?

Hi, du erstellst eine Verteilergruppe mit Exchange (entweder eine neue Gruppe oder Umwandlung deiner schon vorhandenen AD-Gruppe) und weist diese ganz normal in der Ressourcenrichtlinie bei "Stellvertretungen dieses Postfachs angeben" zu. Zu beachten ist evtl. folgendes: Bei Gruppen setzt Exchange dabei wahrscheinlich die notwendigen Rechte auf den Ressourcenkalender nicht ordentlich (Recht "Editor/Bearbeiter" nötig, damit die Stellvertreter zu/absagen bzw. moderieren können). Dies muß daher manuell erledigt werden. Beschreibung siehe hier: http://www.msexchange.org/blogs/walther/news/exchange-2010-resource-mailboxes-and-groups-based-delegation-641.html (Exchange 2010)

Hi, Das kannst du machen. Genau sowas brauchst du. Korrekt. Exchange "sieht" nur mailaktivierte Gruppen ("Verteiler"). Also mach deine AD-Sicherheitsgruppe in der Exchangeverwaltung zu einer universellen E-Mail-Sicherheitsgruppe.

Bei Ex2010 war's noch einfacher: Clean-MailboxDatabase DATABASENAME Get-MailboxDatabase | Clean-MailboxDatabase Warum führt MS manchmal solche neuen "Verrenkungen" ein? :confused:

Hi, evtl. hilft "Update-StoreMailboxState": https://technet.microsoft.com/en-us/library/jj860462%28v=exchg.150%29.aspx Schlecht allerdings, wenn die 14 Tage schon vergangen sind... Restore.

Hab jetzt mal direkt geschaut... Bei OL2013 steht der Name des Standardprofils direkt im Outlook-Schlüssel HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook DefaultProfile (während die eigentlichen Profileinstellungen unter HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Profiles\... stehen) Es müßte also lauten: olProfile = WshShell.RegRead("HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\DefaultProfile") Wie man die Verzweigung macht (Version filtern und verschiedene Scripte aufrufen oder direkt im Script verzweigen) ist "Geschmackssache". Kann da gerade nicht so viel Zeit reinstecken... Ergänzung: Hab mal einiges probiert... Man kommt von einem Problem zum anderen :cry: Kurzfassung: Jetzt zuerst Win32/64bit abfragen wegen unterschiedl. Office-Keys unter HKLM, dann dort Office-Versionsnummer auslesen (ob dieser Weg immer 100%ig funktioniert, weiß ich nicht wirklich), wenn OL nicht läuft das Standardprofil abhängig von OL2010...2016 auslesen und anmelden. Aktualisierte Scripte anbei. Ist aber quick&dirty ;) Ren_Outlook_Abfrage.txt Ren_Outlook_Auto.txt

Wieso "wider besseren Wissens"? Niemand weiß vorher, daß "irgendeine" Anwendung mal ein Problem damit haben könnte. Und es geht ja hier um ein MS-eigenes Produkt und nicht um irgendein selbstentwickeltes Script oder ein Wald-und-Wiesen-LDAP-Tool. In diesem Fall vermeidbar eindeutig durch Microsoft. Schließlich sagt ihre eigene AD-Spezifikation, daß auch Sonderzeichen (z.B. Schrägstrich) erlaubt sind! Und Exchange hatte vor Ex2013 auch kein Problem damit, nur das EAC spinnt. Also hat es MS sozusagen im EAC "versaut". Sie sollten in einem ihrer Hauptprodukte schon etwas sorgfältiger (mit den eigenen Vorgaben!) umgehen. Davon abgesehen hat das EAC von Ex2013 sowieso einige Macken.

Naja, dann sollte Microsoft auch dokumentieren, daß bestimmte Zeichen nicht genutzt werden dürfen. Laut MS-Definition ist im OU-Namen jedes Zeichen erlaubt (wegen LDAP-Namenskonvention). Beim Ansprechen des Objekts über den CN muß das entsprechende System den Slash halt escapen. Und da steckt wohl der Bug im Exchange (2013). OK, ich würde auch keinen Schrägstrich verwenden. Aber so ungewöhnlich scheint mir das auch wieder nicht.

Ah, ist das bei OL2013 in den normalen Office-Schlüssel gewandert? HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Profiles Richtig? Müßte man also bei Bedarf noch die Outlook-Version im Script abfangen...