massaraksch

Hi, eine relativ einfache Möglichkeit wäre, die Aufruf-Verknüpfung anzupassen. Standard (Ex2010) ist ja: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0 -noexit -command ". 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto" Ja, ziemlich lang ;) Wenn du da hinten deinen Befehl mit Semikolon dranhängst, wird er bei jedem Start über diese Verknüpfung zusätzlich ausgeführt, also: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0 -noexit -command ". 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; Set-AdServerSettings -ViewEntireForest $true" PS: Irgendwas in die Powershell-Profildatei ($PROFILE) zu schreiben bringt in diesem Fall nix. Das wird zwar bei jedem Start der Powershell ausgeführt, aber VOR den Exchange-Modulen und da kann man halt noch keine Exchange-Kommandos nutzen.

Hi, das muß kein "Mobile Device" im strengeren Sinne sein. Windows 8/10 Mailapp oder irgendein anderes Dingens, was EAS versucht? PS: Vielleicht mal im IIS-Logs schauen... Da sollten doch die Zugriffe mit Username und Device-Strings stehen.

Schon wieder dieses Oracle-Zeugs für's WebReady Viewing! :thumb2:

Hi, scheint, als gäbe es einen Unterschied zwischen den Listen "Sichere Absender" und "Blockierte Absender". Bei "Blockierte Absender" werden Einträge ohne @ problemlos akzeptiert (dort hab ich getestet) und bei "Sichere Absender" nicht. Wahrscheinlich will Outlook damit gerade verhindern, dass man "versehentlich" eine ganze Domain+Subdomains freischaltet. Mal so, mal so. Outlook ist irgendwie nicht stringent :confused: Idee: Da der IE hier schon mal angesprochen wurde... Im Trust Center (Sicherheitscenter) von Office/Outlook gibt es ja die Einstellung, Bilder von Seiten in der "Vertrauenswürdigen Zone" herunterzuladen. Siehe Pig. Wenn du nun die *.newsletterdomain.com per GPO in die Zone der "Vertrauenswürdige Sites" reinbringst...

Hi, laut Outlook selbst soll das auch ohne @ gehen...

Hi, Naja, die Wildcards sind ja nicht in einer GPO, sondern in einer Textdatei, die von Outlook einfach ausgelesen wird. Insofern hat das mit der GPO selbst nicht viel zu tun. Ich glaube aber, Wildcards werden in den Junk-Mail-Listen nicht ausgewertet. Versuch mal ohne, also nur: newsletterdomain.com Hinweis: Kein @ hinzufügen!

Hi, sieht so aus, als müßtest du dein "get-content " noch in einen String umwandeln. Versuchs so: entweder: $inhalt = get-content C:\TEMP\text.txt | out-string oder: $inhalt = (get-content C:\TEMP\text.txt) -join "`n" Dann Mail senden mit $inhalt als Body: Send-MailMessage -SmtpServer MAILSERVER -From VON -To AN -Body $inhalt -Subject Betreff PS: out-string hat erstmal den Nachteil, dass die Zeilenlänge auf die Breite des Hosts (der aktuellen Shell, d.h. im Standard 80 Zeichen) begrenzt ist. Kann man z.B. mit "Out-String -Width 1024" erweitern. Das "`n" bei join bedeutet Zeilenumbruch. PPS: Das [string]::join([environment]::NewLine von Sunny61 macht im Prinzip das gleiche wie mein -join "`n".

Hi, LOL ;) Nein, ich lache nicht über dich... Ich hatte mal in einem Script ein "\\server\c§\..." und bin fast verzweifelt :)

Hi, muß man IMHO auf den Clients machen, Stichwort Gruppenrichtlinien. Kurz gefasst erstellt man eine sog. "Junk-E-Mail-Filterliste", d.h. eine triviale Textdatei, die die gewünschten Adressen/Domains enthält und weist diese per Gruppenrichtlinie (GPO) den Outlook-Clients zu. Man kann Filterlistendateien für "Sichere Absender", "Sichere Empfänger" und "Blockierte Absender" erstellen. Siehe: https://technet.microsoft.com/de-de/library/cc179183.aspx Wie das allgemein beim Azure-AD mit GPOs so funktioniert ist mir jetzt nicht praktisch geläufig. Bei uns im "lokalen" AD geht das recht gut.

Hi, ja, im Zusammenspiel AD + Exchange muß man oftmals sehr genau hinsehen und darf sich nicht auf die "kreativen" Umsetzungen bei Exchange verlassen. Übrigens gibt's zum altRecipient auch ein entsprechendes Backlink-Attribut: Get-ADObject -Properties altRecipientBL -Filter { altRecipientBL -like "*" } | select Name,altRecipientBL Da sieht man recht schnell, VON wem werden Mails an jemanden weitergeleitet. Ist so ähnlich wie mit dem msExchDelegateListLink und dem zugehörigen msExchDelegateListBL.

