Im nächsten Monat, am 13. Juli 2010 endet endgültig der Support für Windows XP SP2, sowie für alle Windows 2000 Versionen inklusive aller Servervarianten. Erfahrungsgemäß setzen derzeit noch einige Unternehmen auf diese Betriebssysteme. Aber nach zehn Jahren und unzähligen dazwischenliegenden Versionen, ist es an der Zeit diese Systeme abzulösen.

Mehr Informationen gibt es auf der Microsoft-Produktlebenszyklus-Homepage:
http://support.microsoft.com/lifecycle/?LN=de

Thomas Gronenwald

Wie ich bereits vor ein paar Tagen im Artikel Internet Explorer 8: So klappt’s mit dem Rollout! erwähnte, möchte ich euch heute das Excelsheet zur Prüfung der Version des Internet Explorers vorstellen. Dieses kann die Version des Internet Explorers remote prüfen und setzt lediglich Excel 2000/XP/2003/2007 auf einem administrativen Client voraus, da es auf VBA basiert.

Funktionsweise des Makros

Das Makro fragt im ersten Schritt die Erreichbarkeit eines Systems ab. Konnte das System kontaktiert werden, so wird die Version des Internet Explorers über WMI geprüft. Hierfür sind natürlich lokale Adminrechte notwendig, da sonst der Zugriff auf die Systeme nicht möglich ist.

  Check IE-Version 1.0 (1.1 MiB, 120 hits)

Links

blog – port 389: Check IE-Version 1.0

Sascha Giebelhausen

Group Policy + IEAK 8 = IE8 Rollout!

Es kommt leider erschreckend oft vor, dass wir in Kundenumgebungen, die unterschiedlichsten Browserversionen feststellen. Vom guten “alten” Internet Explorer 5 über die Version 6 und 7 ist eigentlich alles vertreten. Manchmal findet sich aber auch ein IE8 – in den meisten fällen ist dies dann aber ein Notebook, mit erhöhten Berechtigungen (lokaler Administrator – schlecht! ), welches ohne Angst auf Verluste sämtliche Softwarekomponenten, einschließlich Windows Updates (gut!) installiert.

Für all diejenigen, die es bisher nicht geschaft haben oder noch in der Testphase stecken, haben wir in diesem Artikel, einen Lösungsweg von vielen, einmal genauer Untersucht und beschrieben. Unserer Meinung nach ist dies ein Weg, den man durchaus so weiterempfehlen kann. Mit einer vernünftigen Testphase, sind so fast keine Überraschungen zu erwarten. In einer Kundenumgebung mit mehr als 300 Workstations traten hierbei keine nennenswerten Fehler auf. Zudem verlief die Umstellung für die Benutzer nahezu unsichtbar – wie von Geisterhand.  Im Fall des IE 8 kann mit dem so genannten IEAK 8 das Rollout hervoragend vorbereitet und durchgeführt werden.

Erstellung des MSI-Paketes mit dem IEAK 8

Mit dem IEAK 8 kann so gut wie jede Einstellung des Internet Explorers automatisch bei der Installation konfiguriert werden. Folgende Einstellungen müssen so nicht mehr händisch festgelegt werden:

• Erstellung eines MSI-Paketes, einer CD mit Autorun und eines Konfigurationspaketes
• Anpassung der Verbindungseinstellungen
• Hinzufügen wichtiger Links und Favoriten
• Übernahme oder Löschung der bisherigen Favoriten des Anwenders
• Anpassung der Such-Provider
• Sicherheitseinstellungen

Hierbei ist jedoch zu beachten, dass lt. Microsoft für folgende Betriebssysteme unterschiedliche Installationspakete erstellt werden müssen. Dies gilt auch für die eingesetzte Sprache des Betriebssystems.

• Windows XP mit SP2/SP3 (x86)
• Windows Server 2003 mit SP2 (x86)
• Windows Vista SP1 und Windows Server 2008 (x86)
• Windows XP mit SP2 und Windows Server 2003 mit SP2 (x64)
• Windows Vista SP1 und Windows Server 2008 (x64)

