Windows Server Backup und lokaler User auf NAS

Posted on Posted in Computer

Ich habe heute auf einem Windows Server 2008 R2 eine Sicherung mit der (als Feature nachzuinstallierenden) „Windows Server-Sicherung“ eingerichtet. Der lokale Server soll auf eine Freigabe auf einer NAS (Synology) gesichert werden.

Die NAS ist nicht Mitglied der Domäre, weshalb für den Zugriff auf die Freigabe die Zugangsdaten eines lokal auf der NAS eingerichteten Users erforderlich sind. Somit hat kein Domänenbenutzer Zugriff auf die Freigabe und ein evtl. Verschlüsselungstrojaner tut sich etwas schwerer auf die gesicherten Daten zuzugereifen.

Bei der Definition der Sicherung habe ich als Sicherungsziel den „Freigegebenen Remoteordner“ angegeben und den User in der Form „NAME_DER_NAS\Lokaler_Username“ angegeben. Dies führt beim Abschluß der Sicherungs-Definition zu einer (ziemlich unspezifischen) Fehlermeldung.

Der Grund für diesen Fehler liegt in der Tatsache, dass der in der Sicherung verwendete User Mitglied der lokalen Windows-Gruppe „Sicherungs-Operatoren“ sein muß, was der lokale NAS-User natürlich nicht ist.

Die (etwas unschöne) Lösung ist sowohl auf der NAS als auch auf dem Windows Server jeweils einen lokalen User mit exakt gleichem Namen und Kennwort anzulegen und den Windows User zum Mitglied der „Sicherungs-Operatoren“ zu machen. Bei der Definition der Sicherung muß man den User dann unbedingt in der kurzen Form „Lokaler_Username“ angeben. Damit findet Windows einen Sicherungs-Operator und die NAS hat die korrekten Zugriffsdaten.

Unsauber, aber funktioniert!

Lange Wartezeit bei erstem Logon nach Disk Cleanup

Posted on Posted in Computer

Auf einem Server 2008R2 ist im Lauf der Zeit die C:\ Partition ziemlich voll geworden. Da auf dem Server schon lange nichts mehr aktiv verändert wurde, hatte ich die Vermutung dass der Platz durch Temp-Dateien und alte Windows-Update-Dateien verbraucht wurde.

Daher habe ich den Disk Cleanup („Datenträgerbereinigung“) Assistenten über die C:\ Partition laufen lassen. Und zwar doppelt: Einmal die erste Stufe mit „Temporary files“ usw. und einmal (hinter dem Button „Clean up system files“) die zweite Stufe mit „Windows Update Cleanup“, „Service Pack Backup Files“ usw.. Diese zweite Bereinigung hat relativ lange gedauert, ist aber irgendwann normal fertig geworden und hat anschließend den üblichen Neustart angefordert. Bevor ich diesen durchgeführt habe ist mir noch aufgefallen, dass durch den Assistenten nicht allzuviel freier Festplattenplatz geschaffen wurde.

Nach der normalen Neustart-Wartezeit konnte ich den Server wieder anpingen und mich auch wieder mit den Shares verbinden. Bei der Anmeldung per RDP jedoch wurde dauerhaft „Please wait for the windows modules installer“ angezeigt. Etwas Recherche hat gezeigt, dass erst jetzt die alten Windows-Updates im WinSxS Ordner („Windows component store“) aufgeräumt wurden und dies durchaus ziemlich lange dauern kann.
Als ich nach ca. 2 Stunden die RDP-Anmeldung mal wieder überprüft habe, konnte ich mich endlich normal anmelden. Jetzt war auch deutlich mehr Platz auf der C:\ Partition frei.

Der Disk Cleanup Assistent wird auf neueren Server-Betriebssystemen übrigens nicht mehr automatisch mitinstalliert. Man kann ihn aber nachträglich über die Aktivierung des Features „Desktop Experience“ installieren. Leider werden dadurch auch eine ganze Reihe anderer Dinge installiert, die man auf einem Server nicht haben möchte wie z.B. der Windows Media Player!
Früher gab es noch Tricks manuell  an Disk Cleanup zu kommen ohne das ganze Desktop Experience Feature aktivieren zu müssen, aber seit Server 2012R2 ist dies nicht mehr möglich.

