faq-o-matic.net » Scripting

IP-Konfigurationen auslesen und zentral sammeln

Nils Kaczenski — Wed, 01 Feb 2012 05:19:00 +0000

Die geneigte Administratorin benötigt oft eine Übersicht über die IP-Konfigurationen ihrer Rechner. Neben der reinen Adressliste zählen dazu häufig auch die eingetragenen DNS-Server – etwa dann, wenn ein alter Server durch einen neuen ersetzt und dieser dann bei den Clients eingetragen werden muss. Eine WMI-basierte Skriptlösung kann dabei helfen.

Unser Skript “Bert” verbindet sich per WMI (Windows Management Instrumentation) mit einem Windows-System und liest die wichtigen Eckdaten der IP-Konfiguration aus. Diese zeigt er als separierte Liste auf der Kommandozeile an. Leitet man diese Ausgabe in eine zentrale Datei auf einem Server um, so entsteht eine CSV-Datei, aus der man etwa mit Excel die IP-Konfigurationen direkt verarbeiten kann. Das Skript funktioniert lokal und über das Netzwerk.

Note: There is a file embedded within this post, please visit this post to download the file.

Syntax und Verwendung

Die Grundsyntax von Bert sieht folgendermaßen aus:

cscript //nologo Bert.vbs [Rechner] /header:[yes|no]

Es handelt sich um ein Konsolenskript, daher muss es mit cscript aufgerufen werden. Der Schalter “//nologo” unterdrückt die Ausgabe der WSH-Informationen, sodass nur die eigentliche Ausgabe des Skripts erscheint. Mit dem Schalter “/header” gibt man an, ob die Spaltenüberschriften in der Ausgabe erscheinen sollen. Lässt man diese nur beim ersten Rechner ausgeben und unterdrückt sie bei allen anderen, so kann man die Ausgabe in einer einzigen Datei sammeln, die dann einmalig mit den Spaltenüberschriften beginnt.

Das Skript erfasst folgende Daten:

Computername
Adaptername
MAC-Adresse
DHCP-Nutzung
IP-Adressen
DNS-Server

Gibt man keinen Rechnernamen an, so wertet Bert die IP-Konfiguration des lokalen Rechners aus. Wenn man einen entfernten Rechner über das Netzwerk auswerten möchte, benötigt man dort Administratorrechte (das ist bei lokaler Ausführung nicht nötig), oder man muss die WMI-Berechtigungen auf dem Remote-System bearbeiten. Außerdem darf keine Firewall die WMI-Schnittstelle blockieren.

Eine zentrale Sammlung der Konfigurationen in der Datei “IP-Daten.txt” in einer Dateifreigabe zeigt folgendes Beispiel:

cscript //nologo C:\Pfad\Bert.vbs DC01 /header:yes > \\SERVER007\IPData$\IP-Daten.txt
cscript //nologo C:\Pfad\Bert.vbs EX01 /header:no >> \\SERVER007\IPData$\IP-Daten.txt
cscript //nologo C:\Pfad\Bert.vbs SQL01 /header:no >> \\SERVER007\IPData$\IP-Daten.txt

Um die Einschränkungen bei der Remote-Auswertung zu umgehen, kann man Bert auch aus einem Start- oder Logonskript aufrufen. Da normale Anwender die WMI-Schnittstelle lokal aufrufen dürfen, sind hierzu keine besonderen Benutzerrechte nötig. In diesem Fall muss man darauf achten, dass für die Anwender (bei Logonskripts) bzw. für die Computerkonten (bei Startskripts) Schreibrechte auf die Sammel-Datei bestehen.

Um beim Einsatz per Logonskript Schreibkonflikte durch gleichzeitigen Zugriff auf die Zieldatei zu vermeiden, kann man z.B. über folgendes Batch die Daten des lokalen Rechners in jeweils eine eigene Datei schreiben:

@echo off
rem Schreibt die IP-Grundkonfiguration des Rechners in eine Textdatei

SET Target=\\SERVER\IPData$\Clients\%computername%.txt
SET Bert=\\SERVER\IPData$\Bert.vbs

COPY %Bert% "%userprofile%"

cscript //nologo "%userprofile%\Bert.vbs" /header:no > %Target%

DEL "%userprofile%\Bert.vbs"