Um euch von den Vorteilen des IEAK 8 zu überzeugen, habe ich euch einmal die Erstellung einen MSI-Paketes für den Internet Explorer 8 mit Screenshots dokumentiert.

1.  Auswahl der Betriebssystemplattform

2.  Auswahl der Sprache

3.  Aussuchen der Bereitstellungsmethode

4.  Festlegen der Installationoptionen

5.  Anpassung der Benutzeroberfläche

6.  Eingrenzung der Suchanbieter

7.  Festlegung der Homepage

8.  Anpassung der Favoriten und Feeds

9.  Optionen zur Verwaltung vorhandener Objekte

10.  Einstellung der einmaligen “Willkommen Seite” nach der Installation

11.  Anpassung der Proxyeinstellungen

12.  Sicherheits- und Datenschutzeinstellungen

13.  Erstellung des MSI-Paketes

Einbindung einer Gruppenrichtlinien zur Installation des Internet Explorer 8

Für die automatische Installation empfiehlt sich der Gebrauch von Gruppenrichtlinien. Da diese in den Server-Betriebssystemen von Microsoft enthalten sind, muss hierfür nicht extra eine Lösung zur Softwareverteilung implementiert werden und die Kunden sparen dann auch noch Geld. Mit diesen GPO’s kann die Installation des vorab erstellten MSI-Paketes schnell und ohne großen Aufwand durchgeführt werden. Dafür muss nur eine neue Computerrichtline für die Softwareinstallation erstellt werden. Diese muss die Software dem jeweiligen System zuweisen.

Auswirkungen für die Anwender

Je nach Installations-Methode kann die Auswirkung für den Anwender verschwindend gering gehalten werden. Hierbei ist jedoch zu beachten, dass das System unbedingt nach der Installation des Internet Explorer 8 neugestartet werden sollte.

1. Anwendungsinstallation

2. Erste für den Anwender erkennbare Veränderung

3. Erste Ausführung des Internet Explorer 8

Tools zur Prüfung der Version des Internet Explorers

Sollte es innerhalb der vorgefundenen Umgebungen keine Inventarisierungs-Lösung geben, so gibt es auch die Möglichkeit, den Status via WMI zu überwachen. Dabei können jedoch nur eingeschaltete und domänenintegrierte Systeme geprüft werden. Ich werde euch in den kommenden Tagen wieder ein Excelsheet für Administratoren bereitstellen, mit welchem ihr den Status abfragen könnt.

Links

Microsoft: Internet Explorer 8 Deployment Guide

Microsoft: Internet Explorer Administration Kit 8

Microsoft: Gruppenrichtlinien für die Remoteinstallation

Sascha Giebelhausen

Ist es euch auch schon passiert, dass ihr den Auftrag erhalten habt, “im gesamten Clientnetz” irgendeine Einstellung zu prüfen oder ein Software zu installieren? Also mir passiert so was schon häufig und der zeitintensivste Teil dieser Aufgaben war es meist, erstmal rauszufinden, welche Systeme in selbigen Netz überhaupt erreichbar sind. Diese Liste könnte dann im zweiten Schritt für irgendwelche Programme weiter genutzt werden.

Damit ich jedoch keine so genannten Ping-Tools von Drittanbieten installieren musste, habe ich mir vorerst ein VB-Script geschrieben, welches die vom Betriebssystem bereit gestellten Funktionen nutzt. Leider musste ich nach kurzer Zeit feststellen, dass diese Methode nicht sehr benutzerfreundlich war. Damit bin ich dann auch schon beim Thema. Im Downloadbereich könnt ihr nun ein Ping-Tool auf der Basis eines Excel-Makros finden. Dieses kann die Verfügbarkeit von Systemen wie Clients, Server, Firewalls oder Switchen prüfen. Die Prüfung erfolgt auf der Basis des Hostnamens oder der IP-Adresse.

