PowerShell Aliase für Cmdlets

Veröffentlicht am von Juli 1, 2013
Antworten

Beim Skripten mit PowerShell gibt es etwas Schreibaufwand, wenn man immer wieder gleiche Cmdlets ansprechen muß und keine Aliase verwendet. Klar wird das Skript durch Aliase nicht leichter lesbar. Über die bereits im Standard definierten Aliase gibt es in der PowerShell die Möglichkeit, eigene Aliase zu definieren, zu importieren, zu speichern.

Auflisten aller aktuell definierten PowerShell Aliase:

Get-Alias oder mit dem entsprechenden Alias 🙂 …
gal | sort Definition

Definieren eigener, neuer PowerShell Aliase
Wenn die definierten Aliase nicht passen, kann man sich eigene, zusätzliche Aliase definieren. Beachte: Die eigenen Aliase gelten nur in der aktuellen Sitzung. Deshalb sollte man die eigenen Definitionen in einem Skript in PSConfiguration-Verzeichnis sichern.

Beispiel: Das Write-Host Cmdlet hat keinen Alias. Wir definieren print als Alias.
>Set-Alias print Write-Host

Hier ein paar von mir definierten und häufig genutzten Aliase:

Get-ChildItem gci Objekte der aktuellen Position (DIR-Befehl)

Invoke-Item ii Öffnen einer Datei, Ausführen eines Programmes

Get-Process gps ps Anzeige der Prozeßliste

Where-Object where Filtern von Daten

 

Hinweis: Keine Aliase für die folgenden Cmdlets auf direktem Weg möglich:

Write-Warning, Write-Host

SCOM 2007 R2 Console über die Command Line mit Parametern starten

Veröffentlicht am von Januar 31, 2013
Antworten

Start der SCOM 2007 R2 Console über die Command Line
C:\%programfiles%\System Center Operations Manager 2007\Microsoft.MOM.UI.Console.exe
Parameter /? zeigt dieses Fenster ( sorry, noch WinXP-Layout)

ui_console_exe

/ClearCache Cache-Speicher der vorherigen Session bereinigen
/Server:<ServerName> Console zum Management Server verbinden
/ViewName:<ViewName> Bestimmte View laden und anzeigen
/TaskName:<TaskName> Starte einen Task
/TaskTarget:<ObjectId> in Verbindung mit /TaskName Ziel-Objekt-ID
/ManagementPack:<MpName> In Verbindung mit /TaskName and /ViewName (*)

(*) noch nicht von mir getestet

PowerShell: Wiederholung von PowerShell-Befehlen

Veröffentlicht am von Februar 13, 2017
Antworten

Auch die PowerShell merkt sich, wie jeder ordentliche Kommandointerpreter, die während der Sitzung eingegebenen Befehle bupropion drug. Somit kann man diese erneut verwenden, ohne diese neu eintippen zu müssen.

Diese gelten im übrigen (zum Teil) auch noch für die etwas betagte Eingabeaufforderung (cmd.exe) von Windows.

Am einfachsten ist die Möglichkeit dies mittels den Cursor-Tasten zu tun. Jedoch wird dies bei mehr als fünf Befehlen recht mühsam.

Besser ist da schon die Möglichkeit mit der Taste F7, diese zeigt eine Liste aller eingegebenen Befehle an. Navigiert wird auch hier mittels Cursor-Tasten.

Weitaus besser ist die Möglichkeit mit F8, hier kann dann auch vorgefiltert werden. Hierzu einfach einen Teil des Befehls eingeben und mit F8 durchblättern.

Sofern man die genaue ID des Befehls kennt (kann man gut mit F7 sehen), kann man diesen direkt mit F9 ausführen.

Editieren kann man den vorherigen Befehl natürlich auch, dies geht mit F2 (Kopieren bis Zeichen) und F4 (Löschen bis Zeichen).

 

Cmdlets zum Anzeigen der Historie

Es gibt auch ein passendes Cmdlet zur Anzeige der Historie, allerdings zeigt es nur bis max. 64 Befehle an: Get-History (alias history). Mit dem Schalter -count kann man die Ausgabe auf die letzten x Befehle reduzieren (in diesem Beispiel auf 20):