Dieses Batch kopiert zunächst die Skriptdatei ins lokale Userprofil, damit es keine Berechtigungsfehler beim Aufruf von einem Share aus gibt. Das Ergebnis der Ausführung landet dann in einer Textdatei auf einer Dateifreigabe, die den Namen des lokalen Rechners trägt. Am ende entfernt das Batch die Skriptdatei wieder vom System.

In der Freigabe liegen dann zahlreiche Dateien – eine pro Rechner. Um sie nachträglich zu einer Datei zusammenzufassen, eignet sich dieses Kommando, das man in einem CMD-Fenster aus dem Ordner ausführt, wo die Dateien liegen:

for /F "usebackq" %i in (`dir /b`) do @type %i | find /i ";" >> "IP-Konfigs Clients.txt"

Keine verwandten Beiträge.

Exchange 2010: Reports über Mailbox-Größen

Nils Kaczenski — Tue, 31 Jan 2012 10:02:50 +0000

In Reaktion auf unseren gestrigen Artikel über das Auslesen von Mailbox-Größen in Exchange 2010 machte uns ein Leser auf ein hübsches Skript aufmerksam, das ein rudimentäres GUI für diese Aufgabe bietet. Es lässt sich mit Exchange 2010 auch remote von einem Admin-PC aus verwenden.

Vorsicht, wie bei jedem Skript muss man der Exchange-Shell bzw. der PowerShell ggf. zunächst erlauben, Skripte auszuführen. Der Aufruf geschieht dann in “Dot Syntax”:

PS C:\Users\Nils\mbsizereportv6> .\mbsizereportv6.ps1

Hier findet sich der Download:

[Glen's Exchange Dev Blog: Mailbox Size Gui - Exchange 2010 Remote Powershell version]

http://gsexdev.blogspot.com/2010/03/mailbox-size-gui-exchange-2010-remote.html

Keine verwandten Beiträge.

Exchange 2010: Mailboxgrößen auswerten

Nils Kaczenski — Mon, 30 Jan 2012 05:11:00 +0000

Exchange 2010 enthält mächtige Funktionen zur Auswertung der Mailbox-Datenbanken. Leider sind diese nur über die PowerShell zugänglich. Als Merker für mich und alle anderen daher hier zwei Kommandos zur schnellen Auswertung von Mailbox-Größen.

Als erstes die Gesamtgröße aller Mailboxen. Das Kommando ruft die Mailbox-Statistiken für alle Postfächer auf und gibt die Summe, den Durchschnitt, das Maximum sowie das Minimum für die Volumina in Megabytes aus:

Get-MailboxStatistics -Server MSX01 | %{$_.TotalItemSize.Value.ToMB()} | Measure-Object -sum -average -max -min

Wichtig: Dieses Kommando zählt alle Mailboxen auf einem Server. Statt “MSX01” ist der Servername anzugeben. Möchte man eine bestimmte Datenbank auswerten, so ändert man das Kommando in:

Get-MailboxDatabase "Mailbox Database 01" | Get-MailboxStatistics | %{$_.TotalItemSize.Value.ToMB()} | Measure-Object -sum -average -max -min

Hierbei ist dann “Mailbox Database 01” der Name der betreffenden Datenbank.

Sodann eine Liste aller Mailboxen mit der jeweiligen Größe. Hier eignet sich folgende Zeile, die das normale Ergebnis von “Get-MailboxStatistics” passend umformatiert.

Get-MailboxStatistics -Server MSX01 | where {$_.ObjectClass –eq "Mailbox"} | Sort-Object TotalItemSize –Descending | ft @{label="User";expression={$_.DisplayName}},@{label="Total Size (MB)";expression={$_.TotalItemSize.Value.ToMB()}},@{label="Items";expression={$_.ItemCount}},@{label="Storage Limit";expression={$_.StorageLimitStatus}} -auto

Hier gilt dasselbe: Soll es wieder nur eine Statistik über eine einzelne Datenbank sein, so nutze man:

Get-MailboxDatabase "Mailbox Database 01" | Get-MailboxStatistics | where {$_.ObjectClass –eq "Mailbox"} | Sort-Object TotalItemSize –Descending | ft @{label="User";expression={$_.DisplayName}},@{label="Total Size (MB)";expression={$_.TotalItemSize.Value.ToMB()}},@{label="Items";expression={$_.ItemCount}},@{label="Storage Limit";expression={$_.StorageLimitStatus}} -auto

Ehre, wem Ehre gebührt: Die Skripte habe ich mir nicht selbst erarbeitet, sondern abgekupfert, und zwar hier:

[Getting Mailbox Sizes in PowerShell]

http://www.petri.co.il/getting-mailbox-sizes-in-powershell.htm

[How to Calculate Exchange 2010 Mailbox Sizes with PowerShell]

http://blog.globalpointllc.com/2011/08/23/calculate-exchange-2010-mailbox-sizes-powershell/

Exchange 2010: Letztes Backup-Datum auslesen

Nils Kaczenski — Wed, 25 Jan 2012 05:08:00 +0000

Der Zeitpunkt der letzten Datensicherung ist bei Exchange schon immer feststellbar gewesen. In Exchange 2010 lauert allerdings bei der Bestimmung des Werts eine Falle.

In der grafischen Konsole findet sich dieser Wert bei den Eigenschaften der Datenbank:

Versucht man diesen Wert nun über die PowerShell auszulesen, so bekommt man vielleicht einen Schreck. Der naheliegende Befehl Get-MailboxDatabase "Mailbox Database 01" | fl behauptet, die Datenbank sei noch nie gesichert worden:

Und genau da lauern a) die Falle und b) der Trick. Man muss das Cmdlet nämlich ausdrücklich dazu auffordern, den Datenbankstatus heranzuziehen – nur dann stimmen die Angaben zum Backup.

