manuel1985

Link und PowerShell haben geholfen, danke.

Moin, gibt es neue Erkenntnisse?

Hat funktioniert, danke :)

Hi Mitstreiter, in der Vergangenheit (unter Ex2003) wurden bei uns die öffentlichen Ordner schwer "missbraucht" und aktuell bin ich dabei, diese aufzuräumen/zu löschen. Aktuellnutzen wir Exchange 2013 Standard (Version 15.0, Build 1263.5). Besteht hier die Möglichkeit, bei mehreren öO gleichzeitig die e-Mail zu deaktivieren? Alles einzeln für Ordner, Unterordner und Unter-Unterordner zu ändern ist sonst eine Arbeit für jemanden, der Vater und Mutter erschlagen hat ;-) Ich habe hierzu den folgenden Link gefunden: https://www.administrator.de/frage/%C3%96ffentliche-ordner-e-mail-deaktivieren-148462.html Dieser hilft mir aber nicht weiter... Vielleicht hat hier jemand eine zündende Idee!? Danke & Gruß Manuel

Aber natürlich: Exchange 2013 Standard, Version 15.0, Build 1263.5 :)

Hallo Mitstreiter, alktuell strunkturiere ich unsere öffentlichen Ordner neu. Wir nutzen Ex2013 auf Server 2012 R2. Beim verändern von Berechtigungen auf diversen Ordnern/Unterordnern erhalte ich oben stehende Fehlermeldung "Die Arraydimensionen haben den unterstützten Bereich überschritten." Siehe auch angehängter Screenshot. Kurz Google befragt erhalte ich u.a. die beiden nachfolgenden Forenbeiträge: https://www.administrator.de/frage/exchange-server-2013-active-sync-einem-smartphone-funktioniert-nicht-137333.html https://www.administrator.de/frage/exchange-2013-%C3%B6ffentliche-ordner-fehler-die-arraydimensionen-unterst%C3%BCtzten-bereich-%C3%BCberschritten-266569.html Leider haben die dort genannten Schritte nicht geholfen, letzterer sorgt eher dafür, dass unser Exchange nicht mehr zuverlässig arbeitet. Kennt hier evtl. jemand das Problem und kann helfen? Danke im Voraus & Gruß Manuel

