Bei einem Kunden ist ein SBS 2003 im Einsatz, der mit ntbackup.exe (nicht mit dem eingebauten SBS Backup) auf externe USB-Festplatten gesichert wird. Zur Sicherstellung der Wiederherstellbarkeit im Notfall soll ein Testrestore in eine virtuelle Maschine (VM) durchgeführt werden.

Auf unserem VMware ESXi Server (noch Version 3.5, da die Hardware nicht 64bit fähig ist) habe ich eine VM für den Testrestore erzeugt und mich im weiteren an die “offizielle” Anleitung von Microsoft gehalten.

  • Wie dort beschrieben habe ich zuerst den SBS 2003 von den Originaldatenträgern installiert, was hier bedeutete: Eine ISO-Datei von der CD1 erzeugen und diese dann mit Veeam FastSCP auf den Datastore des ESXi kopieren (der direkte Zugriff auf die CD im Laufwerk des ESXi-Servers hat nicht funktioniert). Anschließend die “jungfäuliche” VM von dieser ISO starten.
  • Am Ende der Installation will der Installer nach einem Neustart mit dem zweiten Teil der Installation weitermachen. Hier habe ich abgebrochen, von der Microsoft Website das Windows Server 2003 SP2 heruntergeladen und installiert.
  • Nach dem darauf folgenden Neustart soll man die USB-Backupplatte anschließen. Dies ist aber bei einem ESXi 3.5 nicht möglich (USB wird nicht an die VM “durchgereicht”), also habe ich die Platte an einen anderen PC angesteckt und dort freigegeben und in der VM als Netzlaufwerk gemounted.
  • Da auf dem zu restorenden Server eine zweite Datenpartition (D:) verwendet wurde, habe ich die VM jetzt heruntergefahren und mit dem vSphere Client der VM eine zweite Festplatte hinzugefügt und diese nach dem Wiederhochfahren der VM mit der Datenträgerverwaltung formatiert und als Laufwerk D: eingebunden.
  • Dann ntbackup.exe (“Sicherung”) starten, in den Optionen bei Wiederherstellung auf “Datei auf meinem Computer immer ersetzen” umschalten, dann auf dem Reiter “Medien wiederherstellen und verwalten” in der linken Spalte mit der rechten Maustaste auf “Datei” klicken und mit “Datei katalogisieren…” das Backup auf der gemounteten USB-Backupplatte wählen. Dann in der linken Spalte die gewünschten Objekte für die Wiederherstellung wählen: In diesem Fall habe ich das komplette Laufwerk C:, den kompletten “SystemState” und das Verzeichnis “Programme” auf Laufwerk D: (darin befinden sich die Exchange-Datenbanken) gewählt. Der “Information Store” muss nicht gewählt werden, weil ja schon alle zu Exchange gehörigen Dateien komplett restored werden. In dem folgenden “Wiederherstellung bestätigen” Dialog noch auf “Erweitert” klicken und zusätzlich zu den bereits aktivierten 3 Optionen auch noch “Wiederhergestellte Daten in replizierten Datensätzen als primäre Daten für alle Replikate markieren” als 4. aktive Option markieren. Dann die Wiederherstellung starten, die je nach Datenmenge natürlich viele Stunden dauern kann.
  • Nach dem Abschluß der Wiederherstellung auf “Bericht” klicken und überprüfen ob es Probleme – vor allem beim SystemState – gegeben hat. Warnungen bzgl. “short file names” in einigen Verzeichnissen (wie in der Microsoft Anleitung beschrieben) sind normal.
  • Nach dem folgenden Neustart wurde nur weiß auf schwarz eine Fehlermeldung angezeigt. Mir war sofort klar wo das Problem lag und warum in der Anleitung so vehement darauf hingewiesen wurde, vor dem Restore alle (alle!) Partitionen wie im Original vorzubereiten. Auf dem Originalserver gibt es eine “DELL Utility Partition”, die ich in der VM nicht angelegt hatte. Damit stimmt die Nummerierung der Partitionen nicht mit dem Original überein und der Bootloader findet das Betriebssystem nicht. Also eine ISO von einer Notfall-DVD (Win7 PE) erzeugt und die VM von dieser ISO gestartet. Damit die boot.ini auf C: editiert: Windows liegt jetzt auf “partition(1)” und nicht auf “partition(2)”.
  • Nach einem Neustart fährt der Server sehr langsam hoch und will nachdem ich mich endlich anmelden konnte sofort wieder einen Neustart. Dies passiert wegen der massiv geänderten Hardware und der dadurch verursachten Treiberänderung in der VM. Nach dem erneuten, jetzt normal schnellem Neustart erscheint eine Warnung, dass Windows wegen der Hardwareänderungen erneut aktiviert werden muss, was ich (weil es ja nur ein Testrestore ist) natürlich nicht gemacht habe.
  • Da dieser SBS die E-Mails mit dem POP3-Connector abholt und das Ganze ja nur ein Testrestore ist, habe ich als Erstes sofort die automatische Abholung der Mails deaktiviert, damit keine echten Mails abgeholt werden, die dann natürlich für den “echten” Server verloren wären.
  • Jetzt in den Eigenschaften der Netzwerkkarte eine feste IP-Adresse vergeben und – wie für einen DNS üblich – die eigene Adresse als DNS eintragen. Dann im DNS die Forwarders anpassen, wenn diese nicht gleich geblieben sind.
  • Ein letzter Neustart und dann ein ausführlicher Blick in die Eventlogs um den Erfolg des Testrestores zu überprüfen.

 

 