Hi, Hm, jain ;) Das entsprechende AD-Attribut für ForwardingAddress heißt altRecipient. Und da steht der DN drin. Siehe: Get-ADUser xyz -Properties altRecipient Die Exchange Get-Cmdlets "übersetzen" das eigentlich nur in den canonicalName, denn man dann der Shell zu sehen bekommt. Kann man also so oder so sehen :)

Hi, normalerweise steht in ForwardingAddress der DN (DistinguishedName) des Zielobjekts. Aber auch egal, get-recipient "frißt" sowieso fast alles als Identity-Parameter. Also übergeben wir das einfach mal in einem Ausdruck (expression) für select: (get-mailbox -filter {forwardingaddress -ne $empty}) | select displayname,primarysmtpaddress,@{name="ZielSMTP";expression={(get-recipient $_.forwardingaddress | select primarysmtpaddress).primarysmtpaddress}} Funktioniert hier mit Ex2010. OK, sieht gruselig lang aus ;)

Hi, evtl. RBAC kaputt? HTTP 403 ist ja "forbidden" bzw. "deny access", also Zugriff verweigert (die Web-Ressource ist erreichbar, aber du "darfst" nicht). Und der Zugriff auf die Optionen wird über RBAC gesteuert. Also: RoleAssignmentPolicies anzeigen lassen: Get-RoleAssignmentPolicy | select Name,IsDefault Name IsDefault ---- --------- Default Role Assignment Policy True ... Es muss zumindest die "Default Role Assignment Policy" geben und die ist normalerweise Standard (IsDefault = True) und wird daher jedem neuen Postfach zugewiesen. Weiter: Ist diese Policy den Postfächern zugewiesen? Get-Mailbox POSTFACH | select Name,RoleAssignmentPolicy Name RoleAssignmentPolicy ---- -------------------- POSTFACH Default Role Assignment Policy (oder alle auflisten: Get-Mailbox | select Name,RoleAssignmentPolicy) Falls da nix drinsteht (also RoleAssignmentPolicy = leer) oder irgendwelcher Unsinn, dann ensteht z.B. dieser Fehler HTTP 403, und zwar nur bei Aufruf der OWA-Optionen). Oder die Policy ist kaputt. Mal die Rollen in der Policy anzeigen lassen. Müßte ungefähr so aussehen (ist hier Ex2010, aber 2013 sollte ähnlich sein). Get-RoleAssignmentPolicy "Default Role Assignment Policy" | select -ExpandProperty AssignedRoles | select Name Name ---- MyDistributionGroupMembership MyVoiceMail MyTextMessaging MyBaseOptions MyContactInformation Korrektur, um allen Postfächern die Standard-Policy zuzuweisen, wäre einfach: Get-Mailbox | Set-Mailbox -RoleAssignmentPolicy "Default Role Assignment Policy" -WhatIf (meinen "Lieblingsparameter" -WhatIf natürlich weglassen, ich bin immer vorsichtig) Wenn es das nicht ist, dann müssen wir halt weitersuchen...

Hi, ein Versuch, das mal etwas aufzudröseln... Die globale Adressliste hat laut deines Pigs gar keinen Filter. Demzufolge ist deine erzeugte Variable $filter leer. Es kann nun sein, daß mit dieser leeren Variable der Befehl "Get-Recipient -RecipientPreviewFilter $filter" überhaupt nicht funktioniert. Ist aber eigentlich egal, denn richtig komisch ist deine where-Bedingung: Das "Where-Object {$_.HiddenFromAddressListsEnabled -ne $false}" hat zur Folge, es werden nur die ausgeblendeten Objekte aufgelistet (weil "nicht-gleich Falsch" nun mal "Wahr" bedeutet). Die willst du ja aber gar nicht haben (wahrscheinlich sind auch gar keine ausgeblendet), du willst ja die sichtbaren. Also mach mal dies: (ohne Filter, deine GAL hat je eh keinen) Get-Recipient -ResultSize unlimited | where { $_.HiddenFromAddressListsEnabled -eq $false } | select Name,PrimarySmtpAddress Kommt was? Wenn ja (ich bin sicher), dann wirf das halt in die CSV und schick es per Mail. Ach so, deine Mailing-Funktion ist unnötig kompliziert (brauchte man bei Powershell 1). Ab Powershell 2 geht das einfacher mit "Send-MailMessage". Erläuterung: help Send-MailMessage -det PS: Mach deine Tests erstmal ohne Mailversand. Das ist doch erst der letzte Schritt. Guck lieber, ob überhaupt eine CSV erzeugt wird und was drin steht.

Hi, Wie wird die Adresse in das An-Feld "eingefügt"? Irgendwoher kopiert/gezogen? Bitte mal die SMTP-Adresse direkt eintippen (ja, so richtig mit Tastatur). Passiert der Fehler dann auch?