Das Tool ist selbserklärend und kann von jedem System mit Excel ausgeführt werden.

  Ping Check 1.1.xls (860.0 KiB, 179 hits)

Links

blog – port 389: check_state_remote_1.0.xls

Sascha Giebelhausen

Oder: Was ist mit dem Zeitdienst los?

Wie mein Kollege Florian Thiessenhusen vor ein paar Tagen absolut treffend in seinem Blog-Beitrag geschrieben hat, gehört NTP bzw. der Zeitdienst W32Time zu den wichtigsten Komponenten innerhalb einer Active Directory Infrastruktur. Nahezu alle Technologien greifen auf eine einheitliche Zeitbasis zurück – aber nicht jeder erkennt diese enorme Wichtigkeit! Immer wieder treffen wir auf die abstrusesten Selfmade-Lösungen. Dabei stellen Infrastrukturen die gar nicht konfiguriert sind oder Infrastrukturen mit mehr als 30 als autorisierend konfigurierte Zeitserver, sicherlich die Ausnahme dar…

…Es ist ehrlich gesagt keine große Herausforderung eine funktionierende und vorallem Best-Practice-konforme NTP-Struktur aufzubauen. Es gilt jedoch einige entscheidene Faktoren zwingend zu berücksichtigen.

Bei der Migration (Ablösung durch zusätzliche Domain Controller) einer bestehenden Windows 2003 auf eine Windows Server 2008 R2 Domäne, kann es jedoch manchmal ein bisschen länger dauern bzw. um es im “Consulting-deutsch” zu sagen “Warum geht die Schei… nicht?”. Hier muss zwangsläufig der autorisierende Zeitserver der Domäne (in den meisten Fällen der PDC-Emulator) nach dem verschieben der FSMO-Roles angepasst werden. Das geht in der Regel am schnellsten mit folgendem Befehl:

w32tm /config /update /manualpeerlist:pool.ntp.org /syncfromflags:MANUAL /reliable:YES

Pool.ntp.org ist hierbei ein Zeitserver-Pool im Internet mit vier Zeitservern und einer durchaus vernünftigen Verfügbarkeit. Mehr als ebenbürtig sind auch die Server der Physikalisch-Technische Bundesanstalt in Braunschweig (ptbtime1.ptb.de, ptbtime2.ptb.de, ptbtime3.ptb.de).

In mehr als der Hälfte alle Fälle (je nach Unternehmen: Kritische Infrastruktur?, Produktionsunternehmen? Finanz-, Geld- und Versicherungswesen?) empfiehlt es sich (siehe Bundesamt für Sicherheit in der Informationstechnologie, BSI) einen eigenen NTP-Server im lokalen Netz bereitzustellen – hier bieten sich Systeme mit DCF-77 oder GPS geradezu an.

Um nun seinen restlichen Domain Controllern den neuen autorisierenden Zeitserver bekannt zu machen, geht man am einfachsten wie folgt vor:

1. Eingabeaufforderung (ab 2008 Server als Administrator ausführen!)
2. net stop w32time (Zeitdienst beenden, ansonsten gibt es eine “access denied message”)
3. w32tm /unregister (Zeitdienst “deinstallieren”)
4. w32tm /register (Zeitdienst “installieren”)
5. net start w32time (Zeitdienst starten)
6. w32tm /resync (synchronisieren mit Zeitgeber)

In meinem Fall, mussten die Systeme nicht gebootet werden. In manchen Situationen muss jedoch zwischen Schritt drei und vier das System neugestartet werden.

Testen kann man dann seine Konfiguration mit:

w32tm /monitor

Die “RefID” sollte nun überall der autorisierende Zeitserver sein. Beim PDC-Emulator bzw. beim autorisierenden Zeitserver muss diese (RefID) wiederum der Zeitserver im Internet (bsp. pool.ntp.org) oder der Zeitserver im internen Netzwerk sein. Im Optimalfall sollte die Zeit nun bis auf die vierte oder fünfte Stelle im Millisekundenbereich synchron sein.