Die üblichen Speedtests wie speedtest.net oder Zack haben nur beschränkte Aussagekraft. Sehr praktisch für eine fundierte Aussage über die echte Leitungsgeschwindigkeit sind die Testdateien mit gestaffelten, festen Größen auf speedtest.qsc.de, auf die sowohl per FTP (wegen des geringeren Overheads vorzuziehen) als auch per http zugegriffen werden kann.

 

Outlook 2011 (Mac) kommuniziert mit dem Exchangeserver nicht per MAPI wie Outlook für Windows, sondern über den Exchange Web Service (EWS). Die maximale Größe für Anhänge ist in der EWS-Konfiguration am Exchangeserver (und nicht in Outlook 2011) fix auf 13280 KB festgelegt. Da Outlook 2011 Anhänge per MIME verschlüsselt und dies einen Größenzuwachs von ca. 30% bedeutet, liegt die Grenze für Anhänge in per Praxis also bei etwa 10 MB.

Unverständlicherweise gibt es am Exchangeserver keinerlei User Interface für die Konfiguration dieser Größenbeschränkung. Dies gilt sowohl für Exchange 2007 also auch für Exchange 2010. Man muss also “ans Eingemachte”. Hierzu gibt es im Internet nicht allzuviele Fundstellen. Die die es gibt, verweisen meist gegenseitig aufeinander und versuchen zu viele Änderungen an zu vielen Stellen vorzunehmen. Hier ein paar der von mir durchgearbeiteten Fundstellen:

Letztlich habe bei mir (SBS 2008, also Exchange 2007) folgende Schritte geholfen. Ich kann jetzt Anhänge bis ca. 30 MB mit Outlook 2011 verschicken.
  • Die Datei C:\Program Files\Microsoft\Exchange Server\ClientAccess\exchweb\ews\web.config sichern und dann darin die Zeile
    <httpRuntime maxRequestLength="13280" />
    ersetzen durch
    <httpRuntime executionTimeout="600" maxRequestLength="39936" />

    Damit wird erstens die erlaubte Größe auf 30 MB (+ ca. 30%; in Kilobyte) und zweitens der Timeout zum Verschicken der jetzt größeren Mail (auf 600 Sekunden) erhöht

  • Diesen erhöhten Timeout dann auch im IIS an folgender Stelle eintragen:
    IIS Manager -> SBS Web Applications -> Erweiterte Einstellungen (rechte Spalte) -> Verbindungstimeout
  • In einer Eingabeaufforderung die beiden folgenden Befehlen ausführen
    cd %windir%\system32\inetsrv
    und
    appcmd set config "SBS Web Application/EWS" -section:requestFiltering
     -requestLimits.maxAllowedContentLength:40894464
  • Falls man keinen SBS sondern einen normalen 2008 Server hat, muss man statt “SBS Web Application/EWS” im 2. Befehl “Default Web Site/ews” verwenden.
    Die bei maxAllowedContentLength verwendete Größe muss unbedingt die oben bei maxRequestLength verwendete Größe in Bytes, also hier 39936*1024=40894464 sein! Wenn dieser Wert zu klein sein sollte (z.B. weil man nur mal 1000 und nicht mal 1024 gerechnet hat) funktioniert das Verschicken nicht!
  • Abschließend mit “iisreset” den Webserver neu starten.
 