Get-Historie -count 20

Kennt man die ID des Befehls, kann man diesen auch direkt ausführen:

Get-Historie -ID <id>

Wesentlich besser ist jedoch der Einsatz eines Filters, hierbei ist das Select-String Cmdlet sehr hilfreich:

Get-Historie | Select-String „WMI“

In diesem Fall würden alle Befehle ausgegeben, die „WMI“ enthalten.

Die Historie der Befehle kann natürlich auch als csv-Datei exportiert werden:

Get-History | Select -unique | Convertto-Csv > historie.csv

 

Logfile der eingegebenen Befehle mitschreiben

Es ist natürlich auch möglich die Historie direkt in eine Datei mitloggen zu lassen. Hierzu macht man sich das Transcript zu nutze. Zuerst muss das Logfile festgelegt werden:

$Transcript = c:\log\mylog.txt

Danach wird dann noch das Transcript gestartet mit

Start-Transcript

Um das Transcript wieder zu beenden, einfach folgendes eingeben:

Stop-Transcript

Ich habe mir hierzu im PowerShell Profile folgende Zeilen angelegt:

$MyDate = Get-Date -Format yyyy-MM-dd
$MyLibDir = „z:\Programme\PowerShell“
$MyTransDir = „Z:\Programme\PowerShell\Transcript“
$Transcript = „$MyTransDir\Transcript_$MyDate.txt“
Start-Transcript

Die Profildatei kann über die Variable $profile erreicht werden. Um dieses mit dem Notepad zu editieren folgenden Befehl eingeben:

notepad $profile

 

Zusammenfassung der Tastenkürzel

Cursor-Tasten –> Befehle in Cursorrichtung einzeln anzeigen
F7 –> Liste der Befehle
F8 –> Filter auf Befehle
F9 –> Befehl mit bestimmter ID ausführen
F2 –> Kopieren bis Zeichen
F4 –> Löschen bis Zeichen

Storage Management

Veröffentlicht am von Februar 13, 2017
Antworten

Unter Storage versteht man in der IT eine Einheit, auf der Daten vorgehalten werden können. Dabei kann es sich um unterschiedliche Medien wie Festplatten oder Magnetbänder handeln.

Die zentrale Verwaltung und Organisation des Storage bezeichnet man als Storage Management. Dazu gehören das zur Verfügung stellen des Storage für Serversysteme, die Optimierung der Storageressourcen und die Aufrechterhaltung der Datensicherheit auf den genutzten Medien.

Zum Storage Management gehören ebenso die Datensicherung und Archivierung.

Welche Storagesysteme dabei genutzt werden hängt i.d.R. von den gestellten Anforderungen ab. Diese sind u.a. bestimmt durch Ausfallsicherheit, Verfügbarkeit, Datendurchsatz, Kapazität, Skalierbarkeit und nicht zuletzt durch die Kosten.

Dabei gibt es unterschiedliche Möglichkeiten, Storage an Serversystemen zur Verfügung zu stellen (Kurzübersicht, kein Anspruch auf Vollständigkeit):

– Direct Attached StorageW (DAS)

Storageressourcen werden direkt an ein System angeschlossen, welches diese dann exklusiv nutzen kann. Die Datenübertragung erfolgt blockbasiert, z.B. über SCSI, FireWire, USB. Der DAS Ansatz ist üblicherweise eine Punkt-zu-Punkt Verbindung von einem Serversystem zu einem Storage und ist limitiert, wenn mehrere Serversysteme auf eine Storageressource zugreifen sollen.

– Network Attached StorageW (NAS)

Storageressourcen eines zentralen Systems werden via Ethernet freigegeben, so dass andere Systeme über Netzwerkprotokolle wie NFS oder CIFS auf den freigegebenen Storage zugreifen können. Der Zugriff auf die Daten erfolgt fileorientiert. Das Filesystem wird auf dem zentralen NAS System verwaltet und als Netzwerklaufwerk an die „Clients“ gebracht.

Im Gegensatz zum Direct Attached Storage können viele Systeme auf den gleichen Storage zugreifen und diesen nutzen. Bekannte Beispiele aus Unternehmen sind z.B. Gruppen- oder Benutzerlaufwerke. Der Datendurchsatz wird häufig begrenzt durch die Ethernet Infrastruktur.

– Storage Area NetworkW (SAN)

Ein Speichernetzwerk wird für die Anbindung von Speichersubsystemen und Tape- Libraries an Serversystemen genutzt. Die Datenübertragung erfolgt blockbasiert und beruht auf Fibre Channel Technik. Das SAN ist optimiert für die Übertragung großer Datenmengen more information. Die Zuordnung von Speicherressourcen von Storagesubsystemen zu Serversystemen erfolgt dynamisch.

Um die Datensicherheit bei Festplatten zu gewährleisten, werden diese in der Regel in sogenannten RAID- Verbünden (RAID=Redundant Array of Independent Disks) organisiert. Dadurch werden Redundanzen geschaffen, die eine Verfügbarkeit der Daten trotz Hardwaredefekt sicherstellen. Alle gängigen Speichersubsysteme, NAS Systeme oder aber auch Volume Manager von diversen Betriebssystemen bieten die Möglichkeit Festplatten in einem RAID Verbund zu organisieren.

Storage_IBM

HelpDesk Support Systeme, Ticket Systeme

Veröffentlicht am von Februar 13, 2017
Antworten

Was ist ein HelpDesk-System / <a href="http://de bupropion hcl 150mg.wikipedia.org/wiki/Trouble-Ticket-System“ target=“_blank“ title=“From Wikipedia the definition of: Trouble-Ticket-System“ style=“padding-bottom: 2px; border-bottom: 1px dotted #DD0000″ >Trouble-Ticket-SystemW?
HelpDesk-Systeme sind die IT-technologische Unterstützung für den First Level Support / Help Desk. Kunden wenden sich mit ihren Problemen per Mail, Telefon oder direktem Erfassungsformular des HelpDesk-Systems an den Support. Bei persönlichem Kontakt erfasst der Supporter das Problem im System und versucht dies direkt zu lösen. Dazu steht ihm meist eine integrierte Wissensdatenbank (Knowledgebase) zur Verfügung. Bei neuen, noch nicht aufgetretenen Problemen wird bei oder nach der Lösung die Wissensdatenbank erweitert.
Können Probleme nicht sofort durch den Help Desk selbst gelöst werden, muß eine Anfrage an weitere unterstützende Organisationseinheiten (Second Level Support) geleitet werden.
Hierzu wird ein Ticket erstellt und an die jeweilige OrgEinheit geleitet. Diese Funktionalität, ein Ticket zu erstellen, führt oft zur Bezeichnung Ticket- oder Troubleticketsystem.

Grundlegende Funktionalität und Anforderungen an ein HelpDesk-System
Zentrale Ticketerfassung durch den First Level Supporter
Dezentrale Ticketerfassung durch den Kunden und Weiterleitung an den First Level Support
Automatisierte Ticketerfassung über eine Schnittstelle zu externen Systemen
Einordnung der Tickets und Probleme in Kategorien
Verfolgung und Dokumentation der Reaktionszeiten und des zeitlichen Aufwandes zur Problemlösung bzw. Störungsbehebung
Eskalationsmöglichkeit an externe Systeme ( Mail, Voicecall ) wenn Reaktionszeiten überschritten werden
Weiterleitung von Tickets an den Second Level Support zur Unterstützung bei nichttrivialen Problemen
– Eine halbautomatische Erfassung der Problemlösung in einer Wissensdatenbank sollte möglich sein. Dokumentation wenn der Bearbeiter diese Möglichkeit ausschlägt.
– Archivierung gelöster Tickets bei Überschreitung des Reportzeitraum in externer Datenbasis
– Reportfunktionalität über offene, gelöste und geschlossene Tickets