Thomas Gronenwald

Links:
M 4.227 Einsatz eines lokalen NTP-Servers zur Zeitsynchronisation
Kritische IT-Infrastrukturen, BSI

DHCP-Migration mit Hilfe der Windows-Server-Migrationstools…

Ein Kunde möchte seine Active-Directory-Infrastruktur von Windows Server 2003 SP2 auf Windows Server 2008 R2 migrieren. Ein In-Place-Upgrade kommt nicht in Frage, zumal dank Virtualisierung eine Koexistenz schnell geschaffen werden kann. Hierbei sollen alle Domain Controller auf 2008 R2 migriert werden – ein Domain Controller fungiert zudem als DHCP-Server für Clients im Netzwerk. Da Aufgrund der Vielzahl an Reservierungen und Leases nicht einfach ein neuer DHCP mit identischen Einstellungen in Betrieb genommen werden kann, muss die DHCP-Server-Datenbank, sowie die Einstellungen exportiert und auf dem neuen System importiert werden.

Was aber mache ich, wenn die in der Vergangenheit bewährten Methoden nun nicht mehr funktionieren?

In der Vergangenheit gab es einige Möglichkeiten, einen DHCP-Server erfolgreich und schnell zu migrieren. Ein Ex- und Import mit “netsh dhcp server export C:\dhcp.txt all und netsh dhcp server import c:\dhcpdatabase.txt all” beispielsweise oder direkt die DHCP-Server-Funktion “Sichern und Wiederherstellen”.

Die Migration stellt sich nicht immer so einfach dar – ein Domain Controller mit DHCP-Server-Rolle macht die Migration nicht unbedingt einfacher, da es keinen lokalen Administrator mehr gibt der jedoch für den Export vorrausgesetzt wird.

Artikel KB 325473:
…if you plan to promote it to a domain controller, we suggested that you perform the DHCP database migration before promoting it to a domain controller. Although you can migrate the DHCP database to a Windows 2003 domain controller, the migration to a member server will be easier because of the existence of the local administrator account…

Soweit so gut…

Auch die Möglichkeit einen Domain Controller im Wiederherstellungsmodus zu starten und dann mit “lokalem Administrator” den DHCP zu importieren, ist nicht gerade eine präferierte Option.

Hier kommen die Windows Server-Migrationstools zum Einsatz. Diese Powershell cmdlets stehen ab Windows Server 2008 R2 standardmäßig als Feature bereit und können im Server-Manager hinzugefügt werden. Mit diesen Tools ist es nun möglich, von Windows Server 2003 SP2 nach Server 2008 R2, von physikalisch nach virtuell und von einer x86 zu einer x64-Architektur zu migieren – also genau das was ich benötige. Was jedoch nicht möglich ist, ist die Migration bei dem sich die Sprache der Benutzeroberfläche von der des Quellservers unterscheidet. Daher ist es nicht möglich z. B. die Windows Server-Migrationstools zum Migrieren von Rollen, von einem Computer unter Windows Server 2008 mit einer französischen Systembenutzeroberfläche zu einem Computer unter Windows Server 2008 R2 mit einer deutschen Systembenutzeroberfläche zu verwenden. Genauso wenig möglich ist die Migration von Server Core-Rollen, da schlichtweg die Vorraussetzungen (kein .NET Framework verfügbar) im Server Core nicht verfügbar sind.

Vorbereiten der Migration

Step 1: Installieren der Windows Server-Migrationstools (Zielserver, Windows Server 2008 R2)

Als erstes müssen auf dem späteren DHCP-Server und Domain Controller die Windows Server-Migrationstools installiert werden. Im Vorfeld sollte optimalerweise auch das System auf den aktuellsten Stand gebracht werden. Außerdem muss mindestens das .NET Framework 2.0 und die Windows PowerShell 1.0 verfügbar sein. Die Installation der Windows Server-Migrationstools kann einfach über den Server-Manager, über Features hinzufügen, installiert werden.

