Schlagwort-Archive: Migration

#Exchange On-Prem PST Migration zu #Office365

In den letzten Tagen war ich mal mehr in Office 365 unterwegs 😉

Für eine kleine Umgebung war eine Migration vorhandener Postfächer eines lokalen Exchange nach Office 365 notwendig. Allerdings sollte die lokale Umgebung aufgelöst und die vorhandenen User in einer neu angelegtem Domäne innerhalb von Office 365 angelegt und portiert werden. Da es sich um eine kleine Organisation handelt, die primär Mail und Fileserver Dienste einsetzt war die Migration über einen Export der lokalen PST-Dateien und Import über Office 365 die sinnvollste Alternative.

#Exchange On-Prem PST Migration zu #Office365 weiterlesen

Einzelnen Exchange 2016 deinstallieren -ArchiveLog

Bei einem Kunden waren zwei Exchange 2016 Server vorhanden, von denen der erste nach erfolgter Migration gelöscht werden sollte.

Wie immer ist vor den Tätigkeiten ein Backup durchzuführen!

Da es sich um den 1. Exchange 2016 Server handelte, hielt der einige System-Postfächer bereit, die zunächst auf den 2. Server umziehen mussten. Dies ist sicherlich soweit bekannt. Allerdings wurde mit Exchange 2016 eine AuditLog Mailbox eingeführt, die nur auf den Exchange 2016 Servern angezeigt wird. Wurde diese zuvor nicht verschoben, erhalten wir bei einer sauberen Deinstallation über die Systemsteuerung folgende Fehlermeldung:

E2016 - Readiness CheckMit folgenden Befehlen lässt sich prüfen, welche Postfächer noch vorhanden sind:

Get-Mailbox -Database „E2016 DB Name“

Get-Mailbox -Database „E2016 DB Name“ -Arbitration

Get-Mailbox -Database „E2016 DB Name“ -Archive

Get-Mailbox -Database „E2016 DB Name“ -PublicFolder

Sollten noch Postfächer angezeigt werden, kann der Befehl um „New-MoveRequest -TargetDatabase „E2016 DB Name““ ergänzt werden um die vorhandenen Systempostfächer auf die bestehende Datenbank zu verschieben.

Befehl im ganzen:

Get-Mailbox -Database „E2016 DB Name“ | New-MoveRequest -TargetDatabase „E2016 DB Name“

Der Status der Verschiebeanforderung lässt sich mit „Get-MoveRequest“ anzeigen. Sobald dieser abgeschlossen ist, lässt sich die Deinstallation fortsetzen und der Readiness Check erneut ausführen.

Lässt sich die Deinstallation noch immer nicht fortsetzen, ist die erwähnte eine SystemMailBox vorhanden, die mit den genannten Befehlen derzeit nicht angezeigt wird. Dieser Fehler wird in einer der zukünftigen CUs behoben.

Mit folgendem Befehl wird euch diese SystemMailBox angezeigt:

Get-Mailbox -Database „E2016 DB Name“ -AuditLog

E2016 - Readiness Check  ArchiveLogAuch diese sollte für die Deinstallation verschoben werden, dies lässt sich mit bereits vorhanden Befehl vornehmen. Ob der Vorgang erfolgreich verläuft lässt sich mit dem Befehl „Get-MoveRequest“ prüfen. Sobald der Status auf „Completed“ steht ist der Vorgang abgeschlossen. Nun noch die Powershell schließen und schon kann die Deinstallation erfolgen.

E2016 - GetMoveRequestNun wird die Deinstallation sauber durchgeführt und die wichtigen Postfächer wurden auf den verbliebenden Exchange Server verschoben.

Weiterführende Informationen zum Audig logging in Exchange 2016.

Für Fragen stehen wir gerne zur Verfügung.

 

Microsoft Virtual Machine Converter 3.0

Heute wurde von Microsoft der langersehnte Virtual Machine Converter in der Version 3.0 veröffentlicht.
Es ist als Standalone-Version gedacht und lässt sich mit einfachen Schritten auf einem Client oder Server installieren. Nach der Installation lassen sich sowohl Virtuelle als auch Physische Server migrieren. Als Zielsystem ist nun eine Migration in die Cloud nach Microsoft Azure möglich oder On-Premise, nach Hyper-V.
Das Tool bietet einen einfachen Assistenten, der einen durch alle wichtige Konfigurationsschritte leitet.