Man sollte erwarten, dass das Löschen einer abgeschalteten virtuellen Maschine (VM) eigentlich eine Sache von wenigen Sekunden sein sollte. Ich hatte aber den Effekt, dass die VM am Hyper-V-Server auch nach 15 Minuten noch im Status “Wird gelöscht …” war.

Etwas Recherche führt zu der interessanten Tatsache, dass der Hyper-V-Server vor dem Löschen erst einmal alle vorhandenen Snapshots “anwendet”, was bei mehreren Snapshots durchaus einige Zeit dauern kann. Wie ich hier gefunden habe gibt es einen Trick, mit dem man diese Wartezeit vermeiden kann: Einfach den obersten (ersten) Snapshot “anwenden” (geht sehr schnell) und dann die VM löschen. Dann gibt es keine anzuwendenden Snapshots mehr und das Löschen der VM ist in wenigen Augenblicken erledigt.

 

Wenn man auf allen PCs in einer Domäne Remote Desktop aktivieren möchte, ist der von mir in einem älteren Posting beschriebene Weg über die manuelle Änderung eines Registry Keys via “Netzwerkregistrierung” evtl. zu aufwändig oder wg. Firewallregeln gar nicht möglich.

Man kann dies auch sehr einfach mit zwei Gruppenrichtlinien erreichen, allerdings sind die meisten entsprechenden Anleitungen im Internet schon älter und beschreiben nicht die in Server 2008R2 geänderten Gruppenrichtlinien. So wie hier beschrieben sind folgende Schritte erforderlich:

  • Im Server Manager unter Features ein neues Gruppenrichtlinienobjekt (GPO) erzeugen
  • Unter Computer Configuration > Policies > Administrative Templates > Network > Network Connections > Windows Firewall > Domain Profile > Windows Firewall: Allow inbound Remote Desktop exceptions aktivieren
  • Unter Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections > Allow users to connect remotely using Remote Desktop Services aktivieren
  • Das GPO sichern und mit der passenden Organisationseinheit (OU) (z.B. “Computer”) verknüpfen.
 

Auf den beiden DCs (2008 R2) in einer Domain wird alle 5 Minuten der Event 1202 mit dem Text “Security policies were propagated with warning. 0×534 : No mapping between account names and security IDs was done.” im Eventlog eingetragen.

Einige Stunden Recherche haben folgendes ergeben:

KB977695: Der dort verfügbare Hotfix enthält eine Scecli.dll. die älter ist als die bereits installierte Version. Deshalb läßt sich der Hotfix nicht installieren (“The update is not applicable to your computer“).

KB324383: Die dort beschriebene Suche (“find /i “cannot find” %SYSTEMROOT%\security\logs\winlogon.log“) in der winlogon.log liefert “DefaultAppPool” und “Classic .NET AppPool” als die problematischen Account Names.

Mit dem “Resultant Set of Policy” (rsop.msc) findet man unter “Computer Configuration – Windows Settings – Security Settings – Local Policies – User Rights Assignment” einfach heraus, dass die problematischen Account Names in Richtlinien der “Default Domain Controller Policy” stecken.

Das in KB977695 beschriebene Hinzufügen des Präfix “IIS AppPool/” an den entsprechenden Stellen in der Datei “GptTmpl.inf” dieser Policy hat das Problem für “DefaultAppPool” behoben, aber “Classic .NET AppPool” erzeugt immer noch Fehler.

Im “IIS Manager” (Version 7) werden unter “AppPools” nur “ASP.NET v4.0″, “ASP.NET v4.0 Classic” und “DefaultAppPool” aufgelistet, “Classic .NET AppPool” fehlt also.

Ich habe dort dann einen neuen AppPool mit dem Namen “Classic .NET AppPool”, der .NET Version “v2.0″ und dem Pipline Mode “Classic” erzeugt. Danach tauchten keine Warnungen mehr im Eventlog auf

 