Step 2: Erstellen eines Server-Migrationtool-Deployment-Package (Quellserver, Windows Server 2003 SP2 x86)

Um die Migrationstools für den Export auch auf unserem Quellserver nutzen zu können, muss nun ein Installationspaket für unseren Windows Server 2003 SP2 x86 mit den installierten Tools auf unserem Zielserver erstellt werden.

Hierzu wechseln wir auf der Kommandozeile in das Verzeichnis “C:\Windows\System32\ServerMigrationTools” und führen folgenden Befehl zum erstellen des Paketes aus:

>SmigDeploy.exe /package /architecture X86 /os WS03 /path c:\

Hiermit wird auf dem Zielserver (Windows Server 2008 R2) in Laufwerk C:\ ein Ordner mit dem Namen “SMT_<Betriebssystem>_<Architektur>”,  in meinem Fall der Ordner “SMT_WS03_x86″ erstellt.

Step 3: Kopieren des Ordners “SMT_WS03_x86″ vom Ziel- auf den Quellserver

Nun muss der komplette Ordner noch auf den Quellserver (Windows Server 2003 SP2) kopiert werden. In meinem Fall kopiere ich diesen auch in “C:\SMT_WS03_x86″. Auch auf dem Quellserver muss zur Ausführung der Tools mindestens das .NET Framework 2.0 und die PowerShell 1.0 installiert sein.

Step 4: Registrieren der SmigDeploy.exe auf dem Quellserver

Um die cmdlets der Migrationstools auch auf dem 2003 Server nutzen zu können, müssen diese wie folgt registriert werden. Dazu wechseln wir auf der Kommandozeile in das Verzeichnis “C:\SMT_WS03_x86″ und führen folgenden Befehl aus:

>.\Smigdeploy.exe

Step 5: Exportieren der DHCP-Datenbank und Einstellungen mit Export-SmigServerSetting cmdlet (Quellserver)

Um nun die bestehenden DHCP-Einstellungen zu exportieren, empfiehlt es sich zuallererst den DHCP-Dienst zu stoppen. Dann wechseln wir in der Kommandozeile in den eben kopierten Ordner “C:\SMT_WS03_x86″ und führen zum Export folgenden Befehl aus:

>Export-SmigServerSetting -FeatureID “DHCP” -Path “C:\” -Verbose

Für die zu exportierende Datei muss noch ein Password mit mindestens sechs Stellen vergeben werden. Nach Erfolgreichem Export, erhalten wir in Lauwerk “C:\” eine Datei mit dem Namen “servermig.mig”. Jetzt kann der temporär gestoppte DHCP-Dienst vorläufig wieder aktiviert werde.

Step 6: Importieren der DHCP-Datenbank und Einstellungen mit Import-SmigServerSetting cmdlet (Zielserver)

Nun kopieren wir die exportierte Datei wieder auf unseren Zielserver. Der Einfachheithalber auch hier wieder auf “C:\servermig.mig” und wechseln auf die Kommandozeile. Mit dem Befehl:

>Import-SmigServerSetting -FeatureID “DHCP” -Path “C:\” -Verbose

importieren wir die Konfiguration auf unserem neuen Windows 2008 R2 Server. Das tolle daran ist, dass nicht einmal ein DHCP-Server vorab installiert werden muss. Die Import-Routine erkennt, ob der DHCP installiert ist oder nicht und installiert diese Rolle eigenständig. Es kann dabei durchaus sein, dass der Import mehrere Minuten dauert auch wenn die *.mig-Datei nur wenige KB groß ist  – hiervon sollte man sich aber nicht irritieren lassen.

Step 7: Prüfen der importierten Einstellungen