MVMC 3.0 GUI
MVMC 3.0 GUI

Alternativ lässt sich der Converter über die Powershell ansteuern und ermöglicht damit eine automatisierte Migration zahlreicher Server.

Der MVMC 3.0 migriert sowohl Clientsysteme (ab Windows Vista) und Serversysteme (ab Windows Server 2008). Es lassen sich auch Linux-Gäste von VMware basierten Hostsystemen migrieren.

Der MVMC wurde um einige Features erweitert. Dazu zählen z.B.:

  • Einbindung in den Orchestrator
  • VMDKs in VHDs konvertieren
  • Integriert die Integration Components
  • Offline-Migration

Wer nun mit dem Gedanken spielt Windows Server 2003 Systeme damit migrieren zu möchten, muss diese erste auf min. Windows Server 2008 anheben. Dazu kann das, ebenfalls vor kurzem, veröffentlichte Migrations Planning Tool genutzt werden.

Zur Downloadseite des MVMC 3.0.

SCCM 2012 Bereitstellung

Aufgrund einiger bevorstehender kleineren Projekte, bin ich in den letzten Tagen dabei die System Center Familie ein wenig zu evaluieren. Die Produktfamilie ist ja nun doch schon sehr groß geworden und deckt alle erdenklichen Bereiche ab. Aufgrund der Anzahl der zu verwaltenden Server und Clients ist der Einsatz des SCCM essentiell. Daher werde ich einige Zeit in das Produkt investieren um es für die bevorstehenden Projekte optimal einsetzen zu können.

Zunächst einmal ein paar, aus meiner Sicht, wichtige Fakten vorab:

  • SCCM 2012 erfordert einen vollständigen SQL Server (keine Express Edition)
    • Derzeit wird nur SQL 2008 (R2) unterstützt – kein SQL 2012
    • SQL 2008 SP2 CU9 / SP3 CU4
    • SQL 2008 R2 mit SP1 und CU6
    • SQL Server Kollektion: SQL_Latin1_General_CP1_CI_AS
    • supported-sql-versions-in-sccm-2012
    • Keine dynamischen Ports, ausschließlich feste Portzuweisung
    • SQL 2008 Feste Portkonfiguration
      SQL 2008 Feste Portkonfiguration
  • SCCM2012 CAS (Central Administration Site)
    • Wird nur bei mehreren Primären Standorten benötigt
    • Ist ein übergeordnerter Server, der Berichtsübergreifend über alle Primären Server agiert
    • CAS setzt einen dedizierten Server voraus
      • Eine Installation gemeinsam mit einer Primären Rolle ist nicht möglich
    • Eine absolut gute Installationsanleitung gibt es bei windows-noob
  • SCCM2012 Primärer Server
    • Nach Installationsabschluss ist kein Wechsel der Beziehung zu einem CAS möglich
    • Primärer Server unterstützt bis zu 50.000 Clients
      • Bei lokalem SQL Server (auf gleicher Maschine)
    • Bis 100.000 Clients bei dediziertem SQL Server
    • 1 Management Point = 25.000 Clients, 2 MP = 50.000 Clients, usw.
      • Ein Primärer Server verwaltet max. 10 Management Points
    • Sehr gute Installationsanleitung auch unter windows-noob
  • Migration SCCM 2007 zu SCCM 2012
    • Für die Migration von 2007 zu 2012 kann der SCCM 2012 parallel installiert werden
      • Zwingend anderen Sitecode und Maschinennamen verwenden

Ich habe die Installation eines Primären Servers bereits erfolgreich abgeschlossen. Da ich die genannten Anleitungen sehr brauchbar finde, verzichte ich an dieser Stelle darauf eine eigene zu erstellen und habe versucht den Fokus darauf zu legen, was vor bzw. während der Installation für Fragen und Probleme auftauchen können.

Viel Spaß beim Testen und Evaluieren.

Technet IT-Camp Köln

