Wolke2k4

Stand jetzt, ist die Ursache geklärt.

Hallo zusammen, seit dieser Woche bekommen wir vermehrt Rückmeldungen von Kunden mit RDS Servern (mit und ohne Citrix DaaS/XenApp), dass vereinzelt nutzer Probleme haben bei der Anmeldung. Das führt dann zu Ghost Sessions wie bspw. hier oder hier oder hier beschrieben. Da wird aber auch 2 Kunden haben, die den RDS Server ohne Citrix einsetzen, kann es nicht zwingend die in den Citrix Artikeln beschriebene Problematik sein... Mit einer Ausnahme ist bei alle betroffenen Kunden gleich, dass sie Windows Server 2016 im Einsatz haben, Windows Updates sind kürzlich gelaufen aber auch im Bereich Antivirus (Avast) gab es zuletzt Updates. In dieser Masse sind das keine Zufälle. Wir sind noch dabei über verschiedene Maßnahmen die Ursache einzugrenzen. Mich würde aber mal interessieren, ob andere Nutzer ähnliche Probleme haben, was den Verdacht in Richtung Windows Updates erhärten würde... Update: Sorry für die Dopplung mit diesem Thread, war keine Absicht und reiner Zufall, dass wir beide die gleiche Idee hatten...

Bei Roaming Profiles haben wir immer wieder nach einer gewissen Zeit merklich Performance Probleme, weil die Profile sich dann doch mit der Zeit zumüssen, trotz Ordnerumleitung und Browser Cache löschen... sodass wir dazu übergehen die Kunden auf FSL umzustellen. Die Rückmeldung hierzu sind ausnahmslos positiv, was das Anmeldeverhalten angeht.

Du wirst nicht umhin kommen die RDS Lizenzierung sauber aufzusetzen. Heißt Lizenzen kaufen, Lizenzserver aktivieren und RDS CALs einspielen... Das der RDS bei einem nur verfügbaren RDS Lizenzserver auf per User läuft ist ja schon länger geschichte.

Hallo zusammen, mich würde mal interessieren woran Ihr euch bei dem "Desing" für Server oder auch SANs orientiert wenn es um die Entscheidung zu SATA/SAS SSDs oder NVMe SSDs geht. Das Hauptthema sind sicher Preis und Performance. Aber die Aussage, ob eine SATA SSD 500MB/s schreibt und/oder liest muss nicht zwangsläufig ein K.O. Kritierium im Vergleich zur teureren SAS oder NVMe SSD sein. Hab ihr konkrete Anwendungsfälle (SQL Server, Exchange, RDS, Fileserver usw.) bei denen ihr bestimmte Plattentypen verwendet, möglicherweise trotzdem auch noch klassische HDDs?

Hallo zusammen, ich grüble gerade über ein kleines Detail bei der Planung für Serverhardware nächstes Jahr. Der Hersteller bietet optional ein TPM 2.0 Modul für das Mainboard an. Ich hatte dazu vor geraumer Zeit schon mal angefragt beim Hersteller. Der meinte, dass wäre nicht zwingend notwendig. Der Kern von TPM ist soweit klar. Ich sehe nur bisher keine zwingende Notwendigkeit und/oder Nachteile wenn ich diesen für einen Server mit dazu kaufe, auf dem Hyper-V laufen soll. Wenn es keine Nachteile gibt, würde ich ihn für die nicht ganz 100€ einfach dazu stecken lassen getreu dem Motto: "Haben ist besser als brauchen." Gibt es Anmerkung eurerseits dazu?

Nur zur Info, falls mal jemand das gleiche Problem hat. Letztlich konnte ich die Ursache nicht finden. Die Debug Logs waren nicht brauchbar, weder auf dem 2008R2 noch auf einem 2016-er DNS. Letztlich habe ich als Workaround den 2008R2 auf einen 2016-er DNS weiterleiten lassen, denn der hatte mit der Auflösung keine Probleme. Ist bissel von hinten durch die Brust aber da der Kunde sowieso in den nächsten Monaten ins RZ geht, kam der alternative Aufwand nicht in Frage.

