mwiederkehr

Ich würde den Rapport und die Dokumentation trennen. Den Rapport schaut später niemand mehr an, die Doku wird aber unter Umständen noch Jahre später benötigt. Den Rapport würde ich so kurz wie möglich halten. Derjenige, der die Rechnung prüft, wird sich nicht für Details interessieren. Es interessiert nicht, dass Du "apt install mysql-server" eingetippt oder die DNS-Server in der Datei "/etc/resolv.conf" mit dem Editor nano hinterlegt hast. Eher so "Grundinstallation Linux-Server inkl. Updates und Netzwerkkonfiguration, Installation MySQL, Erstellung Backupscripts, Test".

Was ist denn das Ziel des Protokolls? Soll es als Anleitung oder Dokumentation dienen? Im Sinne von "damit soll ein Azubi den nächsten Server alleine installieren können" oder nur "nachschauen können, was der Server für eine IP-Adresse hat und welche Version von Software XY installiert ist"? Oder wird es der Rechnung beigelegt, damit der Kunde sieht, wie lange für welche Aufgabe gearbeitet wurde?

Je nach Anforderungen reicht evtl. die unter https://community.spiceworks.com/topic/324146-windows-server-namespaces-dfs-vs-windows-search-indexing?page=1#entry-4921597 vorgeschlagene Lösung: Anwendungen arbeiten über DFS, auf den Clients werden aber direkt die Server verbunden. Das geht ja dank GPO auch mit unterschiedlichen Servern pro Standort etc. Nur Failover geht dann natürlich nicht automatisch.

Wie die Funktion heisst, konnte ich nicht herausfinden, habe auch keine Dokumentation von Microsoft dazu gefunden. Nur diesen Artikel, in dem die Funktion "Remote Search" genannt wird: http://sourcedaddy.com/windows-7/understanding-remote-search.html Es funktioniert definitiv. (Und ist der wichtigste Grund, Windows Search auf Fileservern zu installieren.) Anscheinend funktioniert es aber nicht mit DFS-Namespaces, da der Suchclient nicht weiss, welchen Server er ansprechen soll. Das könnte hier das Problem sein. Funktioniert es mit dem UNC-Pfad direkt auf einen Server? siehe auch https://social.technet.microsoft.com/Forums/en-US/a1b00d0a-3806-4388-bfcf-62f7df7257f6/dfs-2012-and-windows-search?forum=winserverfiles und https://community.spiceworks.com/topic/324146-windows-server-namespaces-dfs-vs-windows-search-indexing?page=1#entry-4921597 Edit: Habe doch noch einen Link von Microsoft gefunden: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-7/dd744693(v=ws.10) Habe ich nicht gewusst. Anscheinend sind die Kunden mit DFS eher von der ordentlichen Sorte.

Möchte mich NilsK anschliessen. Der Grund "Schutz vor Serverdefekt" fällt bei Office 365 aus. Trotzdem war ich schon froh um eine Sicherung. Dann nämlich, wenn der Kunde eine Mail wieder haben will, die er vor einem Jahr gelöscht hat. Zur Software: bis jetzt sichere ich mit Acronis Backup Cloud. Da bezahlt man nur den belegten Speicherplatz und nicht pro Postfach eine Lizenz. Man muss aber neue Benutzer von Hand ins Backup einbinden und der Restore geht nur entweder pro Mail oder dann pro Ordner oder Mailbox in eine Mailbox (kein PST-Export). Die Lösung von Veeam würde ich mir anschauen, wenn eine lokale Datenhaltung und die Einbindung in andere Veeam Produkte (Cloud Connect etc.) gewünscht sind. Dort bezahlt man dann pro gesichertem Postfach.

Kein Problem, ich habe mich nicht angegriffen gefühlt. Die Aussage von DocData war direkt, aber nicht falsch. Ich erlebe solche Sachen immer wieder im Alltag. Microsoft-Produkte haben (wohl dank SBS) immer noch den Ruf, einfach zu sein. Mit dem Assistenten "zusammengeklickte" Exchanges gibt es, ebenso Hyper-V-Cluster etc. Aber für einen kleinen Linux-Server holt man sofort einen Consultant, weil ist ja kompliziert mit den Konfigurationsdateien und so... Ich nehme mich da selbst nicht aus. Arbeite zwar schon seit Version 2000 mit Exchange und habe schon mal von Shadow Redundancy gelesen, aber auf Anhieb darauf gekommen bin ich trotzdem nicht. Umso mehr bin ich froh, hier im Forum kompetente Hilfe von Leuten zu erhalten, die täglich mit Exchange arbeiten!