Am 02.02.12 fand das IT-Camp von Microsoft in Köln statt. Da ich mir einen der begehrten Plätze sichern konnte, gibt es hier eine kleine Zusammenfassung, was geboten wurde und welche Themen auf der Agenda standen.
Zunächst einmal ist das IT-Camp ein neues Veranstaltungsmodell von Microsoft. In diesem Rahmen sollen die Teilnehmer ihre eigene Hardware (Notebook) mitbringen und können über RDP auf eine Virtuelle Umgebung zugreifen und so einige Übungen durchführen.
Im Zeichen dieses IT-Camps stand natürlich die beiden Themen Migration und das derzeit angesagte Thema Virtualisierung (Cloud). Nach einer Einführung beschäftigte sich der Vormittag mit allem rund um die Migration. Dazu konnte man per Handout einige Teilmigrationen von Server 2003 auf 2008 R2 durchführen. Unter anderem File-/DHCP und Domänen- Migration. Auf weitere Themen, wie PKI-/Print- Migration wurde ebenfalls eingegangen. Die Handouts waren eine Schritt für Schritt Anleitung, so dass jeder Teilnehmer die Möglichkeit hatte, alle Schritte nachzuvollziehen und selbst auszuprobieren. Die beiden Dozenten Carsten Rachfahl (www.rachfahl.de) und Lars Schmoll (Microsoft) standen immer zur Seite und schwirrten durch die Reihen um Fragen und Probleme schnell zu lösen.
Der Nachmittag stand nun im Zeichen von Hyper-V. Allerdings gab es hier, aufgrund der Zeit, keine Möglichkeit mehr, eigene Versuche oder Übungen durchzuführen. So wurde es zu einer Informativen Informationsveranstaltung zum Thema Hyper-V und es gab einige Interessante Informationen zum neuen SCVMM 2012.
Zusammenfassend finde ich das Konzept durchaus gelungen und sehr informativ. Allerdings fand ich, dass gerade zum Thema Hyper-V „zu viele“ Einsteigerinformationen geliefert wurden. Hier hätte man die Zeit ein wenig für tiefgreifende Informationen und Hintergründe verwenden können.

IT-Camp Cologne Themen Migrationen und Hyper-V

Servermigration 2003SBS zu 2008 R2 Standard

Heute steht die Migration für einen Kunden, vom Small Business Server 2003 zum Windows Server 2008 R2 Standard an. Nach einiger Recherche haben wir uns entschieden, die Serverhardware weiterhin zu nutzen und den Server um RAM zu erweitern.

Die Migration werde ich in mehreren Schritten aufteilen. Zunächst werde ich den jetzigen Small Business Server zu einer Virtuellen Maschine migrieren, um die Hardware für die Neuinstallation freizubekommen und gleichzeitig eine Fallback Lösung zu haben, falls die Migration nicht über das Wochenende abgeschlossen wird.

Die Migration der Domäne stellt dabei kein zeitliches Problem dar, aber es gibt so einige Kundenprogramme, die auf dem Server laufen und diese müssen Montagfrüh wieder zur Verfügung stehen. Wie z.B. Charly Solutio und DBSWin.

P2V Migration

Der erste Schritt war eine Physical 2 Virtual Migration. Dazu habe ich mir auf einem Client Server 2008 R2 mit Hyper-V installiert und darauf einen weiteren Server 2008 R2 als DC und mit SCVMM 2008 R2. Um die P2V zu beschleunigen, habe ich im Vorfeld alle nicht benötigten Dateien und Verzeichnisse vom vorhandenen SBS kopiert und gelöscht. Anschließend wurde über den SCVMM 2008 eine P2V angestossen, welche aufgrund der geringen Kapazität, innerhalb von 60 Minuten abgeschlossen war. Nun steht mir der Server virtuell unter der gleichen IP-Adresse zur Verfügung und als Notfall habe ich noch immer ein Backup.

Nachdem Server 2008 R2 auf der vorhandenen Hardware installiert wurde, war zunächst einmal zu erkennen, dass die Allseits beliebte 3Com 905B nicht mehr supported wird. Alle weiteren Geräte wurden einwandfrei vom Server 2008 R2 erkannt.

Domänenaufnahme

