Doso

Oder keinen Chrome einsetzen. Das war unsere Lösung als wir feststellen mussten das Chrome abstürzt wenn das Chrome Profil auf einem Netzlaufwerk liegt.

ICMP (das ist Ping) hat jetzt nicht direkt was mit DHCP zu tun. Blockt vielleicht ein zentrale Router/Firewall auf dem Weg ICMP?

http://lmgtfy.com/?q=old+version+google+chrome

Ich habe das früher nach der ganz einfachen Methode gemacht - vhd kopieren. Klappt wunderbar. http://sondreb.com/blog/post/hyper-v-making-template-virtual-machines.aspx

Unter 2012R2 geht das dann oft auch im laufenden Betrieb, z.B. bei Gen2 VMs oder wenn die Daten VHDx als ISCSI angebunden ist.

Hyper-V Replica für DCs - geht das überhaupt? Bei SQL Server muss man hier ein paar Sachen beachten. Hyper-V Replica lässt sich auch nur schlecht, bis gar nicht, über den VMM verwalten. Ob sich der Aufwand für eigene Management-Umgebung überhaupt lohnt oder ob man nicht lieber auf die Hochverfügbarkeit des Clusters setzt und damit auch die Mangement Umgebung hochverfügbar hat?

Naja, da hast du schon mal ein Problem.

Bei uns hatten wir das Problem das unser SAN irgendwie in einen "komischen" Zustand kam und keinen neuen iSCSI Verbindungen mehr akzeptierte. Beim Patch Day b***d, da ja die Server neu starten. Das hatten wie zwei mal, durch Cluster Aware Updating auf Hyper-V Hosts hatte letztlich ein Host dann immer noch eine Verbindung offen was uns dann gerettet hat. Bei direkter iSCSI Verbindung war der Fileserver down. Bei der VHDx Verbindung war der Fileserver weiter erreichbar. Zugegeben, das ist ein eher unübliches Szenario.

Ich halte mich da an die Empfehlung aus dem Buch: http://www.amazon.de/Microsoft-Hyper-V-System-Center-Administratoren/dp/3836228114 Ich finde es einfacher es per Gruppenrichtline an den DCs zu konfigurieren, anstatt jedes mall an nem Hyper-V Host manuell rumzufummeln. In unserer Umgebung haben wir mehr Hyper-V Hosts als DCs.

Man kann ja auch mehrere VHDx draus machen. Nachdem das letztlich vermutlich immer noch auf dem selben Gerät liegt, isses dann aber auch schon recht egal. Hauptsache das Backup stimmt und liegt woanders.

Domain Controller, Hyper-V Hosts in die Domäne, bei den virt. DCs die Zeitsynchronisation über die Integrationsdienste ausschalten.

Wir hatten das früher mit iSCSI direkt in der VM gemacht, sind aber dann auf vhdx Anbindung umgestiegen. Ist halt dann einheitlich.

Alles klar...

Es ist übrigends ein Rollup, kein Rollout. Die Installation von Rollups macht keine Datenbanken kaputt, da ist etwas anders passiert. Wieso willst du da was defragmentieren, wenn du es reparieren willst. Das hilft dir nicht weiter. Ansonsten musst du halt die Parameter richtig setzen, sonst schreibt dir eseutil die neue edb auf das aktuelle Programmverzeichnis in der Konsole, und das ist dann meist C:.

Dieses Windows Updates gab es wieder einige Updates die das saubere starten unter gewissen Bedingungen verhindert, vielleicht trifft es dich da.

Forefront ist eine Sicherheitssoftware, daher ist vermutlich alles sicherheitsrelevant. Auch so Sachen wie aus dem letzten Rollup 5 würde ich da zählen: FIX: Account lockout alerts are not logged after you install Rollup 4 for TMG 2010 SP2 http://support.microsoft.com/en-us/kb/2954173/en-us

Unter 2010 hatte die auch so ihre Macken, war aber im Vergleich zum Rest noch ganz okay das stimmt. BE2012 war aber in vielerlei Hinsicht ein Reinfall.

Da wirst du nicht drum rum kommen.

AFAIR wird alles was mit Passwörtern zu tun hat nicht gecached sondern geht immer auf das AD.

Eine Exchange Migration über eine alte Version einer bekannt miesen Version einer Backup Software. Ich glaube du verfolgst hier den falschen Ansatz.

Will man höhere Verfügbarkeit muss man Geld in die Hand nehmen und das wird dann in der Tat recht schnell recht teuer. Doppelt Hardware, ein SAN, zwei SANs, zweiter Standort, redundante Netzwerkanbindung 24/7/365 Support, schnelle Reaktionszeiten bei Hardwaredefekt. Machen kann man viel, das kann auch schon bei kleinen Kunden mit großem Umsatz Sinn machen, muss es aber nicht.Nur weil man da einen zweiten Server hinstellt, hat man keine größere Ausfallsicherheit.

Name : EWS (Default Web Site) InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity} ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity} Name : OAB (Default Web Site) InternalAuthenticationMethods : {WindowsIntegrated} ExternalAuthenticationMethods : {WindowsIntegrated} Ich habe auch die Verzeichnisse nochmal durchgeschaut und dabei ist mir aufgefallen das auf einigen Verzeichnisen noch ein HTTP Redirect drauf war. Wir haben auf der Hauptseite des IIS einen HTTP Redirect drauf auf mail.myodmain.de/owa - damit unsere Nutzer halt nur mail.mydomain.de für das Webmail eintippen müssen. Habe das mit einem Testserver abgeglichen und entsprechend den HTTP Redirect auf einigen Verzeichnissen entfernt. Evtl. war es das ja schon.

Ich glaube ich habe da hier vor einer Weilewas manuell an dem Webservicekonfiguriert. Get-WebServicesVirtualDirectory | fl liefert mir folgende Adressen: InternalUrl : https://mail.mydomain.de/EWS/Exchange.asmx ExternalUrl : https://mail.mydomain.de/ews/exchange.asmx Ist die Groß/Kleinschreibung hier wichtig? Jemand eine Idee was hier der Standard ist? Der Server selbst heisst Exchange1, ich habe damals glaube ich die InternalURL gleich der External URL gesetzt, war halt vorher exchange1.mydomain.de. Könnte das die Ursache sein?

Mit der richtigen Software kein Problem. Kommt aber teilweise zu Ausfällen der VM während ein Abbild gezogen wird. Unter HyperV2008R2 und Linux VMs. Bei großen VMs kann das schon mal mehrere Minuten dauern.

Wir haben einen Exchange 2010 SP3, Rollup 8v2 im Einsatz. Der Großteil der Nutzer hat Windows 7 Office 2010 SP2 mit Outlook im Einsatz. Outlook läuft dabei meist im Exchange Cache Modus, bei einigen ist es wegen Problemen mit freigegeben Postfächern deaktiviert. Wir haben nun 2 Rechner in der IT mit Windows 8.1 und Office 2013. Bei diesen Nutzern kommt ständig eine Loginmaske wenn sie normal arbeiten, aber E-Mail scheint sich trotzdem zu aktualisieren. Sobald man den Exchange Cache Modus deaktiviert und sie somit direkt mit dem Server arbeiten gibt es keine Probleme. Server und Clients sind in unterschiedlichen VLANs mit einer Firewall dazwischen, wo wir einen Haufen Ports für RPC etc. freigegben haben, laut Logfiles wird scheinbar auch nix blockiert. Ich bin etwas verwirrt wegen den ganzen RPC over HTTP, das Outlook 2013 ja wohl bevorzugt nutzt. Aus dem Outlook Verbindungsstatus werde ich auch nicht schlau. Finde da irgendwie keinen Fehler und die tollen Tipps von Google helfen mir irgendwie auch nicht weiter. Jemand eine Idee was das sein könnte?