PowerShellAdmin

danke habe es deaktiviert und mir erstmal entsprechendes Zertifikat erzeugt. Nach korrekter MAPI over http Umstellung, benötige ich in diesem Fall aber keine Zertifikate für die FQDN der Hosts wie bei RPC oder?

Ahoi, ich bin ja derzeit in der Exchange 2016 Bereitstellung (Exchange 2010 und 2016 Mischumgebung) In Exchange 2016 ist innerhalb der Organisation -Intranet- der Clientzugriff via Outlook ja über Mapi / Http empfohlen. Exchange 2016 VDirectories Konfiguration (2Node DAG): Node 1: Node1.domain.tld => VDirectory Settings Mapi: mail.domain.tld Node 2: Node2.domain.tld => VDirectory Settings Mapi: mail.domain.tld Die weiteren VDirectories sind ebenfalls auf mail.domain.tld gesetzt. Im Intranet (Splitdns) ist nun ein A-Record für mail.domain.tld auf den Loadbalancer gesetzt, aber auch Round Robin getestet. Mapi wurde aktiviert: Set-OrganizationConfig -MapiHttpEnabled $true Nun wurde ein altes Test-Postfach tesweise auf den Exchange 2010 auf den 2016 verschoben. Der Aufruf in Outlook funktioniert, der LB tut seinen Dienst. Zertifikatsfehler für mail.domain.tld wird angezeigt => korrekt, das San Zert lasse ich entsprechend noch erweitern. Zertifikatsfehler für node1.domain.tld bzw node2.domain.tld wird angezeigt=> habe ich hier einen Denkfehler oder ist das ein Resultat des Mischbetriebes?

DNS Round Robin betrifft hier lediglich den Client Access - Also autodiscover, EAS, Outlook Anywhere und OWA. -Zufallsprinzip des CAS Systems => keine intelligente Lastenverteilung -Nach Ausfall Verzögerung von etwa 20 Sekunden So wie ich es rausgelesen habe, durchaus eine gangbare Alternative, soweit man keinen LB benötigt => wir haben nur eine kleine Umgebung. Bin derzeit am Testaufbau und werde mir dann ein eigenes Bild von machen. Edit: Werde mir mal Kemp anschauen ;) Danke für den Tipp.

Bei uns ist "noch" Exchange 2010 im Einsatz, hier waren die Installationszeiträume andere, auch das Servicepack 3 ging zackig. Bei Exchange 2013 ist das mit Sicherheit anders, da hier natürlich doch ein sehr großer Bruch im Vergleich zu Ex 2010 ist. Aber mir gefällt der 2016er wirklich gut. Gerade da wir über die Lizenzen verfügen und bei uns Mailing eine wichtige Priorität hat, liegt eine Umsetzung einer DAG recht nahe. 2 Nodes auf getrennten Blechen, Postfächer werden auf 2 DBs verteilt - kreuz gespiegelt. Jeder Node hängt an einem separaten Internetanschluss, CAS Zugriff intern und extern via Round Robin, MX entsprechend 2 Records und SMTP ... Natürlich kein richtiges HA und auch kein intelligenter Lastenausgleich, aber funktional mit einer deutlich erhöhte Verfügbarkeit und obendrauf auch noch eine Spiegelung der Daten.

Dann bin ich froh, dass ich bin uns nen kleines DAG bereitstellen werde. Dass die CUs länger brauchen habe ich mir gedacht, allerdings schon ein ordentliches Stückel länger als das SP3 beim Ex2010 ;)

Danke - hatte gestern noch bei den Zwickereien geschaut, ob bereits das September CU bereitgestellt war ;) Was mir auffällt, dass die Updates mit Exchange 2016 deutlich mehr Zeit als auf dem Exchange 2010 benötigen. Ist das mittlerweile generell so oder nur beim CU3 ?

Danke, aber das Verzeichnis wird nach dem Neustart der Dienste wieder erstellt - hatte nur xxx.single umbenannt, nicht das Postfachverzeichnis selbst entfernt. Kann ich das aus der Suche nicht irgendwo rausnehmen oder erfolgt hier eine automatische Bereinigung nach xx Tagen? edit: Möglicherweise ein kleiner Bug, oder einfach nur sonderbar ;) Auf dem betroffenen Node war keine Datenbank mehr vorhanden. Habe nun eine neue Datenbank angelegt und konnte das Verzeichnis nun löschen - ohne Dejavu...