Nun geht es an die Domänenaufnahme. Der neue Server wird als weiterer DC der Domäne hinzugefügt. Um dies zu gewährleisten, ist zunächst eine Vorbereitung der vorhandenen Domäne notwendig. Dazu ist von der Server 2008 R2 CD das Verzeichnis adprep auf den vorhandenen SBS zu kopieren. Anschließend über die Kommandozeile in das kopierte Verzeichnis wechseln und nacheinander adprep32.exe /forestprep und adprep32.exe /domainprep ausführen. Da es sich bei dem SBS 2003 um einen einzelnen Server handelt, wurde auch noch der empfohlene Befehl adprep32.exe /domainprep /gpprep zur Anpassung der Gruppenrichtlinien angehangen. Nach den Updates der Domäneninformationen sollte ein Blick in die EReignisanzeige pflicht sein um zu schauen, ob wirklich alles geklappt hat.

WSUS-Migration

Nächster Schritt war die WSUS Migration, die sich aber sehr schnell erledigen lässt. WSUS über Rollen hinzufügen und für die Erstsynchronisation als Replikatserver einrichten. Danach wurde der Server wieder als Eigenständiger Updateserver eingerichtet und als Updatequelle der MS Server angegeben. Anschließend noch eine abschließende Konfigurationsprüfung und Start der Erstsychnronisation. Natürlich sollte die Anpassung der Gruppenrichtlinien nicht vergessen werden, damit die Clients zukünftig Kontakt mit dem neuen Server aufnehmen.

FSMO Rollen verschieben

Die FSMO-Rollen wurden von mir über die grafische Oberfläche verschoben. Dies geht schnell und führt an der Kommandozeile vorbei 😉 Wer dazu eine Anleitung sucht, findet eine sehr ausführliche bei Yusufs Blog FSMO-Rollen.

Druckerrolle

Auf dem Server wurde die Druckerrolle von Server 2008 R2 aktiviert. Bei den Clients handelt es sich um XP Clients, daher sind sowohl die x64 als auch die x86-Treiber zu implementieren. Dazu sind die Windows 7 Treiber in der 32Bit Variante zu wählen, in denen, im Normalfall auch abwärts die Treiber für XP und 2000 enthalten sind.

Installation von Solutio Charly

Nun stand der schwierigere Teil auf der Agenda. Die Installation der Anwendungssoftware. Derzeit nutzt Charly als Datenbank Primebase, doch diese Version und der Support wird zum Ende des Jahres eingestellt und zukünftig wird als Grundlage Postgre verwendet. Im Zuge der Servermigration wurde gleichzeitig noch eine Migration der Datenbank vorgenommen. Wie so häufig, ist auch hier anzumerken, dass eine Datensicherung unumgänglich ist. Durch den neuen Server wurde eine Neuinstallation von Charly vorgenommen und die Datenbank aus den bestehenden Daten wieder aufgebaut. Mit ein paar Anpassungen, war dieser Teil weitgehend unproplematisch. An dieser Stelle möchte ich mich für die Unterstützung bedanken, die mir Solutio am Freitag noch gewährt hat.

Anpassung DBSWin

Eine weitere Hürde stellte DBSWin dar. Hier ist, neben der Neuinstallation auf dem Server, eine Anpassung der ini-Dateien auf den jeweiligen Clients notwendig. Zum einen muss der Servername dem neuen entsprechen (eine DNS-Umleitung reicht leider nicht aus) ebenso musste der Druckerpfad angepasst werden. Nachdem DBSWin wieder erneut installiert wurde, ist eine erneute Freischaltung des Version notwendig. Dies lässt sich nur in Zusammenarbeit mit der Hotline erledigen.

 

 

Migration V2V ESXi to Hyper-V (SCVMM 2008 R2)