Auf einem DC sollte möglichst keine Software installiert werden, deshalb sollte man ihn nicht als SQL Server und nicht als Terminalserver einsetzen. Windows-eigene Rollen wie DHCP oder Fileserver machen eigentlich keine Probleme. Der IIS ginge zwar, aber für Websites will man meist lokale Benutzer und die gibt es auf einem DC ja nicht. Von daher halte ich Deine Aufteilung für eine private Umgebung für sinnvoll. Für mehr virtuelle Server würdest Du zusätzliche Lizenzen benötigen. Wegen der Virtualisierung würde ich mir keine Sorgen machen. Deren Overhead ist dank Unterstützung direkt in der CPU sehr klein.

Das stimmt natürlich, allerdings muss ich den Admin etwas in Schutz nehmen: Exchange macht mit jeder neuen Version wieder ein paar Sachen mehr automatisch im Hintergrund, die einem auf die Füsse fallen können. Shadow Redundancy ist zweifellos eine gute Sache, aber es müsste nicht unbedingt automatisch aktiviert sein.

Betreue die Umgebung nur als Urlaubsvertretung und die Doku ist sagen wir mal sparsam. So wie ich das verstehe, war der Testserver nicht für Tests im Sinne von "der Azubi soll mal werkeln" gedacht, sondern für "neue CUs werden zuerst da installiert und dann schaut man mit ein paar Testbenutzern, ob alles läuft". Eigentlich ja keine schlechte Idee, wäre da nicht die Abhängigkeit der Server untereinander... Ich denke, den bekommt man gut wieder raus, denn er ist nur Exchange und nicht noch DC und Fileserver, wie man vermuten könnte. Also entweder raus, oder zu einem vollwertigen Exchange machen, mit DAG und extern erreichbar etc. (wobei ich da den Aufwand persönlich lieber gleich in Exchange 2019 stecken würde).

Das Problem scheint gelöst zu sein. Es gab in der Organisation noch einen anderen Exchange, der zu Testzwecken installiert worden war. Hat keine Postfächer in der DB und ist extern nicht erreichbar. Und er hatte weniger RAM (wohl, weil Testserver). Dort in der Ereignisanzeige hatte es Meldungen bezüglich Back Pressure. Weshalb der primäre Server keine Mails angenommen hat, ist mir nicht ganz klar. Ich vermute Shadow Redundancy. Nachdem der Testserver mehr RAM bekommen hat, kommen die Mails auf dem primären Server auf jeden Fall problemlos an. Die Lehre aus der Geschichte: Testserver in einer anderen Domäne installieren. Vielen Dank für die Tipps! Durch das "Bestehen" auf Back Pressure bin ich erst darauf gekommen, nach anderen Servern in der Organisation zu suchen.

Bist Du schnell! C: (Windows + Exchange): 46.5 GB frei von 149 GB E: (Datenbank): 415 GB frei von 599 GB L: (Logfiles): 69.9 GB frei von 99.9 GB 516 MB (habe diese heute Morgen neu erstellen lassen, vorher war sie 2.8 GB). Ausser einem fehlenden Zertifikat gibt es keine Fehler oder Warnungen von "MSExchangeTransport". Das Log reicht aber nur ein paar Tage zurück. Wäre gut möglich, dass das Problem schon länger besteht und es noch niemand gemerkt hat (die Mails kommen ja an, einfach verzögert). Der PowerShell-Befehl vom Link sagt: <ResourceThrottling> <message>Component "ResourceThrottling" is not supported by this process.</message> </ResourceThrottling> (Wohl deshalb, weil ich Back Pressure deaktiviert habe.)