Habe noch einmal geforscht, ja, es sind die Aliase. Bin jetzt mal per Hand durch die PF gegangen, es sind definitiv mehr als eine Hand voll. Wir sprechen in unserer Umgebung von so ca. 1000 public Foldern. Folgendes Script habe ich genutzt, es scheint aber aufgrund der Menge der PF an seine Grenzen zu stoßen: $mailfolders = Get-MailPublicFolder -WarningAction SilentlyContinue | Select-Object –first 10 | Where-Object {$_.Alias -match "\W"} if ($mailfolders -eq $Null) { write-host "" write-host "Keine Sonderzeichen gefunden!" write-host "" } else { foreach ($mailfolder in $mailfolders) { $rightalias = $mailfolder.Alias -replace"\W","" write-host "Ordner $mailfolder wird geändert. Neuer Alias: $rightalias" #set-mailpublicfolder "$mailfolder" -alias "$rightalias" } } Gibt es eine Möglichkeit, das Script "schrittweise" laufen zu lassen? Also z.B. auf einen übergeordneten Ordner?

Ok, ich fange anders an. Ich starte auf dem Ex2013 mit New-PublicFolderMigrationRequest -SourceDatabase (Get-PublicFolderDatabase -Server Ex2010.domäne.de) -CSVData (Get-Content C:\PFMigScripts\pf-mailbox.csv -Encoding Byte) eine neue Migration. Den Stand der Dinge frage ich mit Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | fl ab und erhalte folgenden Fehler: Fehler: Eigenschaftenausdruck "Vorlage Aufgaben" ist ungültig. Gültige Werte: Zeichenfolgen, die aus den Buchstaben A bis Z (Groß- und Kleinbuchstaben), Zahlen von 0 bis 9, !, #, $, %, &, ', *, +, -, /, =, ?, ^, _, `, {, |, } oder ~ bestehen. In einem Alias kann mindestens ein Punkt eingebettet werden, wobei jedoch jedem Punkt mindestens eines der anderen Zeichen vorausgehen und nachfolgen muss. Unicode-Zeichen von U+00A1 bis U+00FF sind ebenfalls in einem Alias gültig, sie werden jedoch in der aus einem derartigen Alias erstellten E-Mail-Adresse mit möglichst guter Übereinstimmung einer US-ASCII-Zeichenfolge zugeordnet.. Nur leider hat "Vorlage Aufgaben" keinen Alias und wurde bereits in "Vorlage_Aufgaben" geändert. Einzig im AD ist die Schreibweise ohne Leerzeichen noch zu finden. Also muss der Fehler doch im AD liegen, oder?

Guten Morgen, ich stehe seit einiger Zeit vor einem Problem bei der Migration der öffentlichen Ordner von Ex2003 über Ex2010 zu Ex2013. Die Migration von Ex2003 zu Ex2010 funktionierte problemlos, allerdings fallen mir gerade die public Folder dahingehend auf die Füße, dass die Objekte im AD Leerzeichen in der Namensgebung haben. ich habe bereits diverse Scripte im Netz gefunden, welche das lösen sollen, allerdings wurden bisher nur die Mail-Aliase und Namen der public Folders geändert, nicht aber die AD-Objekte. Vielleicht hatte jemand von euch eine Idee, wie ich das lösen kann? Gruß Manuel

I know... :( Habe sowas bereits befürchtet. Ich biete ihm die Lösung so an und er soll entscheiden, was ihm der Aufwand wert ist. Danke und euch allen ein schönes WE Manuel

Hi, bin gerade via Google auf diesen Artikel gestoßen, da ich eine ähnliche Thematik habe. Ist das Problem gelöst? Wenn ja wie? Ich selbst habe gerade meinen ersten Hyper-V Cluster auf Basis von Server 2012 R2 aufgebaut. Als zentraler Storage dient eine HP MSA P2000 1GB iSCSI mit ~1,8TB. Hierauf sind Quorum und CSV abgelegt. Frage: wie sichere ich die Daten/VMs, die auf diesem System liegen? Mein Chef kam eben um die Ecke und will - da das System eine Demoumgebung ist - die MSA auch mal zu Testzwecken an Kunden verleihen. Ich brauche also eine Lösung, welche schnell sichert und schnell recovert, habe bisher aber keine Erfahrung mit Sicherungen eines Cluster/Storage. Für Fragen stehe ich gerne bereit und hoffe nun auf eure Hilfe. Gruß Manuel

Hi, den gleichen Thread habe ich auch auf Administrator.de geschrieben: http://www.administrator.de/forum/verbindung-zum-quellpostfach-konnte-nicht-hergestellt-werden-exchange-2010-sp3-2013-migration-211201.html eigentlich ist mein Problem im Titel schon beschrieben. Führe gerade eine Migration der Public Folder aus und nachdem ich in der Shell [PS] C:\Windows\system32>New-PublicFolderMigrationRequest -SourceDatabase PublicFolder -CSVData (Get-Content c:\PF-Import\PF-Mailbox.csv -Encoding Byte) eingegeben habe, folgt folgender Fehler: Verbindung zum Quellpostfach konnte nicht hergestellt werden. + CategoryInfo : NotSpecified: (: ) [New-PublicFolderMigrationRequest], RemoteTransientException + FullyQualifiedErrorId : DB3B399A,Microsoft.Exchange.Management.RecipientTasks.NewPublicFolderMigrationRequest + PSComputerName : server2012mx.demolab.local Hat jemand ne Idee, wo mein Fehler liegt? Tschakka! http://social.technet.microsoft.com/Forums/de-DE/56080971-15e8-4227-8074-9ccc25c8cd74/couldnt-connect-to-the-source-mailbox-when-running-newpublicfoldermigrationrequest Da steht die Lösung. Ergo: mal wieder erst die PF migrieren, bevor man Postfächer migriert :-D

Hi, Folgendes Anliegen: Ich habe einen 2012er RDS und möchte gerne, dass meine User im Computer Laufwerk C: nicht sehen. Geht das? Gruß Manuel

Guten Morgen, anbei mal die Links zu den Bildern in besserer Qualität: https://dl.dropboxusercontent.com/u/102265965/1.JPG https://dl.dropboxusercontent.com/u/102265965/2.JPG https://dl.dropboxusercontent.com/u/102265965/3.JPG https://dl.dropboxusercontent.com/u/102265965/4.JPG Also Port 80 und 443 noch irgendwie freischalten und gut ist!? Allerdings: Port 80/443 sind auf der FW frei, OWA funktioniert ja. Warum dann die Meldung, dass Port 80/443 nicht erreichbar ist?

CNAMEs für autodiscover und remote sind eingerichtet, DNS-Server aktualisiert. testexchangeconnectivity wird etwas grüner. Ich fange mal oben an: - Port 443 auf also-test.de nicht frei/überwacht -> das hat vermutlich mit diesem DNS-Weiterleitungsserver zu tun? - Der Hostname autodiscover.also-test.de entspricht keinem der im Serverzertifikat CN=remote.also-test.de gefundenen Namen. -> neues Zertifikat ausstellen lassen? - Der SRV-Eintrag für die AutoErmittlung wurde nicht in DNS gefunden. -> Info an die IT weitergegeben, dass die mir einen Eintrag erstellen.

Ist ein Testnetz ;-) Im Produktivbetrieb dann also mit nem Zertifikat einer offiziellen CA arbeiten :-)

Für OWA, ECP, etc. ist im Server (durch den Assistenten) remote.also-test.de eingetragen. Also, weiteren CNAME, damit das funktioniert und das Zertifikat vom Server exportieren und am Client importieren, richtig?

OK. Werde mich in der Hinsicht mal mit DNS beschäftigen (müssen). Bisher war das Wissen so nicht vorhanden. Die IT richtet mir einen CNAME autodiscover.also-test.de ein. Im Exchange ändere ich jetzt die Autodiscover-Adresse wie folgt: set-AutodiscoverVirtualDirectory - InternalUrl https://autodiscover.also-test.de/Autodiscover/Autodiscover.xml - ExternalUrl https://autodiscover.also-test.de/Autodiscover/Autodiscover.xml

Also statt exchange.also-test.de autodiscover.also-test.de oder zusätzlich? Das ganze wäre mit fester IP vermutlich 1000x einfacher, oder?

Guten Morgen, OK, kapiert. Habe die Infos gestern noch an meinen Kollegen weitergegeben. Sobald ich eine Rückmeldung habe, berichte ich wieder. Edit: Mal zur Info für mich - wie bewerkstelligt man in meinem Fall die Umleitung von also-test.de auf meinen Server? Der Server hängt ja an einer dynamischen IP, somit müsste ich doch jeden Tag die Umleitung im DNS anpassen? Oder gibt es da andere Lösungen? Wäre das in dem Fall der CNAME? Unsere IT hat nun einen CNAME eingerichtet: exchange.also-test.de

Meine Testumgebung hat keine feste IP, daher der no-ip-Dienst. Unsere IT hat die Domain registriert und entsprechend im DNS eine Weiterleitung auf die no-ip-Adresse eingerichtet. Hat gestern noch funktioniert. OK, erste Aufgabe: die sollen den A-Eintrag prüfen. Der Ping auf die no-ip-Adresse gibt die IP 91.16.201.7 aus. Passt ja also schonmal nicht. So, IT sagt, das hat alles so seine Richtigkeit. Die InterNetX GmbH-Adresse ist ein Weiterleitungsserver. Da passiert nicht mehr als die Weiterleitung der also-test.de auf also-test.no-ip.biz. Ich habe mir nochmal in Ruhe ein paar Gedanken gemacht und festgestellt, dass ich den IIS via https-Verbindung nicht erreiche: https://also-test.de -> passiert nichts http://also-test.de -> IIS Startseite erscheint Via Google bin ich noch auf das Thema Zertifikate gestoßen. OWA poppt zwei Meldungen auf: 1. via also-test.no-ip.biz/owa kommt die Standard-IE-Meldung, Webseite schließen oder fortsetzen 2. via also-test.de/owa kommt die Meldung "Der Inhalt wurde geblockt, da er nicht mit einem gültigen Sicherheitszertifikat signiert wurde." Ich tippe, dass das auch etwas mit meinem Problem zu tun hat und ich vermutlich irgendein Zertifikat irgendwo importieren muss, oder? Wenn ja, welches und wo?

Nun, da es sich hier um eine Test-Domain und eine Testumgebung handelt, sollte es kein Problem sein, euch alles zu zeigen :) Bild habe ich so gerade aktualisiert.