Get-MailboxDatabase "Mailbox Database 01" –Status | fl

Dieses Kommando führt dann zum erwünschten Ergebnis:

PAL: Performance-Analyse mit Log-Dateien

Nils Kaczenski — Wed, 04 Jan 2012 05:09:00 +0000

Die Leistungsdaten eines Servers auszuwerten, erfordert meist tiefes Know-how der beteiligten Applikationen. Glücklicherweise bieten Windows-Server in den aktuellen Versionen dazu mit den “Sammlungssätzen” ein Hilfsmittel, das wichtige Systemdaten assistentengesteuert zusammenstellt und über automatisierte Berichte auswertbar macht. Zumindest für Standardsituationen, die das Gesamtsystem betreffen, hat man damit eine gute und einfache Auswertungsmöglichkeit.

Für wichtige Server-Applikationen findet sich auf Microsofts Open-Source-Repositorium Codeplex ein Werkzeug, das solche know-how-intensiven Analysen auch für einige wichtige Applikationen ermöglicht. Mit “PAL – Performance Analysis of Logs” lassen sich – ebenfalls assistentengesteuert – aufgezeichnete Leistungsdaten auswerten und zu aussagefähigen Reports zusammenstellen. Zwar geht dies immer nur im Nachhinein (man zeichnet also erst im System-Monitor die Daten auf und verfüttert die Log-Datei dann an PAL), doch gerade in Fehlersituationen kann dies eine sinnvolle Auswertung ermöglichen. Während die erste Version von PAL noch auf dem separaten Log Parser beruhte, arbeitet die aktuelle Fassung komplett auf PowerShell-Basis.

Folgende Applikationen deckt PAL ab:

Exchange 2003 bis 2010
SQL Server
Active Directory
Internet Information Services
Sharepoint
BizTalk

Die Logik für diese Applikationen findet sich in komplexen XML-Dateien, die aber auch durchaus in anderen Situationen nützlich sind, denn die dort referenzierten Zähler und Schwellwerte sind von allgemeinem Interesse.

Der Download und einiges an weiterführenden Informationen finden sich unter:

[Performance Analysis of Logs (PAL) Tool]
http://pal.codeplex.com/

Gezieltes installieren von Windows Updates via WSUS

Denis Eckler — Tue, 30 Aug 2011 06:26:13 +0000

Jeden Monat fängt das Grauen von neuem an – MS Patchday.

Ich weiß nicht ob ich der einzige Admin auf dieser Welt bin, der in einem mittelständischen Unternehmen (wie Nils immer sagt 50 – 50.000 Mitarbeiter *g) arbeitet und keine Clientmanagementlösung (ConfigMgr o.ä.) im Einsatz hat.

Was bedeutet das für uns und unserer in ganz Deutschland verteilten Kassensysteme?

Patches in der Testumgebung testen – und dann ausrollen. Aber wirklich auf alle Systeme gleichzeitig?

Viel geschickter wäre es doch, diese gestaffelt auszurollen und dann auch noch immer erst mal nur eine Kasse pro Filiale. Und erst wenn das läuft noch Kasse 2, 3 usw.

Natürlich kann man den "theoretischen" Installationszeitpunkt per GPO einstellen und natürlich kann man auch über WSUS-Gruppen dafür sorgen, dass nicht für alle Gruppen alle Updates genehmigt werden.

In einem interessanten Gespräch bei der ice:2011 in Lingen mit Andreas S. hat mir dieser von einem selbst erstellten Script erzählt, welches die Windows-Update-API antriggert, wodurch sich Updates scriptgesteuert herunterladen und installieren lassen. Nachdem er mir das Script freundlicherweise zur Verfügung gestellt hat, habe ich mir dies zusammen mit unserem Programmierer mal angesehen und sind nach ein wenig "BING it" auch im Netz beim MSDN fündig geworden.

Dieses Script triggert die WUA-API, lädt alle benötigten Updates vom WSUS Server auf den Client und installiert diese. Hierbei werden auch Updates, welche zusammen installiert werden sollten oder solche, die aufeinander aufbauen in Gruppen zusammengefasst. Außerdem erkennt das Script ob ein Reboot benötigt wird und führt diesen auf Nachfrage auch aus.

Wir haben das Originalskript so verändert, dass es, wenn es Updates gefunden hat, unsere Antiviren Lösung stoppt (Zeile 22-25 – das beschleunigt das Update auf unseren Kassensystemen um Faktor 10) und den Reboot automatisch ohne Nachfrage durchführt bzw. das AV-Programm wieder startet (Zeile 98-100), sollte kein Reboot benötigt werden.

Das Script wird wie folgend lokal ausgeführt:

cscript WUA_SearchDownloadInstall.vbs

oder Remote per PsExec

"PsExec.exe \\RECHNERNAME -u DOMAIN\USER -p PASSWORD -e cscript \\SERVER\SHARE\WUA_SearchDownloadInstall.vbs"

Um mehrere Rechner von einer Remotemaschine anzutriggern, könnte man die @File-Option von PsExec nutzen – leider werden diese dann nacheinander ausgeführt, was deutlich zu zeitaufwändig ist.

Eine Quick-and-Dirty-Lösung ist es, für eine überschaubare Anzahl an Clients diese in ein Batch einzubauen:

start c:\windows\system32\cmd /c "PsExec.exe \\RECHNERNAME1 -u DOMAIN\USER -p PASSWORD -e cscript \\SERVER\SHARE\WUA_SearchDownloadInstall.vbs" start c:\windows\system32\cmd /c "PsExec.exe \\RECHNERNAME2 -u DOMAIN\USER -p PASSWORD -e cscript \\SERVER\SHARE\WUA_SearchDownloadInstall.vbs"

Hier wird jetzt für jeden Rechner ein CMD-Fenster geöffnet.

Wenn man sich das Resultat noch ansehen will kann man den Befehl um ein & pause ergänzen:

start c:\windows\system32\cmd /c "PsExec.exe \\RECHNERNAME2 -u DOMAIN\USER -p PASSWORD -e cscript \\SERVER\SHARE\WUA_SearchDownloadInstall.vbs & pause"

Download modifiziertes Script WUA_SearchDownloadInstall_tap.vbs

Getestet unter Windows XP 32bit SP3, Windows 7 32bit SP1, Windows Server 2008 32/64bit inkl. R2

Happy Patching

www.ewig-drohendes-versagen.de

José: Version 3.1

Nils Kaczenski — Wed, 06 Jul 2011 04:00:00 +0000

Mein Dokumentationswerkzeug José ist nun in Version 3.1 verfügbar. Neben einigen Fehlerkorrekturen gibt es ein paar neue Funktionen.

Im Einzelnen:

Neue Funktionen:
- Exchange-Schemaversion 2010 SP1
- Anzahl Werte bei Multi-Value-Feldern (z.B. Gruppen – die Anzahl Gruppenmitglieder ist so leicht abzulesen)
- alle DCs der aktuellen Domäne in Domänen-Info angegeben
- OUs jetzt mit Angabe der Schachtelungstiefe (erleichtert die Orientierung bei langen Reports)
- Optionale Angabe von Details, falls José Objekte nicht lesen kann
Korrekturen:
- Korrektur UAC-Flags
- Korrektur der Objektzählung: Objekte im Domain-Root werden jetzt gezählt
- "memberOf" jetzt korrekt übersetzt
- OUs mit Schrägstrich im Namen erzeugen keinen Abbruch mehr

Hier ist der Download:

Note: There is a file embedded within this post, please visit this post to download the file.

Hier allgemeine Informationen zu José:

[faq-o-matic.net » José: Version 3.0 ist da]
http://www.faq-o-matic.net/2010/05/26/jos-version-3-0-ist-da/

Zeitangaben im Batch verwenden

Nils Kaczenski — Thu, 16 Jun 2011 04:58:00 +0000

Die klassische Command-Shell in Windows ist funktional sehr eingeschränkt. Trotzdem bietet sie für viele Aufgaben eine leicht beherrschbare Automatisierung durch einfache Kommando-Stapel – oder bekannter: Batches. Eine der fehlenden Funktionen betrifft den Umgang mit Datums- und Zeitangaben.

Möchte man das aktuelle Datum und die aktuelle Zeit in einem Batch verwenden, z.B. um Dateien oder Ordner nach dem Zeitstempel zu benennen, so helfen folgende FOR-Funktionen. Sie sind hier auf das deutsche Datumsformat abgestimmt, verwenden also den Punkt (beim Datum) bzw. den Punkt, den Doppelpunkt und das Komma (bei der Zeit) als Trenner. Wer eine andere Regionaleinstellung verwendet, passt diese Trennzeichen entsprechend an.

for /f "tokens=1-4 delims=. " %%i in ("%date%") do (
  set day=%%i
  set month=%%j
  set year=%%k
)

for /f "tokens=1-4 delims=.:, " %%i in ("%time%") do (
 set hour=%%i
 set minute=%%j
 set second=%%k
 set hundredth=%%l
)

Die einzelnen Teile der Zeit- und Datumsangabe finden sich dann in den verschiedenen Variablen. Um sie in einem Ordner zu verwenden, eignet sich etwa folgende Syntax:

SET Ziel=%Drive%\%year%-%month%-%day%-%hour%-%minute%
if not exist %Ziel%\. md %Ziel%

Carmen: Query Active Directory Using SQL Syntax

Nils Kaczenski — Tue, 14 Jun 2011 04:50:00 +0000

My script-based query tool “Carmen” for Active Directory has been downloaded more than 10,000 times since its release. Now I added an English version for an international audience.

Carmen lets you query Active Directory using SQL-style syntax. This makes it easier for most admins to get data from AD as SQL is more common to use than LDAP. Since its very beginning, Active Directory has supported SQL queries – as only few people seem to know.

Carmen is an HTA application written in HTML and VBSript. It is “safe” for your environment as it only reads data but cannot write to AD. Simply launch the tool by double-click and fill in the three data fields SELECT, FROM, and WHERE. (In most cases you can leave the FROM clause as it is since it already contains your domain name.)

Note: There is a file embedded within this post, please visit this post to download the file.

Here are some sample queries:

All users	SELECT * FROM 'LDAP://DC=contoso,DC=com' WHERE objectClass='user' and objectCategory='person'
Alle users from Hannover whose phone numbers contain "123", sorted by name in reverse order	SELECT name, telephoneNumber FROM 'LDAP://DC=contoso,DC=com' WHERE objectClass='user' and objectCategory='person' and l='Hannover' and telephoneNumber='123' ORDER BY name DESC
Disables users (unless other flags are set!)	SELECT * FROM 'LDAP://DC=contoso,DC=com' WHERE objectClass='user' and objectCategory='person' and userAccountControl='5142
All groups	SELECT * FROM 'LDAP://DC=contoso,DC=com' WHERE objectClass='group'
All domain Global Groups	SELECT * FROM 'LDAP://DC=contoso,DC=com' WHERE groupType='-21474836462
All Domain Local Groups	SELECT * FROM 'LDAP://DC=contoso,DC=com' WHERE groupType='-21474836442
All Builti groups	SELECT * FROM 'LDAP://DC=contoso,DC=com' WHERE groupType='-21474836432
All Universal Groups	SELECT * FROM 'LDAP://DC=contoso,DC=com' WHERE groupType='-21474836402
All computers	SELECT * FROM 'LDAP://DC=contoso,DC=com' WHERE objectClass='computer'
All computers with Windows XP and Service Pack 2	SELECT * FROM 'LDAP://DC=contoso,DC=com' WHERE objectClass='computer' and operatingSystem='Windows XP*' and operatingSystemServicePack='Service Pack 22
All sites and subnets in Active Directory	SELECT name,objectClass FROM 'LDAP://CN=sites,CN=configuration,DC=contoso,DC=com' WHERE objectClass='site' or objectClass='subnet'
The FSMO role owners	SELECT name,fSMORoleOwner FROM 'LDAP://DC=contoso,DC=com' WHERE fSMORoleOwner='*'