Jetzt gilt es noch die importierten Einstellungen zu prüfen, den alten DHCP-Server zu deaktivieren und die Autorisierung im AD aufzuheben, den neuen DHCP-Server in Betrieb zu nehmen und zu autorisieren. Wichtig ist es auch vorab noch bestimmte Schnittstellen zu prüfen, die den alten DHCP-Server nutzen. Dies kann zum einen eine VPN-Appliance sein und zum anderen Server die als DHCP-Relay fungieren – hier muss die IP-Adresse bzw. der DNS-Name auch umgestellt werden. Diese Schnittstellen gilt es jedoch vor der Migration, in der eigentlichen Planung, genauer unter die Lupe zu nehmen.

Sind alle benötigten Einstellungen vorhanden, steht der Promotion zum Domain Controller nichts mehr im Wege.

Nächster Artikel: DHCP-Split-Scope

Links:
Handbuch zur DHCP-Server Migration (Technet)

Thomas Gronenwald

Mit der PowerShell zum Ziel:

Immer wieder steht man vor bestimmten Herausforderungen und im Endeffekt ist die Lösung dafür wie so oft die Windows PowerShell – auch in diesem Fall:

Folgendes Szenario:

Ein Kunde möchte gerne seine Berechtigungen für Outlook Web Access (OWA) und ActiveSync über vorher definierte Verteilergruppen steuern. Heißt im Klartext, dass Mitglieder der Verteilergruppe “gr_mail_owa_ena” oder “gr_mail_acs_ena” berechtigt sind Ooutlook Web Access bzw. ActiveSync zu nutzen. Alle nicht in diesen Gruppen enthaltenen Benutzer bekommen diese Berechtigungen nicht.

Mit dem folgenden, bekannten PowerShell-Kommando kann man sich zuerst einmal alle E-Mailkonten anzeigen lassen:

Get-CASMailbox | ft DisplayName

Alle Mailboxen mit aktiviertem Outlook Web Access anzeigen:

Get-CASMailbox | where { $_.OWAEnabled } | ft DisplayName, OWAEnabled

Oder mit aktiviertem ActiveSync:

Get-CASMailbox | where { $_.ActiveSyncEnabled } ft DisplayName, ActiveSyncEnabled

Damit die im nachfolgenden Script angegebenen Verteilergruppen auch funktionieren, müssen diese vorab angelegt und mit den berechtigten Benutzern versehen werden.

Das eigentliche Script (owa.ps1) muss dann nur noch im Powershell-Pfad abgelegt werden und kann dann direkt über die Shell angesprochen werden. Den zugehörigen Pfad findet man schnell mit der Variable “$PSHome”.

Das Script arbeitet dabei wie folgt:

Step 1: Deaktivierung ActiveSync und Outlook Web Access für alle Postfächer
Step 2: Alle Benutzer aus den Verteilergruppen zuordnen
Step 3: Für jeden Benutzer Outlook Web Access aktivieren
Step 4: Für jeden Benutzer ActivSync aktivieren

Jetzt lässt sich das Script noch nach belieben, etwa als geplanter Task, mehrmals täglich ausführen.

Download (owa.ps1)

Ich habe das Script sorgfälltig getestet. Ich bitte jedoch auch hier, vor der produktiven Nutzung, das Script in einer Testumgebung zu testen.

Thomas Gronenwald

Eine der wichtigsten Basisdienste in einem Netzwerk, ganz gleich wie groß oder klein, ist das NTP (Network Time Protocol). (Synchrone) Zeiten sind nicht nur wichtig, damit die gesamte Firma gleichzeitig Feierabend macht oder das Mittagsbuffet stürmt, sondern auch folgende Dinge stabil laufen:

- (Windows) Authentifizierung
- Clusterdienste (Windows wie auch OpenSource (u)Carp)
- EMail
- Billingsysteme
- Verschlüsselung/Hashes
- Replikationen
- …