[Update] In einem Blog-Posting habe ich eine Möglichkeit gefunden, mit PowerShell und dem Tool „DISM“ den WinSxS-Ordner auch unter Windows Server 2012R2 zu optimieren.

Windows Server 2008R2 Installationsmedium mit USB 3.0 Treibern erstellen

Posted on Posted in Computer

Vor einiger Zeit mußte ich eine Windows Server 2008R2 Installation von einem älteren, unzuverläßig gewordenen DELL PowerEdge R210 auf einen neuen R230 umziehen. Da täglich ein Backup mit der „Windows Server-Sicherung“ auf eine NAS durchgeführt wird, war der Plan dieses Backup ein letztes Mal am alten Server zu aktualisieren, diesen dann herunterzufahren, den neuen Server von einer passenden Windows Server 2008R2 DVD zu booten und die Installation dann von diesem Backup wiederherzustellen.

Nach dem Start von der Windows Server 2008R2 DVD wird als erstes ein Bildschirm mit den Auswahlmöglichkeiten für Sprache, Tastatur/Währung und Tastaturlayout angezeigt. Nur funktionieren an dieser Stelle weder Maus noch Tastatur, ich hatte als keine Möglichkeit irgendetwas auszuwählen und die Installation fortzusetzen!

Etwas Recherche hat die Information geliefert, dass auf dem original Windows Server 2008R2 Installationsmedium nur Treiber für PS/2 und USB 2.0 vorhanden sind, nicht aber für USB 3.0. Am DELL PowerEdge R230 gibt es aber keine PS/2- oder USB 2.0 Ports und die vorhandenen USB 3.0 Ports sind beim R230 (im Gegensatz zu den höherwertigeren PowerEdge Modellen) auch nicht im BIOS auf USB 2.0 umstellbar.

Auf der DELL Website gibt es ein ausführliches Blog Posting das auf dieses Problem eingeht und erklärt, wie man sich ein Installationsmedium mit integrierten USB 3.0 Treibern erzeugen kann. Dazu braucht man viel Zeit, einen Windows-Rechner mit viel freiem Festplattenplatz, natürlich eine original Windows Server 2008R2 DVD, die Intel USB 3.0 Treiber von der DELL Support-Website und das passende Microsoft-Tool zum Erzeugen des neuen Installationsmediums.

Der ganze Vorgang wird in dem Blog-Posting ausführlich erklärt, nur finde ich den Text sehr unübersichtlich deshalb hier ein paar Hinweise:

  • Es werden dort drei alternative Methoden erklärt eine ISO-Datei mit den USB 3.0 Treibern zu erzeugen. Das ist nicht klar ersichtlich, man könnte meinen man muß die Seite von oben bis unten durcharbeiten.
    • Methode 1: Ein DELL-Tool, das man auf der Seite herunterladen kann
    • Methode 2: Power Shell
    • Methode 3: Klassische Eingabeaufforderung
  • Für die Methoden 2 und 3 muß man sich das passende Microsoft-Tool herunterladen. Wenn man auf einem Windows 7 Rechner arbeitet, benötigt man das „Windows Automated Installation Kit (WAIK)“, für Windows 8 und neuer benötigt man das „Windows Assessment and Deployment Kit (ADK)“
  • Ich habe die neue ISO-Datei auf einem Windows 7 Rechner mit der Methode 3 erzeugt. Dazu habe ich zuerst das WAIK installiert, die komplette DVD nach C:\temp\WindowsISO und die Intel USB 3.0 Treiber nach C:\temp\drivers kopiert und dann in einer administrativen Eingabeaufforderung folgende Befehle eingegeben, die teilweise erhebliche Laufzeiten haben:
    cd c:\temp
    Dism /Get-WimInfo /WimFile:C:\temp\WindowsISO\sources\boot.wim
    Dism /Get-WimInfo /WimFile:C:\temp\WindowsISO\sources\install.wim
    
    Dism /Mount-Wim /WimFile:C:\temp\WindowsISO\sources\boot.wim /Index:1
      /MountDir:C:\temp\wim
    Dism /Image:C:\temp\wim /Add-Driver /Driver:C:\temp\drivers /Recurse
    Dism /Unmount-Wim /Mount-Dir:C:\temp\wim /Commit
    
    Dism /Mount-Wim /WimFile:C:\temp\WindowsISO\sources\boot.wim /Index:2
      /MountDir:C:\temp\wim
    Dism /Image:C:\temp\wim /Add-Driver /Driver:C:\temp\drivers /Recurse
    Dism /Unmount-Wim /Mount-Dir:C:\temp\wim /Commit
    
    Dism /Mount-Wim /WimFile:C:\temp\WindowsISO\sources\install.wim /Index:1
      /MountDir:C:\temp\wim
    Dism /Image:C:\temp\wim /Add-Driver /Driver:C:\temp\drivers /Recurse
    Dism /Unmount-Wim /Mount-Dir:C:\temp\wim /Commit
    
    oscdimg –n –m –bC:\temp\WindowsISO\boot\etfsboot.com C:\temp\WindowsISO\
      C:\temp\mynew.iso
  • Von der so erzeugten mynew.iso habe ich dann mit UNetbootin einen startfähigen USB-Stick erzeugt, den neuen R230 davon hochgefahren und konnte dann endlich Maus und Tastatur verwenden um das Backup zurückzuspielen. Dies hat dann auch ohne Probleme funktioniert.

 