Datenkopien pro Wochentag

Nils Kaczenski — Wed, 08 Jun 2011 04:48:00 +0000

Methoden zur Datensicherung gibt es wie Sand am Meer. Ein einfacher, je nach Situation aber sehr leistungsfähiger Ansatz besteht in einfachen Dateikopien, die man durch Betriebssystembefehle erzeugen kann. Seit Windows Vista ist dafür das flexible Programm “robocopy” im Betriebssystem enthalten, das über einen sehr großen Satz an Funktionen verfügt.

Die folgende Skriptlösung zeigt, wie man mit robocopy ein Datensicherungssystem aufbauen kann, das täglich die Änderungen eines Datenbestandes in einen Tages-Ordner kopiert. Hierbei erzeugt das Skript für jeden Wochentag (Montag, Dienstag usw.) einen Ordner und legt dort die gesamten Daten der Quelle ab. Als Ergebnis erhält man ein tagesaktuelles, versioniertes Backup seiner Daten, das tageweise bis zu einer Woche zurückreicht. Die tatsächliche Dateiauswahl kann man über die Parameter von robocopy anpassen.

Zunächst muss das Skript ein Problem lösen: In der Standard-Shell gibt es keine zuverlässige Möglichkeit, den Wochentag zu bestimmen. Daher nutzt die Lösung ein separates VBS-Skript, das diese Aufgabe erledigt. Es gibt beim Aufruf den Namen des Wochentages zurück. Über einen FOR-Trick liest das Batch den Tag ein und legt ihn in der Variablen %Day% ab.

Den Rest erledigt dann der robocopy-Aufruf. In der hier vorliegenden Variante nutzt er die Mirror-Funktion, d.h. er erzeugt eine Kopie der Quelldaten mitsamt ihrer Ordnerstruktur im Zielordner. Dabei muss robocopy nur die Daten kopieren, die nicht bereits am Ziel liegen – ab der zweiten Woche kopiert es also nur das, was sich gegenüber der vorherigen Woche geändert hat. Gelöschte Quelldateien entfernt es auch am Ziel. Auf diese Weise lassen sich Änderungen bis zu sechs Tage lang in Tagesschritten manuell wiederherstellen.

Skript 1: Das Backup-Batch (Wochenbackup.bat)

@echo off
REM Umgebung festlegen
SET Source="C:\Daten\Wichtig"
SET Target="D:\Backups"

REM In Skript-Ordner wechseln
CD %0\..\

REM Ordner fuer Wochentag identifizieren und ggf. anlegen
FOR /F "usebackq" %%I IN (`cscript Wochentag.vbs`) DO SET Day=%%I
IF NOT EXIST %Target%\%Day% md %Target%\%Day%

REM Kopierjob 1
ROBOCOPY %Source% %Target%\%Day% /Z /MIR /MT /R:3

Skript 2: Bestimmen des Wochentags per VBS (Wochentag.vbs)

Select Case WeekDay(Now)
	Case 1 strTag = "Sonntag"
	Case 2 strTag = "Montag"
	Case 3 strTag = "Dienstag"
	Case 4 strTag = "Mittwoch"
	Case 5 strTag = "Donnerstag"
	Case 6 strTag = "Freitag"
	Case 7 strTag = "Samstag"
End Select

WScript.Echo strTag

Und hier der Download der Skripte:

Note: There is a file embedded within this post, please visit this post to download the file.

faq-o-matic.net » Scripting

IP-Konfigurationen auslesen und zentral sammeln

Exchange 2010: Reports über Mailbox-Größen

Exchange 2010: Mailboxgrößen auswerten

Verwandte Beiträge:

Exchange 2010: Letztes Backup-Datum auslesen

Verwandte Beiträge:

PAL: Performance-Analyse mit Log-Dateien

Verwandte Beiträge:

Gezieltes installieren von Windows Updates via WSUS

Verwandte Beiträge:

José: Version 3.1

Verwandte Beiträge:

Zeitangaben im Batch verwenden

Verwandte Beiträge:

Carmen: Query Active Directory Using SQL Syntax

Verwandte Beiträge:

Datenkopien pro Wochentag

Skript 1: Das Backup-Batch (Wochenbackup.bat)

Skript 2: Bestimmen des Wochentags per VBS (Wochentag.vbs)

Und hier der Download der Skripte:

Verwandte Beiträge: