Hallo Robert,
Vielen Dank.
"get-logonstatistics" hilft mir schon mal recht gut weiter. Zumindest kann ich sehen, wann sich mal eingeloggt wurde und wer. Das man nicht sieht, wie lange die Sitzung war, ist für mich OK.
Zumindest kann ich nachkommen, das die User zu belegbaren Zeiten eingeloggt waren.
Danke, Torsten
Hallo an alle,
ich suche eine Auswertungsmöglichkeit/Übersicht bzw. Log, aus dem ich erkennen kann, wann sich welcher User über OWA oder per Outlook mit dem Ex2010 verbunden hat (und wie lange er geblieben ist).
Im Ex2010 gibt es in der Verwaltungskonsole unter Toolbox die "Benutzeranrufprotokolle", leider nur für die Unified Messaging Komponente. Aber das wäre genau die gesuchte Info-Sammlung, halt eben nur für OWA selbst.
Danke für's Lesen - und hoffentlich gibt's eine einfache Lösung ...
Torsten
Hallo,
erst mal Danke für Eure Antworten.
Dann mache ich mir mal darüber keine Gedanken mehr, sondern werde den Weg andersherum gehen, d.h. ich muß mir die Einwahl von außen für die Heimarbeitsplätze anders organisieren.
Ich habe mit den Netgear-Produkten keine Sorgen. Schlechte Erfahrungen gibt es bestimmt überall. Für mich eigentlich schade, das Netgear die Hardwarelösung "SSL3122" vor 2 Jahren einfach so vom Markt nahm, obwohl Updates und verbesserungen angeblich auf dem Plan standen.
NobbyausHB: Bei uns selbst betrifft das 5 Heimarbeitsplätze. Ich habe diese Hardwarelösung aber auch bei einigen Kunden im Einsatz, welche über Außenstellen verfügen. Gern lerne ich dazu, wenn Du also etwas Besseres empfehlen kannst? Die Geräte von Netgear sind bzw. waren einfach zu admimistrieren, und durch die Oberfläche auch für normale PC-Benutzer simpel zu bedienen. Ich brauchte keine speziellen Clients auf den Außenstellen-PC-Systemen, Internetzugang langt. Da es sich bisher immer um die Anbindung einzelner Arbeitzsplätze handelte, war eine Site-to-Site-Lösung mittels Router nicht notwendig, aber die SSL312 könnte das auch.
Sicher hat jeder so seine Lieblinge, aber ich möchte sagen, das ich nicht schlecht über die Pro-Produkte von Netgear reden kann. Freilich, die silbernen Brotbüchsen aus derem Hause habe ich nicht in guter Erinnerung, auch einige der kleineren Router (FVS114) nicht. Nicht zuletzt ist ja auch der Preis ein nicht zu vergessender Punkt. Auch hat Netgear in den ersten Jahren viel Schulungen angeboten, so daß man sich gut einarbeiten konnte. Dies ist zwar heute nicht mehr so, und ich finde das schade, aber ändern kann ich es nicht.
Euch allen nochmals herzlichen Dank für die "Laß die Finger davon" - Antworten. Ich werde diese Rätschläge befolgen.
mfg Torsten
Hallo,
ich suche nach der Möglichkeit, den Port 443 im Exchange zu ändern. Grund dafür wäre der reibungslose(re) Zugang von außen mittels OWA und der derzeit leider gar nicht mögliche Zugang für's iPhone mittels EAS.
In anderen Threads in diesem Forum bin ich auf ähnliche Fragen gestoßen, aber (unter Exchange 2007) scheint es keine Lösung zu geben oder nicht sinnvoll zu sein.
Folgendes Szenario kann ich beschreiben, damit der Hintergrund meiner Frage verständlich wird (ich hoffe, mich verständlich ausdrücken zu können).
Innerhalb unseres Hausnetzwerkes ist es kein Problem, im Internet-Explorer die Adresse des Exchange-Servers mit https://server/owa aufzurufen und die Anwendung zu nutzen. Somit sind meiner Meinung nach alle Einstellungen bezüglich Benutzer und Kennwörter funktionstüchtig.
Für den Zugang von den Heimarbeitsplätzen haben wir eine Hardwarelösung von Netgear installiert, welche seit Jahren zuverlässig dienst tut. Dieses Gerät nennt sich "SSL312" und stellt den einwählenden Benutzern über Port 443 eine gesicherte Oberfläche mit diversen Diensten wie RDP etc. zur Verüfung.
Damit stellt sich - so denke ich - sofort das Manko dar. Alle Anfragen an Port 443 unseres Routers von außen werden an die Adresse der SSL weitergleitet. Unter Port 443 kann ich also von außen den Exchange-Server nicht erreichen.
Der Gedanke, einen anderen Port (Bsp: 4443) zu nutzen und im Router auf Port 443 an die IP-Adresse des Exchange-Servers zu routen, funktioniert mit einigen Hürden. So kann man von außen kommend nur dann auf OWA zugreifen, wenn man den "neuen" Port bei der Anfrage mehrfach mitgibt. Zur Verdeutlichung folgende Syntax:
Normal wäre: https://öffentliche-ip/owa => funktioniert wegen SSL-Gerät nicht
Abgewandelt auf neuen Port: https://öffentliche-ip:4443/owa => funktioniert bis zum Login-Fenster; dann ist Schluß
Es funktioniert aber wie folgt reibungslos: https://öffentliche-ip:4443/owa/auth/logon.aspx?url=https://öffentliche-ip:4443/owa/&reason=0
So kann man sich anmelden und mit OWA arbeiten. Da sich natürlich kaum jemand die ganze Eingabe merken kann, ist das recht umständlich, funktioniert aber. Was aber gar nicht funktioniert, ist EAS mit dem iPhone. Es gibt im iPhone keine Möglichkeit, die Konfiguration von Port 443 auf Port 4443 zu ändern. Ich kann wohl bei der Eingabe der Serveradresse den Port 4443 mitgeben. Aber anscheinend ist im Exchange-Server irgendwie eine feste definierte Einstellung, die Daten für EAS nur auf Port 443 (nach außen)kommunizieren will, und somit kommt im iPhone keine Verbindung zu stande.
Nun, um dieses Dilemma zu beseitigen, erhoffe ich, das es eine Konfigurationsmöglichkeit gibt, den Port für den Exchange zu ändern und ein Forumsmitglied eine Idee oder Lösung kennt.
Danke für's Lesen. Und vielleicht eine Lösung haben 
MfG; Torsten
Zitatdie Option ist ein "Switchparameter", steht ja auch in der Doku.
Doku? Was'n das? 
Nochmals vielen Dank.
Torsten
Erst einmal Entschuldigung für die Verhunzung des Namens. Das war vollkommen unabsichtlich geschusselt.
Das cmdlet hat funktioniert! Immer schön mit "Ja" die Abfragen beantwortet. Die Datenbank ließ sich anschließend sauber löschen und die Applikation wie es sein soll über die Systeuerung deinstallieren.
Nun steht der Einbindung des neuen richtigen Servers nichts mehr entgegen.
Vielen Dank für die Lösung, ich hätte es nicht ohne Euch geschafft.
Danke. Torsten
PS: Was bin ich schuldig und wohin? 
Hallo an alle,
erstmal vielen Dank für die Antworten, bin noch nicht eher zum Lesen gekommen (Außendienst) ...
Zitat
hast du weitere Exchangeserver in der Org, wenn ja, was für welche?
Noch nicht. Deswegen der Testlauf. Wir wollen/müssen in dieser Richtung was tun, da unser bisheriges System vom Hersteller abgekündigt wurde. Da eine Enscheidung anstand, was es werden soll, habe ich halt den Test mit einem einfachen PC und einer Testinstallion von Server 2008R2 und Exchange 2010 gemacht. Danach stand fest: Exchange = ja. Aber nicht mit einem PC, sondern richtiger Serverhardware, mit richtigen HDD's und ordentlich RAM etc. Und deswegen muß alles wieder ordentlich rückgewickelt werden...
Zitat
Und es ist ziemlich mutig, mit einem Test ins echte AD zu gehen.....
Na ja, wenn ich das ganze jetzt so sehe, also das "klitzkleine" Problem was ich nicht allein lösen kann, würde ich mein Verhalten selbst nicht unbedingt als mutig einschätzen. Das war eher wagemutig oder schlimmer ...
@NorbertW
Zitat
Ich habe gerade am WE eine Deinstallation hinter mir und weiß daher garantiert, dass in der Fehlermeldung der korrekte Befehl steht
JEIN. Ich will nicht aufsässig erscheinen und keinesfalls diejenigen verbessern, deren Hilfe ich erflehe Aber bei mir steht wortwörtlich in der Fehlermeldung des Analyzers "Führen Sie den Befehl 'Get-Mailbox -Database <Database ID> -Arbitration' aus, um eine Liste aller Vermittlungspostfächer in der Datenbank abzurufen."
Daraufhin habe ich das cmdlet - wie in meinem ersten Post geschildert - ausgeführt. Das Ergebnis war dann die Anzeige der 3 Postfächer/Systemweiterleitungen. Danach kam dann das Deiner Meinung nach unvollständige cmdlet. Ich habe die beiden cmdlets mal nacheinander ausgeführt und hier ist der ausgegebene Inhalt der Console (ich hoffe das ist hier erlaubt und verstößt nicht gegen Boardregeln):
[PS] C:\Windows\system32>get-mailbox -Database 1823920716 -Arbitration
Name Alias ServerName ProhibitSendQuota
---- ----- ---------- -----------------
SystemMailbox{1f05a927... SystemMailbox{1f0... exchange-server unlimited
SystemMailbox{e0dc1c29... SystemMailbox{e0d... exchange-server unlimited
FederatedEmail.4c1f4d8... FederatedEmail.4c... exchange-server 1 MB (1,048,576 bytes)
[PS] C:\Windows\system32>get-mailbox -arbitration -database 1823920716 | remove-mailbox
Der Vorgang konnte nicht ausgeführt werden, weil das Objekt 'Firma.local/Users/SystemMailbox{1f05a927-a8c5-4104-b878-8318a60b8484}' nicht auf 'Server2.Firma.local' gefunden wurde.
+ CategoryInfo : InvalidData: (Firma.local/Use...8-8318a60b8484}:MailboxIdParameter)[Remove-Mailbox], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : B721D0F3,Microsoft.Exchange.Management.RecipientTasks.RemoveMailbox
Der Vorgang konnte nicht ausgeführt werden, weil das Objekt 'Firma.local/Users/SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}' nicht auf 'Server2.Firma.local' gefunden wurde.
+ CategoryInfo : InvalidData: (Firma.local/Use...8-e6c29d823ed9}:MailboxIdParameter) [Remove-Mailbox], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : C5E774BA,Microsoft.Exchange.Management.RecipientTasks.RemoveMailbox
Der Vorgang konnte nicht ausgeführt werden, weil das Objekt 'Firma.local/Users/FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042' nicht auf 'Server2.Firma.local' gefunden wurde.
+ CategoryInfo : InvalidData: (Firma.local/Use...bf-00a95fa1e042:MailboxIdParameter) [Remove-Mailbox], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : 32E0B925,Microsoft.Exchange.Management.RecipientTasks.RemoveMailbox
Das cmdlet, welches bei mir nach Deinen Worten unvollständig erscheint, hatte ich mir nach vielen Recherchen selbst zusammengebraut. Dabei kann ich in meiner Unwissenheit und Verzweiflung natürlich etwas vergessen haben.
Wenn ich das von Dir vervollständigte cmdlet auf meiner Installation ausführe, erhalte ich folgende Rückmeldung:
[PS] C:\Windows\system32>get-mailbox -arbitration -database 1823920716 | remove-mailbox -RemoveLastArbitrationMailboxAllowed $true
Die Argumenttransformation für den Parameter "Identity" kann nicht verarbeitet werden. Der Wert "True" kann nicht in den Typ "Microsoft.Exchange.Configuration.Tasks.MailboxIdParameter" konvertiert werden. Fehler: "Ungültige Umwandlung von "System.Boolean" in "Microsoft.Exchange.Configuration.Tasks.MailboxIdParameter"."
+ CategoryInfo : InvalidData: (:) [Remove-Mailbox], ParameterBindin...mationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,Remove-Mailbox
Irgendwas paßt bei meiner Installation so gar nicht mehr... Oder ich mache etwas falsch.
Torsten
Hallo,
habe zum "Test" einen Exchange 2010 auf separater Hardware mit Server 2008 R2 in unser Netzwerk integriert. Kam mit Installation und Betrieb des Systems klar. Nach 14 Tage sollte der Exchange wieder entfernt werden.
Nun hänge ich schon ein paar Tage - immer wenn es meine Zeit zuläßt - an dem Problem, das die Deinstallation über die Software/Systemsteuerung nicht funktioniert. Habe lange gegoogelt und diverse Anleitungen und Tipps gelesen, teilweise auch ausprobiert, ohne erfolgreich zu sein. Habe im Forum hier einen Link auf eine Anleitung gefunden, wie man mit der groben Bürste den letzten Exchange aus dem System "manuell" wirft, scheue mich aber ehrlich gesagt davor, so reinzugreifen...
Die Überprüfung des Analyzer bei der Deinstallation meldet, das in der Postdachdatenbank mindestens ein Postfach oder Vermittlungspostfach existieren.
So oft wie ich es mir auch angeschaut habe, es ist kein Postfach mehr in der Datenbank.
Wenn ich in der Shell mit "get-mailbox -Database 1823920716 -Arbitration" meine Datenbank prüfe, weißt das Tool immer zwei SystemMailBoxen und eine FederatedEmail aus. Die scheinen dann die Vermittlungspostfächer zu sein.
Mit dem Cmdlet "get-mailbox -arbitration -database 1823920716 | remove-mailbox" bekomme ich die Meldung, das der Vorgang nicht ausgeführt werden konnte, weil das Objekt "SystemMailBox" nicht im AD gefunden werden konnte. gleiche Meldung dann nochmals für die zweite SystemMailBox und die FederatedEmail ...
Was muß ich tun, um die für mich eigenlich leere Datenbank sauber vom System zu bekommen und den Exchange sauber zu deinstallieren, also auch sauber aus dem AD zu haben?
Danke für's Durchlesen.
Torsten