Hallo zusammen Ein Exchange 2013 lehnt etwa die Hälfte aller Mailzustellungen ab mit "452 4.3.1 Insufficient system resources" nach dem DATA-Kommando. Für gewöhnlich ist da ja zu wenig freier Speicher die Ursache. Auf jeder Partition sind aber noch über 30% Speicher frei und auch der Arbeitsspeicher ist nicht ausgelastet. Zum Test habe ich "EnableResourceMonitoring" auf "false" gesetzt und den Transport-Dienst neu gestartet. Leider ohne Erfolg. In der Ereignisanzeige sehe ich keine Fehler in diesem Zusammenhang. Das Problem tritt nur im Zusammenhang mit SMTP auf. Intern über Outlook werden alle Mails sofort zugestellt. Frage: Wo kann ich nachschauen, aufgrund welchen Kriteriums der Exchange auf die Idee kommt, eine Mail abzulehnen? Vielen Dank!

Der Exchange ist von Office 365. Die Anbindung ist -dank lokalem Glasfaseranbieter- sehr komfortabel mit 1 GBit/s symmetrisch. Aber die Verzögerung beim Wechsel zwischen E-Mails ist immer noch spürbar und einige Benutzer springen mit "Pfeil runter" durch die Mails und akzeptieren keine Verzögerung. Danke für die Links, das ist genau, was ich gesucht habe! Wusste nicht, dass das mit Outlook 2016 schon geht. Mit FAST wäre dann auch die nervige Meldung "weitere Resultate auf dem Server suchen" weg. (Konnte den Cache nur auf drei Monate festlegen, würde sonst zu viel Platz belegen.)

Hallo zusammen Bei einem Kunden läuft Outlook 2013 auf einem Windows Server 2012 R2. Die E-Mails laufen über Office 365. Damit die Suchfunktion im Outlook funktioniert, habe ich Windows Search installiert. Es wird nur Outlook indexiert, keine lokalen Dateien. Das Problem ist nun, dass der Suchindex immer grösser wird. Aktuell ist er bei 38 GB. Und das bei zehn Benutzern! Das ist schon etwas merkwürdig, denn ein Index sollte ja kleiner sein als die indizierten Daten. Problematisch ist aber, dass die Daten von gelöschten Benutzern nicht entfernt werden. Ich habe es mit der Offline-Defragmentierung versucht. Leider wurde die Datenbank dadurch nur unwesentlich kleiner. Eine Neuerstellung der Datenbank ist leider keine Option, da der Index nur aktualisiert wird, wenn die Benutzer angemeldet sind. Dann ist tagsüber der Server ausgelastet und die Suchresultate sind über mehrere Tage unvollständig. Von Microsoft habe ich dazu leider nicht viel gefunden. Irgendwo steht, man solle Windows Search nicht auf Terminalservern installieren. Das widerspricht aber irgendwie der Angabe, Outlook 2013 sei auf Terminalservern supported. Eine Lösung wäre, den Cache-Modus zu deaktivieren. Dann würde die Suche auf dem Exchange statt dem Client stattfinden. Leider akzeptieren die Benutzer die (kleine, aber merkliche) Verzögerung beim Wechsel zwischen E-Mails nicht. Wie macht ihr das? Ist das gelöst mit dem Outlook aus Office 365? Oder in Outlook 2019? Es fehlt ja eigentlich nur die Option "Suche auf Exchange Server statt lokalem Windows Search durchführen". Vielen Dank für eure Tipps!

Vielen Dank für die Bestätigung! War ja eigentlich klar, aber der Kunde war derart überzeugt, dass es mich etwas verunsichert hat.

Als Ergänzung zum Link von "testperson": Wenn Du nicht spezielle Features wie Cache für vSAN oder so verwenden möchtest, kannst Du Dir die Anpassung sparen. Auch wenn der Datastore nicht als SSD erkannt wird, wird natürlich trotzdem die SSD-Performance erreicht. Es läuft also keine "Drosselung" oder so.

Hallo zusammen Nach der Ablösung eines Servers mit Windows 2003 durch einen mit Windows Server 2016 beklagt der Kunde, dass in seinem 16 Bit-CAD auf Windows XP nicht mehr alle Verzeichnisse angezeigt werden. Gemerkt, dass alle Verzeichnisse mit einem Namen länger als 8 Zeichen fehlen. Ok, 8.3-Namen sind beim Server 2016 standardmässig nicht mehr aktiviert. Einstellung angepasst und 8.3-Namen generiert. Jetzt sieht man alle Verzeichnisse, die langen einfach in der "Tilde-Form". Das Problem ist nun, dass der Kunde vehement behauptet, vorher habe er auch lange Verzeichnisse vollständig gesehen. Zum Test die Freigabe auf dem alten Server nochmals angehängt: Verzeichnisse haben ebenfalls Tilde. Kann mir nicht vorstellen, dass da a.) einmal lange Namen angezeigt werden konnten und b.) dass sich durch die Einbindung eines neuen Servers das Verhalten auch auf dem alten Server ändert. Nur ist sich der Kunde sehr, sehr sicher, dass das früher anders war. Deshalb kurz die Frage: kann das sein? Vielen Dank!

