ChristianHemker

Hallo, du brauchst keinen Zeitplan mehr, es reicht "As items arrive". Der Push ist eigentlich ein ausgelöstes Pull, ist bei Blackberry aber auch nicht anders. Der Exchange Server sendet über die HTTP(S) Verbindung eine Nachricht (keine E-Mail, enfach ein Paket) an das mobile Gerät. Anhand dieser Nachricht weiß es das was geändert wurde und macht einen ActiveSync. Natürlich muss dafür die GPRS oder UMTS Verbindung stehen, sonst kommt die erste Nachricht nicht an. Warum wird die GPRS Verbindung bei dir zeitweise beendet?

Ich denke damit ist alles gesagt.

Dann kann der Client die AIA und CRL Pfade nicht erreichen. Er kann also nicht auf die Zertifikatssperrliste zugreifen, welche in dem SSL Zertifikat angegeben ist. Nachträglich bleibt dir da nur die Möglichkeit diese Pfade anzupassen und das SSL Zertifikat neu auszustellen. Alternativ kann der Client das SSL Zertifikat einmal im LAN installieren, wo er ja auf die Pfade zugreifen kann. Hier gibt es einige Info dazu: http://technet2.microsoft.com/WindowsServer/en/Library/a4f44bc9-7517-413e-a18f-75886e9c62a71033.mspx?mfr=true

Wenn das Sicherungskonzept steht, würde ich ab und an mal ein Desaster Recovery durchführen: 1. Server per Image sichern (Norton Ghost 2003 macht immer noch wunderbare Offline Images) 2. Alternativ neue Festplatten (temporär) einbauen 3. Das ASR Backup und alles Daten zurückspieln 4. Hoffen das alles läuft ;) PS: Nichts zu danken!

Und wenn die Hostmaschine mit deinen 10 virtuellen Maschinen abraucht bekommst du Spaß...

Dann liegt es an der Hardware im Server oder an einer anderen Komponente (wie du bereits vermutet hast, evtl. die Switches). Oder du machst bei oder unmittelbar nach der Installation irgendeine Konfiguration die das Problem ausschließt.

Die von mir beschriebene Reihenfolge ist Standard unter Windows 2000 und höher, vorausgesetzt WINS und DNS sind in den TCP/IP Einstellungen konfiguriert. Wenn diese nicht konfiguriert sind, werden sie natürlich auch nicht benutzt.

Mal einen PING auf "Rechnername" machen. Was löst er dabei auf? Nur "Rechnername" oder "Rechnername.domain.local"? Ich verbinde Netzlaufwerke standardmäßig mit dem FQDN (Fully Qualified Domain Name), z. B. \\rechner.domain.local\daten. Dabei weiche ich dann der lästigen NetBIOS Namensauflösung aus. Wichtig ist die Reihenfolge der Namensauflösung unter Windows: 1. lokaler DNS Namenszwischenspeicher 2. HOSTS Datei 3. DNS Server 4. lokaler NetBIOS Namenszwischenspeicher 5. WINS 6. Broadcast 7. LMHOSTS Datei Das heißt: 1-3 ist DNS, 4-7 ist NetBIOS. Durch Einsatz von WINS Servern kann man den NetBIOS Namensbroadcast umgehen. Das würde ich auf jeden Fall machen, da dieser doch relativ lange dauert und unzuverlässig ist. Ganz abgesehen von der negativen Wirkung auf ein Netzwerk, was bei 20 Clients aber nicht relevant ist. Damit die Clients (und Server) den WINS nutzen, muss dieser in den TCP/IP Eigenschaften der Netzwerkkarte eingetragen sein.

Halte uns mal auf dem Laufenden, ob das Problem wieder auftritt.

Off-Topic: Das wäre mein nächster Post gewesen :)

