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

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

Coole Neuerungen: AD DS, AD PowerShell und Best Practice Analyzer

Die AD DS unter Windows Server 2008 R2 haben ja nun einige wirklich nette Neuerungen erfahren. So auch der jetzt integrierte Best Practice Analyzer für die verschiedensten Serverrollen wie die AD DS oder das DNS. Hierbei ist es nun möglich, nach der Initialen Konfiguration, die getätigten Einstellungen auf Best Practices zu prüfen.

In vielen Fällen erhält man nach der Überprüfung der AD DS die folgende Warnung:

Alle Organisationseinheiten in der Domäne müssen vor versehentlichen Löschungen geschützt werden.

Leider kommt es trotz eingeschränkter und delegierter Administration vor, dass versehentlich Organisationseinheiten (OUs) gelöscht werden – komischerweise sind es dann auch direkt immer die OUs der Geschäftsführung – mmh naja. Daher empfiehlt es sich im generellen alle bestehenden OUs vor dem zufälligen Löschen zu schützen.

Das funktioniert im Einzelfall wie folgt:

• Snap-in Active Directory Benutzer und Computer
• Auswählen der zu schützenden OU
• Rechtsklick auf OU -> Eigenschaften
• Im Reiter Objekt -> Haken setzen bei – “Objekt vor zufälligem Löschen schützen”

So erhält man nun beim Versuch die OU zu löschen folgende Fehlermeldung:

Beim erstellen von neuen OUs wird standardmäßig der Objektschutz gesetzt. Alle vorher angelegten OUs sind davon jedoch nicht betroffen – daher sind diese noch ungeschützt.

Turnschuhprojekt oder PowerShell?

Was aber macht man, wenn man eine große, verteilte Domänenumgebung mit mehr als 500 OUs betreut? – alles von Hand setzten und aus dieser Anforderung ein Turnschuhprojekt mit einem Monat Laufzeit machen? – Nein, natürlich nicht. Hier drängt sich die neue AD-Powershell gerade zu auf.

Mit folgendem PowerShell-Befehl lassen sich so innerhalb weniger Sekunden alle noch nicht geschützten OUs vor dem ungewollten Löschen schützen:

Get-ADOrganizationalUnit –filter { Name -Like “*” } -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion –eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true

Und so können wir prüfen ob es funktioniert hat:

Get-ADOrganizationalUnit –filter { Name -Like “*” } -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion –eq $false}

Wenn wir hier keinen Output mehr erhalten, sollten jetzt alle OUs geschützt sein. Nichts desto trotz sollten noch ein paar Stichproben innerhalb des AD DS durchgeführt werden.

Thomas Gronenwald

Wie schließe ich die Rücksicherung erfolgreich ab?

Wie mein Kollege Thomas Gronenwald bereits in Teil 1 angerissen hat, wird für eine erfolgreiche Rücksicherung eine funktionierende Dateisicherung vorausgesetzt. Hier muss jedoch beachtet werden, dass zuerst die letzte erfolgreiche Vollsicherung und dann erst die Zuwachssicherungen wiederhergestellt werden. Leider beinhalten Dateisicherungen keine Freigaben für die fehlenden Fileshares (lerdiglich die NTFS-Berechtigungen). Nun gibt es  zwei Methoden zur Wiederherstellung der fehlenden Fileshares:

Methode 1: Wiederherstellung via Registry Export

Wie im Blog-Eintrag von Thomas Gronenwald bereits beschrieben ist ein Export/Import der benötigten Registry-Schlüssel (Systemstatebackup) zur Rücksicherung geeignet.

Methode 2: Halbautomatische Erstellung über eine Exceltabelle mit VBA

Sollten die Registrierungsschlüssel nicht vorhanden sein (so wie keine Dokumentation über bestehende Shares), so gibt es nicht sehr viele Möglichkeiten. Eine davon ist jedoch die im Blog-Eintrag Disaster Recovery: Letzte Ausfahrt Wireshark? Teil 1 beschriebene Vorgehensweise. Nachdem die fehlenden Freigaben enumeriert wurden, müssen diese noch erstellt werden. Diese Methode ist sehr zeitintensiv und fehlerträchtig -  wir sind ja auch nur Menschen.

Aus diesem Grund habe ich in Excel 2003 ein Makro zur Erstellung von Fileshares unter Windows 2000, Windows XP und Windows Server 2003 geschrieben.

Dies ermöglicht ein automatisiertes Erstellen von Fileshare auf einem Remote-System. Wichtig ist nur, dass die notwendigen administrativen Berechtigungen bereits vorhanden sind.

In der ersten Version wird vorerst bei einem erreichbaren Remote-System eine Freigabe erstellt. Der lokale Ordner und der Freigabename kann selbst gewählt werden. Hier können nun die mit Wireshark enumerierten und als *.csv exportierten Freigaben hinzugefügt werden.

Nachdem mit diesem Tool alle enumerierten Freigaben erstellt wurden, kann nochmals mit Wireshark überprüft werden ob alle SMB-Anfragen richtig beantwortet werden.

Das Tool ist derzeit noch in der Betaversion und wird weiter entwickelt. Gerne nehme ich dazu auch Anregungen und Verbesserungen entgegen. Eine Haftung schließe ich jedoch über diesen Weg generell aus.

Download:
Remote share creator 1.0

Sascha Giebelhausen