Anfragen der Kunden müssen in Häufigkeit und Zeitraum des Auftretens, Zeitdauer der Bearbeitung und möglicher Einbindung weiterer organisatorischer Einheiten zur Problemlösung, erfasst, dokumentiert und ausgewertet werden. Zur Erfüllung von Service Level Agreements (SLA) werden Reports erstellt und regelmäßig ausgewertet.
Neben der angestrebten Kundenzufriedenheit sind die Mitarbeiter des First Level Supports über die erreichten Problemlösungen, SLA-Zustand zu informieren, weiterzubilden und zu motivieren.

Eine wichtige Funktion in Ticket Systemen ist die Eskalation- und Verfolgung von Störungen und Problemen. Den aktuelle Zustand bei der Ticketbearbeitung kann man mittels Datenbankabfrage auf einer Webkonsole darstellen.

PowerShell: Internet Explorer ohne Adresszeile, Menü und Co. starten

Veröffentlicht am von Februar 13, 2017
Antworten

Auch der Internet Explorer läßt sich in einem schlichten Gewand starten. Hierzu wird allerdings ein kleines PowerShell Script benötigt:

function OpenURL([string] $url)
{
$ie = new-object -comobject „InternetExplorer.Application“
$ie.visible = $true
$ie click this link now.navigate($url)
$ie.ToolBar = $false
$ie.StatusBar = $false
$ie.MenuBar = $false
$ie.AddressBar = $false
$ie.Resizable = $true
}
OpenURL http://www.symablog.de

und so sieht es nach dem Aufruf des kleinen Skripts aus:
powershell_ie_01

PowerShell: PowerShell 3.0 unter Windows 7

Veröffentlicht am von Januar 29, 2013
Antworten

Mit dem Windows Server 2012 bzw. Windows 8 stellt Microsoft auch die PowerShell 3.0 zur Verfügung.

In der neuen Version sind einige nützliche Cmdlets hinzu gekommen, welche auch hier im Blog an verschiedenen Stellen zum Einsatz kommen.

Da es für Windows 7 keinen direkten PowerShell Download mehr gibt, hat Microsoft die PowerShell mit in das Windows Management Framework aufgenommen.

Der entsprechende Download ist hier zu finden: Click mich!

Active Directory: Alte Computerkonten ausfindig machen

Veröffentlicht am von Januar 29, 2013
Antworten

In einem größeren Active Directory (AD) kommt es mit der Zeit vor, das es alte Computerkonten gibt, welche nicht mehr benutzt werden. Dies kommt zustande, wenn Server oder Clients abgebaut werden ohne das das dazugehörige Computerkonto gelöscht wird.

Dies gilt auch, wenn ein Computer zwar aus der Domäne entfernt wird, das Computerkonto bleibt bestehen und muß noch gelöscht werden.

Auch durch die heutigen virtualisierten Umgebungen, wo sehr schnell Rechner auf- und abgebaut werden können, entstehen immer mehr solcher Karteileichen.

Windows liefert hier eigentlich alle Tools mit, um diese Karteileichen zu finden: dsquery und PowerShell 3.0!

Sobald ein Computer aus der Domäne entfernt wird, wird das Computerkonto disabled. Diese Computerkonten kann man recht einfach heraus finden:

dsquery computer -disabled

In PowerShell 3.0 sieht es dann so aus:

Search-ADAccount -AccountDisabled -ComputersOnly

Ist man sich dann sicher, das alle gesperrten Computerkonten gelöscht werden sollen, kann man dies so tun:

dsquery computer -disabled | dsrm

Alternativ natürlich auch mit PowerShell 3.0:

Search-ADAccount -AccountDisabled -ComputersOnly | Remove-ADComputer

 

Etwas schwieriger gestaltet sich das Problem bei inaktiven Computern. Diese sind beispielsweise einfach abgebaut worden, ohne das einem AD-Admin bescheid gesagt wurde. Gründe hierfür gibt es verschiedene.

Auch Außendienstmitarbeiter sind hier zu finden, wenn diese sich länger mit ihrem Computer nicht im Firmennetz aufgehalten haben.

Hier einen entsprechenden Inaktivitätszeitraum zu finden, sollte jeder selbst entscheiden und nach seiner Umgebung anpassen können.

Mit dsquery kann man diese Rechner recht schnell finden:

dsquery computer -inactive 6 -limit 0

Der Parameter inactive gibt hierbei die Anzahl der Wochen an, limit die Anzahl der maximalen Einträge (0=unendlich).

Mit PowerShell 3.0 ist dies natürlich auch möglich:

Search-ADAccount -AccountInactive -ComputersOnly -TimeSpan 42.00:00:00

Damit diese Computerkonten nicht sofort gelöscht werden, empfiehlt es sich, diese erstmal zu disablen:

dsquery computer -inactive 6 | dsmod computer -disabled yes

Mit PowerShell 3.0 geht dies so:

Search-ADAccount -AccountInactive -ComputersOnly -TimeSpan 42.00:00:00 | Set-ADComputer -Enabled 0

Wer mag, kann dies dann natürlich auch automatisieren.

 

Für die Mausschubser gibt es aber auch eine nette Freeware: AD Tidy

 

Monitoring & Eskalation von Störungen, Problemen, Situationen

Veröffentlicht am von Januar 29, 2013

IT-Komponenten, die produktiv Geschäftsprozesse unterstützen oder vollständig abbilden, müssen überwacht werden. Störungen, Probleme und Situationen werden erfasst, auf Konsolen dargestellt, via SMS und Telefon eskaliert und notwendige Tätigkeiten zur Lösung in Ticketsystemen angewiesen und dokumentiert.

Die vielfältigen technischen Systeme, die uns täglich an jeder Ecke unterstützen, neigen zu Fehlern und Ausfällen. Zusätzlich machen Menschen Fehler und lösen auch dadurch Störungen aus, verursachen Probleme im Betrieb.

Die IT als Dienstleister und grundsätzlicher Träger von Geschäftsabläufen ist ebenso anfällig für technische Fehler und menschliches Fehlverhalten. Technische Komponenten müssen deshalb überwacht und mögliches menschliches Fehlverhalten durch unterstützende Prozesse, z.B. Plausibilitätsprüfungen, reduziert und in seiner Auswirkung minimiert werden.

Welche Komponenten sollten überwacht werden?

Die IT als Dienstleister unterstützt Geschäftsprozesse. Somit müssen nach Möglichkeit alle beteiligten Komponenten überwacht und im Fehlerfall eskaliert werden.
Das können z.B. sein:

  • Server ( Hardware, Betriebssystem )
  • Datenbanken
  • Netzwerkkomponenten ( Router, Switche )
  • Applikationssoftware / notwendige Dienste
  • Verbindungen zu angeschlossenen Systemen, Internet, MQSeries, …
  • Storagesysteme – verfügbare Kapazitäten, SAN-Verbindungen

Dabei kann die Überwachung aktiv von den Komponenten durchgeführt werden, oder passiv von einer zentralen Stelle z.B. durch „anpingen“ erfolgen.

Typisierung von Situationen

Je nach Auswirkung einer Situation auf den Betrieb der Komponente, den Einfluß auf den Service / Prozeß, werden Schweregrade (Severities) definiert. Nach festgestelltem Schweregrad muß eine Eskalation in der jeweiligen Stufe erfolgen.

  • Störung – Komponente funktioniert nicht mehr. Der Ablauf ist so gestört, dass der Prozeß zum Halten kommt. Kunden können das System nicht mehr nutzen. Dringender Handlungsbedarf durch den Support erforderlich.
  • Problem – Komponente funktioniert eingeschränkt, der Prozeß läuft noch, aber es sind weitergehende Einschränkungen, bis hin zu einem Ausfall zu erwarten. Tätigkeiten durch den Support sind notwendig, aber Kunden können noch arbeiten, ggf. eingeschränkt durch z.B. Performanceverringerung.
  • Warnung – Es ist keine Einschränkung der erforderlichen Funktionalität vorhanden und kein aktives Eingreifen des Supports notwendig. Die gemeldete Situation sollte aber beachtet und für mögliches Eingreifen vorgemerkt werden.
  • Information – Eine Situation wird angezeigt und dient nur zur Visualisierung oder Information, z.B. für eine erfolgreiche Dateiübertragung oder Prozeßschnitte.
  • OK– oder Wiedergut-Meldungen dienen dazu eine vorhergehende Situtation zu beheben und weitergehende Eskalation in Alarme zu unterbinden.