So ziemlich jeder Dienst im Netzwerk benötigt eine Konstante, die in den meisten Fällen die Uhrzeit ist. Unterschiede, selbst im Millisekundenbereich, können fatale Auswirkungen haben. Zum Beispiel lief bei einem Kunden kürzlich die Interstandort Replikation zweier Windows Domänencontroller nicht mehr, weil die Uhrzeit 30 Sekunden auseinandergelaufen ist. Wie kann sowas passieren? In dem Moment, wo ein System keine zuverlässige Zeitquelle nutzt, versucht es, die Zeit selber zu “generieren”. Da dies verschiedenste Abhängigkeiten hat (Bios, Systemtaktung, Schaltzeiten, ..) können dort, teilweise enorme, Differenzen entstehen.

Um das zu vermeiden, sollte man seiner eigenen NTP Struktur immer ein wenig mehr Aufmerksamkeit widmen, als man es tut. Denn leider wird diese allzu oft unterschätzt.
Es spielt dabei keine Rolle, ob es sich dabei um ein Windows- oder Unixsystem handelt, die Grundlagen sind immer gleich.

Woher sollte man sich die Uhrzeit holen?

Wenn man nicht seine eigene Atomuhr betreiben möchte, hat man als Netzwerkbetreiber im Grunde nur drei Möglichkeiten:

• GPS
• DCF77
• Internet

“Produziert” wird die Uhrzeit jedoch hauptsächlich nur in den GPS Satelliten (für Peilung wird eine exakte Uhrzeit benötigt und da “oben” herschen optimale Vorraussetzungen (Schwerelosigkeit)) oder von der PTB (Physikalisch-Technische Bundesanstalt) (Atomuhr) welches dann via Langwellensender ausgestrahlt wird und für entsprechende Empfänger (Funkuhren oder andere DCF77-.Empfänger) immer empfangsbereit ist. Für beide Dienste gibt es für PCs/Server spezielle Erweiterungskarten die diese Zeiten empfangen können (mit anschliessbaren Antennen).

Die Angabe “Stratum”

Mit “Stratum” wird die Vererbungshistorie der zeit angegeben. Um so niedriger, um so besser. DCF77 und GPS wird als “Stratum 0″, also Quelle, bezeichnet. Ein Server, der von dort die Zeit synchronisiert, ist in einer NTP-Struktur “Stratum 1″. So geht es dann immer weiter:

In einer mittelgroßen Umgebung kann es dann bis Stratum 3/4 gehen. Das Ziel ist, den Stratum bis zum Client gering zu halten. Man geht davon aus, dass jede zusätzliche Synchronisierungstelle Zeit “kostet” (durch Laufzeiten etc.). So wird die Zeit “hinten raus” immer ungenauer (immernoch im Millisekundenbereich).