Hi, Habe eine Testumgebung bestehend aus SBS 2011 auf einem ProLiant ML350 G6 mit Server 2012 und Hyper-V. Das Netzwerk besteht aus Cisco Small Business 520W an einer Cisco Small Business 520 am Internet. Ziel der Umgebung ist eine Migration vom Exchange 2010 zu Office 365. www.testexchangeconnectivity.com zeigt beim Test der Outlook Anywhere-Funktion das Bild im Anhang. Die Ports sind auf beiden SAs freigeschaltet, OWA und Remote Web Access funktionieren. unsere Test-Domain ist auf einen no-ip.biz-Eintrag weitergeleitet, ein MX-Record für die Test-Domain ist gesetzt, Mails können versendet und empfangen werden. Spaßeshalber habe ich die SBS-Firewall mal ausgeschaltet, keine Änderung. Mit den Kollegen habe ich mich bereits besprochen, theoretisch müsste alles funktionieren (dem ist aber nicht so! Verdammt!). Frage an euch Kollegen an dieser Stelle: Wer hat noch Ideen und kann mir weiterhelfen? So lange das ganze nicht grün ist, kann ich nicht migrieren :)

Ich sollte anfangen, alle Probleme in diesem Projekt bei meinen Kollegen zu suchen :D Manchmal zweifel ich an meinen eigenen Kenntnissen :D

Jepp. Allerdings nicht meine, sondern die des Kollegen, die noch davor hängt. Jetzt funktioniert alles. Danke :)