Gadget Competition 2007 Friday, August 31, 2007 5:05 PM Toni Pohl Seit heute sind unsere beiden Windows Vista Sidebar Gadgets "Ask LEO" und "Passwort-Generator" auf http://www.gadgetcompetition.at/ online! Kaum gestartet, hat sich "Ask LEO" bereits auf den derzeitigen Rang 2 gehievt! Wir freun uns! Download und Beschreibung direkt hier: Ask LEO: http://www.gadgetcompetition.at/at/de/GadgetDetail.aspx?g=7129366b-bc10-418f-8063-b1dcb6af06a6Pwd-Gen: http://www.gadgetcompetition.at/at/de/GadgetDetail.aspx?g=304351c3-1eff-4f1e-b9cb-0ff58aba94be Wir freun uns aufs Mit-Abstimmen und wenn Sie unsere Gadgets anschaun und einsetzen! General | Tools Mediumlink | Permalink | Comments (2) | Post RSS mehr
Code selbst signieren - Teil 2 (Das Zertifikat) Tuesday, August 28, 2007 8:05 AM Toni Pohl In Teil Eins wurde ein Sidebar Gadget als Vorbereitung für das Signieren vom simplen ZIP-Format in eine CAB-Datei gepackt. Teil Zwei beschreibt nun, wie Sie (beliebigen) Programmcode selbst mit einem Zertifikat versehen können. Nun, haben Sie ein eigenes digitales Zertifikat? Wenn ja: fein. Wenn nein: auch gut. Dann erstellen wir uns einfach ein eigenes Zertifikat! Variante 1: Selbsterstelltes Zertifikat erzeugen und verwenden Wir benötigen das Tool makercert. Das Tools ist Bestandteil von Microsoft Visual Studio 2005 Platform SDK und im Verzeichnis C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin zu finden. Makecert erstellt ein X.509-Zertifikat mit öffentlichem und privatem Schlüssel - allerdings nur zu Testzwecken. Innerhalb Ihrer Firma wäre das aber wahrscheinlich schon ausreichend. Wenn Sie kein Visual Studio 2005 installiert haben, können Sie alternativ das Microsoft® .NET Framework Software Development Kit (SDK) version 1.1 herunterladen und das Tool von hier verwenden (Hinweis: im Internet Explorer Administration Kit Download sind diese Tools _nicht_ mehr vorhanden). cd C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin makecert -sv "C:\Projekte\VistaGadgets\Deploy\pwdgen.pvk" -n "CN=www.atwork.at" C:\Projekte\VistaGadgets\Deploy\pwdgen.cer Passen Sie Pfad und Dateiname sowie den common name an. Damit werden der öffentliche Schlüssel .cer und der private Schlüssel .pvk erzeugt. Diese werden später benötigt. Variante 2: Eigenes öffentliches Zertifikat verwenden Wenn Sie - so wie ich - ein digitales Zertfikat besitzen, bereiten Sie Ihre Hardware vor (in meinem Fall ein persönliches Zertifikat von a-trust: USB-Kartenleser anschließen, Chipkarte einlegen, a.sign-Client _nicht_ öffnen weil sonst das Kartensystem in Verbindung mit dem folgenden, gleichzeitigen Zugriff verwirrt ist... etc). Weiter mit dem Signieren... Benötigt wird signtool.exe (welches ab 2003 die Vorgängerversion signcode.exe ersetzt), ebenfalls aus dem Microsoft Visual Studio 2005 Platform SDK. cd C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin signtool signwizard Nach Willkommen-Dialog und Auswahl des zu signierenden Programmfiles (in unserem Beispiel: C:\Projekte\VistaGadgets\Deploy\pwdgen.gadget = die erstellte CAB-Datei). Wählen Sie Benutzerdefiniert. Wählen Sie bei eigenem Zertifikat "Aus Speicher wählen" - soferne Sie ihr Zertifikat bereits einmal zum Zertifikatspeicher hinzugefügt haben - was empfehlenswert ist :-) Wenn Sie zuvor mit makecert ein eigenes (Test-)Zertifikat erstellt haben, verwenden Sie "Aus Datei wählen" und geben in den folgenden Schritten die Dateien .cer und .pvk an! Wählen Sie dann "Priv. Schlüssel auf Datenträger". Wählen Sie das Zertifikat. Nun weiter. Bestätigen Sie mit Weiter. Auswahl der Verschlüsselung - wahlweise. Und weiter. Eingabe der eigenen Informationen. Wenn gewünscht, einen Timestamp zum Zeitpunkt der Signierung hinzufügen, z.B.: http://timestamp.verisign.com/scripts/timstamp.dll Und Fertigstellen. Das war das SignTool. Wenn Sie das Zertifikat auf einen Kartenleser haben, folgt nun die Eingabe der PIN. Und wenn alles ok gegangen ist die Erfolgsmeldung. Das wars! Die signierte Datei pwdgen.gadget sollte nun um ein paar KB größer als zuvor sein. Kontrollieren Sie die Datei-Eigenschaften - hier findet sich nun eine neue Registerkarte "Digitale Signatur". Schaut soweit gut aus. Nun die Kontrolle: Starten der Anwendung - in unserem Fall mit Doppelklick auf pwdgen.gadget: Die zu installierende Software besitzt nun einen Herausgeber und einen Vertrauensgrad - in meinem Fall leider "nur" gelb, da a-trust anscheinend standardmäßig leider nicht von Root weg vertraut wird. Grün wirds, wenn der ganzen Vertrauenskette vertraut wird. Damit ist sichergestellt, dass die Anwendung vom angegebenen Hersteller stammt und unverändert ist. Anwender erhalten somit Sicherheit über die zu installierende Software - zum Beispiel, dass sie von der eigenen IT ausgerollt und geprüft wurde. Es gibt natürlich weitere Methoden, Software selbst zu signieren. Mit SignTool und dem eingebauten Wizard ist dies allerdings recht einfach und zweckmäßig. ...Nie wieder Software von unbekannten Herausgebern installieren! :-) Beitrag von Toni Pohl Developer | Security | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
Surface - Technische Gedanken zu einem angeblich untechnischen Produkt Monday, August 27, 2007 11:48 PM Martina Grom Letzten Samstag war ich auf einer Flughafenbesichtigung - dankenswerterweise habe ich bei einem Gewinnspiel etwas gewonnen: ein Vormittag Flughafen Wien mit Besichtigung des Towers, einer Flughafenrundfahrt und Besuch bei der Feuerwehr (und den Feuerwehrmännern). Zum Abschluss waren wir noch im Visit Air Center. Was das alles mit dem Technet Blog zu tun hat? Nun ja, jetzt kommts: das Visitair Center ist neu ausgestattet. Touchscreens, Kopfhörer, Bildschirme und vieles mehr. Unter anderem gibt es da auch einen Präsentationstisch (ok, er ist sehr groß), auf dem man Magnetkarten ablegt und dann an den dafür definierten Punkten weitere Infos erhält - Zum Flughafen, zur Geschichte, etc. etc. Klingelts? Tisch - Informationen - Surface! Nicht alle meiner Kollegen sind der Meinung, dass Surface für Techniker interessant sein könnte. Tja, mag schon sein. Andererseits - welche Anwendungsgebiete hätten wir alle mit Surface? Der Flughafen hat es mir eindrucksvoll gezeigt - die haben ein Surface quasi nachgebaut. Für mich ist es definitiv interessant: durch meinen Focus auf Onlinelösungen und deren einfache Anwendung sind Kiosksysteme und solche Präsentationsflächen immer eine tolle Sache: durch einfache Berührungen werden Befehle ausgeführt, Bilder gezeigt, Daten synchronisiert, Präsentationen gezeigt, Kartenspiele aufgerufen, Tischrechnungen aktiviert, Musikdateien abgerufen, Oberflächen grafisch illustriert, Pläne veranschaulicht, Zeichnungen entworfen, Gesellschaftsspiele abgerufen, Hotels gesucht, Barrierefreiheit erzeugt.... nahezu unendlich, was es da für Möglichkeiten geben wird. Video: Possibilities of Microsoft Surface Ich jedenfalls bin jetzt schon ein Fan davon. ;-) Aber natürlich auch die technischen Details sind zu liefern: Ein 30'' Schrim, eingebaut in einen Tisch. 5 Kameras. Ein Computer. KEIN Touch Screen, sondern ein Touch Interface - die Kameras zeichnen die Bewegungen am Tisch auf. Surface ist für 52 gleichzeitige Berührungen optimiert - klingt witzig - ist es auch, aber trotzdem mal kurz nachrechnen: 4 Personen mit 10 Fingern und 12 Dinge, die am Tisch liegen. Also alle Gadgets, die man so hat, alle vier Personen haben gleichzeitg Kamera, Phone und Zune am Tisch. :-) Klar, Surface hat natürlich Ethernet, Wireless und Bluetooth. Weitere Details finden sich hier. Die Kollegen vom readyblogAustria haben auch schon darüber berichtet und sind offensichtlich auch der Meinung, dass Surface etwas bahnbrechendes werden könnte (seien wir uns doch ehrlich: es ist NICHT bequem, ein 4x5 cm grosses Handydisplay mit dem Finger zu bedienen). Sehen Sie hier:Video: Power of Microsoft Surface Die offizielle Website zum Thema gibts auf Microsoft Surface. Viele nette Links haben die Kollegen aus der Schweiz in Ihrem Surface Artikel gesammelt, besonders erwähnenswert ist das 18 Minutige englische Video auf on10.net, wo Surface Live gezeigt wird. Beitrag von Martina Grom Microsoft | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
Code selbst signieren - Teil 1 (Beispiel: Gadgets verpacken) Monday, August 27, 2007 11:25 PM Toni Pohl Programm-Code kann selbst mit einem Zertifikat versehen werden um den Herausgeber zu verifizieren. Im ersten Teil dieses Beitrags erfahren Sie anhand eines Sidebar Gadgets, wie dieses vorbereitet werden kann und Sie erfahren Wissenswertes über die Gadget-Technologie. Viele von uns verwenden sie bereits täglich und wollen sie nicht mehr missen: die Windows Vista Sidebar Gadgets. Nützliche kleine Tools, um rasch Informationen in den verschiedensten Bereichen zu erhalten, sei es den Wetterbericht, Aktienkurse, die Rechnerauslastung, Outlook-Infos oder RSS-Feeds. Sidebare Gadgets können relativ einfach erstellt werden und sind in Wahrheit nichts anderes als gezippte Dateien mit der Endung .gadget. (Probieren Sie es aus: Benennen Sie eine heruntergeladene Datei von .gadget in .zip um und entpacken Sie das Zip - voila.)Beim Ausführen einer *.gadget-Datei wird diese in das eigene Application Directory entpackt: C:\Users\<username>\AppData\Local\Microsoft\Windows Sidebar\Gadgets\<gadgetname> Eine Manifest-Datei gadget.xml beschreibt das Gadget, die Funktionalität besteht im Wesentlichen meist aus HTML-Seiten, Javascript und einigen Images. Soweit so gut. Die meisten Gadgets besitzen allerdings keinen Hinweis über den Herausgeber der Software - smybolisiert mit dem roten Schild. Ist ein zu installierendes Gadget wirklich vertrauenswürdig? Wer hat es programmiert und wie können wir sicherstellen, dass es sich um nicht um schädlichen Code handelt? Nun, zu schädlichem Code muss gesagt werden, dass Gadgets in einem eigenen geschützten Bereich laufen und nur zu bestimmten Teilen des Rechners Zugriff erhalten - hier besteht im Regelfall keine Sorge, dass ein Gadget wirklich "Böses" ausführen kann - dennoch sollten Entwickler einige Richtlinien beachten. Wir gehen davon aus, dass Sie den Code, welchen Sie verteilen wollen, sicher ist. :-) Aber wie kann nun die Installationsquelle "sicher" gemacht werden, damit die Anwender auf die Identität des Herausgebers vertrauen können? Wenn Sie Entwickler eines Gadgets oder IT-Pro mit dem Ziel einer sicheren Verteilung sind, benötigen Sie ein Zertifikat. Keine Sorge, wenn Sie kein "offizielles" Zertifikat besitzen, das können Sie sich auch einfach selbst erstellen. Gadgets werden im Regelfall als einfache Zip-Dateien geliefert. Schritt eins ist, statt eines Zip-Files ein .CAB-File (=Microsoft Cabinet File, ein gepacktes Archiv zur Software-Verteilung) zu erstellen. Warum? Weil .CAB-Dateien signiert werden können! Dazu benötigen wir das Microsoft Cabinet Software Development Kit. Ein Hinweis, worüber auch ich anfangs gestolpert bin: CAB-Dateien können nicht mit Visual Studio erzeugt werden, weil Visual Studio in CAB-Projekten keine Verzeichnisstruktur speichern kann - diese wird für Gadgets aber benötigt. Daher empfiehlt sich der Einsatz des Microsoft Cabinet SDK! Laden Sie Cabsdk.exe herunter und entpacken diese Datei in ein temporäres Verzeichnis. Die extrahierten Dateien werden in einen allgemeinen Folder kopiert, damit die Tools im PATH gefunden werden können (wenn Sie Visual Studio 2005 installiert haben, empfiehlt sich das Verzeichnis C:\Program Files\Microsoft Visual Studio 8\VC\bin). Nun das Visual Studio 2005 Command Prompt starten und in das Verzeichnis des Gadgets navigieren. Nun wird das Gadget in eine neue .CAB-Datei gepackt: cabarc -p -r N pwdgen.gadget * Ersetzen Sie "pwdgen.gadget" durch den gewünschten Gadget-Namen.-p behält die Verzeichnis-Struktur, -r steht für rekursiv und N für ein neues Archiv. Als Ergebnis erhalten Sie eine neue Datei pwdgen.gadget. Es handelt sich hierbei um eine gepackte Datei vom Typ CAB, welche signiert werden kann - aber nicht muss. Das Gadget kann nun (genauso wie auch .gadgets vom Typ Zip) verteilt werden. Damit wäre der erste Schritt - das Packen des Gadgets - erfüllt. In Teil Zwei sehen wir uns an, wie wir das CAB-Gadget (oder beliebigen anderen Code) mit einem eigenen Zertifikat versehen können! Beitrag von Toni Pohl Developer | Security | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
Wsusutil.exe - den WSUS in Schuss halten Saturday, August 18, 2007 2:54 PM Martina Grom Man kann es gar nicht oft genug sagen: haltet Eure Systeme fit, haltet Eure Systeme gepatcht, spielt Updates regelmässig ein, etc. etc. Viele werden das jetzt belächeln und als alten Hut abwinken, leider komme ich aber immer wieder zu Kunden, die Ihre Systeme nach wie vor nicht patchen, bzw. vom WSUS (Windows Server Update Services) noch nie gehört haben. Dabei ist es damit so einfach, ganze Netzwerke zu aktualisieren - ohne Administration per Pedes. Wer allerdings mit dem WSUS arbeitet, wird ihn nicht mehr missen möchten. Wenn da nicht die sache mit dem vielen Speicherplatz wäre. Update für Update wird geladen, da kommen schon etliche GBytes zusammen. Und so mancher Festplattenplatz, der eigentlich reichen müsste, wir immer enger und enger. Das passiert vor allem dann, wenn man mehrere Sprachen bzw. viele Programme synchrnisiert - WSUS hält ja mittlerweile nicht mehr nur Betriebssysteme, sondern auch Office, Visual Studio, SQL Server, etc. etc. am aktuellen (Update-)Stand. Um den WSUS zu optimieren, gibt es das Tool wsusutil.exe, das bei jeder WSUS Installation mit dabei ist. Mit diesem Tool gibt es einige Einstellungsmöglichkeiten: WSUSUtil.exe exportWSUSUtil.exe importWSUSUtil.exe migratesusWSUSUtil.exe movecontentWSUSUtil.exe resetWSUSUtil.exe deleteunneededrevisionsWSUSUtil.exe listinactiveapprovalsWSUSUtil.exe removeinactiveapprovals Was die einzelnen Befehle tun, können Sie hier in der englischen Technet nachlesen. Sollte man den WSUS etwas verkleinern wollen, hilft: WSUSUtil.exe deleteunneededrevisions Dieser Befehl macht gleich mal einige GB Platz auf einem Laufwerk - oft schon ausreichend, um einfach wieder mehr Platz zu haben. Wichtig vor dem Ausführen ist: den WSUS im IIS beenden! Ich habe mir dazu eine kleine Batchdatei angelegt, da wir mehrere WSUSe verwalten und dies ab und zu ausführen: cd [Systemlaufwerk]:\[Programmverzeichnis]\Update Services\ToolsWSUSUtil.exe deleteunneededrevisions pause Tja, aber was, wenn dieser Eingriff doch nicht mehr ausreicht? Dann kommt movecontent zum Einsatz, wo mit einem Befehl die Content-Files des WSUS verschoben werden - auf eine - hoffentlich - größere Festplatte oder ein größeres Laufwerk. Die Syntax von movecontent lautet: wsusutil movecontent contentpath logfile -skipcopy Für eine Batchdatei: cd [Systemlaufwerk]:\[Programmverzeichnis]\Update Services\Tools WSUSUtil.exe movecontent [Laufwerk]:\[Name des ordners, wo hinverschoben werden soll]\ [Laufwerk]:\[Verzeichnisname]\logfilename.log pause Das Zielverzeichnis muss in NTFS formatiert sein. Der Vorgang kann schon eine Weile dauern, also bitte um Geduld! Nach dem erfolgreichen Verschieben sollte das Logfile so aussehen: 2007-08-18T11:52:42 Successfully stopped WsusService.2007-08-18T11:52:42 Beginning content file location change to e:\WsusContent\2007-08-18T12:27:43 Successfully copied content files.2007-08-18T12:27:43 Successfully changed WUS configuration.2007-08-18T12:27:45 Successfully changed IIS virtual directory path.2007-08-18T12:27:45 Successfully changed registry value for content store directory.2007-08-18T12:27:45 Successfully changed content file location.2007-08-18T12:27:47 Successfully started WsusService.2007-08-18T12:27:47 Content integrity check and repair...2007-08-18T12:27:47 Initiated content integrity check and repair. Tja, den alten Content: den müssen Sie dann von Hand löschen.... Übrigens: den WSUS gibt es jetzt bereits in der Version 3.0. Mehr darüber in einem späteren Beitrag. ;-) Wer ihn _wirklich_ noch nicht kennt, hier ein paar Links: Microsoft Windows Server Update Services Erste Schritte mit WSUS Patch Management, das neue Maßstäbe setzt Webcast zu WSUS Beitrag von Martina Grom Microsoft | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
Das Zertifikat ist abgelaufen! - Das Zertifikat ist abgelaufen? Friday, August 17, 2007 2:00 PM Martina Grom Wer kennt es nicht: gaaanz dringend noch eine Kleinigkeit im System machen - schnell remote anmelden, alles erledigen, fertig. Denkste. Schadenfroh meldet sich ein abgelaufenes Zertifikat, welches die Verbindung sicherstellt - tja, das wars dann wohl mit "ich brauche nur noch 5 Minuten". Um solche unliebsamen Dinge zu vermeiden, hat Microsoft jetzt seine PKI-Dienste mit einem Tool aufgewertet: Identity Lifecycle Manager (ILM). Zertifikatverwaltung, Identitätsbereitsstellung und die Verwaltungsfunktionen des Identity Integration Servers werden in diesem Produkt vereint. Der ILM-CM Manager (in Langform: Identity Lifecycle Manager Certificate Management) erfordert für die Installation SQL Server und Active Directory. Die Installation erfolgt Assistenten-gestützt - mit einigen Vorbereitungsschritten: Schemaerweiterung .net Framework 2.0 SQL Server IIS SMTP ... Die Verwaltung erfolgt danach über eine Weboberfläche. Eine tolle Anleitung und Kurzvorstellung des Tools finden Sie hier: Ein leistungsfähiges neues Tool für die Zertifikatsverwaltung Englische Produktinfoseite Englische Technet Infos Weitere Infos zur Identitätsverwaltung:Englische Identity Solution Seite MIIS Ressource Tool Kit Erstellen eines einstufigen Bereitstellungsworkflows Identitäts- und Zugriffsverwaltung: Einfacheres einmaliges Anmelden mittels ADFS Beitrag von Martina Grom Microsoft | Security | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
MMPC = Mehr zum Thema Sicherheit Thursday, August 16, 2007 10:25 PM Toni Pohl Es gibt Themen, da können IT-Pros gar nicht gut genug informiert werden. Dazu gehört zweifelsohne das Thema Sicherheit. Oft wissen IT-Abteilungen erst nach Attacken, Hacks und Missbrauch, wie sie auf solche Vorfälle reagieren können und versuchen nachher, Löcher zu stopfen und ihre Infrastruktur sicherer zu machen. Genau diesem Thema nimmt sich Microsoft mit einem neuen Online-Werkzeug an: Microsoft Malware Protection Center (MMPC). Das MMPC ist ein Web-Portal, welches über "Threat Research and Response" (also Bedrohung, Analyse und Reaktion) informiert und es sich zum Ziel macht, die eigene IT vorher zu überprüfen, und Schwachstellen und Störungen zu minimieren. Das Portal zeigt die aktuellsten und häufigsten Bedrohungen in den verschiedenen Bereichen wie Desktop, E-Mail, Adware/Spyware. Ein durchsuchbares Lexikon liefert Informationen über Viren und Exploits. So bringt die Suche nach "pdf attachment" über das derzeit recht aktuelle Spaming mit PDF-Dateien 434 Ergebnisse und auch brauchbare Hinweise, wie die Schädlinge in den einzelnen Antivirus-Programmen heißen, beispielsweise: Win32/BagzWORM_BAGZ.GEN (Trend Micro) W32/Bagz.gen@MM (McAfee) W32.Bagz@mm (Symantec) Vom MMPC können auch die aktuellsten Updates (Latest Definition Updates) für Windows Defender und Microsoft Forefront Client Security downgeloadet werden. Im Tools-Bereich sind Programme verlinkt sowie Links zu Security-Blogs: Vom kostenlosen Windows Defender bis hin zum umfassenden Schutz mit Microsoft Forefront. Es können auch verdächtige oder infizierte Files (bis 10MB) an Microsoft zur Untersuchung gesendet werden - nun kann man Viren an Microsoft schicken! :-) Das Portal präsentiert sich zeitgemäß und funktionell. Ein Link führt direkt zum Microsoft Security Intelligence Report (der Report Juli bis Dezember 2006 ist übrigens wirklich interessant und hier ladbar). Unsere Kollegen vom Ready Blog Austria haben auch bereits Ende Juli in ihrem Beitrag über MMPC berichtet, aber man kann Security ja bekanntlich gar nicht oft genug an den Mann bringen! Tipp: Melden Sie sich gleich für den monatlichen Security Newsletter an! Der Newsletter enthält Security Bulletins, Update-Infos, Webcasts-Links und vieles mehr zum Thema Sicherheit. Den letzten Newsletter können Sie übrigens hier online ansehen. MMPC ist ein guter Start, sich intensiver mit dem Thema Sicherheit in Ihrer IT-Infrstruktur zu befassen und bietet dazu eine Fülle an Links und Informationen. Auf Ihre sichere IT! Beitrag von Toni Pohl Microsoft | Security | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
HowTo Script in PowerShell Wednesday, August 8, 2007 1:40 AM Toni Pohl Langsam wird die neue PowerShell immer populärer. Im Windows Server 2008 ist die PowerShell bereits in der Evaluation Version inkludiert. Für alle anderen Windows Betriebssysteme muss die PowerShell 1.0 heruntergeladen und installiert werden (Voraussetzung ist nur das Vorhandensein des .NET Framework 2.0). Seit Ende Jänner ist die finale Version verfügbar, nun gibt es seit dem 31. Juli für die Benutzer der MUI Versionen von Windows XP und Windows Server 2003 eine PowerShell Version für x86, x64 und Server IA64 hier zu laden. (Hinweis: Die MUI Language Packs laufen nur unter den MUI Versionen von Windows. Zuerst muss die englische Version der PowerShell 1.0 installiert werden und danach das Language Pack for Windows PowerShell 1.0.) Die PowerShell arbeitet vollständig objektorientiert. Wie bei anderen Shells gibt es eine Pipeline, in der Ergebnisse von Befehlen an andere Kommandos weitergegeben und weiterverarbeitet werden können. Für alle jene, die sich die PowerShell noch nicht angesehen haben und einmal selbst drauflosprobieren wollen hier eine Quick-Start-Anleitung für das schnelle Erfolgserlebnis. Nach dem Download erfolgt die Installation zügig: Der Aufruf der PowerShell erfolgt einfach über den Pearl-Button und Aufruf der PowerShell (C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe): Und schon geht´s los mit einfachen Kommandos: get-process Die PowerShell besitzt vielleicht den Charme der Eingabeaufforderung, bietet unter der Haube aber ein völlig neues Konzept der Administration von Windows-Rechnern und eine neue, zusätzliche Plattform der Automation. Beim Aufruf von Scripts lauert ein Stolperstein: Das gewohnte Ausführen von Scripts mit der Erweiterung .ps1 öffnet bei Ausführung das Script im Notepad und startet nicht (wie vielleicht von Windows Scripting Host gewohnt) das Script! Als Abhilfe hier nun die Schnellanleitung zum Handling und Testen eines einfachen Scripts in der PowerShell: Zuerst wird (außerhalb der PowerShell) ein neues Textfile mit Notepad mit einer Zeile (zur Anzeige der Betriebssystem-Version mit gwmi win32_operatingsystem) erstellt: Das File wird in C:\Script\test1.ps1 gespeichert. Nun, wie wechselt man (in der PowerShell) das Verzeichnis? cd C:\Scriptdir Microsoft hat übrigens auch Altbewährtes - Flashback! ;-) - aus einer anderen Welt übernommen: pwd, chdir, ls, ... Logisch erscheint, nun einfach das Script test1.ps1 aufzurufen... Das klappt aber so noch nicht. Warum? Die PowerShell verwendet eine "excution policy", welche verhindert, dass nicht signierte Scripts aufgerufen werden (versuchen Sie mal Get-ExecutionPolicy um anzusehen welche Policy eingestellt ist oder Get-Help About_Signing). Das bedeutet, wir stellen mal die Policy auf "RemoteSigned" ein: Set-ExecutionPolicy RemoteSigned Neuerlicher Aufruf von test1.ps1... es klappt noch immer nicht. Durch das Ändern der Policy ist es möglich, Scripts aufzurufen. Allerdings - obwohl wir uns im richtigen Verzeichnis befinden - behandelt die PowerShell Pfade anders als gewohnt. Das bedeutet, es muss immer der Pfad zum Script mit angegeben werden: C:\Script\test1.ps1 (oder kürzer mit ".\":) .\test1.ps1 Nun funktioniert der Aufruf! Wenn C:\Script im PATH vorhanden ist, kann die Pfadangabe entfallen. Um den aktuellen PATH auszugeben, verwenden Sie beispielsweise $env:path und zerlegen diesen mit Split(";") nach dem Trennzeichen ";" in einzelne Elemente:$a = $env:path; $a.Split(";") Hinweis: $-Zeichen definieren übrigens Variablen. D.h. $a wird der Environment-Variable zugewiesen und gibt im zweiten Teil die Variable aus. Nachdem es sich um .net Objekte handelt, sind deren Eigenschaften und Methoden (wie hier .Split verwendbar). Dies ist auch die Stärke der PowerShell, dass fast alle .net-Objekte verwendbar und "pipe-able" (weiterverwendbar) sind. Um dem PATH eigene Verzeichnisse hinzuzufügen verwenden Sie:$env:path = $env:path + ";c:\scripts" Achja noch ein Tipp: Bei Script-Aufrufen in Pfaden mit Leerzeichen muss der Pfad - wie gewohnt - in "C:\Mein Script\test1.ps1" eingefasst werden UND dieser "String" mit dem & - Zeichen als Call-Operator aufgerufen werden: & "C:\Mein Script\test1.ps1" Und wie kann man nun ein PowerShell-Script außerhalb der PowerShell aufrufen? Die Lösung ist einfach: Aufrufen der PowerShell mit dem Script (und der optionalen Anweisung -noexit, damit die PowerShell geöffnet bleibt): powershell.exe -noexit c:\script\test1.ps1 Das wars! Mit diesem Handwerkszeug steht die Basis zum Experimentieren mit PowerShell Scripts bereit und die Fülle an bereits verfügbaren Scripts kann getestet und angepasst werden. Das Windows PowerShell Owner's Manual liefert die ersten Informationen zur Verwendung der PowerShell, das Windows PowerShell 1.0 Documentation Pack eine Getting Started-Dokumentation. Zum Einstieg empfehle ich u.a. die Links Scripting with Windows PowerShell im Microsoft Script Center und das Blog des PowerShell Teams sowie den Download des Windows PowerShell Graphical Help File (PowerShell.chm). Es gibt auch bereits eine deutschsprachige community mit einem Angebot an News, Informationen, Blogs und Tutorials. In diesem Sinne wünsche ich viel Spaß beim Entdecken der Fähigkeiten der PowerShell und beim Scripten! Beitrag von Toni Pohl Developer | Microsoft | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
Zwei neue Tools: MSCD (CTP) und Network Monitor 3.1 Tuesday, July 31, 2007 7:51 PM Toni Pohl Sie wollen eine große Datei herunterladen und der Download bricht immer wieder ab? Abhilfe schafft der Microsoft Secure Content Downloader (MSCD) July 2007, welcher als Community Technology Preview (CTP) verfügbar ist. MSCD arbeitet im peer-to-peer Prinzip und lädt Teile des Downloads von anderen Clients und fehlende Teile vom zentralen Server. Damit wird eine wesentlich schnellere Downloadrate erreicht und MSCD kann unterbrochene Downloads fortsetzen. Die CTP ist allerdings nur für 4 Wochen lauffähig, es ist also damit zu rechnen, dass bald die finale Version verfügbar sein wird. Microsoft Network Monitor 3.1 (MN) ist ein Network Protocol Analyzer, welcher Netzwerk-Traffic mitprotokollieren und analysieren kann. Version 3.1 ist ein Update zur Version 3.0 und ersetzt die Versionen 2, ein Word Dokument beschreibt die Fixes. Microsoft Network Monitor 3.1 ist unter Windows Server 2003, Windows Server 2003 x64 Editions, Windows Vista, Windows XP und Windows XP 64-bit lauffähig. Einige Neuerungen der Version 3.1: Unterstützung von Wireless (802.11), RAS-Tracing, Filter mit rechter Maustaste, Update per WU, neue und schnellere Parser-Engines. Ein eigenes Technet-Blog informiert über weitere Fähigkeiten und How-To´s. Beitrag von Martina Grom Microsoft | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
Kill Task per Script Monday, June 18, 2007 10:00 AM Toni Pohl Für administrative Zwecke, zum Beispiel für automatisierte Backups, Scheduled Tasks o.ä. ist es manchmal erforderlich, bestimmte Applikationen per Script zu beenden. Letztlich hatte ich genau so eine Anforderung: Outlook sollte für das Backupen der OST-Datendatei geschlossen werden. Als Lösung wird ein simpler Aufruf von Windows Management Instrumentation (WMI) verwendet, welcher abfragt, ob ein Prozess mit einem bestimmten Namen läuft und diesen terminiert: ' killtask.vbs by TP' simple script for killing a proccess task.pgm = "Outlook.exe" set wmi = getobject("winmgmts:") sQuery = "select * from win32_process " &_ "where name='" & pgm & "'" set processes = wmi.execquery(sQuery) for each process in processes process.terminate next ' decomment for user info:' msgbox pgm & " closed.", vbinformation Öffnen Sie Notepad oder einen ähnlichen Texteditor, kopieren Sie das obige Script hinein, passen Sie den Applikationsnamen an (z.B. Outlook.exe) und speichern Sie das Script "killtask.vbs" ab. Dann einfach Outlook starten und mit Doppelklick ausprobieren! Hinweis: Wenn in der zu schließenden Applikation ungesicherte Dokumente geöffnet sind, sind diese durch das Beenden verloren! D.h. wenn Sie beispielsweise "Winword.exe" mit dem Script beenden und es ist ein neues oder geändertes Dokument offen, wird dieses ohne Sicherheitsabfrage geschlossen und der Inhalt ist verloren. Das war aber auch nicht Zweck dieses Scripts ;-). Interessierte finden in WMI als Bestandteil des Windows Betriebssystems eine riesige Spielwiese für allerlei brauchbare Automatisierungen. Viele interessante Scripts und Informationen finden sich u.a. im Script Center. PS: Ein ganz heißes Nachfolge-Thema für Scripting und Automatismen ist die Microsoft Powershell! Viel Spaß beim Scripten! Beitrag von Toni Pohl Developer | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr