Jump to content

illumina7

Members
  • Gesamte Inhalte

    42
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von illumina7

  1. Naja die Gäste (RDSH und alle anderen VMs) sind schon komplett gepatched, nur wie gesagt die Hosts entsprechend derzeit nicht. Teams und Zoom laufen auch via VPN vom HO sehr gut, nur verbraucht irgendetwas massiv CPU Leistung auf den RDSH VMs, das ich nicht finden kann. Zum Patchstand: Hyper-V Hosts sind aktuell leider ungepatched, Gäste sind aktuell, wir sind schon am überlegen wie wir weiter vorgehen, wenn MS nicht zeitnah das Nachfolgefeature zu RemoteFX zur Verfügung stellt. Ggf. auf einen anderen Hypervisor wechseln, der die GPU Leistung auf mehrere VMs aufteilen kann. Unser IT-Sicherheitskonzept sieht nicht vor, dass MitarbeiterInnen außerhalb der virtuellen Umgebung im Homeoffice arbeiten, das ist leider keine mögliche Lösung.
  2. Machine Wide installiert inkl. WVD Dienst, läuft so weit gut. Zoom mit VDI Plugin läuft auch gut. Hosts laufen derzeit ohne Updates, ist mir bekannt, dass das Feature abgekündigt und deaktiviert worden ist, können aber derzeit nicht darauf verzichten. Sobald GPU-P funktioniert werden wir von RemoteFX wechseln.
  3. Moin, äääh sorry mein Fehler, korrekt ist natürlich Datacenter nicht ENT, kp wie ich da drauf gekommen bin Energie-Profil steht überall auf Höchstleistung (Hosts und Gäste), mit dem Supermicro Distributor habe ich auch schon gesprochen und alle BIOS Einstellungen gecheckt, alles korrekt eingestellt. RemoteFX ist derzeit nur als Zwischenlösung gedacht, bis GPU-P unter Server 2019 funktioniert, aber darauf verzichten kann ich derzeit auch nicht, da u.a. Zoom und Teams auf den RDSH genutzt wird (deshalb läuft auch noch Server 2016 als Hyper-V Host und kein 2019). Ich kann es aber temporär mal für einen RDSH deaktivieren und schauen ob sich an der CPU Last etwas ändert.
  4. Hallo zusammen, habe eine Terminalserverfarm bestehend aus 4 RDSH und 1 Broker, Umgebung läuft unter Hyper-V auf Basis Server 2016 ENT, die Farm besteht komplett aus Server 2019 ENT. Hardwarebasis Hyper-V Hosts: Supermicro Server: 2x Epyc 7302, 256GB Ram, Raid10 aus NVMe SSDs, nvidia Quadro P1000 Die RDSH haben folgende Specs: 8 vCPUs, 48GB Ram, 100GB HDD, Remote-FX 1GB Ram zugewiesen, Userprofiledisks auf einem gemeinsamen Share Problem: schon mit 5-6 Usern hat ein RDSH 60-70% CPU Last, selbst wenn die User nichts weiter machen. Dabei sehe ich aber weder im Task-Manager/Ressourcenmonitor noch mit dem Process Explorer irgendwelche Dienste/Anwendungen, die die CPU Leistung verbrauchen. Sind dann mal um die 10 User auf einem RDSH, dann laufen die durchgehen bei 80-100%, sobald mal für ein paar Sekunden die 100% CPU Auslastung gehalten wird, werden einzelne User immer wieder getrennt, brauchen beim neu Verbinden wieder mehr CPU Power, dann wird wieder ein anderer getrennt usw. So gut wie alle unnötigen Dienste sind deaktiviert, wir nutzen Windows Defender als Virenschutz. Dabei geht es nach einem Reboot relativ gut, aber mit zunehmender Laufzeit verschwindet immer mehr CPU Rechenleistung im Nirvana, irgendwann sogar so viel, dass selbst wenn kein User mehr arbeitet noch durchgehend 50-60% CPU Last im Idle dauerhaft anliegt. Jemand eine Idee wie ich der Ursache auf die Spur kommen könnte?
  5. Nicht so wirklich, also der Support hat ja das Packet Capture bekommen und kann den Fehler dort sehen, als Antwort darauf kam wieder ein endlos langer Fragetext ohne wirklichen Bezug zum Fehlerbild. Wir hatten auch noch den Distributor Support (Infinigate) zugeschaltet, die konnten aber bei Ihren Messungen nie einen Fehler feststellen, sie hatten unter anderem S2S IPSec Tunnel mit Ihren eigenen Netzen hergestellt und gebencht, gecaptured etc. Da muss ich sagen war die Kommunikation dann ziemlich gut, zu den falsch zusammengesetzten Paketen konnte uns dort aber auch niemand wirklich weiterhelfen. Nach mehreren 100 Stunden Fehlersuche hatte ich dann aber auch genug davon, ich mein wir hatten Tage, da mussten wir scheinbar völlig grundlos alle MitarbeiterInnen an Standort B heimschicken. Die IPSec Tunnel waren online aber es kam kein Traffic zustande, egal wie oft wir die XGs rebootet hatten. Zwischendurch hatten wir die Appliances auch auf Werkseinstellungen resettet und neu konfiguriert, leider auch ohne Erfolg. Als wir die XG230 leihweise vom Systemhaus bekommen haben, hatten wir die Konfig allerdings nur eingespielt, nicht neu eingerichtet. Das Verhalten bei uns konnte niemand nachvollziehen, dabei haben wir eine ganz einfach Standardkonstellation. Nachdem die Fehlersuche die letzten Monate mein Arbeits- und Privatleben komplett in Beschlag genommen hatte, hat es mir dann auch gereicht und da musste was anderes her. Ich hab dann gute 2 Wochen gebraucht bis ich mich durch die pfSense Doku gewühlt hatte, aber es hat sich definitiv gelohnt.
  6. Guten Morgen, zwar war hier jetzt sowieso nicht so viel los, aber vielleicht hat mal jemand ein ähnliches Problem und ist über mögliche Tipps zur Behebung dankbar. Man mag es kaum glauben: die Sophos XG Appliances waren Schuld an den Abbrüchen, was ich von Beginn an vermutet hatte, aber das Systemhaus vehement abgestritten hat. So richtig bewusst geworden ist mir das aber erst, als bei einem Packet Capture aufgefallen ist, dass die XGs die Pakete aus dem VPN Netz in der falschen Reihenfolge zusammengesetzt haben. Also die Pakete gingen korrekt raus, 1-2-3, die Empfänger XG hat daraus dann z.B. 3-1-2 gemacht womit dann die Anwendungen nichts mehr damit anfangen konnten und die Pakete neu angefordert haben. Das hat teilweise zu einem sogenannten TCP Ack Storm auf den VPN Verbindungen geführt, 2000+++ Anfragen für die fehlerhaften Pakete innerhalb weniger Sekunden pro Client, da könnt ihr euch vorstellen was auf den Leitungen los war, wenn 20-30 Clients jeweils 2000+ Paketanfragen abschicken. Dabei kamen die Pakete auch wieder in der falschen Reihenfolge an und so hat sich das häufig noch weiter aufgebaut. Während dieser ACK Storms war dann kaum noch Bandbreite für den übrigen Traffic verfügbar, so sind dann oft alle Verbindungen zeitgleich abgerissen. Der Sophos Support war übrigens sehr wenig hilfreich, außer endlos langer Fragenkataloge kam da nicht viel rum. Die Lösung des Problems, eher auch etwas notgedrungen, da wir jetzt ja kurzfristig wieder Homeoffice anbieten müssen und nach 4 Monaten ergebnisloser Fehlersuche auch meine KollegInnen an Standort B langsam richtig angenervt waren von den ständigen Ausfällen: Ich hab alle Sophos rausgeworfen und durch pfSense Firewalls ersetzt - die VPNs fetzen jetzt in alle Richtungen. Keine Abbrüche, keine Timeouts, volle Bandbreite nutzbar, komplett stabile iperf Werte! MTUs hab ich alle auf default zurückgestellt bzw. gelassen, das war ja die Vermutung vom Support und des Systemhauses, dabei musste ich die letzten 10 Jahre an keinem Router/Firewall jemals an den MTUs rumschrauben und auch jetzt nicht. Was den Fehler an den XGs genau ausgelöst hat kann ich so letztendlich nicht genau sagen, aber ich bin von Sophos Produkten und deren (kaum existenten) Premium Support erstmal geheilt.
  7. Ips aus/anschalten verändert nichts. Ich bin mir auch ziemlich sicher, dass wir schon die volle Bandbreite im site2site hatten, das haben wir ja ursprünglich ausgiebig getestet. Ich hab jetzt an beiden Firewalls mit MTU und MSS rumgespielt, mit mtu 1460 und mss 1320 habe ich die volle Bandbreite im Tunnel und auch per SSL vpn. Ich lasse die Werte jetzt eingestellt und schau Sonntag nochmal was dann los ist. Wenn im site2site nur 0,7-1MB/s ankommen, dann ist mir schon ziemlich klar, dass immer wieder einzelne RDP Sessions abreißen, das ist zu für 15 Sitzungen mit teilweise zwei FHD Monitore. Noch eine Frage: hab noch etwas mit der flood protection getestet. Ist es normal, dass die nach Aktivierung erstmal so gut wie alles blockt? Sogar den ipsec Tunnel, bevor ich die WAN Ips in den Bypass eingetragen hab? EDIT: Bin jetzt zwei Stunden später endlich zu Hause und habs trotzdem gleich getestet. Jetzt ist Performance wieder komplett weg, sowohl site2site als auch übern externen SSL Tunnel kommen wieder nur 0,3-1MB/s an. Die XG210 idlet vor sich hin, Bandbreite ist derzeit auch komplett ungenutzt. Ich denke mein Problem liegt irgendwo an der Sophos, nicht an der Windows/Serverumgebung.
  8. Flood Protection ist an, aber nur für WAN -> LAN, auf der VPN ist keine IPS Regel gesetzt. Ich hatte vorgestern noch zwei DoS Bypass Rules angelegt: Von * nach NetzadresseStandortA 3389 TCP und UDP Wir mussten die SGs rauswerfen, die waren zu klein dimensioniert für die Verlagerung auf die RDSH Server und auch schon ~6 Jahre alt. Die XGs sollten eigentlich mehr als ausreichend sein, laufen auch fast nur im Leerlauf vor sich hin, aber irgendwie haben wir absolut nur Probleme damit. Irgendwie hat unser Sophos Gold Partner auch nicht so den ultimativen Plan von den Kisten, habe jetzt schon einige falsch konfigurierte Einstellungen gefunden, die in der Dokumentation von Sophos anders drin stehen... Und genau hier vermute ich irgendwo einen Fehler, leider sind die XGs für mich komplett neu und ich hab jetzt erst notgedrungen angefangen mich mit denen auseinanderzusetzen. Default Regeln sind fast überall im Einsatz. Hast du sonst noch einen Tipp bezüglich Sophos? Mir ist gestern Nacht noch etwas komisches via Shell aufgefallen: -> XG210 an Standort A hat ca. 10% dropped Packets RX auf LAN1 (interne Lan Schnittstelle, Switch zeigt aber 0 Errors auf dem LAN Port) EDIT: Mir ist eben noch aufgefallen, dass via SSL VPN die Datenrate auch extrem mies ist, komme beim SMB File kopieren auf 2-400 KB/s(!) und das bei einem eigentlichen Upload von 6-7 MB/s. Der Remote VPN Zugang läuft auch auf der 210er. EDIT2: Eben SSL VPN über die XG135 getestet, hier kommen tatsächlich 6-7 MB/s dauerhaft an beim SMB Filecopy. Auf der 135 läuft sonst aber praktisch nichts außer dem VPN zwischen den beiden Standorten (Kein IPS/Filter/etc.).
  9. Also RDP lief gestern den ganzen Tag super flott auf fast allen Arbeitsplätzen, nur an 2 PCs am Standort B trennt es immer mal wieder die RDP Session. Den einen PC hatte ich letzte Woche sauber neu installiert mit Win10 (inkl. Treiber und Updates), es sind alles die identischen Fujitsu PCs im ganzen Haus, denke nicht, dass es irgendwie an der Hardware liegt. Der Dlink Switch meldet auch keine Fehler auf den Leitungen. Heute Nachmittag möchte ich die XG135 am Standort B durch die eine alte SG105 ersetzen und schauen wie es dann kommende Woche aussieht, mit der SG105 lief das alles tiptop vorher. Der Fehler macht mich noch wahnsinnig, wenn an Standort A auch alle ständig Verbindungsabrüche hätten, dann könnte ich das auf die Server bzw. RDSH-Farm schieben, aber dort läufts echt überragend gut, selbst wenn hier 20 Leute ein Zoom Meeting in der Session abhalten läuft das ohne Probleme. Der Fehle wäre auch einfacher zu suchen, wenn an Standort B absolut alle die Abbrüche hätten, aber immer sporadisch einzelne Arbeitsplätze und auch nicht immer die gleichen. Mit Wireshark und dem Packte Tracking der Sophos konnte ich gestern übrigens nichts feststellen, allerdings trat in dem Zeitraum auch nichts auf.
  10. Danke für deinen Hinweis bezüglich Dual Stack. Habe das jetzt nochmal in der Tarifbeschreibung nachgelesen und folgendes gefunden: Dualstack Vodafone stellt die statische IPv4-Adresse per reinem IPv4 zur Verfügung (kein IPv6-Support/Präfix). Die Bereitstellung der dynamischen IP-Adressen erfolgt mit gleichzeitiger Unterstützung von IPv4 und IPv6 (Dual Stack). Als Business Kunde sollten wir mit der statischen IPv4 also grundsätzlich keinen DS (Lite) Anschluss haben. RDP läuft schon komplett via UDP, nur testweise hatte ich es an meinem Arbeitsplatz auf TCP umgestellt - allerdings mit sehr mäßigem Ergebnis - es ist einfach sau lahm. Ich habe gestern Nacht, nach langer Recherche im Sophos XG Forum noch etwas gefunden: die IPS der Sophos blockiert u.a. UDP Pakete oder verwirft sie komplett, habe dann eine Ausnahme für die Terminalserver gesetzt, heute flutscht es richtig. Bis jetzt auch noch kein Disconnect/Abbruch, aber das muss noch nicht unbedingt etwas heißen, wir hatten durchaus schon Tage an denen es richtig gut funktioniert hat.
  11. Moin zusammen, ich hab ein großes Problem in meiner neuen Serverumgebung und langsam weiß ich nicht mehr wirklich weiter. Kurz zur Umgebung: - 2 identische Supermicro Server mit folgender HW: 2x Epyc 7302 256GB Ram Supermicro H11DSi-NT Mainboard Adaptec SmartRaid 3154-8i 7x INTEL SSDSC2KG960G8 im Raid10 (6 + Hotspare) Intel X710-DA2 Nvidia Quadro P1000 (f. RemoteFX) Windows Server 2016 ENT als Hyper-V Host Switchunabhängiges Teaming für die 2x1GBit NICs (Windows) - 3 Standorte Hauptstandort: Sophos XG210 mit 3 Leitungen: dedizierte EtherConnect Leitung ohne Zugriffsmöglichkeit Tsystems 100/40 Leitung, feste IPv4, bintec rs353jv hängt am Anschluss Vodafone Business 500/60 Leitung, feste IPv4, derzeit hängt die Vodafone Box dran, eigentlich Fritzbox 6660 Cable ca. 50 Mitarbeiter intern Hier stehen die beiden Server Site-to-Site IPSec Tunnel über Vodafone <-> Vodafone mit Standort B, Tsystems Leitungen als Failover konfiguriert Netzwerktopologie sieht folgendermaßen aus: Beide Server und sonstige Netzwerkressourcen hängen an einem neuen Netgear 48Port GBit Switch, an diesem hängen mehrere HPE Switches sternförmig, an denen wiederum alle Clients verteilt hängen. Standort B: Sophos XG135 dedizierte EtherConnect Leitung ohne Zugriffsmöglichkeit Tsystems 100/40 Leitung, feste IPv4, bintec be.ip hängt am Anschluss Vodafone Business 500/60 Leitung, feste IPv4, derzeit hängt die Vodafone Box dran, eigentlich Fritzbox 6660 Cable ca. 20 Mitarbeiter 1 Dlink DGS-1210-48, für 20 PCs und 5 Drucker/Kopierer Standort C: Sophos XG135, ist aber noch nicht vollständig angebunden mit der Anbindung muss ich auch warten, bis wir den Fehler finden können. ca. 50 Mitarbeiter Die beiden Server replizieren die VMs über die 2x10Gbit (dediziert), insgesamt laufen über beide Hosts verteilt 18 VMs, allesamt Server 2019 ENT. Alle User arbeiten in einer Terminalserverumgebung, bestehend aus 4 RDSH (max. 25 User pro RDSH) und 1 Broker. Um den ganzen etwas Geschwindigkeit zu verleihen, haben die RDSH jeweils die Quadro für RemoteFX Beschleunigung aktiviert, ich weiß das Feature ist abgekündigt, allerdings muss ich das nutzen, bis das GPU-P Feature endlich nachgepatcht wird. Auf den RDSH wird fast ausschließlich in gehosteten Web-Anwendungen und mit Office gearbeitet, zusätzlich werden Zoom und Teams Meetings in den Sitzungen abgehalten (hierfür die WVD VDI Optimierungen eingespielt), intern haben wir Sfirm und noch zwei andere SQL Server basierte Anwendungen laufen. Alle RDSH VMs haben folgende Ressourcen: 8 vCPUs, 32GB Ram, 100GB VHD, 1 NIC zum vSwitch, die User arbeiten mit Profildisks. Es steht ein Fileserver für die Profildisks zur Verfügung, ein zweiter Fileserver für die SMB Shares (je 2 vCPUs, 6GB Ram). Am Serverstandort können alle User absolut problemlos arbeiten, Geschwindigkeit ist wie wenn man lokal auf einem Rechner arbeiten würde, zum Teil auch mit 2 Bildschirmen in den RDP Sessions, läuft wie es soll. Am Standort B ist es über VPN eine Katastrophe, immer wieder friert die Anzeige ein oder die Benutzer bekommen reihum RDP Session Timeouts, müssen einige Minuten warten, bis wieder eine Verbindung hergestellt werden kann. Hier taucht auch hin und wieder mal die Meldung "Ein interner Fehler ist aufgetreten" auf. An manchen Tagen läuft es aber auch hier richtig flott und problemlos, praktisch der Idealzustand, wobei selbst da hin und wieder einzelne User mal rausfliegen, während alle anderen nichts davon mitbekommen. Allerdings ist es so - während die Verbindung zu den RDSH Hosts abbricht, kann ich parallel per RDP auf den anderen Servern weiterarbeiten - dort ist auch die Geschwindigkeit wesentlich besser, obwohl die dann zum Teil auf dem gleichen Host liegen. Auf einem 3. Server, Backup und Testserver, alter Fujitsu RX200 S7 (Dual E5-2640, 64GB DDR3, Intel Server SSDs Raid5, Server 2019 Ent, hängt am gleichen Switch, Windows NIC Teaming aktiviert), habe ich auch die Hyper-V Rolle installiert und einen bestehenden Terminalserver geklont, diesen dann in eine eigene Sammlung verschoben und nur für mich zum Testen bevor die Änderungen ins Produktivsystem gehen, läuft auch alles bestens. Sprich: Ich fliege via VPN vom Produktiv-RDSH raus, aber kann parallel auf dem Test-RDSH ohne irgendwelche Probleme weiterarbeiten - auch richtig performant. Was wir schon (zusammen mit dem Dienstleister der die Sophos Firewalls eingerichtet hat) zwecks Fehlersuche unternommen haben: - alle Router getauscht -> keine Veränderung - mehrmals Internetleitungen geprüft (Vodafone und Tsystems) -> keine Veränderung - Unter Windows Server das Teaming aufgelöst -> keine Veränderung - RSC und VMQ für die RDSH deaktiviert -> keine Veränderung - alle Server/Switch/Firewall Netzwerkkabel an beiden Standorten getauscht -> keine Veränderung - mit dem Sophos Support alle Logfiles auf Fehler geprüft -> nichts gefunden - Intel Netzwerktreiber aktualisiert -> keine Veränderung - Supermicro UEFI Update eingespielt -> keine Veränderung - Supermicro Chipsatztreiber etc. aktualisiert -> keine Veränderung - die Sophos XG210 gegen eine Leih-XG230 getauscht -> keine Veränderung - RDSH VMs zwischen den Hyper-V Hosts migriert -> keine Veränderung - Netzwerkperformance mit diversen Tools getestet -> alles bestens (vServer-Client, Client-vServer, vServer-vServer, Host1-Host2, Host1-vServer, Host2-vServer, etc. also jegliche mögliche Kombination) - Raid Array Performance geprüft -> r/w top, nichts auffällig - an manchen Tagen funktioniert die Verbindung über Tsystems-Tsystems gut, am nächsten Tag funktioniert es nur über Vodafone-Vodafone, die Woche darauf geht überhaupt nichts mehr, bis ich den Site-to-Site Tunnel auf Telekom-Vodafone umgestellt habe. - Ereignisprotokolle ohne Ende gewälzt, versucht den Fehler auf dem Test-RDSH zu reproduzieren - bisher erfolglos, es sind keine offensichtlichen Fehler auf dem Broker und den RDSH zu finden. EDIT: - Site-to-Site Tunnel ist immer stabil und verbunden, egal über welche Leitung, aber im Tunnel selbst haben wir schon Paketverluste -> niemand weiß wirklich warum der Dienstleister schiebt es auf die Vodafone Leitungen, die Vodafone Leitungen sind mehrfach geprüft und iO, auch über die Telekom Leitungen treten die Paketverluste im Tunnel auf, ich tippe nach wie vor darauf, dass an den Firewalls irgendwas nicht stimmt. So drehen wir uns seit ca. 2 Monaten im Kreis und langsam aber sicher wird mein Chef ungeduldig. EDIT2: - Im Zuge der Fehlersuche habe ich festgestellt, dass Winserver sich mit Firewall Regeln der User zumüllt und nicht mehr löscht, die alten Regeln hab ich gelöscht (insgesamt knapp 10k verwaiste FW-Einträge) und das ganze per Registry Eintrag abgeschaltet -> keine Veränderung - Alle Clients sind Win10 Pro Clients mit 20H2 und 21H1, alle Clients sind in der Domäne - Wir nutzen derzeit nur Windows Defender und die Windows Firewall, keine Software von einem Drittanbieter, zusätzlich filtert und prüft die XG210 den Traffic ins Internet, intern gibt es keine Restriktionen. - Fair Share CPU Scheduling, Dynamic Disk Fair Share und Dynamic Network Fair Share per Reg Eintrag deaktiviert -> keine Veränderung Irgendwie stecke ich eben in einer Sackgasse fest, wir haben bestimmt noch das ein oder andere mehr probiert, das ergänze ich wenn es mir wieder einfällt. Über einen Tipp oder Denkanstoß würde ich mich sehr freuen. Bei Fragen einfach fragen. Grüße illumina7
  12. Oh Danke für den Hinweis, dass RTM nicht für R2 freigegeben ist. Da es eine Testumgebung ist, probiere ich erstmal das Upgrade auf CU3, einspielen von SP1 und Upgrade auf CU6, hab ja nichts zu verlieren. Wenn das so nicht funktioniert, dann setze ich die ganze Testumgebung neu auf, und werde gleich mit CU6 beginnen :D
  13. "Schein soweit ok zu sein" heißt, die Ausgabe der Shell per "Get-ExchangeServer" ist korrekt. "Funktioniert nicht" bedeutet im Zusammenhang mit dem Zertifikat-Import, dass der gleiche Fehler auftritt beim connect. Benutze zum connecten Office 2013 Professional Plus 32bit SP1 inklusive aller Updates unter Win 8.1 Pro x64 mit allen Updates. Die Test-VM läuft unter Win 7 Pro x64 auch mit Office 2013 Pro Plus SP1 32bit (der Client, den ich in die Domain gejoint habe). Hab grade nochmal die Version des Ex2013 geprüft und festgestellt, dass es die RTM ist. Lade grade CU6 und werde das Update mal installieren und dann sehen was passiert.
  14. Hi Ihr, mal eine Frage bzw. ein Problemchen mit einem Exchange 2013. Habe einen 2012r2 DC und einen zweiten 2012r2 mit Exchange 2013 virtualisiert in einer Testumgebung installiert. Zur Info, ist mein erster ex2013, um mir den einfach mal anzusehen und bisschen zu Testen. Kurz Zur Installation: das AD auf den Exchange vorbereitet, alle erforderlichen Rollen und Features per PS installiert, Filter Packs und ComManager installiert, Setup des Ex2013 ohne Fehler/Warnungen durchgeführt. Erstkonfiguration anhand eines Tuts durchgeführt (video2brain). Jetzt zum eigentlichen Problem, ECP OWA ActiveSync (auch von extern) funktionieren super. Email Versand/Empfang ebenfalls. Nur lässt sich mein Outlook nicht connecten, bzw das stimmt auch nur teilweise. Habe einen Testclient in die Domäne gehoben und mit dem entsprechenden Exchange User angemeldet, dort klappt die Verbindung problemlos und auch Outlook ist voll funktionsfähig. Möchte ich nun einen Client außerhalb der Domäne mit Outlook zum Exchange verbinden, dann kann ich zwar die ganze Einrichtung im Outlook durchführen und auch erfolgreich abschließen. Beim Start von Outlook kommt dann allerdings eine Fehlermeldung: "Microsoft Outlook kann nicht gestartet werden. Das Outlook-Fenster kann nicht geöffnet werden. Diese Ordnergruppe kann nicht geöffnet werden. Bevor Sie Ihre Ordner mit Ihrer Outlook-Datendatei (.ost) synchroniesieren können, müssen Sie eine Verbindung mit Microsoft Exchange mit Ihrem aktuellen Profil herstellen." Jetzt habe ich natürlich schon etliche Tuts und die MS kb durchgestöbert, und keinen wirklichen Hinweis zu diesem Fehler gefunden. - Autodiscover per EX Shell geprüft - scheint soweit ok zu sein - das Zertifikat des EX exportiert und am Client importiert - funktioniert nicht - Reparaturinstallation von Office durchgeführt bzw Deinstalliert, Registry und Filesystem gereinigt und neu installiert - geprüft, ob eine .ost File angelegt wird - wird erstellt, aber ist 0 kB groß, also ohne Inhalt Habt Ihr Tipps für mich oder habe ich irgendwo einen Fehler in meiner Konfiguration? Warum klappt der Connect innerhalb der Domäne, ohne Domäne nicht? Vielen Dank schon mal im vorraus Gruß illumina7
  15. illumina7

    SBS2003 Defekt

    Vielen Dank für den Tipp, habe die Software gestern noch gekauft und konnte damit alle Mailpostfächer aus der Exchange db eportieren. Damit hat sich das Problem jetzt erledigt, kann geschlossen werden.
  16. illumina7

    SBS2003 Defekt

    Vielen Dank für die schnellen Antworten erstmal. Backup ist nicht bootbar, weil die Partitionsgröße nicht stimmt, Partition ist tatsächlich ca. 1TB groß, aber wird nur noch mit 20gb Größe angegeben. Habe da schon etliches versucht um das System wieder zum Laufen zu bekommen. Laut Testdisk ist die MFT "bad". War froh aus dem defekten Raid-Array überhaupt noch Daten ziehen zu können (Servergespeicherte Profile, WaWi, Datev db etc...). Welche Tools zum offline auslesen der Exchange DB gäbe es da denn? Ist eine Reparaturinstallation bei einem SBS2003 sinnvoll? LG illumina7
  17. illumina7

    SBS2003 Defekt

    Hi Ihr, hab ein kleines Problem. Erstmal Kurzfassung zum Hintergrund: Älterer Server mit MS Server 2003 SBS (nicht von mir betreut!); Raid defekt; Kunde meldet sich erst nachdem der Server schon seit über einer Woche "pfeift" und der eigentliche Dienstleister keine Zeit hat und Ihn weiter an uns verwiesen hat; Raid degraded bzw inoperable und mit ECC Errors..; Backup nicht gelaufen seit 2011; mit Raid-Controller Hersteller 3 Tage lang das Raid soweit wieder i.O. gebracht, dass ich ein Vollbackup erstellen kann; Backup ist aber nicht mehr bootbar nach zurückspielen, Daten aber alle zugänglich. So jetzt die Große Preisfrage, kann ich die Exchange 2003 DB, die ich aus dem Backup exportieren konnte irgendwie bei einem SBS2011 importieren? Das alte OS ist nicht mehr funktionsfähig, daher fällt die normale Migration flach. Ideen Vorschläge? Freue mich über jeden Tipp! LG illumina7
×
×
  • Neu erstellen...