Hi, siehe Link ("TNEF-Konvertierungsoptionen" oder auch "MAPI-RTF-Format") https://technet.microsoft.com/de-de/library/bb310786(v=exchg.141).aspx Ich würde es zentral einstellen sprich verbieten (Einstellungen für Remotedomänen), damit überhaupt keine TNEF-Nachrichten (MAPI-RTF) nach draußen gehen. Macht nur Ärger. Oder nur an bestimmte Maildomänen erlauben falls gewünscht. Zwar könnte man das leicht für alle Kontakte auf einmal per Command konfigurieren (get-mailcontact | set-mailcontact -UseMapiRichTextFormat <Never | Always | UseDefaultSettings>), aber die zentrale Konfiguration erscheint mir sinnvoller.

Hi, gleiche Clients oder doch unterschiedliche Clients? Tipp: Smartphones mit ActiveSync?

Ah, der altbekannte Fallstrick :rolleyes: Man sollte eben immer einen User "Normalo" als Tester haben...

Hi, nur so'ne Idee: Ist im virt. Verzeichnis "Microsoft-Server-ActiveSync" bei der Windows Authentifizierung unter "Providers..." der Anbieter "Negotiate:Kerberos" aktiviert?

Hi, der Befehl an sich ist wohl korrekt (funktioniert jedenfalls hier™, genauso mit $_.alias und $_.pst usw.). Der Fehler deutet ja auf Zugriffsprobleme zum Postfach hin, wieso auch immer. Schon mal neu angemeldet (ich nehme an, du bist per RDP auf dem Server)? Probier mal nur eine Mailbox zu exportieren und verwende den Parameter "-verbose" zur erweiterten Ausgabe, also direkt: New-MailboxExportRequest -Mailbox TEST -FilePath "\\SBS2011\c$\pst\test.pst" -verbose PS: Und achte auf korrekte Anführungszeichen und nicht so ein aus dem Browser kopiertes Zeug wie diese typografischen Anf.zeichen. Am besten selbst in der Shell eingeben. Ergänzung: wenn eine einzelne Mailbox auch nicht geht, dann mal schauen, ob irgendwas beim MAPI-Protokoll geblockt ist: Get-CASMailbox POSTFACH | fl *mapi* Ergebnis ungefähr so: MAPIEnabled: True MAPIBlockOutlookNonCachedMode: False MAPIBlockOutlookVersions: MAPIBlockOutlookRpcHttp: False

[...entfernt...] Beitrag passte nicht...

Hi, wirklich komische Sache. Kannst dir ja mal die Konfig des entsprechenden Receive Connectors anschauen: Get-ReceiveConnector "ConnectorName" | fl und dort z.b. nach MaxAcknowledgementDelay schauen. Dies evtl. mal abschalten: Set-ReceiveConnector "ConnectorName" -MaxAcknowledgementDelay 0 Hier beschrieben: https://technet.microsoft.com/en-us/library/hh529935%28v=exchg.141%29.aspx Zwar für 2010, aber da es den identischen Parameter auch bei 2016 gibt, sollte das für 2013 nicht anders sein. Kann gerade nicht direkt irgendwo nachschauen. Versuch ist's wert... Merk dir einfach den aktuellen Wert.

Hi, Möglichkeiten: Get-WmiObject win32_volume | ? { $_.DriveType -eq 3 } | select Name [System.IO.DriveInfo]::getdrives() | ? { $_.DriveType -eq 'Fixed' } | select Name Damit ginge z.b. sowas in der Richtung: $drives = Get-WmiObject win32_volume | ? { $_.DriveType -eq 3 } foreach ($d in $drives) { gci $d.name #weitere Befehle }

Hi, mit "Where" würde ich bei sowas nicht arbeiten. Ein direkter Filter mittels INCLUDE sollte schneller sein: gci H:\ -Recurse -Force -Include *.accdb -ErrorAction SilentlyContinue | Format-Table FullName,CreationTime,Length PS: Mit "-Force" bekommst du auch versteckte (hidden) Dateien. "-ErrorAction SilentlyContinue" muß nicht sein, es verhindert aber die störende Anzeige eventueller Fehlermeldungen, falls auf bestimmte Verzeichnisse nicht zugegriffen werden kann.

Hi, Leichen vom alten Server? Kannst mal in der Powershell nach Objekten suchen, die den alten Exchangeserver drinhaben: ([adsisearcher]"msexchhomeservername=*ALTERSERVERNAME*").findall() | select -ExpandProperty Properties | select {$_.name},{$_.msexchhomeservername} | fl Geht natürlich auch in der AD-Benutzerverwaltung (LDAP-Suche, Attribute anschauen) Und wenn du dich dann traust, wirf sie weg ;)