So, nachdem die Regeneration der Serverhardware am Wochenende abgeschlossen wird, ist es Zeit die VM`s langsam vom ESXi zum Hyper-V zu verschieben.

Dazu habe ich den ersten ESXi durch eine Server 2008 R2 Installation mit der Roller Hyper-V ersetzt. Da der erste Hyper-V auch gleichzeitig ein virtuelle Maschine mit dem ISCSI-Target als SAN inne hat, wurde auf die Servercore-Installation verzichtet, da ich den RAID-Controller im Laufenden Betrieb managen möchte.

Eine V2V Migration über den SCVMM funktioniert nur mit einigen Vorraussetzungen, die vorher beachtet werden müssen. Hier sei angemerkt, dass der VMware Converter von VMware wesentlich Leistungsfähiger ist, als der Converter im SCVMM 2008 R2.

Solltet Ihr die ESXi-Hosts ohne vSphere Center betreiben, empfehle ich euch, für eine Übergangszeit, den vSphere-Center-Server zu installieren, dieser ist ja für 60 Tage kostenlos. Damit ist eine Migration wesentlich einfacher, da so auch die ESXi Hosts im SCVMM verwaltbar werden.

Eine Migration der VM`s vom ESXi, die in der Hardware Version 7 erstellt wurden und möglicherweise noch mit dem SCSI-Controller VMware Paravirtual ausgestattet sind, ist nicht ohne vorherige Maßnahmen möglich. Um bei diesen VM`s eine V2V Migration per SCVMM zu ermöglichen, ist zunächst ein Zwischenschritt über den VMware Converter notwendig. Die Freeware Version reicht aus.

Über den VMware Converter konvertiert ihr die Maschine unter der Angabe eines anderen Namens (z.B. Zusatz „N“) auf den gleichen Host. Dabei wählt ihr als Hardware-Version „4“ und als SCSI-Controller LSI Logic. Nach Abschluss der Migration könnt ihr die neue VM nun, nach der genannten Anleitung, auf einen Hyper-V Host migrieren.

Um eine Migration einer ausgeschalteten VM über den SCVMM vorzunehmen, sind folgende Punkte zu beachten:

1. Falls vmxnet (2)(3)-Netzwerkkarten verwendet werden, diese deinstallieren und durch E1000 Kompatible Netzwerkkarten mit der gleichen Konfiguration ersetzen

2. Nach einem Neustart Deinstallation der VMware-Tools

3. Die VM muss im ausgeschalteten Zustand sein, um eine Migration per SCVMM vornehmen zu können.

4. Im SCVMM V2V-Migration auswählen. In Bibiliotheksfenster werden die ausgeschalteten VM`s angezeigt. Hier wählt ihr die zu migrierende VM aus.

5. Danach wählt ihr noch den neuen Host und die Netzwerkkarten aus (ich verbinde die Karten noch nicht, sondern wähle nur das Netzwerk aus).

6. Nun beginnt die Migration. Zunächst wird die Konvertierung der vmdk-Files in vhd-Dateien vom SCVMM vorgenommen, dass kann je nach Größe der zu migrierenden VM einige Zeit dauern.

7. Nach Abschluss der Migration könnt ihr die VM starten und die Netzwerkkonfiguration vornehmen.

8. Prüft die Ereignisanzeige auf FEhler oder ähnlichem. Sollte euch nichts negatives auffallen, könnt ihr nun die Alte VM auf dem ESX(i) Host löschen.

 

 

Migrationsvorbereitung ESXi zu Hyper-V

In nächster Zeit liegen bei mir doch noch so einige Projekte an. Zunächst steht ein Wechsel der Virtuellen Maschinen von ESXi zu Hyper-V an. Gründe liegen vor allem in den benötigten Features.
Der ESXi bringt viele Features mit, die ich von Hause aus nicht benötige. Features die ich benötige sind wiederrum nur in den Lizenzpflichtigen Versionen enthalten (z.B. vMotion).
Aufgrund der Lizenzrechtlichen Geschichte und der ausreichenden Features von Hyper-V werde ich meine derzeitigen Virtuellen Maschinen nach und nach zu Hyper-V migrieren.

Migration Nagios Server nach Ubuntu LTS 10.04. mit check_mk

Da der Server mit Nagios schon seid einiger Zeit nur rudimentär eingerichtet war und die Konfiguration dringend einer Überarbeitung bedürfte, habe ich mich entschieden. Nagios auf einem Ubuntu LTS 10.04. neu aufzusetzen.