Als negatives Beispiel sei folgendes genannt:
Als Zeitquelle wird eine Internetquelle genutzt. Die Internetquelle ist im optimalen Fall “Stratum 1″, jedoch ist die nicht immer gewährleistet (die Internetquelle müsste in dem Fall einen GPS- bzw. DCF77-Empfänger angeschlossen haben.

Desweiteren baut man sich damit zu viele Abhängigkeiten auf (z. B. Firewall oder eine genaue Uhrzeit vom Zeitanbieter), was in mittleren bis großen Netzwerken nicht tolerierbar ist.

Fazit

Das Ziel sollte sein, seinen eigenen “Stratum 1″-Server aufzubauen. Es gibt wenig Abhängigkeiten und volle Kontrolle. Nachteil: DCF- bzw GPS-Hardware ist immernoch vergleichsweise teuer und für Unix-Systeme kommen nur Komponenten in Frage, die auch kompatibel sind und mit den gängigen NTP-Servern (z. B. ntpd).

Florian Thiessenhusen

Quizfrage: Angenommen, ihr habt einen (wahlweise einen auf Microsoft IIS basierenden) SMTP-Relayserver und wollt überwachen, ob sich Mails/Dateien in den Ordnern “Queue”, “BadMail” oder “Dropmail” befinden, die älter als…sagen wir vier Stunden sind. Wie würdet ihr das lösen (ohne einen Praktikanten oder Azubi damit zu beauftragen, jede Stunde manuell zu kontrollieren)? Wenn die Antwort “Nagios” war, dürft ihr jetzt weiterlesen!

Und zwar hatte ein Kunde kürzlich exakt dieses Problem. Wir haben daraufhin kurzerhand ein vorhandes Plugin umgeschrieben/erweitert und das entwickelt.

Darüberhinaus kann dieses Tool auch folgendes:

- Dateialter von spezifischen Dateien (basierend auf MIME-Typ) checken und Alarm geben, wenn ein Schwellwert überschritten worden ist (fileage.vbs)
- Dateialter von allen Dateien checken, die in einem Ordner sind. Älter als X Tage (in diesem Fall sieben)  gibt einen Alarm aus (youngestfile.vbs)

So sieht’s dann aus (klick):

Wie man es einbindet, hat der “Ur-Entwickler” in seinem Beitrag recht gut erklärt.

Dieses Tool ist aber nicht nur für o. g. Anwendungsfall zu empfehlen. Es lassen sich generell alle Ordner überwachen, in denen automatisiert Dateien kopiert werden und man auf Aktualität angewiesen ist.

Auch hier gilt mein besonderer Dank Christopher Sack.

Florian Thiessenhusen

Tool – Remote Sharecreator v1.0

Wie zuvor in der Beitragsreihe “Disaster Recovery” mit Wireshark erwähnt, habe ich jetzt den Remote Sharecreator soweit modifiziert das ein wirklich, nettes und kleines “Tool” entstanden ist. Das ganze basiert auf dem .net Framework 3.5 und kann jetzt eine oder mehrere Freigaben auf dem lokalen oder einem entfernten System im Netzwerk erstellen. Zudem gibt es die Möglichkeit, über eine Importfunktion auf bestehende CSV-Dateien zuzugreifen. Folgende gängigen Betriebssysteme werden unterstützt:

• Windows 2000 Professional
• Windows 2000 Server
• Windows XP
• Windows Server 2003
• Windows Server 2003 R2
• Windows Vista
• Windows 7
• Windows Server 2008
• Windows Server 2008 R2

Die wichtigsten Voraussetzungen für die Erstellung von Freigaben ist eine funktionierende Domänenstruktur, .net Framework 3.5, ein Nutzer mit den notwendigen Berechtigungen und das vorhandensein des freizugebenden Ordners auf dem Remotesystem.

Vorgehensweise bei der Erstellung einer Freigabe

Für die Erstellung einer Freigabe werden nur die Atribute Computername, Pfad und Freigabebezeichnung benötigt. Die müssen in folgendem Format eingetragen werden.

Computername: [HOSTNAME]
Pfad (Local): [LAUFWERKSBUCHSTABE]:\[Ordner1]...\[OrdnerN]
Freigabebezeichnung: [FREIGABENAME]

Vorgehensweise für die Erstellung mehrerer Freigaben

Zur Erstellung mehrerer Freigaben können diese händisch in den Remote Sharecreator eingetragen oder über eine CSV-Datei importiert werden. Hierbei ist jedoch zu beachten, dass mit dieser Version ein Import über die Zwischenablage von Excel noch nicht möglich ist. Dies ist jedoch für eine der kommenden Versionen angedacht. Die CSV-Datei kann eine beliebigen Stelle im Netzwerk oder im Dateisystem des lokalen Systems abgelegt werden. Diese muss über folgende drei Spalten verfügen.

• Spalte 1: Servername
• Spalte 2: Lokaler Pfad
• Spalte 3: Freigabe

Die Kopfzeile der CSV-Datei beliebig angepasst werden. Es ist jedoch notwendig, dass die Reihenfolge beibehalten wird.

Für den Import der Datensätze der CSV-Datei muss der Remote Sharecreator geöffnet und die Ansicht für die Erstellung mehrerer Freigaben geöffnet werden. Dann könnt ihr einfach über die Schaltfläche “Import von CSV” die gewünschte Datei auswählen und importieren.

Sascha Giebelhausen