Hey Leute, ich hab hier ne echt harte Nuß im Bereich DNS Namensauflösung. Folgende Konstellation: Kundenumgebung mit bisher 1x Windows Server 2008R2 Domain Controller, der natürlich auch DNS macht. Als DNS Weiterleitungsziel ist ein einziger Server eingetragen, ein DNS Server eines RZ Hosters im Landesnetz. Das Problem: Einige wenige DNS Namen wie bspw. gema.de werden nicht aufgelöst, wenn Clients aus dem Netzwerk den 2008-er DC als ersten DNS ansprechen, der die Anfrage ja nur weiterleitet. Was sehr wohl geht ist die Namensauflösung, wenn die Clients den 2008-er DC umgehen und den Landenetz DNS direkt ansprechen! Versuchter Lösungsansatz: parallele Neuinstallation eines 2016 DNS Servers mit der gleichen Weiterleitung wie sie der 2008-er DC nutzt. Aber auch der 2016-er DNS Server hat die gleichen Probleme, kann gema.de nicht auflösen, wenn er der DNS Server ist, der vom Client zuerst angefragt wird. Den 2016-er DNS habe ich nur als Domain integrierten Server in das Kundennetz hinzugefügt, DNS Rolle installiert und dann die Weiterleitung eingestellt... also f*** einfaches Szenario. Ich habe aktuell keine Ideen mehr. Fällt euch noch was ein? Update: Auch spannend, jetzt gehts auf dem 2016-er. Einziger Unterschied: Es sind 2-3 Tage vergangen... P.S. Ja bezüglich 2008R2 ist mir klar... Support usw...

Listenansicht ist mir bekannt aber verhunzt natürlich die Wochen bzw. Monatsansicht... das ist leider keine brauchbare Alternative.

Ja das ist klar... der Zeitraum hätte womöglich schon geholfen aber hier ist das Auditlogging wohl putt... ist aber erstmal egal. Das Thema ist damit erledigt, wieder was dazu gelernt.

Besten Dank, da hab ich schon mal Input. Ich gehe auf die Suche!

@NorbertFe: Ich hatte ja nicht geschrieben, dass ich VPN als unangreifbar betrachte. Mir ist natürlich klar, dass es auch hier Lücken gibt und die haben wir vom Hersteller der von uns eingesetzten Appliances auch schon gesehen und fixen müssen. Aber ich sehe es so: Während ich mit HTTPS via Exchange/Reverse Proxy UND VPN 2 offene Türen in der Firewall habe, die ggf. sogar ganz bis auf den Exchange durchgereicht wird, habe ich mit VPN only nur eine Tür. Das ist nach meinen Dafürhalten schon ein zwingend zu berücksichtigender Punkt in der Sicherheits und Patcharchtektur. @cj_berlin: Wir haben bereits erste Kunden umgestellt. Der erste Kunde hatte vorher nur Outlook Sync über iCloud Systemsteuerung. Was das für ein Seegen ist, wenn man dann auf AS via VPN geht muss ich Dir ja nicht sagen... Der zweite Kunde hats auch geschluckt und das Argument mit der Sicherheit zieht auch bzw. muss eben ziehen. Weniger ist eben mehr, ich denke da sind wir uns einig.

Hallo zusammen, gibt es für Exchange 2016 oder generell für Exchange ab 2013 die Möglichkeit herauszufinden wer wann welche oder überhaupt Berechtigungen auf Exchange Postfächer gesetzt hat? Es geht darum, dass Zugriffe auf Postfächer eingerichtet waren, die jetzt zu Ärger in der Leitungsebene geführt haben. Da man keine schriftlichen Anweisungen erteilt und dokumentiert hat, ist nun somit unklar, wann und wer diese Berechtigungen vergeben hat. Ich vermute, dass es sich hier ähnlich wie mit der Dateisystemüberwachung handelt. Geben tut es die Möglichkeit aber aktiv eingeschaltet werden muss es oder?

Es ist ein Webdienst, HTTP/HTTPS... der auf einen LAN Server zeigt. Der RP ist aktuell kein WAP, wenngleich wir vorgeschaltet noch eine Firewall haben mit diversen Sicherheitsmechanismen... aber ich sehe es letztlich genauso wie Du: Portforwarding ist ein No-Go und ich für mich oder wir für uns haben die Entscheidung getroffen, dass wir die Kunden von solchen Szenarien entkoppeln werden. Dann wird es halt künftig AS nur mittels VPN Client geben.