Eskalation von Situationen

  • Störung -> Ticket/Mail -> AlarmSMS/Voicecall
  • Problem -> Ticket/Mail
  • Warnung, Information -> keine Eskalation, nur ggf. Darstellung auf technischer und/oder prozeßorientierter Konsole

Situationen werden durch die verschiedensten Quellen an ein zentrales System gemeldet. Dort findet nach einer Verarbeitung in einem Regelwerk die Speicherung in einer Datenbank statt. Diese zentrale Datenbasis dient dezentralen Konsolen zur Darstellung der Situationen, angepasst an die jeweilige Aufgabenstellung und Verantwortung des Betrachters.
An der zentralen Stelle des Regelwerks und der Datenbasis wird abhängig von definierten Parametern eine Eskalation initiiert. Die erste Stufe der Eskalation kann ein Ticket über ein HelpDesk- oder Ticketsystem sein, begleitet durch eine Mail. Oder es gibt in der einfachen Lösung nur eine Mail an die jeweilige Supportergruppe ( niemals an eine einzelne Person! ).
Die zweite Stufe ist die Eskalation via SMS und/oder Anruf (VoiceCall) an ein Mobiltelefon einer Bereitschafts- oder Einsatzgruppe. Grundlage für die Eskalation in der zweiten Stufe ist aber immer eine Eskalation der ersten Stufe! Gründe sind ist detaillierte Information und die Verfolgung der Aktivitäten durch die Systeme in der ersten Stufe.
Klar ist auch, das die unterschiedlichen Situationen in ihrem Schweregrad (Severity) eine jeweilige Eskalationsstufe nach sich ziehen. Über das Regelwerk kann ein Finetunig des Eskalationsweges, z.B. über Alarmverzögerung in der zweiten Stufe erfolgen.

Management Group des SCOM-Agenten umkonfigurieren

Veröffentlicht am von Januar 29, 2013
Antworten

Wenn ein SCOM-Agent an einer verwaisten, oder falschen Management Group hängt, kann er lokal umkonfiguriert werden. Dazu das MSI-Programm MOMAgent.msi, meist unter C:\Programme\SCOM\, in folgenden zwei Schritten ausführen.

a) Hinzufügen der neuen Management Group

msiexec /i C:\Programme\SCOM\MOMAgent.msi /norestart /qn /l*v %temp%\MOMAgentAdd.log MANAGEMENT_GROUP=NEW_SCOM_MANAGEMENT_GROUP MANAGEMENT_GROUP_OPERATION=AddConfigGroup MANAGEMENT_SERVER_DNS=SRV_MY_SCOMSRV.DOMAIN.DE REINSTALL=ALL

b) Entfernen der nicht mehr notwendigen Management Group

msiexec /i C:\Programme\SCOM\MOMAgent.msi /norestart /qn /l*v %temp%\MOMAgentRemove.log MANAGEMENT_GROUP=OLD_SCOM_MANAGEMENT_GROUP MANAGEMENT_GROUP_OPERATION=RemoveConfigGroup MANAGEMENT_SERVER_DNS=OLD_SCOMSRV.DOMAIN.DE REINSTALL=ALL

Nach der Ausführung dieser zwei Programme, wird sich der gestartete Agent an die neue SCOM-Management Gruppe binden. In den meisten Umgebungen unter der Pending List zu finden, wenn kein anderes Verfahren konfiguriert ist. Aus der Pending List muss der Agent aproved / zugelassen werden. Wer nur Schritt b), das Entfernen der alten Management Group durchführt, wird den Agenten damit deinstallieren.

mehr zu diesem Thema unter:
http://technet.microsoft.com/en-us/library/ee424297.aspx
http://technet.microsoft.com/en-us/library/cc180985.aspx