Wichtig dabei ist, dass der private Schlüssel der CA im System gespeichert ist. Das bleibt natürlich auch so wenn man die Dienste beendet. Da liegt der Knackpunkt. Deshalb empfiehlt man immer erst eine Offline Root CA zu konfigurieren. Ist ja heute im Zeitalter der Virtualisierung einfach zu realisieren.

Ich würde eine andere Reihenfolge empfehlen. Die 293 enthält alle möglichen Themen aus der 290, 291, 294, 297 und 299. Daher würde ich die 293 am Schluss machen, dann hast du alles (Bis auf Zertifikatsdienste und Cluster) schon mal gehört. Die 299 wäre auch gut als "Vorbereitung" auf die 293, da eine Menge Security Themen dran kommen. Sie ist aber nicht notwendig für den MCSE.

Da es bis vor kurzem funktioniert hat, hier die Standardfrage: Was wurde geändert? Eventuell automatisch ein Update eingespielt worden? Ansonsten ist Realtek nicht gerade der beste Chipsatz, vor allem nicht in Servern.

Der Windows Audio Dienst ist gestartet? Standardmäßig ist Sound in W2k3 deaktiviert.

Tante Google hilft: http://www.visualwin.com/host-header/ http://www.aspheute.com/artikel/20000801.htm http://support.microsoft.com/default.aspx?scid=kb;en-us;308163

Das war dann aber auch keine tolle Vorbereitung! Nichts gemacht? Dann kann ich nur sagen: selber schuld. - Global schwer zu beantworten: Keine Global Catalogs, öfter Replizieren, keine Domänencontroller am Remotestandort einsetzen - Nein, es wird ja immer nur einer benutzt. - Nur bei unzuverlässigen Leitungen. - Wenn man möchte das sich die User nicht mit zwischengespeicherten Anmeldedaten anmelden können und die WAN Verbindung öfter al ausfällt und keine Global Catalogs eingesetzt am Remotestandort werden, ja. Lernen sollte man vor jeder Prüfung. Für das 2nd Chance Programm muss sich vor der ersten Prüfung anmelden und den Code dann vor der Prüfung angeben! Zu der zitierten Prüfungsfrage: Man muss es beheben, was bringt einem da GPRESULT? Ich würde sagen GPUPDATE ist richtig.

Off-Topic: Pfft, Angeber :) Mehr als 2 GB macht mein Notebook nicht mit.

Durch internes Routing (Portforwarding) oder sehr viele IP Adressen. Host Header wäre auch noch eine Möglichkeit.

Wobei da hauptsächlich Arbeitsspeicher wichtig ist. Auf meinem Notebook mit 1,5 GHz und IDE Notebook Festplatte laufen 6 virtuelle Maschinen mit VirtualPC ohne Probleme. Dafür habe ich dann aber auch 2 GB RAM eingebaut :D

Wir können grizzly999 ja notfalls noch aushelfen ;)

Das war auch mein erster Gedanke, bis ich dann gesehen habe das es Windows 2000 Server ist.

Der benutzer müsste dann http://www.domain.de:84 eingeben, was natürlich nicht gewollt ist. Die Webseite, die auf dem IIS schon auf Port 80 läuft, ist die auch von außen erreichbar? Wenn nicht könnte der Router die Lösung sein: Ein Portforwarding von Extern 80 -> nach intern 84. So könnte der Benutzer außen auch 80 benutzen, du aber intern 84.

Wobei dann das Umbenennen von Verzeichnissen auch nicht mehr funktioniert, da das intern ein Verschieben ist, welches intern wiederum ein Kopieren mit anschließendem Löschen ist.

Dann findest du die PowerShell in Vista bestimmt interessant: http://blogs.msdn.com/PowerShell/

Normalerweise muss man dem Ding das gar nicht sagen. Der IIS horcht einfach auf eine IP Adresse und einen bestimmten Port. Wenn dann eine Anfrage auf der IP Adresse mit diesem Port kommt liefert der IIS Server die Seite zurück. Eigentlich kein Problem...