Hallo zusammen, ein Kunde fragt an, möchte EWS gern für Anbindung eines Fachverfahrens nutzen. Zugriff soll aus dem Internet via 443 auf den Exchange erfolgen. Wir könnten zwar einen bereits in Benutzung befindlichen Reverse Proxy (Windows Host) hierfür mitnutzen. Aus Sicherheitsgründen wollen wir künftig aber alle Kunden mit RP Lösungen auf VPN only umstellen. Mir gehts jetzt aber speziell noch mal um das EWS: Verstehe ich doch korrekt?: 1. EWS wird nicht mehr weiterentwickelt? 2. EWS ist ein Dienst, der wenn aus dem Internet verfügbar gemacht wird, letztlich genauso anfällig gegen Angriffe ist wie OWA und Active Sync? 3. Noch etwas in Bezug auf die Sicherheit was den EWS anbelangt und gegen den Einsatz über Portforwarding WAN zu DMZ (RP) zu LAN spricht? Danke für euer Feedback.

Tatsächlich war es am Ende die falsche Absender IP der Firewall, mit der der Exchange verschickte, die zu den Problemen geführt hat. Man hat es dann mit einem Postfix als Versendelösung umgesetzt.

Um das Problem kümmern sich jetzt die Verursacher... Trotzdem Danke für die Rückmeldungen!

Die Frage stellte sich mir unabhängig von dem Queue Problem...

Geht nur allgemein darum: Exchange 2010 bis 2019 IPv6 = aktiviert lassen oder nicht?

Hallo zusammen, soweit ich mich erinnere ist für Exchange 2010 zwingend IPv6 erforderlich. Für alle Versionen danach scheint das nicht mehr der Fall zu sein? In den offiziellen Requirements ist dazu jedenfalls nicht eindeutig etwas zu finden, dass es zwingend notwendig ist... Trotzdem gibt es aber auch noch Artikel im Netz, die bspw. bei Exchange 2013 und deaktiviertem IPv6 von Problemen berichten. Wie sind eure Erfahrungen?

Den Artikel hatte ich auch gefunden, die Befehle nimmt der 2013-er aber nicht... Das vorgeschaltete Gateway leitet ungefiltert alles auf Port 25 zum Exchange... die Queue ist derzeit 14GB groß...

Hat mal jemand einen Befehl für mich, mit dem ich die Mail Queue eines Exchange 2013 leeren kann... scheinbar ist der Echange zur Mailschleuder geworden... Alle Befehle die ich bisher gefunden haben, funktionieren nicht...

Danke, den hatte ich zuerst gesehen aber die Anpassung ließ die Warteschlange nicht kleiner werden. Es gibt allerdings noch einen Missmatch zwischen A Record des MX-er des Kunden und der dazugehörigen IP. Denn aus den Abuse/Mailerdaemons der Empfangsserver geht hervor, dass der Kundenserver/Exchange mit einer anderen WAN sendet… Hier vermute ich, dass die Empfangsserver einen einfachen Check durchführen, der fehlschlägt und daher von vielen Mailsevern die Zustellung abgelehnt wird. würde auch erklären, warum andere Mailsserver die Mails schon annehmen… bspw. Outlook.com… Gegenteilige Einschätzungen zu meiner Theorie?

Das haben wir seit Jahren auch in den Citrix Umgebungen nicht mehr genutzt... eben weil die Leute es nicht raffen. Darüber hinaus hat Citrix mit veröffentlichten Anwendungen immer wieder Probleme und Bugs gehabt, sodass wir dann schlussendliche vor Jahren auf den Deskotp umgestiegen sind. Dieses Experiment möchte ich mit RDS nicht auch noch machen, reicht mir schon diese Baustelle. Trotzdem Danke für den Vorschlag. Ja benötigen sie...

Hallo zusammen, ich habe hier einen Kunden, der will über den Exchange direkt versenden... der SMTP Banner entspricht aber im Sendekonnektor dem lokalen SMTP Namen... das führt mit der bisherigen Konstellation mail.externe-domain.de zu problemen, denn der Exchange erscheint mit exchange.interne-domain.de... Ich hab schon gesucht aber ich finde keine Möglichkeit diesen SMTP Namen/SMTP Banner vom Exchange auf den Hostnamen mail.externe-domain.de zu ändern. Solche Experimente haben wir bisher bei den Kunden aus entsprechenden Gründen vermieden und stets über andere Smarthosts verschickt... Wenn ich das hier richtig gegooglet habe, lässt sich im Sendekonnektor der Bannername aber nicht ändern, im Empfangskonnektor aber schon, was mir hier wohl aber nicht wirklich hilft?