ABOUT
IN4OUT Logo
IN4OUT it solutions ist ein Dienstleistungsunternehmen
im Bereich der Informationstechnologie.
 
In diesem Blog berichten IN4OUT-Mitarbeiter über Erlebnisse und Abenteuer rund um Informatik-Probleme und -Lösungen, Web-Design und -Entwicklung, Microsoft Produkte, Social Computing sowie alles andere, was die Gedanken bewegt.

  Feed abonnieren

Symantec Endpoint Protection 11: Backup der Datenbank nicht möglich unter Windows Server 2008

by Martin Wildi 31. March 2009 15:14

Wiedereinmal ein Fall in der Kategorie "Wildi vs. UAC": Auf Windows 2008 Servern lässt sich die Symantec-Datenbank der Endpoint Protection-Lösung nicht sichern. Will man die Sicherung über das Tool "Database Back Up and Restore" sichern, erhält man folgende Fehlermeldung:

Natürlich kommt einem hier direkt die Idee "als Administrator starten", doch auch das scheint nicht zu klappen:

Nach ein paar Tests folgende Lösung:

Der Link startet ein Batchfile ("C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\bin\dbtools.bat") in welchem wiederum einige Befehle stehen:

@start "DBTools" "C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\jdk\bin\javaw.exe" -Xms256m -Xmx512m -Djava.library.path="C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\bin;C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\webapps\scm\WEB-INF\lib;C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\webapps\scm\clientpkg\ext" -Dcatalina.home="C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat" -cp inst.jar com.sygate.scm.tools.DatabaseFrame

Nun muss eine Konsole mit Administrationsrechten gestartet werden, darin in den Pfad der Endpoint-Installation gewechselt (hier "C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\bin") und das Batchfile "dbtools.bat" gestartet werden.

Wildi vs. UAC: 3:0 ;)



i4Skiweekend

by Nicole Strebel 27. March 2009 17:03

Das Team der IN4OUT hat sich für einmal ganz dem Schneesport gewidmet. In aller Herrgottsfrühe (7.20 an 'nem Samstag Yell) gings von Aarau  Richtung Baden und dann ins schöne Bünderland nach Davos. Auf dem Weg in die Berge machten wir unterwegs einen Halt und trafen uns im Heidiland mit den anderen vom IN4OUT-Team. Wir alle hatten eine sehr spirituelle und kulturelle Begegnung mit dem "Heidi" und dem "Bärli" und machten uns dann mit grossen Lachern auf in die schöne Berglandschaft

Der Höhepunkt und gleichzeitig das Ende des Tages war die wunderbar  angenehme Talabfahrt. Wink Wir waren alle schon ganz gespannt auf unser Hotel auf der Schatzalp, welches mit vielen zahlreichen historischen Geräten ausgestattet sein soll, und so machten wir uns am 16.00 auf den Weg zur Schatzalp-Bahn welche uns in die Höhe zum Hotel führte und wo wir dann die letzten Sonnenstrahlen des Tages geniessen konnten.

Der Sporttag hat hungrig gemacht und wir freuten uns alle wahnsinnig auf unser feines Abendessen mit diversen Leckereien wie Yakitori und Perlhuhn. Das Fischgericht hat bei mir allerdings irgendwie nach Mitleid gerufen. Irgendwie sah der Fisch aus wie der kleine Nemo...

Der Sonntag erwartete uns mit einem herzhaften Frühstück, aber leider nicht so schönem Wetter. Da wir Samstags auf dem Jakobshorn gefahren sind, entschieden wir uns kollektov dafür den anderen Tag ganz Parsenn zu widmen. Dort war Martin, unser Freerider, voll und ganz in seinem Element.

 

Dank des ausgiebigen Frühstücks konnten wir den Tag nutzen und hatten erst um 14.00 ein klein bisschen Hunger. Kurz nachdem wir gegessen hatten, riss die Wolkendecke wieder auf und wir hatten wieder zwei Stunden lang schönstes,herrliches Bergwetter. Um 16.00 machten wir uns wieder auf den Heimweg, wo wir den Weg bis zur Autobahn in leichtem Stau verbringen durften.  Kurz vor Zürich bahnte sich dann der grosse Stau durch die City an, wo wir von unsrem Chef gute Tipps erhielten wie man sich am Besten und Schnellsten durch die Zürcher Innenstadt drängen kann.



Logitech Setpoint nur in Chinesisch?

by Martin Wildi 25. March 2009 08:28

Da meine Maus letzthin den Geist aufgab, erhielt ich eine schöne neue Logitech MX-400. Um alle Tasten ordnungsgemäss konfigurieren zu können lud ich die SetPoint-Software (v4.72) von Logitech herunter (Windows Vista 32bit). Nach dem download führte ich die Datei unter meinem normalen Benutzer als Administrator aus (man lernt ja schliesslich dazu ;). Dann erscheint folgende Fehlermeldung:

Da ich nicht so gut Chinesisch kann, komme ich hier schonmal nicht weiter. Da ich die Software auf anderen PC's ebenfalls schon installieren wollte, dort aber einen Schritt weiter kam, meldete ich mich als Administrator an, und führe das Setup nochmals mit Administrationsrechten aus. Die Fehlermeldung kommt nicht mehr, sondern der Installationsbildschirm:

Gut. Da ich auch als Administrator kein Chinesisch kann, wende ich mich an den Support von Logitech. Dieser bestätigt mir, dass das Problem "sporadisch" auftritt (ich hatte das Problem bisher auf mehreren Windows Vista-PC's), und dass einfach "der vierte Eintrag des Dropdown-Menüs ausgewählt werden müsse". Das Dropdown sieht folgendermassen aus:

Der vierte Eintrag entspricht tatsächlich "Deutsch", "Englisch" wäre auf Position 13. Diese Nummerierung stimmt aber nur, wenn "Chinesisch vereinfacht" ausgewählt ist. Je nach Sprache ändert die Reihenfolge.

Anschliessend lässt sich SetPoint problemlos installieren.



Backup Exec Fehlermeldung "DO_NOT_REMOVE_NtFrs_ PreInstall_Directory wurde nicht gefunden"

by Martin Wildi 20. March 2009 08:36

Nachdem ein SBS 2003 SP2-Server auf den aktuellsten Stand gebracht wurde, meldet Veritas Backup Exec 9.1 bei jeder Sicherung folgenden Fehler:

Sichern - C:
Verzeichnis C:\WINDOWS\SYSVOL\sysvol\DOMAINNAME.local\DO_NOT_REMOVE_NtFrs_PreInstall_Directory wurde nicht gefunden, oder es war kein Zugriff möglich.
Im Verzeichnis befindliche Dateien oder Unterverzeichnisse werden nicht gesichert.

Gemäss Symantec kann dieses Verzeichnis aber problemlos ausgeschlossen werden: http://seer.support.veritas.com/docs/276102.htm



Kiddies vs. Sysadmin: unerwünschte HTTPS-Verbindungen im ISA Server unterbinden

by Markus Frey 3. March 2009 12:19

Das Internet - eine schier unendliche Informationsquelle, eine riesengrosse Spielwiese, ein Welt mit süssen Verlockungen und Abgründen so schwarz wie die tiefste Nacht. Es gibt viel zu entdecken. Besonders reizvoll wird das Ganze, wenn das surfende Individuum eigentlich andere, weitaus weniger reizvolle Aufgaben zu erledigen hätte, wie zum Bespiel die Aufmerksamkeit dem drögen Lehrer zu schenken - es lockt die neue Facebook-Bekanntschaft und die Tilllate-Dokumentation des letzten Wochenendes!

Internet-Nutzungsrichtlinien sollten und können diese Versuchungen im Berufsleben gut eindämmen; grundsätzliches Vertrauen und das Wissen über eine mögliche Stichkontrolle der Internet-Nutzungsprotokolle reichen bei einer guten Unternehmenskultur meist aus. Anders sieht dies bei Schulen aus: hier sind die Verlockungen bei gleichzeitig überschaubarem Strafenkatalog offensichtlich einfach zu gross. Nicht zu vergessen der zusätzliche Kudos bei erfolgreichen Kampf gegen den System-Administrator - hail to the thief!

Hier kommen nun die technischen Hilfsmittel zum Zug. In unserem Fall hat der Sysadmin ein gut bestücktes Arsenal an Kontroll- und Abwehrmechanismen, bestehend unter anderem aus einer Rollen-basierenden, restriktiv konfigurierten Anwendungs-Firewall mit einem dynamisch aktualisierten Content-Filter, einem ISA Server 2006 mit einem GFI WebMonitor PlugIn. Durch die ActiveDirectory-Intergration und die erforderliche Authentifizierung führt kein Weg an diesen Schranken vorbei - vermeintlich!

Da HTTPS-Verbindungen direkt zwischen Client und Webserver aufgebaut und verschlüsselt werden, fehlt dem ISA Server sowie dem Content-Filter die Möglichkeit, diesen Netzwerkverkehr zu untersuchen und bei Bedarf einzuschränken. Findige Studenten finden früher oder später heraus, das viele einschlägige Seiten im Internet, wie zum Beispiel Facebook, auch per https://www.facebook.com antworten:

217:216 für die Kiddies!

Doch mit dem Wissen um diese Lücke ist sie auch bereits schon wieder gestopft: der SysAdmin schaut sich regelmässig die ISA-Web-Nutzungsprotokolle mit besonderem Augenmerk auf verdächtige HTTPS-Websites:

217:217 - Gleichstand!

Die unerwünschten HTTPS-Websites können zwar nicht automatisch vom ContentFilter gesperrt werden - wohl aber über eine Deny-Regel unter Einbezug eines Domain Name Sets im ISA Server:

Domain Name Set: Blocked Web Sites, beinhaltet:
*.facebook.com 

217:218 für den Sysadmin - momentan!

Wichtig in diesem Zusammenhang ist, dass die DNS-Auflösung auf dem ISA Server korrekt funktioniert, da die URL Sets ansonsten nicht korrekt ausgewertet werden können. 

Übrigens: die kurz vor dem Release stehende nächste Version des ISA Servers, der Forefront TMG, unterstützt die Analyse von HTTPS-Verbindungen - damit wird dann auch obige zusätzliche Deny-Regel überflüssig!