IMCEAEX Fehler bei internen Empfängern nach Umzug zu Office 365

Posted on Posted in Computer

Nach der Migration vom lokalem Exchange zu Office 365 via Export/Import bei einem Kunden sind hin und wieder beim Versenden NDR-Fehler mit dem Hinweis „Your email program is using outdated address information for the recipients“ aufgetreten. In der Erläuterung des Fehlers werden lange Links angezeigt, die mit „IMCEAEX“ beginnen.

Nach einiger Suche konnte ich das Problem eingrenzen: Der Fehler tritt nur bei internen Empfängern auf, und zwar nur dann, wenn man in einer alten E-Mail (also einer, die vor dem Umzug empfangen wurde) auf „Antworten“ klickt. Outlook hat sich bei internen Empfängern nicht die SMTP-Adresse, sondern die interne X500-Adresse gemerkt, die jetzt nach der Migration zu Office 365 natürlich nicht mehr funktioniert.

Das Problem wird in einem Microsoft KnowledgeBase-Artikel beschrieben. Als Lösung wird dort empfohlen, bei jedem Postfach in Office 365 eine zusätzliche X500-Adresse hinzuzufügen und es wird auch genau beschrieben wie diese aus der IMCEAEX-Fehlermeldung generiert werden kann.

Nur heißt es dort, dass die Adresse mit „X500:“ beginnen muß, was in der aktuellen Office 365 Version nicht korrekt ist. Dort wird (wie in diesem Posting beschrieben) der Adresstyp (eben X500) in einem getrennten Feld eingegeben, die eigentliche Adresse beginnt direkt mit „/o=…“.
In dem erwähnten Posting wird auch beschrieben, wie man diese X500-Adresse statt aus der IMCEAEX-Fehlermeldung alternativ für alle Postfächer mit PowerShell ermittelt.

Ich habe bei allen Postfächern bei diesem Kunden eine entsprechende X500-Adresse hinzugefügt. Seitdem ist der Fehler nicht wieder aufgetreten.

 

Windows 10: Zugriff auf administrative Freigaben wieder ermöglichen

Posted on Posted in Computer

Nachdem ein Kunde seinen PC (nicht Mitglied der Domäne) auf Windows 10 aktualisiert hatte, war es nicht mehr möglich über das LAN mit einem lokalen Adminstratorkonto auf dessen administrative Freigaben (in diesem Fall: \\IP-des-PCs\ADMIN$) zuzugreifen. Trotz Eingabe der korrekten Zugangsdaten wurde der Zugriff verweigert.

Etwas Recherche hat mich zu einem Forenthread gebracht, in dem die Lösung beschrieben wird: Zuerst mit RegEdit das folgende DWORD (32 Bit) mit dem Wert „1“ erzeugen:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\
   LocalAccountTokenFilterPolicy