Man könnte bei der Zählung interne und externe Empfänger unterscheiden: entweder hat das Recipient-Objekt eine Eigenschaft "isInternal" oder ähnlich (habe nicht nachgeschaut), oder man gleicht die Domain mit den internen Domains ab.

Man könnte das mit einem Transport-Agenten lösen. Dort (im Event "OnSubmittedMessage") kann man noch zwischen "To", "CC" und "BCC" unterscheiden. Falls "To" oder "CC" mehr als zehn Empfänger enthält, könnte man die Nachricht löschen und den Absender benachrichtigen. Aber der Versand über ein CRM oder meinetwegen die Serienbrieffunktion von Outlook wäre sicher die bessere Lösung.

Wenn man die Outlook-App verwendet, kann man die Synchronisation von Kontakten mit dem Telefon (und somit WhatsApp) verhindern. Dies kann der User aber jederzeit ändern und es hat den Nachteil, dass die Anruferkennung nicht mehr funktioniert.

Der Eintrag gilt pro Benutzer, also pro Benutzerprofil. In Deinem Fall müsstest Du dem einen Benutzer eine Autodiscover.xml unterschieben, die auf den internen Exchange zeigt. Beim zweiten Benutzer müsste nichts angepasst werden, der macht ja schon Autodiscover nach extern. Aber ich stimme "NorbertFe" zu: es wäre besser, nur einen Exchange zu haben. Entweder den Internen (mit Cache-Modus ist es ja nicht so schlimm mit den Mails in der Aussenstelle) oder gleich einen Externen, entweder beim derzeitigen Provider oder bei Office 365. Der "Trick" mit dem Registry-Key ist zwar kostenlos umsetzbar, aber irgendwann macht man ein neues Profil, vergisst den Key und sucht einen halben Tag nach dem Fehler, was dann nicht kostenfrei ist.

Man kann Outlook eine eigene Autodiscover.xml unterschieben: https://www.virtualdcs.co.uk/blog/outlook-2016-autodiscover-workaround/ Das sollte in Deinem Fall funktionieren, ist aber natürlich keine schöne Lösung.

Die Performance von RDP ist sehr gut. Was Du früher evtl. gehört hast, hat die ersten Versionen von RDP betroffen. Da hat man aus Performancegründen manchmal ICA (sprich Citrix MetaFrame) genommen. Heute ist das aber kein Problem mehr, zumindest nicht bei Standard-Anwendungen. VNC ist meiner Erfahrung nach deutlich langsamer als RDP, da es ganz anders arbeitet: VNC greift den Bildschirm ab, RDP erzeugt virtuelle Bildschirme (deshalb können damit auch mehrere Leute gleichzeitig arbeiten).

Du hast die Geschwindigkeit schon fest auf 100 MBit/s gestellt und nicht auf 1 GBit/s, oder? Fest auf 100 MBit/s hat bei mir bei vier Adern immer geholfen. Kann aber nichts zu neuen Netzwerkkarten sagen, solche "Legacy"-Umgebungen sind mir zum Glück die letzten Jahre nicht mehr untergekommen.

Müssen die Leute auf jeweils eigenen Desktopsystemen arbeiten? Liesse sich Dein Vorhaben nicht mit einem Terminalserver umsetzen? Das würde erheblich weniger Ressourcen benötigen. Wieso nicht per RDP arbeiten? Bei SPLA werden Betriebssysteme per Core lizenziert, CALs aber pro Benutzer oder Gerät. Du müsstest also die Cores mit Windows lizenzieren und für jeden Benutzer oder jedes Gerät eine CAL mieten. Achtung: "Benutzer" heisst "Mensch" und nicht "gleichzeitiger Benutzer". Wenn 100 Leute zugreifen können, musst Du 100 Lizenzen haben, auch wenn nur 10 Leute gleichzeitig arbeiten.