Monatelang hat es problemlos funktioniert, dass CheckIns mit der Android foursquare App automatisch als Posts in Facebook erscheinen, plötzlich funktioniert die Verbindung zu Facebook nicht mehr. Die CheckIns werden in foursquare korrekt angezeigt, es gibt keine Fehlermeldungen, aber es erscheinen trotz entsprechender Konfiguration keine automatischen Posts mehr auf Facebook.

Nach langer Recherche und vielen Versuchen hat folgendes Vorgehen das Problem behoben:

  • Abmelden von foursquare in der Android App
  • Anmelden in foursquare auf der foursquare-Website
  • Trennen der Verbindung mit Facebook auf der foursquare-Website (es hilft NICHT dies mit der Android App zu tun!)
  • Abmelden von foursquare auf der foursquare-Website
  • Anmelden zu foursquare und Wiederherstellen der Verbindung zu Facebook in der Android App
 

Ich hatte das Problem, das Robocopy auf einem Windows Server 2003 beim Kopieren einer 90 GB Imagedatei nach ca. 1,5h mit dem Fehler 1450 (“Insufficient system resources exist to complete the requested service“) abbricht. Der normalerweise bei großen Dateien hilfreiche Robocopy-Switch /IPG:3 hat (auch mit anderen Werten als 3) keine Abhilfe gebracht.

Mit Google bin ich auf diverse Hinweise zu dem Thema gestoßen, die alle auf den MS KnowledgeBase Artikel KB304101 verweisen. Der Artikel passt zwar nicht ganz, aber ich habe trotzdem wie dort empfohlen den Registy Key

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
    \PoolUsageMaximum

als DWORD mit dem Wert 60 erzeugt, den Server neu gestartet und seitdem kann Robocopy auch die 90 GB Datei ohne Probleme kopieren!

 

Zur Installation eines Netzwerkdruckers gehört eigentlich immer bei der Installation die Option “lokaler Drucker” auszuwählen und dann einen neuen Port vom Typ “Standard TCP/IP Port” mit der gewünschten IP-Adresse zu erzeugen.

Heute hat ich bei einem Farblaserdrucker das Problem, dass diese Porterstellung ewig gedauert hat und nach einiger Zeit dann ein “Generic Port” angeboten wurde mit dem Hinweise, dass mit dieser IP-Adresse kein Gerät gefunden wurde. Ich habe dann einfach weiterinstalliert mit dem Ergebniss, dass der so erzeugte Drucker zwar drucken konnte, aber völlig falsch konfiguriert war. So konnte ich z.B. nicht in Farbe drucken.

Ein Post in einem Forum hat mich auf die einfache Lösung gebracht: Damit Windows bei der Druckerinstallation abfragen kann welche Eigenschaften der Drucker unterstützt, muss auf dem Drucker SNMP (“read only” und “public” ist ausreichend) aktiviert sein! Nachdem ich SNMP aktivert hatte war eine erneute Installation in wenigen Sekunden erledigt und der erzeugte Drucker funktioniert problemlos.

 

Outlook 2011 (Mac) kennt keine Lesebestätigungen (Return Receipts). Es gibt also keine Möglichkeit dieses Feature ein- oder auszuschalten bzw. das Verhalten bei angeforderten Lesebestätigungen zu definieren.

Dies wäre ja kein Problem, wenn Outlook 2011 Lesebestätigungen einfach irgorieren würde. Aber leider schickt Outlook 2011 automatisch eine Lesebestätigung an den Absender zurück, wenn dieser eine solche angefordert hat, ohne dass man dies in Outlook 2011 verhindern könnte.

Eine Lösung für dieses Problem ist, schon am Exchangeserver mit einer “Transport Rule” von den eingehenden E-Mails den entsprechenden Header “Disposition-Notification-To” zu entfernen. Damit erfährt Outlook 2011 nie davon, dass den Absender eine Lesebestätigung angefordert hat und versendet dann natürlich auch keine. Das Vorgehen ist eigentlich relativ selbsterklärend und wird im Detail im Exchange Team Blog im MS TechNet erklärt.

© 2012 Impressum Suffusion theme by Sayontan Sinha
Stop censorship