Also Server wurde bereits neugestartet, ebenso hatte ich mal eine Vollsicherung des Systems ausgeführt. Brachten keine Besserung. Das Stoppen der Exchange Suche reicht nicht aus, hier läuft scheinbar mehreres rein. Änderungen oder neue Dateien wurden seit dem löschen der Datenbank nicht mehr erzeugt. Wollte jetzt auch ungern das Ding "hard löschen", mich würde interessieren wieso dieses Verzeichnis noch im Zugriff ist. Hier ist das Problem bereits beim Ex2013 angesprochen: https://social.technet.microsoft.com/Forums/office/en-US/06163128-0322-4e44-9b96-b9cc677723e8/exchange-2013-removing-a-database-and-deleting-folders-but-they-still-reappear?forum=exchangesvradmin

Version: Exchange 2016 CU 2 Moin, ich habe auf dem Exchange 2016 (kleines DAG in der Einrichtung) auf einen Node eine Datenbank (erfolgreich) gelöscht. Abschließend wollte ich die Reste auf den Datenträger entfernen. Im Verzeichnis der Datenbank und Logs ist ein Ordner (Bezeichnung UID) der sich nicht entfernen lässt. Normalerweise sollte sich der Ordner löschen lassen, tut er aber nicht - Im Exchange 2013 gab es wohl mal einen ähnlichen Fehler=> Hier hat wohl ein Update geholfen. Scheinbar werden dort Meta/Indizierungsdaten für die gelöschte Datenbank abgelegt. Ich gehe davon aus, dass ich die Indizierung bereinigen muss, wie ich gehe ich hier am besten vor? VG :)

Ich kann nachvollziehen, wieso du den technischen Vorgang - weil eben Client-Pull und nicht -Push- richtig stellst und eben eine Bereitstellung nicht Verteilung stattfindet. Das erschließt sich ja auch indirekt aus der konkreten Situation, da das KB auf den Client aufgespielt werden muss und eben nicht via WSUS aufgespielt werden kann. Dennoch bin ich der Meinung, dass das Vorgehen mit der Verteilung -logische Konsequenz- richtig beschrieben ist. Ich weiß, sehr ich ja auch als Ergänzung ;) und ich bin doch nur ein Sturrkopf der seine ungenaue Formulierung retten will ;)

Weil Tools oftmals nicht den Anforderungen entsprechen. Outdatet mit Update, unnötiger Java Script und Inhalte die nachgeladen werden, weil vielleicht der Datenschutz nicht erfüllt wird und das mit neuen Versionen nicht mehr erfüllt wird In Wordpress umgehe ich auch Plugins, die ich nicht brauche, da hier vorallem der Datenschutz ein großes Problem ist - Googlefonts, Facebook Connect uvm. Hatte ich erst bei den Social Share Plugins, am Ende ne Codevorlage genommen und nach meinen Wünschen angepasst.

Mir ist es ja selber bekannt - daher auch die Analogie. Ansonsten - Der technische Vorgang war mit meiner Formulierung im Detail falsch beschrieben. Inhaltlich sieht das wieder ganz anders, da ist die Beschreibung für den Vorgang absolut i.O. und korrekt. :-)

Ja ich weiß der WSUS ist ne Prostituierte und die Clients sind seine Freier... alles gut. Aber wenn wir schon so pendantisch sind: Ich habe geschrieben, dass die Verteilung des Updates via Skript läuft. Die GPO Dient nur zu Planung der Ausführung.

Die Verteilung vom 1607 via WSUS lief nach dem WSUS Update problemlos. Vorraussetzung war natürlich der ESD MIME Typ. Nach dem 1607 haben die Clients keine Updates mehr vom Server bezogen - Download vom WSUS war nicht möglich. Nach der manuellen Installation von KB3189866 geht es bei mir ebenfalls wieder... Bin froh hier nur 3 Testbüchsen zu haben und mit der Umstellung noch zu warten... PS: Verteilung des Updates kann man ja auch via GPO und z.B. PS Skript übernehmen.

Hallo Peter, dass du dieses Vorgehen nicht bevorzugst, hatte ich schon rausgelesen. Die logische Argumentation kann ich ebenfalls nachvollziehen, aber gerade kostentechnisch empfinde ich die Argumentation unzutreffend, da es hier "sinnvoller" Alternativen ist. Im Detail sollte man die Gesamtkosten beider Lösungen gegenüberstellen... aber nun gut :) Ansonsten - man sollte dem Kunden 2-3 vernünftige Vorschläge anbieten. Soweit diese abgelehnt werden und auch keine sinnvoller Lösungswunsch vorhanden ist, sollte man die Zusammenarbeit überdenken.

Und wo ist da der Vorteil gegenüber einen 1xWindows Server 2012r2 Std (2xVM - DC + Exchange), Exchange 2016 Std + User Cals?

Wieso soll man für das Intranet Outlook Anywhere verwenden .... :rolleyes: Und wieso sollte man bei passender Infrastruktur auf die Vorteile einer Domäne verzichten... So weiter arbeiten und zuviel Popcorn ist ungesund ;-) Jeder Topf hat seinen passenden Deckel ... :jau:

Also mein Arbeitsleben wird noch deutlich länger als über das Jahr 2016/17 hinaus gehen. Aber es soll auch heute noch Admins geben, die "never change a running system" runterbeten ....

Richtig Kritik, wäre der Hinweis, dass Microsoft dies via GPO nachliefern sollte. Ich kann deine Posts auch nur bedingt nachvollziehen - Polemik ist selten hilfreich und im Job erstrecht nicht.

Also die Fehlerbehandlung nehme ich üblicherweise im Testlab/Sandbox vor, genau wie die vorsorglichen Tests. Da es sich wahrscheinlich um ein physikalisches Einzelsystem handelt, ist ein Restore auch nicht sehr angenehm. Zur Problemlösung würde ich zeitnah einen critical case bei Microsoft eröffnen, aber hierfür solltest du auch vor Ort sein. Hört sich ziemlich ekelig an... Alternativ vor Ort fahren, recherchieren und testen. Ansonsten: Daten sichern!!! (ganz wichtig welche...) Restore Differenzen einspielen.

Hört sich nicht gut an, gerade durch die Mandanten wird es regelmäßig Überstunden geben - die solltest du so oder so vertraglich Deckeln. Ich möchte nicht mehr in einem Systemhaus im Kundenservice arbeiten und das Gehalt klingt nach ziemlicher Unterkante. (Bin damals im Raum FFM beim AUsbilder auch für 1 Jahr mit 2300 eingestiegen und zwei Jahre später gewechselt- darf man noch etwas Inflation aufschlagen). Für einen Neueinsteiger gerade so akzeptabel. Bin mit meinem jetzigen Arbeitgeber sehr zufrieden, Gehalt aber auch die Flexibilität als Familienvater - die unbezahlbar ist- kommen hier zusammen. Gehalt ist wichtig, aber nicht alles. Zum Thema Gehalt nach Probezeit - würde ich nie eingehen. Das Gehalt wird davor definiert, wenns dem AG nicht passt, hat er die Probezeit um dich rauszuschmeißen. Alles andere ist Glaskugel. Ein Arbeitgeber der dir Gehaltserhöungen gibt, wird dir auch ein angemessenes Anfangsgehalt bieten - umgekehrt kannst du es dir ja denken...

Das ADMX von Windows 10 1607 überschreibt diese Einstellungen - wie bereits Rackzack geschrieben hat. Hier gibt es ja neue und differenzierte Einstellungen in der Updateverwaltung. Möchte man das Problem umgehen, ist es am einfachsten den Registrierungswert via GPO einmalig auf 0 zusetzen. In der lokalen GP Verwaltung am Client ist die Option natürlich verfügbar. Mir waren die Umstände so jedenfalls vorab nicht klar.

Genau davon reden wir - gelöscht, vom W2k12r2 wurden die PolicyDefinitions reinkopiert und dann mit den Win10 1607 überschrieben. MMC und GPO Verwaltung => GPMC.MSC So wie ich das sehe, ist die GPO Einstellung nachträglich ergänzt worden. https://support.microsoft.com/en-us/kb/3050267 Das Update wurde aufgespielt edit : test

Den Central Storage habe ich jetzt nochmal gelöscht und die neuen Windows 10 1607 ADMX neu eingespielt. Die W10 Einstellungen sind auch korrekt ersichtlich. Die Einstellung "Turn off the upgrade to the latest version of Windows through Windows Update." wird weiterhin nicht angezeigt (unter W2k8r2 und W2k12r2) (Computer-Konfiguration->Administrative Vorlagen->Windows-Komponenten->Windows-Update). Die Einstellung selber musste bei Tests gesetzt worden sein, bei dem betroffenen Gerät ist diese nicht mehr erstellt worden. Mich wundert nur das Fehlen der Funktion.

Habe ich ja auch nicht behauptet :-) Ich habe hier aber die ADMX Vorlagen (1511er) in Verdacht. Das wird eigentlich über die Einstellung "Turn off the upgrade to the latest version of Windows through Windows Update." gesetzt, welche bei mir aber fehlt. Die Option Upgrade zurückstellen war auch nicht gesetzt und testweise auf deaktiviert. Das Update Windows 7 auf Win 10 RTM, als auch das Inplace Upgrade auf Windows 10 1511 lief noch - daher muss die Einstellung erst im Anschluss durch die GPOs gesetzt worden sein. Die GPO wurde erst nach den obigen Upgrades eingerichtet (Testbetrieb), womöglich kollidiert hier auch eine andere Einstellung. Werde die ADMX Vorlagen erstmal aktualisieren.. Vielleicht weißt du ja was - du bist schließlich der GPO-Guru :-)