Während ich mich über die Neuigkeiten von Nagios informiert habe, bin ich über das Tool check_mk von Matthias Kettner gestossen. Das Tool habe ich direkt mit in meine Neuinstallation aufgenommen. Um Nagios nun auch vernünftig zu konfigurieren, habe ich dazu die beiden HowTo`s vom Blog von Stefan Daniel Schwarz und von BenV ein wenig im Mix verwendet.
Warum im Mix? Nun ja, einige Pfade haben sich bei den neueren Versionen geändert und man möchte ja auch noch ein wenig eigenen Anteil an der Installation und Konfiguration haben.

Auf jeden Fall lässt sich sagen, dass das neue check_mk einem die Installation und insbesondere die Konfiguration von Nagios sehr deutlich vereinfacht. Meiner Meinung nach, mit eines ders besten Tools welche die letzten Jahre (der doch sehr langsamen Entwicklung von Nagios) erschienen sind.

Die Plugins NSClient++ habe ich sogleich von den zu überwachenden Servern entfernt und durch check_mk ersetzt. Danach Dienst starten und ein check_mk -I tcp auf dem Nagios Server, ein check_mk -U und ein check_mk -R und schon waren die Server in der Nagios Webseite vorhanden und die Überwachung der Dienste setzte sich nahtlos fort. Einzige Frage die noch bleibt, wie kann ich die bisherigen, gesammelten Daten vom Altsystem importieren.

 Hier mal ein Screenshot von der neuen Oberfläche:

<img class=""size-medium" title=""check_mk" src="http://multiblog.f1nalbyte.de/server/files/2010/10/check_mk-Ansicht1-1024×601.jpg" alt="
check_mk Ansicht

vSphere Virtual Machine Hardware Upgrade

Da Direct Access in meiner Umgebung derzeit immer noch nicht lauffähig ist und ich vom Gefühl her immer den Eindruck hatte, es liegt mit der virtuellen Netzwerkstruktur zusammen, habe ich die Hardware Versionen der Virtuellen Maschinen einem Upgrade unterzogen.

Zunächst einmal gibt es in der Hardware Version 7 vom vSphere 4 mehrere neue Hardwarekomponenten, die für eine bessere Performance sorgen sollen.

Darunter fällt zu einem der neue Netzwerkadapter vmxnet3 (Unterstützung von JumboFrames, Hardware Offloads, fully IPv6 Support, IPv6 offloads, usw.) und der neue VMware Paravirtualized SCSI Adapter (PVSCSI), der eine bessere Performance und weniger I/O-Last erzeugen soll.

Das Upgrade habe ich in mehreren Schritten durchgeführt:

  1. Zunächst einmal sollte man schauen, ob die IP-Liste der Server noch aktuell ist
  2. Wichtig ist vorher noch ein mal zu checken, dass die VMware-Tools auf dem aktuellen Stand sind, ggf. neu installieren bzw. updaten
  3. Solltet Ihr diese upgraden, danach ein Neustart durchführen und anschliessend die Virtuelle Maschine runterfahren
  4. Bevor ihr die Hardware Version aktualisiert, solltet Ihr eine Sicherung der VM anlegen, da ein Downgrade nur umständlich möglich ist
  5. Nun könnt ihr die Hardware Version der VM upgraden, in dem ihr ein Rechtsklick auf die VM im vSphere Client tätigt und dort „Upgrade Virtual Hardware“
  6. Hinzufügen einer neuen Netzwerkkarte in den VM-Eigenschaften vom Typ VMXNET3 und Zuordnung zur selben Port-Gruppe
  7. Hinzufügen einer neuen virtuellen Festplatte (Grösse unerheblich). Wichtig, diese muss dem SCSI-Punkt 1:0 oder höher zugewiesen werden
  8. Ändern des neuen, zweiten SCSI-Controller Typ in VMware Paravirtual
  9. Starten der VM, dabei am besten die Desktopansicht des VSphere-Clients verwenden, um keinen Verbindungsabbruch beim Ändern der IP-Adresse zu haben
  10. Nachdem anmelden, vorherige Netzwerkkarte auf DHCP stellen und bei der neuen Netzwerkkarte die IP-Adresse konfigurieren
  11. Neue Systemvariable anlegen „DEVMGR_SHOW_NONPRESENT_DEVICES“ Wert= „1“
  12. Nun Geräte-Manager aufrufen und unter Ansicht „Ausgeblendete Geräte anzeigen“ wählen
  13. Die vorherigen Netzwerkadapter „Intel Pro E1000“ entfernen
  14. Nun sollte die Migration auf die neue Hardware abgeschlossen sein.

Wichtig: Laut VMWare ist es nicht supported, den Paravirtuellen SCSI-Adapter für Boot-Devices (Systemlaufwerk) zu verwenden, dieser soll ausschliesslich für Datenträger mit Daten und Anwendungen verwendet werden, siehe: VMware Paravirtual SCSI-Adapter Support