Wir sind TechNet auf Facebook TechNet News App für Windows TechNet Austria auf Twitter Georg Binder auf Twitter Gerhard Göschl auf Twitter Martina Grom auf Twitter Toni Pohl auf Twitter
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
Mark Russinovich (Sysinternals) ist mitunter auch so etwas wie ein Sherlock Holmes. In seinem Blog berichtet er von einem Problem mit der "Senden an Zip-komprimierten Ordner" Funktion. Das spannende dabei ist weniger, dass er den Fehler hat, sondern wie er mit Werkzeugen auf die tatsächliche Ursache des Problems stößt. Hier die Übersetzung seines Originalartikels.
Eines Tages hat Bryce versucht, mittels der Explorer Funktion Senden an --> ZIP-komprimierten Ordner die aktuellsten Process Monitor Source Code Updates an mich zu senden.
Anstatt dass der Dialog erscheint, mit Fortschrittsbalken und anschließender Möglichkeit einen Dateinamen Namen zu vergeben, hat der Explorer mit folgender Meldung abgebrochen:
Bryce war verwirrt. Der Fehler schien keinen Sinn zu ergeben, denn er hatte ja Lesebeechtigung auf den ausgewählten Dateien, die er zudem ja gerade editiert hatte. Und die Komprimierung sollte ja auch auch nicht in einer gescheiterten Suche enden,... dennoch auch wiederholte Versuche halfen nicht, selber Fehler, wenngleich diesmal nach einer anderen Anzahl von Dateien, die gepackt wurden.
Der Zufall wollte es, dass ich in diesem Moment gerade zu Bryce ins Zimmer kam und er konnte mir so das Verhalten gleich noch ein paar Mal zeigen. Nun waren wir beide perplex. Zeit für eine Untersuchung! Ironischerweise war das geeignete Werzeug dafür... der nicht-packbare Process Monitor.
Wir starteten den Process Monior, haben den Fehler reproduziert, stoppten den Capture und durchsuchten dann die tausenden Operationen im Trace nach Fehlern. Wir stießen dabei auf riesige Mengen von "NICHT GEFUNDEN" Fehlern am Anfang des Logs, was darauf schließen läßt, dass eine Applikation vor der eigentlichen Operation das Vorhandensein einer Datei prüft. Da waren buchstäblich hunderte solcher Einträge, alle mit Verweisen auf die zu erstellende ZIP-Datei:
Das war beunruhigend, aber nicht direkt mit unserem Problem verbunden. Ich speicherte es geistig mal ab um darauf später noch zurückzukommen.
Mehrere hundert Einträge später stießen wir auf eine Zugriffsverletzung ("SHARING VIOLATION") die nach einer eingehenderen Untersuchen verlangte:
Wenn ein Prozess eine Datei öffnet kann sie festlegen ob und wie sie die Datei mit anderen Prozessen teilen will, während der Zugriff erfolgt. Drei verschiedene Typen gibt es: Lesen, Schreiben und Löschen, und jeder Typ wird mit einem Flag repräsentiert, das an die CreateFile API weitergereicht wird. In der Operation, wo der Zugriff fehlgeschalgen ist, hat der Explorer kein Flag weitergereicht, was meint, dass er nicht wollte dass die Datei mit anderen Prozessen geteilt wird, wie man im SharedMode Feld sehen kann:
Damit ein Öffnen erfolgreich ist, müsse der ShareMode des öfnnenden Prozesses kompatibel sein, mit jene, ShareMode des Prozesses, der die Datei bereits offen hat. Die Erklärung für die Zugriffsverletzung ist also, dass offenbar ein anderer Prozess die entsprechenden Flags nicht gesetzt hat.
Zurück im Trace zeigt sich, dass erst eine Öffnen Operation durch den Explorer stattfindet, direkt gefolgt von einer weiteren Öffnen-Operation - die dann scheitert. Das gescheiterte Öffnen der selben Datei erfolgt durch einen Prozess namens InoRT.exe. (Das Schließen der Datei ist im Screenshot nicht sichtbar, weil es erst lange nach dem erfolglosen Versuch des Explorers kommt, die Datei zu öffnen.) Das bestätigt, dass der Explorer unwillig ist, die Datei nicht-exklusiv zu öffnen, obwohl InoRT bei seinem Öffnen der Datei sehr wohl die Öffnen, Lesen und Löschen Flags gesetzt hat.
Process Monitor erwies sich auch weiter hilfreich: InoRT.exe hält die Datei offen, wenn dann der Explorer sie versucht zu öffnen, kommt es zu der Zugriffsverletzung und damit zu der mißverständlichen Fehlermeldung. Nächster Schritt war also zu identifizieren, wer/was/wie InoRT ist, damit wir mit einer Lösung oder einem Workaround weiterkommen. Process Monitor beantwortete auch das mit dem Tooltip.
eTrust, der Antivirus Scanner von Computer Associates, öffnete offensichtlich die Datei um sie nach Viren zu durchsuchen, funkte da aber dem Explorer dazwischen. Eigentlich sollte ein Virenscanner für das System unsichtbar agieren, also handelte es sich hierbei um einen Bug von eTrust. Der Workaround für Bryce war das setzen eines Verzeichnis Filters, dass das Quellverzeichnis vom Real-Time Scanner des Antiviren Programms ausgeschlossen hat.
Ich konnte den Fehler nicht nachstellen, als ich zurück in mein Büro kam, also vermutete ich einen Versionunterschied von InoRT bei mir bzw. Bryce. Die Event Eigenschaften der Process Seite von Process Monitor zeigen für das Inort.exe Ereignis dass Bryce die Version 7.01.0192.0001 hatte, während bei mir die aktuellere 7.01.0501.0000 lief.
Warum wir verschiendene Versionen hatten, ist nicht ganz klar, da beide ausgerollten Images von der Microsoft IT gemanaged werden, aber offenbar hat Computer Associates den Bug in neueren Releases gefixt.
Nun wendete ich meine Aufmerksamkeit wieder dem ineffizienten Pack-Features des Explorers zu. Ich zeichnete mit Process Explorer einen Trace auf, wo ich genau eine einzige Datei packte und zählte die damit verbundenen Operationen. Alleine in diesem simplen Fall konnte ich feststellen, dass der Explorer das Ziel-ZIP 14 mal öffnete, davon 12 mal BEVOR die Datei überhaupt erstellt worden ist - deshalb auch die NOT FOUND Ergebnisse. Daneben zählte ich noch 19 Directory Lookups. Genauso mit dem Quellfile: 28x geöffnet, die Eigenschaften wurden 17x abgerufen. eTrust hatte also genug Möglichkeiten dem Explorer reinzufunken um die Zugriffsverletzung auszulösen.
Um auch wirklich nachzuweisen, dass der Explorere selbt an dem Fehler schuld war, und nicht irgendeine Dritthersteller-Erweiterung, schaute ich in die Stacks der einzelnen Events hinein und drückte Strg+K um den Eigenschaften Dialog aufzurufen:
Zipfldr.dll, das ist die Explorer DLL für die Kompression, war in den meisten Stack Traces, das heißt, dass sie für die Verschwendung hauptverantwortlich war. Mehr noch: die Zahl an sich wiederholenden Zugriffen explodiert geradezu, wenn man mehrere Dateien komprimiert. Hier gibt es offensichtlich einige Wege den Algorithmus zu optimieren, hoffentlich sehen wir in Windows 7 eine effizientere Kompressions-Engine.
Update: Ich habe mittlerweile erfahren, dass die Kompressions-Engine in Vista SP1 einer Aktualisierung unterzogen worden ist, demnach wird sie dann weniger Datei Operationen durchführen.
Download: Process Monitor
Übersetzung / Beitrag von Georg Binder
Mittlerweile sind ganz schön viele Virtuelle Hard Disks (VHD) für den Einsatz in Virtual PC 2007 oder Virtual Server 2005 R2 verfügbar. Damit läßt sich schnell & schmerzlos (keine Installation, fertig konfiguriert) und kostenlos in ein Produkt hineinschnuppern, eine Produktdemonstration, oder ähnliches machen.
Gefunden bei TechNet VHD Downloads, Idee von Kay Giza.
Beitrag von Georg Binder.
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:
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
Unlängst hatte ich während einer Umstellung von Exchange 2003 auf Exchange 2007 Probleme mit dem Email Routing, welche für mich auf den ersten Blick nicht unbedingt ersichtlich waren. Nach einiger Forschungsarbeit und einigen Versuchen habe ich auch eine Lösung für dieses Problem gefunden. Meine Erkenntnisse möchte ich hier nun zusammenfassen.
Bei größeren Organisationen kommt es vor, dass nicht sämtliche Benutzer Exchange als Mail System benutzen. Dies bedeutet, dass mehrere, teils völlig unterschiedliche Mailsysteme zum Einsatz kommen und somit der Exchange Server diese SMTP Domänen als nicht autorisierend behandeln muss. Die Konfiguration ist in keiner der beiden Exchange Versionen ein Problem und ist weiter unten beschrieben. Ein Problem entsteht jedoch, wenn während des Parallelbetriebs eine neue Email-Adressen-Richtlinie für eine nicht autorisierende SMTP Domäne unter Exchange 2007 erstellt wird. Alle Benutzer mit Legacy Postfächern (Benutzer am Exchange 2003) können von nun an keine Emails an Benutzer senden, welche nicht im Active Directory definiert sind. Exchange 2003 weiß einfach nichts von diesen fremden Mailsystemen. Dieses Problem tritt nicht auf, wenn vorhandene Empängerrichtlinien über die Verwaltungsshell aktualisiert werden. Und dass neue Richtlinien erstellt werden ist ein durchaus denkbarer Weg, da Exchange 2007 die Richtlinien in jedem Fall anwendet und die Struktur und Konfiguration daher wesentlich besser durchdacht sein müssen als es unter Exchange 2003 notwendig war.
Unter Exchange 2003 ist es prinzipiell auf zwei Arten möglich, eine Email Domäne mit einem fremden Mailsystem zu teilen. Der nicht empfohlene Weg ist die direkte Konfiguration am smtp Service mit der Einstellung "Alle E-Mails mit nicht ausgewerteten Empfängern weiterleiten an Host". Da diese Einstellung keine Rücksicht auf den Domänennamen nimmt und somit sämtliche Möglichkeiten der feineren Konfiguration wegfallen, sollte dieser Punkt nicht verwendet werden und nur in Speziallfällen Anwendung finden. Die zweite Möglichkeit ist die Konfiguration über die Empfängerrichtlinien. Dies ist auch logisch der richtige Ort dies zu konfigurieren, da ja auch hier allgemein die empfangbaren EMail Domänen konfiguriert werden. Bei der Definition der SMTP-Adressen findet sich hier die Checkbox: "Diese Exchange-Organisation ist für die gesamte E-Mail-Übermittlung an diese Adresse verantwortlich". Ist diese Checkbox aktiv (default) so erzeugt Exchange für nicht auflösbare Adressen eine Unzustellbarkeitsnachricht. Ist sie nicht aktiv so versucht das Exchange Routingmodul im Falle einer nicht auflösbaren Adresse die Zustellung über einen Connector. Entweder über die normalen MX Einträge im DNS oder, sofern vorhanden, über einen entsprechenden Connector für diese Domäne.
Unter Exchange 2007 wurden die gültigen SMTP Domänen von den Empfängerrichtlinien (E-Mail-Adressenrichtlinien) getrennt und sind somit seperat zu konfigurieren. SMTP Domänen werden nun unter Organisationskonfiguration->Hub-Transport->Akzeptierte Domänen eingetragen bzw. in der Shell mit New-AcceptedDomain erstellt. Hier gibt es auch die Eigenschaft DomainType welcher drei verschiedene Werte annehmen kann:
Dies bedeutet für heterogene SMTP-Domänen sind diese als Interne Relaydomäne zu konfigurieren und zusätzlich ein Sendeconnector zu konfigurieren.
Von diesen neuen Einstellungen bekommt das "alte" Exchange 2003 System natürlich nichts mit. Es kennt die Struktur der Akzeptierten Domänen nicht und auch nicht die DomainType Eigenschaft. Es beurteilt ausschließlich anhand der Empfänger Richtlinien. Eine genauere Analyse der relevanten Active Directory Objekte führte mich auf die NonAuthoritativeDomains Eigenschaft des Empfängerrichtlinien Objekts. Für jede unter Exchange 2003 erstellte SMTP Adresse wird hier der idente Wert eingetragen sobald die Checkbox für die Verantwortlichkeit deaktiviert wird. Dies bedeutet, wird zum Beispiel eine Email-Adresse %g.%s@contoso.com definiert, so wird bei deaktivierter Checkbox der Eintrag smtp:%g.%s@contoso.com ebenfalls der Eigenschaft NonAuthoritativeDomain hinzugefügt. Die Eigenschaft selbst ist als Liste definiert, kann also mehrere Einträge aufnehmen.
Werden nun bestehende Empfängerrichtlinien mit Set-EmailAddressPolicy auf 2007 aktualisiert, so bleiben diese Attribute vorhanden und werden nicht verändert. Dies bedeutet, dass die Funktionalität für Exchange 2003 voll erhalten bleibt. Als kleine Randbemerkung sei erwähnt, dass das Exchange Setup bei der Installation des ersten Exchange 2007 Servers in einer bestehenden Exchange 2003 Umgebung alle Domänen Typen für die erkannten SMTP-Domänen auf Autorisierend setzt. Anders sieht es jedoch aus, wenn eine neue Richtlinie über die Verwaltungskonsole von Exchange 2007 oder über die Shell mit New-EmailAddressPolicy erstellt wird. Hier bleibt diese Eigenschaft in jeden Fall leer. Mir ist auch keine Möglichkeit bekannt, diese Eigenschaft über die Shell zu verändern, da ein entsprechender Parameter bei Set-EmailAddressPolicy fehlt. Ein Versuch, das Objekt über die Verwaltungskonsole von Exchange 2003 zu verändern schlägt mit einer Versionsfehlermeldung fehl. Als Folge davon können Legacy Benutzer keine E-Mails an "externe" Empfänger der entsprechenden Domänen senden. Um dieses Problem zu beheben muß direkt das entsprechende Active Directory Objekt bearbeitet werden.
Ich möchte ausdrücklich darauf hinweisen, daß dieses Tool mit Vorsicht und Bedacht zu verwenden ist, da durch falsche Verwendung großer Schaden angerichtet werden kann!Die Empängerrichtlinien findet man mit adsiedit unter:Configuration->CN=Configuration, DC=(Domain)->CN=Services->CN=Microsoft Exchange->CN=(Oranisation)->CN=Recipient PoliciesIn den Eigenschaften der entsprechenden Richtlinie findet sich das entsprechende Attribut unter msExchNonAuthoritativeDomains und kann hier direkt bearbeitet werden. Die Syntax ist ident zu den Einträgen des Attributs gatewayProxy, welches die eigentlichen Emailvorlagen enthält. Im Zweifelsfall kann man sich die Attribute auch an entsprechend erstellten Testrichtlinien ansehen. Im Fall des obigen Beispiels für Contoso wäre der richtige Eintrag: smtp:%g.%s@contoso.com
Sobald dieses Attribut geändert ist reicht ein Neustart des Exchange-Routingmoduls um die Änderung wirksam zu machen.
Weitere Informationen über Empfängerrichtlinien und deren Aktualisierung finden sich unter:
Beitrag von Heinrich Pommer
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
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:
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:
MIIS Ressource Tool Kit
Erstellen eines einstufigen Bereitstellungsworkflows
Identitäts- und Zugriffsverwaltung: Einfacheres einmaliges Anmelden mittels ADFS
Passend zu meinem Artikel vom Data Protection Manager 2007 freue ich mich besonders, hier den nächsten Webcast am 30. August 2007 zu diesem spannenden Thema anzukündigen - hier geht es um den System Center Data Protection manager und seinen Einsatz in virtuellen Umgebungen.
Durch das kürzlich erschienene Servicepack 1 für Virtual Server 2005 R2, das den Virtual Server Volume Shadow Copy Service Writer einführt, ist es dem DPM nun möglich, auch die immer grösser werdende Zahl an virtuellen Umgebungen zu schützen.
Übrigens: DPM 2007 Beta Tester können jetzt auch eine XBox gewinnen. ;-)
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!
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:
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:
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!
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.