und dann die Einstellungen der Firewall kontrollieren, da evtl. weitere (dynamische) Ports zugelassen werden müssen.

Nach diesen Änderungen war der Zugriff von einem Windows Server 2008 R2 aus wieder problemlos möglich.

Office 365 unter Remote Desktop Services („Terminalserver“) betreiben

Posted on Posted in Computer

Mit Office 365 hat sich die Art der Installation von Office auf einem Terminalserver komplett geändert.

  • Früher mußte für den Terminalserver zwingend eine „Open License“ Office-Lizenz gekauft und installiert werden. Ob auf den Clients die auf den Terminalserver zugegriffen haben dann auch eine für solch einen Zugriff berechtigte Officeversion installiert war, wurde nicht überprüft.
  • Mit Office 365 muß für den Terminalserver keine eigene Lizenz gekauft werden (!).
  • Auf jedem Client der dann dieses Office auf dem Terminalserver verwenden will, muß ein Office 365 Plan der Office ProPlus enthält installiert sein. Damit ist z.B. der im SMB-Bereich verbreitete „Office 365 Business Premium“ Plan nicht möglich, da dieser eben kein Office ProPlus enthält. Es muß ein Enterprise-Plan wie z.B. der „Office 365 Enterprise E3“ verwendet werden.

Die Installation von Office auf dem Terminalserver wird in diesem TechNet-Artikel beschrieben:

  • Man muß zuerst das „Office-Bereitstellungstool“ herunterladen und entpacken. Dieses besteht aus einer setup.exe und einer configuration.xml.
  • Wenn man damit nur das Office auf dem Terminalserver installieren möchte, muß man keine Installations-Freigabe erzeugen wie das in dem TechNet-Artikel beschrieben wird, sondern kann das Office einfach bei der Installation herunterladen lassen.
  • Die von mir verwendete configuration.xml sieht wie folgt aus. Als einzige Besonderheit habe ich zwei Sprachen installiert, um die Office-Interfacesprache je nach Benutzer einfach umstellen zu können.
<Configuration>
  <Add OfficeClientEdition="32" >
    <Product ID="O365ProPlusRetail">
      <Language ID="en-us" />
      <Language ID="de-de" />
    </Product>
  </Add>
  <Display Level="None" AcceptEULA="True" />
  <Property Name="SharedComputerLicensing" Value="1" />
</Configuration>
  • Für die Installation auf dem Terminalserver ist wie gesagt keine Office 365 Lizenz erforderlich! Wenn sich jetzt ein Benutzer zum erstenmal mit dem Terminalserver verbindet und dort ein Office-Programm startet, erscheint ein Dialog in die Office 365 Zugangsdaten des Benutzers abgefragt werden. Damit wird sichergestellt, dass der Benutzer über eine berechtigte Office 365 Lizenz verfügt.
  • Wenn Office 365 in das lokale Active Directory integriert wurde, entfällt dieser Schritt.
  • Der Zugriff auf solch ein im „SharedComputerLicensing“ Modus betriebenes Office wird nicht mit den im Office 365 Plan enthaltenen 5 möglichen Installationen verrechnet.

Umzug zu Office 365 via Export/Import

Posted on Posted in Computer

In den vergangenen Tagen habe ich bei einem Kunden alle Postfächer von einem lokalen Exchange 2010 zu Office 365 umgezogen. Dazu habe ich zuerst über die „Exchange Management Shell“ alle Postfächer in je eine PST-Datei exportiert und diese PST-Dateien dann manuell bei jedem User mit Outlook in das neue Office 365 Postfach importiert.

Den grundsätzlichen Weg habe ich in einem älteren Posting bereits beschrieben. Wie man mit einer einfachen Schleife über „New-MailboxExportRequest“ sämtliche Postfächer aus einem Exchangeserver exportiert wird in diesem Blog-Posting erklärt. Das Problem dabei: In der Default-Einstellung werden immer 5 Postfächer gleichzeitig exportiert und die restlichen Postfächer in eine Warteschlange gestellt. Obwohl ich dem Exchangeserver 16 GB Arbeitsspeicher zugwiesen habe, lief der Export (bei 99% Speicherauslastung) extrem langsam. Spätere Exporte von einzelnen Postfächern liefen deutlich schneller, weshalb ich den oben beschriebenen Automatismus nicht mehr verwenden, sondern die Postfächer sequenziell einzeln exportieren würde.

Beim Import der so erzeugten PST-Dateien ist mir Outlook bei einigen Benutzern nachvollziehbar abgestürzt. Ich konnte das Problem auf eine einzelne E-Mail mit (wohl defekten) Anhängen zurückführen, die sich die betroffenen Benutzer gegenseitig weitergeleitet haben. Das Problem: Wenn ich solch eine PST-Datei „importiere“, stürzt Outlook ab. Wenn solche eine PST-Datei „öffne“, die besagte E-Mail darin lösche und dann den „Gelöschte Elemente“ Ordner leeren will, stürzt Outlook ab. Wenn ich die E-Mail per Shift-Del „endgültig löschen“ will, stürzt Outlook ab. Die PST-Datei mit ScanPST „reparieren“ zu lassen bringt keine Änderung. Outlook im Safemode starten bringt keine Änderung.
Es ist mir schließlich gelungen, die E-Mail per OWA auf dem alten Exchangeserver zu löschen. Nachdem ich die PST dann erneut exportiert habe, ist mir Outlook beim Import trotzdem abgestürzt, denn die defekte E-Mail ist im Ordner „Recoverable Items“ immer noch in der PST enthalten. Erst als ich diesen Ordner beim Export mit dem Parameter „-ExcludeDumpster“ ausgeschlossen habe, konnte ich die PST-Datei problemlos in Outlook importieren. Der schließlich verwendete Exportbefehl lautete also (der FilePath muß immer als UNC-Pfad angegeben werden!):

New-MailboxExportRequest -Mailbox User.Name -ExcludeDumpster
   -FilePath "\\Server.Name\Share.Name\User.Name.pst"

Apache, PHP und MySQL unter El Capitan (OS X 10.11) installieren

Posted on Posted in Computer

Wie schon in der 10.6-, der 10.7- und der 10.8-Version dieses Posts erklärt, wird auf der Site „Coolest Guides on the Planet“ für jede OS X-Version eine ausführliche Beschreibung gepostet, wie man den Apache Webserver, PHP und MySQL unter OS X aktiviert und konfiguriert.

Hat seit Jahren bei jeder OS X-Version problemlos funktioniert, deshalb beschränke ich mich hier auf den obigen Link.

Wenn man auch den Zugriff per SSL lokal testen möchte, muß man ein selbstsigniertes Zertifikat erzeugen und einbinden, was für El Capitan in diesem Posting erklärt wird.

„Offizieller“ Weg eine Festplatte am Mac auf eine SSD zu klonen

Posted on Posted in Computer

Wir haben in meinen schon etwas in die Jahre gekommenen iMac statt dem optischen Laufwerk eine SSD eingebaut, was eine ziemliche Fummelei war.

Jetzt blieb die Aufgabe die vorhandene Festplatte vollständig (also inkl. der unsichtbaren EFI- und Wiederherstellungs-Partitionen) startfähig auf die frisch formatierte SSD zu klonen.

Die bekannten Utilities zum Kopieren ganzen Festplatten wie SuperDuper! oder vor allem Carbon Copy Cloner von Mike Bombich kümmern sich erst mal nicht um die unsichbaren Partitionen und kommen daher für den geplanten Zweck nur begrenzt in Frage.

Der „offizielle“ Weg für das Kopieren ganzer Festplatten ist laut Apple in die Wiederherstellungspartition zu booten und dort im Festplattendienstprogramm eine „Wiederherstellung“ laufen zu lassen. Dabei gibt man die alte „Macintosh HD“ Partition als „Quelle“ und die leere Partition auf der neuen SSD als „Ziel“ der Wiederherstellung an.

Das habe ich so gemacht und nach wenigen Sekunden die (korrekte) Meldung erhalten, dass die Quelle größer als das Ziel ist und daher die Wiederherstellung nicht durchgeführt werden könne.

Diverse Fundstellen bei Google empfehlen einfach die „Macintosh HD“ Partition auf der alten Festplatte mit dem Festplattendienstprogramm entsprechend zu verkleinern und anschließend die Wiederherstellung erneut durchzuführen. Das habe ich gemacht, wobei der Vorgang ziemlich lange gedauert hat (weit über eine Stunde) und die Fortschrittsanzeige sehr sprunghaft war: Sie stand über 1/2 Stunde bei ca. 33%. Ganz am Ende erschien dann eine Fehlermeldung dass die Partition nicht ausgeworfen werden könne, die Verkleinerung wurde abgebrochen und die „Macintosh HD“ Partition auf der alten Festplatte wurde grau (Deaktiviert) angezeigt.
Mit dem Button „Volume reparieren“ konnte ich die Partition wieder aktivieren und dann auch problemlos davon booten.

Weitere Recherche bei Google ergab dann, dass man die „Macintosh HD“ Partition nicht verkleinern kann wenn man von der Wiederherstellungspartition gebootet hat. Also einfach normal booten, das Festplattendienst- programm starten und die „Macintosh HD“ Partition verkleinern. Diesmal hat das problemlos (und sehr viel schneller als vorher) geklappt.

Anschließend wieder in die Wiederherstellungspartition booten und wie oben beschrieben eine „Wiederherstellung“ durchführen. Das hat ca. 1,5 Stunden gedauert und lief ohne Probleme durch. Am Schluß noch ein neues Startvolume festlegen (in dem Moment gibt es zwei, an dieser Stelle nicht unterscheidbare „Macintosh HD“: 50% Chance die Richtige zu wählen) und neu booten. Am Schluß noch die Kopie auf der SSD in „Macintosh SSD“ umbenennen, um sie von der „Macintosh HD“ auf der alten Festplatte unterscheiden zu können.

Mein iMac ist durch diesen Umzug auf die SSD deutlich schneller geworden!

Zum Abschluß wollte ich noch kontrollieren ob die unsichtbaren Partitionen tatsächlich kopiert wurden. Dazu muß man wie in diesem Artikel beschrieben zuerst das Festplattendienstprogramm beenden und dann mit dem Terminalbefehl

defaults write com.apple.DiskUtility DUDebugMenuEnabled 1

das „Debugmenü“ im Festplattendienstprogramm aktivieren. In diesem Menü kann man dann den Befehl „Jede Partition einblenden“ aktivieren, wodurch auch die unsichtbaren Partitionen angezeigt werden.

Wenn man anschließend den Befehl „Jede Partition anzeigen“ wieder deaktiviert und das Festplattendienstprogramm beendet, kann man mit dem Terminalbefehl

defaults write com.apple.DiskUtility DUDebugMenuEnabled 0

den Defaultzustand des Festplattendienstprogramms wiederherstellen.

„Clutter“ für alle Postfächer deaktivieren

Posted on 1 CommentPosted in Computer

Seit kurzem hat Microsoft das vergangenes Jahr eingeführte Feature „Clutter“ (als „unwichtig“ erkannte E-Mails werden in den Ordner Clutter verschoben) automatisch für alle existierenden Office 365 Postfächer aktiviert.

Da ich von diesem Feature nichts halte und viele Kunden ebenfalls keinen Vorteil darin erkennen können habe ich nach einem Weg gesucht Clutter global für alle Postfächer einer Firma zu deaktivieren.

Zuerst bin ich in einem TechNet-Artikel auf ein interessantes Script gestoßen, das Clutter für alle Postfächer deaktiviert sofern Clutter nicht manuell eingeschaltet wurde. Theoretisch jedenfalls – Bei mir hat das Script versucht Clutter bei den Postfächern zu deaktivieren, bei denen es bereits abgeschaltet war und hat alle anderen Postfächer ignoriert. Funktioniert also nicht.

Letztlich habe ich dann die simple Lösung verwendet, die ich in einem Blog-Posting gefunden habe: Nach der üblichen Anmeldung mit PowerShell (wie in diesem TechNet-Artikel beschrieben) einfach folgenden Befehl ausführen:

Get-Mailbox | Set-Clutter -Enable $false

Damit wird Clutter für alle Postfächer deaktivert, egal ob es manuell aktiviert wurde oder nicht. Etwas radikal, aber wirkungsvoll.