Leopard Server, iCal Server
Jens Peter Moeller
ich habe mir gerade mal
http://www.apple.com/de/server/macosx/leopard/icalserver.html
angeschaut und bin ziemlich begeistert. Das wäre genau das, was
wir schon lange suchen.
Etwas unsicher bin ich mir aber bei den Clients. Die Unterstützung
offener Standards ist ja genial. So kann ich auf meinem Windows
z.B. Sunbird nutzen. Aber was ist mit unseren ganzen Macs? Müssen
die dann alle auch auf Leopard upgedatet werden?
"Perfekte Zusammenarbeit ... Kalenderprogrammen wie iCal 3
in Leopard ..."
Also wird das iCal von Tiger als Client nicht unterstützt?
BTW: Nach einem Termin für 10.5 frage ich lieber mal nicht ;-)
Aber weiß jemand, ob die Serverversion zeitgleich mit dem Client
erscheinen wird? Wie war das bei T10.4?
Gruß
JPM
Thomas Kaiser
> ich habe mir gerade mal
> http://www.apple.com/de/server/macosx/leopard/icalserver.html angeschaut
> und bin ziemlich begeistert. Das wäre genau das, was wir schon lange
> suchen.
Gibt es hier schon zum Spielen:
<http://trac.calendarserver.org/projects/calendarserver>
Offizielle Einschränkungen für die Spielwiese: Darwin 8.0+ (Mac OS X 10.4/
10.5) mit HFS+, Linux 2.6+ mit passenden Dateisystemen oder FreeBSD 5.1+ mit
passenden Dateisystemen (siehe <http://undefined.org/python/#xattr>)
> Etwas unsicher bin ich mir aber bei den Clients.
Völlig zu recht.
> Die Unterstützung offener Standards ist ja genial.
Denn das bedeutet, daß irgendwann mal passende Clients da sein werden, die
damit umgehen können. Vorher sollte halt noch der "offene Standard", der
aktuell den Status "draft" hat
<http://www.ietf.org/internet-drafts/draft-dusseault-caldav-15.txt>
aber vielleicht sogar noch zum richtigen Standard mutieren ;-) Wenigstens
ist die Entscheidung, daß es einer wird, schon gefallen...
> So kann ich auf meinem Windows z.B. Sunbird nutzen.
Ich hab vor paar Monaten Sunbird auf obige Lösung angesetzt -- hat auch
keinen Spaß gemacht, genauso wie allen anderen damals verfügbaren Kalender-
Clients.
> Aber was ist mit unseren ganzen Macs? Müssen die dann alle auch auf
> Leopard upgedatet werden?
Wenn Du es mit iCal versuchen willst, dann ja. Ansonsten reicht Dir jeder
CalDAV-kompatible Client, der keine Probleme mit den relevanten Encodings
hat und sich auch bequemt, schreibenderweise auf den Kalender-Server
zuzugreifen, als da heute wären: _keiner_ (außer iCal 3.0). Angetestet habe
ich aber eh nur die da:
<http://trac.calendarserver.org/projects/calendarserver/wiki/CalendarClients>
> BTW: Nach einem Termin für 10.5 frage ich lieber mal nicht ;-)
Erstes Halbjahr 2007 -- such nach Stimmen zu den aktuellen Betas im Netz,
dann kannst Du Dir ausmalen, ob mit einer Veröffentlichung eher Endes des
Halbjahres zu hoffen ist oder nicht (im Sinne der Qualitätssicherung). Wann
de facto mit dem Release zu rechnen ist, hat damit natürlich nichts zu tun.
Das ist Sache des Produktmanagements bzw. der so schick geradlinienigen
Führungsstrukturen bei Apple.
> Aber weiß jemand, ob die Serverversion zeitgleich mit dem Client
> erscheinen wird? Wie war das bei T10.4?
Erschien bisher immer zeitgleich. Leute, die sich mit der Server-Version
auskennen, attestieren 10.x.0/10.x.1/10.x.2/10.x.3 und teils noch Folge-
Releases allerding nicht wirklich Produktionsstatus.
Soll heißen: Entscheidet das Produktmanagement oder Herr Jobs, daß 10.5
ausgeliefert werden soll, dann bekommen die MacOS X Server Fritzen bei Apple
eben den Auftrag, bis zum soundsovielten ("Golden Master" Termin) alle noch
klaffenden Löcher entweder zu schließen (Quick&Dirty oder echter Fix des
Problems) oder 'ne Plane drüberzulegen und die Spuren zu verschwischen (dann
verschwindet halt Funktionalität aus den Binaries/GUIs, auf die sich dann
hier und dort noch Hinweise finden).
Richtig funktionieren werden dann paar Sachen erst Monate später (kostenlose
Updates) oder werden komplett umgebaut und auf die Folgeversion verschoben
(so geschehen bspw. mit Spotlight und Netzwerk-Fähigkeiten in 10.4 -- da
stecken wirklich drollige Ansätze drin. In halbwegs funktionierend soll das
aber erst mit 10.5 kommen).
Gruss,
Thomas
Jens Peter Moeller
> Jens Peter Moeller schrieb
>> Die Unterstützung offener Standards ist ja genial.
>
> Denn das bedeutet, daß irgendwann mal passende Clients da sein werden, die
> damit umgehen können. Vorher sollte halt noch der "offene Standard", der
> aktuell den Status "draft" hat
>> So kann ich auf meinem Windows z.B. Sunbird nutzen.
>
> Ich hab vor paar Monaten Sunbird auf obige Lösung angesetzt -- hat auch
> keinen Spaß gemacht, genauso wie allen anderen damals verfügbaren Kalender-
> Clients.
>
>> Aber was ist mit unseren ganzen Macs? Müssen die dann alle auch auf
>> Leopard upgedatet werden?
>
> Wenn Du es mit iCal versuchen willst, dann ja. Ansonsten reicht Dir jeder
> CalDAV-kompatible Client, der keine Probleme mit den relevanten Encodings
> hat und sich auch bequemt, schreibenderweise auf den Kalender-Server
> zuzugreifen, als da heute wären: _keiner_ (außer iCal 3.0).
Na super. :-( Und mein Chef, Mac-Nutzer seit Jahr und Tag, war schon ganz
begeistert, als ich ihm davon erzählte.
Dann werden wir uns wohl noch eine Weile mit dem gruseligen NowUpToDate
rumschlagen müssen.
Gruß
JPM
Thomas Kaiser
> Solche postings halten einen wach :-)
Leg Dir einfach MacOS X Server selbst zu -- der hält auch wach. Ich könnt
schon wieder nur noch schreien. Kann es denn sein, daß dieses tolle, ach so
64-Bit-taugliche System, bei der Quota-Kalkulation für IMAP-User an kleinen
häßlichen 32-Bit-Hürden scheitert?
Wir werfen hier gerade per imapcopy [1] von Rechner C aus Mails von A
(steinalte Suse-Linux-Mailserverkrücke) nach B (todschicke Applesche Xeon-
Flunder). Und geraten allen Ernstes in Probleme, wenn wir el Cheffes Mails,
die knappe 5 GByte schwer sind, auf den xServe bekommen wollen, weil der
sich bei der Kalkurierung der Quotas jenseits 4 GByte lächerlicherweise
vertut.
IMAP-Clients fliegen ab 904 MByte und gesetzten 5000 MByte Quota auf die
Nase und melden "over quota" (5000 - 904 = 4096 MByte == 2^32 Byte), imapd
meldet seinerseits "v2.2.12-OS X 10.4.8" und Bugzilla @ Carnegie Mellon
meldet schließlich <https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2690>)
Äh, hallo? Schreiben wir schon das Jahr 2007 oder noch 1997? =8-|
Gruss,
Thomas
[1] <http://home.arcor.de/armin.diehl/imapcopy/imapcopy.html>
HK Fried
hk
Hannes Gnad
Hallo!
> nimm lieber exchange, ist zwar die böse firma, geht aber dafür ..
Meistens schon, aber auch nicht immer. Und kostet dafür auch
ein paar Taler.
--
Beste Gruesse, Hannes Gnad h.g...@apfelwerk.de
Freier Apple Systemberater http://www.apfelwerk.de/
*** "Wer Großes will, muss seine Träume leben!" VfB Stuttgart ***
*** Verein für Begeisterung www.vfb.de ***
Konni Scheller
> Und geraten allen Ernstes in Probleme, wenn wir el Cheffes Mails,
> die knappe 5 GByte schwer sind, auf den xServe bekommen wollen, weil der
> sich bei der Kalkurierung der Quotas jenseits 4 GByte lächerlicherweise
> vertut.
Peinlich. Wie löst ihr das jetzt? Ich meine, ohne den Server zu
zertrümmern?
Servus,
Konni
--
Grummelnd am Herd: http://www.roterochs.de/kulinarische-monologe/
Hannes Gnad
Hallo!
> > Und geraten allen Ernstes in Probleme, wenn wir el Cheffes Mails,
> > die knappe 5 GByte schwer sind, auf den xServe bekommen wollen, weil der
> > sich bei der Kalkurierung der Quotas jenseits 4 GByte lächerlicherweise
> > vertut.
> Peinlich. Wie löst ihr das jetzt? Ich meine, ohne den Server zu
> zertrümmern?
Erinnert mich daran, schon mehr als eine Mail an die zuständigen
Product Manager geschrieben zu haben, doch bitte dafür zu sorgen,
daß im Rahmen von Mac OS X Server nicht nur xxx OSS-Pakete inte-
griert werden, sondern auch regelmäßig(er) und kurzfristig(er)er
gepflegt werden als im Rahmen der Mac OS X 10.x.y-Updates.
Leider passiert dies auch bei 10.4.x eigentlich nur dann, wenn
es aus Sicherheitsgründen unbedingt notwendig ist, und selbst
dann wird noch lieber mal eine antike Version gepatcht statt
das längst verfügbare neuere Release bereitgestellt. Features,
Bugfixes? Spielen offensichtlich weniger eine Rolle... =:-/
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Und geraten allen Ernstes in Probleme, wenn wir el Cheffes Mails, die
>> knappe 5 GByte schwer sind, auf den xServe bekommen wollen, weil der sich
>> bei der Kalkurierung der Quotas jenseits 4 GByte lächerlicherweise
>> vertut.
>
> Peinlich. Wie löst ihr das jetzt? Ich meine, ohne den Server zu
> zertrümmern?
Beim Chef Quota-Limitierung gestrichen -- schon geht's. Ist vielleicht auch
gut für die Arbeitsmoral, dann lohnt es sich wenigstens, Cheffe zu sein ;-)
Gruss,
Thomas
Thomas Kaiser
> Erinnert mich daran, schon mehr als eine Mail an die zuständigen Product
> Manager geschrieben zu haben, doch bitte dafür zu sorgen, daß im Rahmen
> von Mac OS X Server nicht nur xxx OSS-Pakete inte- griert werden, sondern
> auch regelmäßig(er) und kurzfristig(er)er gepflegt werden als im Rahmen
> der Mac OS X 10.x.y-Updates.
Warum sollte jenen Produktmanager sowas interessieren? Die Zielgruppe kauft
die Server entweder rein aus ästhetischen Gründen oder weil sie eh keine
Ahnung hat -- da braucht's doch kaum Aufhebens um die Funktionalität, oder?
> Leider passiert dies auch bei 10.4.x eigentlich nur dann, wenn es aus
> Sicherheitsgründen unbedingt notwendig ist, und selbst dann wird noch
> lieber mal eine antike Version gepatcht statt das längst verfügbare neuere
> Release bereitgestellt. Features, Bugfixes? Spielen offensichtlich weniger
> eine Rolle... =:-/
Mal abgesehen davon, _wer_ das Ganze umsetzen soll (personelle Resourcen,
die im Serverbereich bei Apple ein wenig unterentwickelt sind), gibt es
einen ganz massiven Grund, der dagegen spricht: servermgrd (das server-
seitige Gegenstück zu "Server Admin.app".
Hast Du Dir mal (mittels sandal, fseventer, etc.) angeguckt, wie der mit
seinen dicken Wurschtfingern überall in welchen Konfig-Dateien herumbatzt,
wenn Du im Server Admin vor Dich hin klickst? Mach das ruhig mal... aber
nicht bei nervösem Magen.
Wenn die bei Apple von irgendwelchen OpenSource-Tools neue Versionen
einbauen wollen, dann sind schon die normalen Regression Tests nicht
wirklich ohne. Aber dann noch die ganze "Logik" aus "Server Admin.app"
nachzuziehen, dürfte ein Job sein, der einen reif für die Klapse macht.
Scusa, bin zur Zeit extrem angenervt, weil mit "MacOS X Server Bordmitteln"
ja noch nicht mal die allersimpelsten Dinge funktionieren, wie bspw. einen
Spooler einzurichten, der
* per remote LPR PostScript-Druckjobs annimmt
* unverändert per AppleTalk auf einen Laserdrucker schiebt (Sinn der Übung:
Umgehung der in [1] geschilderten Probleme)
Geht nicht. Eine "raw Queue" kann man sowieso nicht einstellen, also wird
erstmal völlig unsinnig der Kram auf dem xServe durch den pstops-Filter
gedreht. Und der cups-lpd ist anscheinend der Meinung, daß je Druckjob eine
Bannerpage vorweg ausgedruckt werden soll. Die Umgehung beider Limitationen
erzeugt eine Situation, in der man anschl. nichts mehr mit "Server Admin" im
Bereich Druckserver administrieren darf, was über reines Starten/Stoppen der
Queues hinausgeht (weil sonst Kollege servermgrd im Hintergrund alles wieder
zerdeppert).
Gruss,
Thomas
[1] HP LaserJet will per AppleTalk angesteuert werden, weil Jobs per TCP/IP
eingeliefert hängenbleiben oder sogar den Drucker zum Absturz bringen
(Problem tritt offensichtlich nur im DTP-Umfeld auf). Helios-Server will
aber besser nicht direkt per AppleTalk drucken, weil er unter Linux
läuft -- siehe bspw. <news:dt46rf$dl6$2...@svr7.m-online.net>
Jens Peter Moeller
> Jens Peter Moeller schrieb:
>>
>> ich habe mir gerade mal
>> http://www.apple.com/de/server/macosx/leopard/icalserver.html
>> angeschaut und bin ziemlich begeistert. Das wäre genau das, was
>> wir schon lange suchen.
>>
Böse Firma, gute Firma - ich möchte funktionierende und für
uns passende Lösungen.
Lass uns mal kurz nachdenken ...
1. Wir stellen uns noch einen Server mit W3K hin.
2. Wir schmeißen alle unsere Macs weg und steigen auf Windows um.
Oder halt: Da gab's doch auch so eine Art "Ausguck" für MacOS
von Microsoft. Liefe das mit Exchange?
Egal das Ganze wäre absolut übertrieben für unsere 15 Mann/Frau Firma.
Außerdem bekam ich schon Ärger, als ich einem Kollegen Thunderbird
auch sein neues Powerbook gespielt habe, weil er es halt vorher unter
Windows auch benutze. Mein Chef ist Apple Mail Fanatiker. Ich hasse
Apple Mail. ;-)
Sicher ist so eine unified messaging Lösung ungemein reizvoll und
wäre gerade bei uns, die wir ein extrem hohes Aufkommen an E-Mails
und auch nicht wenig Faxe haben, sehr sinnvoll.
Ich würde allerdings Tobit David bevorzugen. Leider wollen die
einfach keinen Client für MacOS erstellen, werben aber mit der tollen
Lösung für mehrere Tausend Benutzer. Klar, in Firmen dieser Größenordnung
wird auch immer und grundsätzlich nur mit Windows gearbeitet.
Sorry, ich schweife ab ...
Gruß
JPM
Goetz Hoffart
> Die Zielgruppe kauft die Server entweder rein aus ästhetischen Gründen
> oder weil sie eh keine Ahnung hat
Du machst es dir deutlich zu einfach.
Es gibt durchaus gute Gründe für einen XServe - etwa, wenn man einen
AFP-Server braucht, der nicht Netatalk heißt und man sich Helios nicht
leisten will. Und ExtremeZ-IP zu schlecht in die restliche
IT-Infrastruktur einzubinden ist, da das OS untendrunter im wesentlichen
nur sich selbst kennt.
Für das Geld XServe + externes RAID bekomme ich nur 40% der
erforderlichen Helios-Lizenzen. Und hab noch keine Hardware dabei.
Grüße
Götz
--
http://www.knubbelmac.de/
Konni Scheller
> Warum sollte jenen Produktmanager sowas interessieren? Die Zielgruppe kauft
> die Server entweder rein aus ästhetischen Gründen oder weil sie eh keine
> Ahnung hat -- da braucht's doch kaum Aufhebens um die Funktionalität, oder?
ähnliches war vorgestern bei dem neuen Lokal in Forchheim mit dem
Kassensystem zu beobachten: Touch-Bildschirm (die ich hasse), kein
Bondruck. Sowas gefällt den Entscheidern. Dumm nur, dass am Schluss
keiner mehr wusste, wer was boniert oder schon ausgeliefert hatte.
Direkt neben der Theke hat das Warten aufs Wasser uns schon etwas nervös
gemacht.
Entscheider sollten einmal mit dem Produkt *arbeiten* und nicht nur auf
Präsentationen damit herumspielen... aber was sag ich da...
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Die Zielgruppe kauft die Server entweder rein aus ästhetischen Gründen
>> oder weil sie eh keine Ahnung hat
>
> Du machst es dir deutlich zu einfach.
Ja und nein. Ja, weil das Sprüchlein natürlich schön provokant klingen
sollte, nein, weil ich mich eigentlich noch ausschließlich im Kontext "Was
bringt mir MacOS X Server, wenn ich mir nur die inkludierten OpenSource
Sachen anschaue?" befand.
Auf den ersten Blick Adminstration des Ganzen per Mausschubsen und ohne sich
tief mit irgendwelchen Unix-Interna auskennen zu müssen... Stimmt so
"eigentlich" auch. Aber nicht für jemanden, der zufälligerweise die diversen
OpenSource-Pakete eh schon kennt und entsprechende Erwartungen hat...
Der kriegt dann das kalte Grausen, wenn er sieht, daß Trivialitäten (wie
bspw. "raw queue" bei CUPS, oder sinnige Postfix-Konfiguration, gemeinsame
IMAP-Ordner mit cyrus, etc.) entweder gar nicht gehen oder nur auf einem
Weg, bei dem man dann anschl. sich vor jedem künftigen System-Update
fürchten muß [1] oder in Server Admin auf einmal diverse Bereiche hat, bei
denen man auf keinen Fall mehr den "Sichern"-Knopf benutzen kann [2].
Wenn man keine Ahnung von dem Zeugs hat, dann findet man sich damit ab und
freut sich, daß "Server Admin" hübscht bunt ist. Ist das nicht der Fall,
kriegt man in einigen Bereichen eben recht flink die Krise :-\
Gruss,
Thomas
[1] Bspw. weil man in /System/Library/LaunchDaemons an printer.plist
herumfummeln muß ("-o job-sheets=none,none" anstatt forciertem CUPS-
Autotyping "-o document-format=application/octet-stream")
[2] Weil man Postfix' main.cf bisserl Richtung Spam-Prävention aufgebohrt
hat, 'ne neuere ClamAV-Engine eingebaut hat, weil einen das Zumüllen der
Logs mit "freshclam.log:WARNING: Your ClamAV installation is OUTDATED!"
anödet, etc. etc. etc.
Hannes Gnad
Hallo!
> Hast Du Dir mal (mittels sandal, fseventer, etc.) angeguckt, wie der mit
> seinen dicken Wurschtfingern überall in welchen Konfig-Dateien herumbatzt,
> wenn Du im Server Admin vor Dich hin klickst? Mach das ruhig mal... aber
> nicht bei nervösem Magen.
Ja, ich weiß. Mir fehlt aber Zeit und Mut, mir das detaillierter
anzutun. =:-/
> [1] HP LaserJet will per AppleTalk angesteuert werden, weil Jobs per TCP/IP
> eingeliefert hängenbleiben oder sogar den Drucker zum Absturz bringen
> (Problem tritt offensichtlich nur im DTP-Umfeld auf). Helios-Server will
Hm-hm. Das wiederum sollte über ein Firmware-Update der Jet-
Direct-Karte in den Griff zu bekommen sein. Welche Karte (HP-
Modellnummer) mit welcher Firmware ist es denn?
--
Beste Gruesse, Hannes Gnad h.g...@apfelwerk.de
Freier Apple Systemberater http://www.apfelwerk.de/
*** Lustiger Fußballspruch aus aktuellem Anlaß leider gestrichen ***
Hannes Gnad
Hallo!
> 1. Wir stellen uns noch einen Server mit W3K hin.
Du meinst W2k3. =:*)
> 2. Wir schmeißen alle unsere Macs weg und steigen auf Windows um.
> Oder halt: Da gab's doch auch so eine Art "Ausguck" für MacOS
> von Microsoft. Liefe das mit Exchange?
Ja, das geht seit dem 11.3.0-Update für Office 2004 ziemlich gut.
> Windows auch benutze. Mein Chef ist Apple Mail Fanatiker. Ich hasse
> Apple Mail. ;-)
Warum?
> einfach keinen Client für MacOS erstellen, werben aber mit der tollen
> Lösung für mehrere Tausend Benutzer. Klar, in Firmen dieser Größenordnung
> wird auch immer und grundsätzlich nur mit Windows gearbeitet.
Warum gibt es von SAP einen Mac-Client?
Das war Apples Bedingung, um SAP einzuführen.
Noses
> Auf den ersten Blick Adminstration des Ganzen per Mausschubsen und ohne sich
> tief mit irgendwelchen Unix-Interna auskennen zu müssen...
*Das* kannst Du mit Webmin billiger und einfacher haben.
> Der kriegt dann das kalte Grausen, wenn er sieht, daß Trivialitäten (wie
etwas anspruchsvollere DNS-Konfigurationen (PTR oder NAPTR RRs)
> entweder gar nicht gehen oder nur auf einem
> Weg, bei dem man dann anschl. sich vor jedem künftigen System-Update
> fürchten muß
oder den alle 5 Minuten auftretenden Crash des servermgrd. Und der gemeldete
Fehler wurde seit fast einem Jahr nicht angepackt. Sowas passiert nicht
einmal bei Suse.
> kriegt man in einigen Bereichen eben recht flink die Krise :-\
Täglich. Hier sollen zwei Xserve als Fileserver 400 Schüler und Lehrer
versorgen. Leider sind die beiden Kerberos-Server, die nur Authentisierung
u. ä. liefern, so überfordert, daß ein Login schon mal einige Minuten dauern
kann, weil die Fileserver bei jeder Flatulenz eine Geruchsprobe zum
Unterschreiben schicken.
Noses.
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Hast Du Dir mal (mittels sandal, fseventer, etc.) angeguckt, wie der mit
>> seinen dicken Wurschtfingern überall in welchen Konfig-Dateien
>> herumbatzt, wenn Du im Server Admin vor Dich hin klickst? Mach das ruhig
>> mal... aber nicht bei nervösem Magen.
>
> Ja, ich weiß. Mir fehlt aber Zeit und Mut, mir das detaillierter anzutun.
Mut braucht es für ein kleines "sudo sandal" aber echt nicht [1]. Du guckst
halt nur zu, was ab dem Moment an welcher stelle im Filesystem passiert...
und wenn Du dann noch die Zeit aufbringst, notierst Du Dir, wo überall was
geändert wurde, machst die Änderung in Server Admin rückgängig und bringst
dann zweimal diff(1) oder fortschrittlichere Kollegen ins Spiel, wenn Du die
ursprüngliche Konfigurationsänderung erneut triggerst. Ist gut fürs
Verständnis :-)
>> [1] HP LaserJet will per AppleTalk angesteuert werden, weil Jobs per
>> TCP/IP eingeliefert hängenbleiben oder sogar den Drucker zum Absturz
>> bringen (Problem tritt offensichtlich nur im DTP-Umfeld auf).
>> Helios-Server will
>
> Hm-hm. Das wiederum sollte über ein Firmware-Update der Jet- Direct-Karte
> in den Griff zu bekommen sein.
Nö.
> Welche Karte (HP- Modellnummer) mit welcher Firmware ist es denn?
Egal bzw. aktuellste. Ich hatte bei inzwischen drei Kunden das Vergnügen,
kostenpflichtige Analyse von Druckproblemen vornehmen zu dürfen, die
allesamt darauf hinausliefen, daß man bei Vorliegen gewisser Kombinationen
um AppleTalk nicht herumkommt weil ein und diesselben Druckjobs per remote
LPR oder TCP/IP Streams eingeliefert, nicht gedruckt werden oder sogar den
Drucker ins Nirvana schicken (betrifft neben aktuellen HPs auch Canon
ImageRunner z.B.)
Gruss,
Thomas
[1] <http://www.matterform.com/mac_software/file_security/sandal.html>
Goetz Hoffart
> daß man bei Vorliegen gewisser Kombinationen um AppleTalk nicht herumkommt
> weil ein und diesselben Druckjobs per remote LPR oder TCP/IP Streams
> eingeliefert, nicht gedruckt werden oder sogar den Drucker ins Nirvana
> schicken (betrifft neben aktuellen HPs auch Canon ImageRunner z.B.)
Ähnliches habe ich hier auch für Ricoh Aficio 1060 festgestellt.
Bestimmte PDFs per LPR -> Drucker hängt. Kein LPR: druckt.
Hannes Gnad
Hallo!
> > daß man bei Vorliegen gewisser Kombinationen um AppleTalk nicht herumkommt
> > weil ein und diesselben Druckjobs per remote LPR oder TCP/IP Streams
> > eingeliefert, nicht gedruckt werden oder sogar den Drucker ins Nirvana
> > schicken (betrifft neben aktuellen HPs auch Canon ImageRunner z.B.)
> Ähnliches habe ich hier auch für Ricoh Aficio 1060 festgestellt.
> Bestimmte PDFs per LPR -> Drucker hängt. Kein LPR: druckt.
Das finde ich ziemlich seltsam. Wie kann die Art der Paketüber-
mittlung den Inhalt bzw. die Ausführung des Druckjobs beeinflussen?
Thomas Kaiser
> Goetz Hoffart <use...@hoffart.de> wrote:
> [Thomas Kaiser wrote:]
>> > daß man bei Vorliegen gewisser Kombinationen um AppleTalk nicht
>> > herumkommt weil ein und diesselben Druckjobs per remote LPR oder TCP/IP
>> > Streams eingeliefert, nicht gedruckt werden oder sogar den Drucker ins
>> > Nirvana schicken (betrifft neben aktuellen HPs auch Canon ImageRunner
>> > z.B.)
>
>> Ähnliches habe ich hier auch für Ricoh Aficio 1060 festgestellt.
>> Bestimmte PDFs per LPR -> Drucker hängt. Kein LPR: druckt.
>
> Das finde ich ziemlich seltsam.
<Loriot>Ach?</Loriot>
> Wie kann die Art der Paketüber- mittlung den Inhalt bzw. die Ausführung
> des Druckjobs beeinflussen?
Es gibt da einerseits den "Klassiker" der Druckdaten-Kodierung: Stichwort
ASCII, binär, BCP oder TBCP. Siehe Archiv der Gruppe, Suchworte "binaer" und
"tbcp" bspw.
Dann gibt es aber ganz unabhängig davon auch den Fall, wo Du einen Job bspw.
aus Acrobat heraus auf einen LaserJet schickst... und wenn Du das per remote
LPR oder TCP/IP Streams (Port 9100) getan hast, dann loslaufen kannst, um
den Drucker aus- und wieder einzuschalten. Ich weiß nicht, ob das unbedingt
Zufall ist -- aber die drei Kunden, bei denen ich in derlei Drucker-Trouble
involviert war, hatten alle mindestens 400 User und eine dazu passende
Anzahl Drucker auf den Fluren und in den Büros herumstehen -- die
Ein-/Ausschalterei war jedenfalls immer ein elendes Gerenne...
BTW: Es scheint auch noch am PS-Code selbst zu liegen. Bei einem Kunden
war die Grund-Aufgabenstellung, immer nur PDFs aus InDesign skaliert oder
unskaliert auf A3-Lasern rauszulassen. Dauerte mit dem PS-Code aus Acrobat
immer halbe Ewigkeiten (und teils eben noch länger, weil Jogging zum Drucker
und Reset desselben nötig war). Das selbe dann als serverseitiger Hotfolder
mit Helios' pdfprint (aus dem PDF Handshake Paket) realisiert führte nicht
nur zu *drastisch* geringeren RIP-Zeiten auf den Druckern sondern auch zum
Ausbleiben der Freezes. Wohlgemerkt in beiden Fällen mit visuell 1:1
identischem Ergebnis auf Papier (wenn denn im ersten Fall der Drucker nicht
vorher abgeschmiert ist ;-)
Ich zitiere im Folgenden einfach mal die anonymisierte Nachbereitung, die
ich wegen der Druckeransteuerung an sich damals verfaßt habe:
------------------------------------ 8< ------------------------------------
2) Ansteuerung der HP LaserJet-Drucker
--------------------------------------
Es existieren grundsätzlich zwei sinnvolle Varianten: HP JetDirect/Socket
(Port 9100) oder AppleTalk. Beide sind grundsätzlich 8Bit-clean (bei
Socket ab neueren HP JetDirect-Firmwares) und bidirektional, d.h.
Statusmeldungen gelangen retour zum Server.
Socket/JetDirect:
~~~~~~~~~~~~~~~~~
Diese Variante ist theoretisch *deutlich* schneller, in der Praxis
passiert allerdings das genaue Gegenteil. Ursache aktuell unklar.
Ein weiteres Problem besteht darin, daß gewisse Jobs den Drucker faktisch
abstürzen lassen. Er reagiert anschließend auf keine neue Jobs mehr und
verweilt mit einer Fehlermeldung auf dem Display. Durch eine Testreihe
konnte zwar der Eindruck gewonnen werden, daß ein Bereinigen der
Druckerpräferenzen und das Ansteuern des Druckers mit dem korrekten
PostScript-Level die Probleme lösen /könne/, allerdings finden sich im
Netz zuhauf Meldungen bzgl. dieses Fehlers, deren Ursache in allem
möglichen liegen kann, so daß bezweifelt werden darf, ob ein globales
"Großreinemachen" der Drucker-Preferences und das Zuweisen korrekter
(evtl. angepasster) PPDs auf allen Clients das Problem aus der Welt
schafft.
AppleTalk:
~~~~~~~~~~
Theoretisch in der Ansteuerung der Drucker langsamer (theoretische
Maximaltransferrate dürfte bei ca. 3,5 MByte in einem Fast-Ethernet-
Segment sein) als Socket, allerdings bei der Kombination aus Größe und
Komplexität der Jobs (durchschnittlich 5 MByte, JPEG-komprimierte
Abbildungen) immer noch ausreichend schnell. Bei Verwendung von AppleTalk
dürfte immer noch die Rechengeschwindigkeit des RIP der limitierendere
Faktor sein.
Jobs, die per Socket geschickt den Drucker zuverlässig einfrieren ließen
(auch nach empfohlenem "cold reset" des JetDirect-Printservers und
separat Einspielen der aktuellsten JetDirect Firmware), funktionierten
per AppleTalk geschickt einwandfrei (es handelte sich bei den Tests um
1:1 identische PS-Dateien, die mal so und mal so geschickt wurden)
3) Ansteuerung der Canon ImageRunner
------------------------------------
Die Canon ImageRunner sind theoretisch nur sauber per AppleTalk
ansteuerbar, da die ebenfalls implementierte Socket-Variante keinen
Rückkanal kennt und diese fehlende Bidirektionalität die Kontrolle über
abbrechende Jobs aufgrund PostScript-Fehler verhindert.
Da zudem bei der Ansteuerung per Socket/Port 9100 anscheinend deutlich
öfter "Hänger" zu verzeichnen sind, die nur durch einen Reset respektive
Aus-/Einschalten behoben werden können, haben wir nur die Ansteuerung per
AppleTalk weiter untersucht.
Das Problem ist an Helios kommuniziert (HELIOS_Sup_Ref_No: XXXXXX.XXX)
und seitens Helios sind weitere Anweisungen gekommen, wie das Problem
einzugrenzen ist. Generell -- so die Aussage -- sei von keinen
spezifischen Problemen mit ImageRunnern und Ansteuerung seitens
EtherShare per AppleTalk bekannt (was aber nichts heißen muß -- die
Rückmeldungsquote von Problemen ist in manchen Fällen extrem niedrig)
Status: Das Anfertigen von Netzwerktraces ist in Vorbereitung, weitere
Informationen/Tools seitens Helios folgen
------------------------------------ >8 ------------------------------------
Die anderen beiden Supportfälle sind schon archiviert und ich grad zu doof,
da heran zu kommen :-\
Gruss,
Thomas
HK Fried
> HK Fried schrieb:
>> Jens Peter Moeller schrieb:
>>> ich habe mir gerade mal
>>> http://www.apple.com/de/server/macosx/leopard/icalserver.html
>>> angeschaut und bin ziemlich begeistert. Das wäre genau das, was
>>> wir schon lange suchen.
>>>
>> nimm lieber exchange, ist zwar die böse firma, geht aber dafür ..
>
> Böse Firma, gute Firma - ich möchte funktionierende und für
> uns passende Lösungen.
>
> Lass uns mal kurz nachdenken ...
>
> 1. Wir stellen uns noch einen Server mit W3K hin.
> 2. Wir schmeißen alle unsere Macs weg und steigen auf Windows um.
> Oder halt: Da gab's doch auch so eine Art "Ausguck" für MacOS
> von Microsoft. Liefe das mit Exchange?
>
> Egal das Ganze wäre absolut übertrieben für unsere 15 Mann/Frau Firma.
> Außerdem bekam ich schon Ärger, als ich einem Kollegen Thunderbird
> auch sein neues Powerbook gespielt habe, weil er es halt vorher unter
> Windows auch benutze. Mein Chef ist Apple Mail Fanatiker. Ich hasse
> Apple Mail. ;-)
anpreist, das schon 5000 Applikationen gegen UB linkt, auf die kann man
sich als Firma nicht verlassen (http://guide.apple.com/universal/), wenn
man mal die Datenbasis von Windows als Vergleich nimmt.
>
> Sicher ist so eine unified messaging Lösung ungemein reizvoll und
> wäre gerade bei uns, die wir ein extrem hohes Aufkommen an E-Mails
> und auch nicht wenig Faxe haben, sehr sinnvoll.
> Ich würde allerdings Tobit David bevorzugen. Leider wollen die
> einfach keinen Client für MacOS erstellen, werben aber mit der tollen
> Lösung für mehrere Tausend Benutzer. Klar, in Firmen dieser Größenordnung
> wird auch immer und grundsätzlich nur mit Windows gearbeitet.
zum SAPs degenerieren aber ein Windows-basiertes Netzwerk läuft nunmal
für die Nutzer einfacher ..., räusper, behaupte ich mal. ;-) ;-)
>
>
> Sorry, ich schweife ab ...
>
>
> Gruß
> JPM
HK
Hannes Gnad
Hallo!
> Ich würde mir ja auch was anderes wünschen, aber eine Firma, die stolz
> anpreist, das schon 5000 Applikationen gegen UB linkt, auf die kann man
> sich als Firma nicht verlassen (http://guide.apple.com/universal/), wenn
> man mal die Datenbasis von Windows als Vergleich nimmt.
Was hat die aktuelle Anzahl der UB mit der Verlässlichkeit von
Apple zu tun?
(Ich wüßte xx andere Kriterien, "Verlässlichkeit" zu bewerten.)
> zum SAPs degenerieren aber ein Windows-basiertes Netzwerk läuft nunmal
> für die Nutzer einfacher ..., räusper, behaupte ich mal. ;-) ;-)
Wenn ich Deine diversen Postings hier lese, behauptest Du so
allerhand, nur wenig sinniges.
HK Fried
> HK Fried <hkf...@t-online.de> wrote:
>
> Hallo!
>
>> Ich würde mir ja auch was anderes wünschen, aber eine Firma, die stolz
>> anpreist, das schon 5000 Applikationen gegen UB linkt, auf die kann man
>> sich als Firma nicht verlassen (http://guide.apple.com/universal/), wenn
>> man mal die Datenbasis von Windows als Vergleich nimmt.
>
> Was hat die aktuelle Anzahl der UB mit der Verlässlichkeit von
> Apple zu tun?
>
> (Ich wüßte xx andere Kriterien, "Verlässlichkeit" zu bewerten.)
muß ich mich nicht verbiegen, Software zu bekommen. Für OS X muß ich das
schon. Und dann die diversen faux pas, Verprellung von Classic-Anwendern
usw.
>
>
>> zum SAPs degenerieren aber ein Windows-basiertes Netzwerk läuft nunmal
>> für die Nutzer einfacher ..., räusper, behaupte ich mal. ;-) ;-)
>
> Wenn ich Deine diversen Postings hier lese, behauptest Du so
> allerhand, nur wenig sinniges.
Windows-Netzwerke sind sehr einfach zu handhaben, nimm mal die
Druckertreiberinstallation einer Druckerfreigabe, was passiert? Richtig,
der Treiber wird Dir installiert. Jetzt mach das mal mit einem OS X
basierten Netzwerk(Cups). Nein, ich denke M$ hat eben Erfahrung mit
solchen Dingen und Apple nicht, ganz einfach ...
Oder anders gesagt: warum soll ich auf die tollen Sachen warten, die
Jobs uns verpricht, wenn diese bei M$, Blackberry und CO&KG schon
laufen(seit Jahrzehnten mittlerweile) und ich dann auch noch die
Maschinen problemlos upgraden kann? Nicht ohne Grund sieht man Apple auf
der Cebit nie ...
HK
HK Fried
> HK Fried <hkf...@t-online.de> wrote:
>
>> Windows-Netzwerke sind sehr einfach zu handhaben, nimm mal die
>> Druckertreiberinstallation einer Druckerfreigabe, was passiert? Richtig,
>> der Treiber wird Dir installiert. Jetzt mach das mal mit einem OS X
>> basierten Netzwerk(Cups).
>
>
> Daniel
Ich geb mich geschlagen ... ;-)
HK
Noses
> Windows-Netzwerke sind sehr einfach zu handhaben
_Das_ ist vollkommener Quark. Nur sind die meisten Benutzer in irgendwelchen
Klitschen noch nie mit einem richtig gepflegten Netz in Berührung gekommen.
Meistens ist der Admin irgendein Drösel, der bei drei nicht schnell genug
auf dem Baum war.
Für die meisten Anwender reicht das allerdings volkommen aus.
Noses.
Hannes Gnad
Hallo!
> > (Ich wüßte xx andere Kriterien, "Verlässlichkeit" zu bewerten.)
> Ganz einfach: Konstanz. Nein, nicht die Stadt... ;-) Und für Windoofs
Apple sieht seine Stärke nicht bei "Konstanz", sondern bei
"Innovation".
> muß ich mich nicht verbiegen, Software zu bekommen. Für OS X muß ich das
> schon.
Hm? Es gab für den Mac nie mehr native Software als heute.
> Und dann die diversen faux pas, Verprellung von Classic-Anwendern
> usw.
HM?! Mac OS 9.2.2 wurde 2002 abgekündigt, und vier Jahre
später stampft Apple im Rahmen von Mac OS X für Intel die
Classic-Umgebung endgültig ein - einer der besten Neben-
effekte des Intelswitches, so aus der Sicht als Mac-Sup-
porter.
(Am Rande: Apple hat viele Fehler gemacht, und auch heute
gibt es zahlreiche Ansätze für Kritik und Verbesserungen.
Irgendwie triffst Du aber immer daneben.)
> > Wenn ich Deine diversen Postings hier lese, behauptest Du so
> > allerhand, nur wenig sinniges.
> Gut, für dich als Spezialisten hab ich nicht viel zu sagen, aber
> Windows-Netzwerke sind sehr einfach zu handhaben, nimm mal die
Hust. Schon mal mit AD gerungen?
> Druckertreiberinstallation einer Druckerfreigabe, was passiert? Richtig,
> der Treiber wird Dir installiert. Jetzt mach das mal mit einem OS X
> basierten Netzwerk(Cups). Nein, ich denke M$ hat eben Erfahrung mit
Zu CUPS lasse ich lieber Thomas was tippen.
Im Alltag sieht es aber heute so aus: Netzwerkdrucker mit
Bonjour, wird unter Mac OS X gesehen, anklicken, fertig.
Unter Windows darf man einen Assistenten starten, Bonjour
ist nicht, also TCP/IP, und dann muß man wissen, daß für
XP ein TCP/IP-Drucker kein Netzwerkdrucker, sondern ein
lokaler Drucker am Anschluß "TCP/IP" ist...
> solchen Dingen und Apple nicht, ganz einfach ...
Das stimmt, zumindest generell: Im Bereich "IT" ist M$
Apple viele Jahre an Erfahrung und Lösungen voraus.
> Oder anders gesagt: warum soll ich auf die tollen Sachen warten, die
> Jobs uns verpricht, wenn diese bei M$, Blackberry und CO&KG schon
> laufen(seit Jahrzehnten mittlerweile) und ich dann auch noch die
> Maschinen problemlos upgraden kann?
Liest Du Berichte über Vista? =;*)
> Nicht ohne Grund sieht man Apple auf der Cebit nie ...
Die Frage, welche Firma warum an der CeBit teilnimmt, ist ein
ganz anders Thema.
Thorolf Godawa
> ich habe mir gerade mal
> http://www.apple.com/de/server/macosx/leopard/icalserver.html
> angeschaut und bin ziemlich begeistert. Das wäre genau das, was
> wir schon lange suchen.
das hatte ich mir auch vor kurzem mal genauer angesehen als ich nach
einer gemeinsamen Kalenderlösung für den Mac gesucht habe.
Ich bin dann aber beim Cosmo Projekt der OSA Foundation gelandet das
ebenfalls einen gemeinsamen Kalender bietet und zudem auf Linux läuft.
Da es eine JSP/Java-Anwendung auf Basis von Tomcat ist dürfte es aber
auch auf anderen Systemen, u.a. MacOS X laufen.
Auf einer "500MHz-Gurke" mit 512MB RAM und schneller SATA-Platte ist es
allerdings zeitweise recht träge, funktioniert ansonsten aber einwandfrei!
> Etwas unsicher bin ich mir aber bei den Clients. Die Unterstützung
> offener Standards ist ja genial. So kann ich auf meinem Windows
> z.B. Sunbird nutzen. Aber was ist mit unseren ganzen Macs? Müssen
> die dann alle auch auf Leopard upgedatet werden?
Also iCal aus 10.4 wird nicht richtig unterstützt, man kann die Termine
zwar anzeigen aber nicht mehr. Sunbird lässt sich korrekt via CalDAV
anbinden und einen einfachen Web-Kalender gibt es bei Cosmo auch.
Für kleine Arbeitsgruppen reicht es, ansonsten setze ich aber Lotus
Domino/Notes ein, der Domino-Server läuft grundsätzlich auf
Linux-Maschinen und der Mac-Client für Notes 7.0.2 ist endlich wieder
der Windows-Version ebenbürtig.
In der "Express"-Variante kostet Notes/Domino ca. 150 EUR pro Client,
kann natürlich viel mehr als nur Kalender/Gruppenkalender, Adressbücher
und Mails da es sich um einen Applikations-Server handelt für den es
viele fertige Anwendungen gibt, für den man aber auch selbst Anwendungen
erstellen kann!
--
To Answer please replace "invalid" with "de" !
Zum Antworten bitte "invalid" durch "de" ersetzen !
Chau y hasta luego,
Thorolf
Thomas Kaiser
> nimm mal die Druckertreiberinstallation einer Druckerfreigabe, was
> passiert? Richtig, der Treiber wird Dir installiert. Jetzt mach das mal
> mit einem OS X basierten Netzwerk(Cups).
_Wenn_ es der Admin checkt, dann wird da kein "Treiber" installiert, weil es
das gar nicht braucht und die Druckershare einfach so funktioniert. Insofern
ein tolles Beispiel.
Zum eigentlichen Thema hat Noses schon alles gesagt.
Gruss,
Thomas
HK Fried
nicht schlimm, nur gepflegt müssen sie sein. Vielleicht hat er ja Recht
gehabt. ;-) Vielleicht ist der iCal-Server ja gar nicht so schlecht, mal
sehen ...
HK
Markus Hippeli
> Jens Peter Moeller schrieb:
> > http://www.apple.com/de/server/macosx/leopard/icalserver.html
> nimm lieber exchange, ist zwar die böse firma, geht aber dafür ..
... im Gegensatz zu Deiner Shift-Taste. Exchange nutzt Dir mit iCal in
seiner aktuellen Version genau gar nix, alldieweil das Tiger-iCal
Kalender nur abonnieren oder veröffentlichen kann, nicht aber
syncronisieren. Und das war das eigentliche Anliegen des OP, so dünkt es
mich. Was die Leopold-Version von iCal mit Exchange anfangen kann werden
wir sehen, wenn sie da ist. Abgesehen von fühlbaren Lizenzkosten
brauchst Du für Exchange zwingend einen Windows-Server, das Backup des
Exchange ist auch nicht umsonst und man hat in einer Mac-Umgebung ein
Adminproblem. Mein Rat wäre dann schon eher Kerio, das ist billiger,
läuft auf dem Mac (unter anderem) und deckt einen grossen Teil der
Exchange-Funktionalität ab mit einigen Bonuspunkten obendrauf -
zumindest mit Entourage als Client oder Thunderbird. iCal siehe oben.
Meiner Meinung nach hat der OP derzeit eine, wenn auch ungeliebte,
Lösung und das offenbar auch schon länger, also sollte er noch ein paar
Tage dabei bleiben und erst mal abwarten, was denn der iCalServer kann,
wenn er auf den Markt kommt und wie sich das u.U. auf die Preise der
Konkurrenz auswirkt. Jetzt ohne dringenden Bedarf $irgendwas zu kaufen
im Wissen, dass in näherer Zukunft ein weiteres Produkt für den
gewünschten Einsatzzweck auf dem Markt antritt wäre IMHO ziemlich
dämlich.
cu
Markus
Hannes Gnad
Hallo!
> ... im Gegensatz zu Deiner Shift-Taste. Exchange nutzt Dir mit iCal in
> seiner aktuellen Version genau gar nix, alldieweil das Tiger-iCal
> Kalender nur abonnieren oder veröffentlichen kann, nicht aber
> syncronisieren. Und das war das eigentliche Anliegen des OP, so dünkt es
> mich. Was die Leopold-Version von iCal mit Exchange anfangen kann werden
Am Rande: Das läßt sich beheben, kostet allerdings wieder:
http://www.snerdware.com/groupcal/
--
Beste Gruesse, Hannes Gnad h.g...@apfelwerk.de
Freier Apple Systemberater http://www.apfelwerk.de/
*** Lustiger Fußballspruch für den Rest der Saison leider gestrichen ***
HK Fried
...
> Meiner Meinung nach hat der OP derzeit eine, wenn auch ungeliebte,
> Lösung und das offenbar auch schon länger, also sollte er noch ein paar
> Tage dabei bleiben und erst mal abwarten, was denn der iCalServer kann,
> wenn er auf den Markt kommt und wie sich das u.U. auf die Preise der
> Konkurrenz auswirkt. Jetzt ohne dringenden Bedarf $irgendwas zu kaufen
> im Wissen, dass in näherer Zukunft ein weiteres Produkt für den
> gewünschten Einsatzzweck auf dem Markt antritt wäre IMHO ziemlich
> dämlich.
warum soll ich auf irgendwas warten, was vielleicht läuft, wenn eine
firma lösungen schon seit über 10 jahren erfolgreich vertreibt? außer
das es mich reizt zu warten? und wenn man schon seine firma mit macs
bestückt, dann sollte man sich vorher gedanken machen, was man braucht.
und m$-software funktioniert nunmal und ist grade für firmen
interessant, da es nunmal standard ist. basta. exchange über sbs
installieren, einrichten und arbeiten, fertig. alles andere ist doch
gezippel.
http://www.msexchange.org/tutorials/Installing-and-Configuring-SBS2003.html
siehe hier, da geht alles, ich brauch nur mäßiges wissen und keine
shift-taste. was ich dann mit macs und os x zusätzlich mache, ist doch
eine ganz andere frage.
>
> cu
>
> Markus
hk
Thomas Kaiser
> Markus Hippeli schrieb:
>
>> Meiner Meinung nach hat der OP derzeit eine, wenn auch ungeliebte, Lösung
>> und das offenbar auch schon länger, also sollte er noch ein paar Tage
>
> warum soll ich auf irgendwas warten
Nicht Du, der OP soll warten -- und das aufgrund seiner Praxis-Situation,
die Du weiterhin ulkigerweise ausblendest.
> was vielleicht läuft, wenn eine firma lösungen schon seit über 10 jahren
> erfolgreich vertreibt?
Ja, Microsoft ist nicht nur im Marketing stark sondern auch im Vertrieb.
Hast Du parallel auch was über die Qualität der Produkte ausgesagt?
> und m$-software funktioniert nunmal und ist grade für firmen interessant,
> da es nunmal standard ist. basta.
Damit wäre für meinen Geschmack die Troll-Grenze bereits überschritten :-)
> exchange über sbs installieren, einrichten und arbeiten, fertig. alles
> andere ist doch gezippel.
> http://www.msexchange.org/tutorials/Installing-and-Configuring-SBS2003.html
>
> siehe hier, da geht alles, ich brauch nur mäßiges wissen
Vielleicht ist das die Erklärung, warum die größten Mail-GAUs, von denen ich
bisher so mitbekam, immer mit Exchange im Zusammenhang standen. Hat wohl
doch weniger mit der Software an sich zu tun als mit Selbsteinschätzung und
Wissen der Admins von dem Zeugs.
Gut' Nacht,
Thomas
Markus Hippeli
> ich brauch nur mäßiges wissen und keine shift-taste.
Das merkt man. Wird wohl auch zu entsprechenden Ergebnissen führen.
cu
Markus
Michael Grundmann
> HK Fried <hkf...@t-online.de> wrote:
>
>> ich brauch nur mäßiges wissen und keine shift-taste.
>
> Das merkt man. Wird wohl auch zu entsprechenden Ergebnissen führen.
loool - ich wollte mich eigentlich bei diesem Thema nicht beteiligen,
aber das ist ja wohl mal ein Volltreffer!
Ich habe so den Eindruck, dass ein WinUser hier im Usenet seinen
Schabernack treiben will :)
--
Gruß Michael
...der auch immer die eierlegende Wollmilchsau sucht. Aber entweder sind
die Eier faul, die Wolle verfilzt oder die Sau gehört schon längst als
Gammelfleisch entsorgt
Hannes Gnad
Hallo!
> interessant, da es nunmal standard ist. basta. exchange über sbs
> installieren, einrichten und arbeiten, fertig. alles andere ist doch
> gezippel.
> http://www.msexchange.org/tutorials/Installing-and-Configuring-SBS2003.html
> siehe hier, da geht alles, ich brauch nur mäßiges wissen und keine
Jaja, es wurde (insbesondere in D) noch kein ITler entlassen,
weil er die M$-Lösung genommen hat. Nur, ob es dann wirklich
(für den speziellen Fall) auch gut funktioniert, und was es
kostet, dann sind auch noch Themen.
Thomas Kaiser
> HK Fried <hkf...@t-online.de> wrote:
>
>> interessant, da es nunmal standard ist. basta. exchange über sbs
>> installieren, einrichten und arbeiten, fertig. alles andere ist doch
>> gezippel.
>> http://www.msexchange.org/tutorials/Installing-and-Configuring-SBS2003.html
>
>> siehe hier, da geht alles, ich brauch nur mäßiges wissen und keine
>
> Jaja, es wurde (insbesondere in D) noch kein ITler entlassen, weil er die
> M$-Lösung genommen hat.
Aber sicher gibt und gab es das. Unfähigkeit reicht da wirklich schon aus,
egal ob nun Beschaffungsopportunismus im Spiel ist oder nicht.
> Nur, ob es dann wirklich (für den speziellen Fall) auch gut funktioniert,
> und was es kostet, dann sind auch noch Themen.
Exakt. Und das ist der Knackpunkt. Es gibt Umgebungen, wo Exchange, innigst
mit einem Active Directory schmusend und evtl. noch Zusätze wie SharePoint
Portal Server, M$ Dynamics (vormals Navision), etc. etc. angeschraubt
habend, prima hineinpaßt. Grundvoraussetzung sind dann aber mindestens
Outlook/Entourage 2004 bzw. wenn man wirklich sinnig mit OWA spielen will,
ein IE 5.x aufwärts. Bzw. im Idealfall eine Windows-Monokultur auf Seite der
Clients (Server sowieso) und sonst gar nichts. Die damit einhergehenden
Probleme muß man halt mögen oder mit ihnen klarkommen (was *fähigen*
Windows-Admins überigens regelmäßig auch gelingt).
Dann gibt es andere Konstellationen, wo man die ganze Featuritis gar nicht
braucht und mit einer viel simpleren Lösung -- ggf. sogar für lau -- viel
passender wegkommt. Sei es auf Client- und/oder Server-Seite.
Dann gibt es wiederum andere Konstellationen, wo man aufgrund verzwickter
Rechtesituationen und erforderlicher Flexibilität beim Kontaktmanagement
feststellt, daß man mit AD/NTFS/Exchange nicht mehr weiterkommt und bspw.
bei Novell landet.
Dann gibt es Konstellationen, wo aufgrund der existenten IT-Infrastruktur
gewisse Lösungen aufgrund deren Anforderungen automatisch ausscheiden, so
nett die damit erreichbaren Vorteile auch immer gewesen sein mögen.
Es kommt eben immer drauf an. Das Ganze ist auf mehreren Ebenen aufwändig
(Anschaffungs-/Schulungs-/Wartungskosten) und im Normalfall gehört eine
gehörige Portion Know-how dazu, damit der Kram anschließend auch wirklich so
funktioniert, wie er soll (gerade Exchange/Outlook/Office ist eine wahre
Feature-Hydra, die erstmal gezähmt und dann vielleicht auch wenigstens zu
mehr als 5% genutzt werden will!)
Die "Argumentation" des Vorredners spiegelt eher "klassische Entscheidungs-
prozesse" wider und wie es halt in der Praxis meist läuft. Mit "mäßig
Wissen" Ausgestatte klicken irgendwas ohne Berücksichtigung von Umfeld und
Folgekosten zusammen, und wenn das Ganze dann auf den ersten Blick nicht
gleich total auseinanderkracht stellt sich auch schon ein Erfolgsgefühl
bei den Verantwortlichen ein. Das ist meist das einzig Positive, was man
über solche Installationen berichten kann.
...und das Ganze ist nicht auf Windows-Netze oder Exchange beschränkt
sondern findet eigentlich überall dort statt, wo mangelndes Wissen die Wahl
der Werkzeuge diktiert. Findet sich also auch zuhauf in reinen Mac-
Klitschen, wo MacOS X Server als Allheilmittel gepriesen wird ;-)
Gruss,
Thomas
Noses
> Jaja, es wurde (insbesondere in D) noch kein ITler entlassen,
> weil er die M$-Lösung genommen hat.
Doch, das ist schon passiert.
Noses.
Hannes Gnad
Hallo!
> > Jaja, es wurde (insbesondere in D) noch kein ITler entlassen,
> > weil er die M$-Lösung genommen hat.
> Doch, das ist schon passiert.
Beispiele bitte.
Noses
>> > weil er die M$-Lösung genommen hat.
>> Doch, das ist schon passiert.
> Beispiele bitte.
Ich habe 2002 dabei mitgewirkt, einem Admin, der idiotischerweise auf die
Anforderung, einen Mailserver zwecks POP- und SMTP-Nutzung aufzusetzen, ohne
Rücksprache mit der Geschäftsführung oder seinem Vorgesetzten in einem
Sun/HP-Laden einen Windows 2000 Server zuzüglich Exchange gekauft und
installiert hat, aus der Systemumgebung zu entfernen. Gut, daß es eine
Probezeit gibt. Sie sollte nicht auf zwei sondern auf 10 Jahre ausgedehnt
werden.
Noses.
HK Fried
> Markus Hippeli schrieb:
>> HK Fried <hkf...@t-online.de> wrote:
>>
>>> ich brauch nur mäßiges wissen und keine shift-taste.
>> Das merkt man. Wird wohl auch zu entsprechenden Ergebnissen führen.
>
> loool - ich wollte mich eigentlich bei diesem Thema nicht beteiligen,
> aber das ist ja wohl mal ein Volltreffer!
> Ich habe so den Eindruck, dass ein WinUser hier im Usenet seinen
> Schabernack treiben will :)
>
>
netzfetischisten spielen.
hk
--
ich wollte nie witzig sein, i never planed to tell a joke.
Hannes Gnad
Hallo!
> Ich habe 2002 dabei mitgewirkt, einem Admin, der idiotischerweise auf die
> Anforderung, einen Mailserver zwecks POP- und SMTP-Nutzung aufzusetzen, ohne
> Rücksprache mit der Geschäftsführung oder seinem Vorgesetzten in einem
> Sun/HP-Laden einen Windows 2000 Server zuzüglich Exchange gekauft und
> installiert hat, aus der Systemumgebung zu entfernen.
Warum?
1. War es zu teuer?
2. Er hat sich kein ok geholt?
3. Hat es nicht funktioniert?
4. Hat es Dir nicht gefallen?
5. ...?
> Gut, daß es eine
> Probezeit gibt. Sie sollte nicht auf zwei sondern auf 10 Jahre ausgedehnt
> werden.
=;*)
Thomas Kaiser
> Noses <noses....@noses.com> wrote:
>
>> Ich habe 2002 dabei mitgewirkt, einem Admin, der idiotischerweise auf die
>> Anforderung, einen Mailserver zwecks POP- und SMTP-Nutzung aufzusetzen,
>> ohne Rücksprache mit der Geschäftsführung oder seinem Vorgesetzten in
>> einem Sun/HP-Laden einen Windows 2000 Server zuzüglich Exchange gekauft
>> und installiert hat, aus der Systemumgebung zu entfernen.
>
> Warum?
>
> 1. War es zu teuer?
> 2. Er hat sich kein ok geholt?
> 3. Hat es nicht funktioniert?
> 4. Hat es Dir nicht gefallen?
> 5. ...?
Äh, um was geht's Dir eigentlich grad in diesem ganzen Teilthread? Willst Du
irgendwelche Anekdoten für Mac-Stammtische sammeln oder Pseudo-Argumente, um
sie potentiellen Apple-Kunden aufs Brot zu schmieren?
"Mailserver zwecks POP- und SMTP-Nutzung". Schon mitbekommen, daß es sowas
wie einen dedizierten SMTP-Server eh erst mit Exchange 2007 und dem "Edge
Transport Server" gibt? Also eine Kiste, die man als echte SMTP-Schleuder in
die DMZ stellen kann ohne gleich die Hälfte der internen Firmen-Strukturen
mit in die DMZ stellen zu müssen?
Ist die Stärke von Exchange etwa seine Standardkonformität wenn es um offene
Standards wie POP oder SMTP geht? Wohl kaum? Die Stärke liegt auf dem Gebiet
Groupware mit einer klar definierten Schar dafür tauglicher Clients... und
genau das war doch in dem Szenarium gar nicht gefragt.
Dann: Wenn eine Klitsche sich serverseitig auf HP-UX und Solaris festlegt...
was soll dann auf einmal ein Windows-Server in dem Umfeld? Der Beweis, daß
auch "der Neue" den nicht vernünftig administrieren kann, ist doch beinahe
schon dadurch erbracht, daß jemand, der in so einer Umgebung und unter den
Randbedingungen Exchange ins Spiel bringt, auch kein fähiger Windows-Admin
sein kann, weil er schon ganz generell irgendwo einen an der Klatsche hat.
Es ist doch offensichtlich: In der Situation ist Exchange teurer Overkill,
der sich zu 0% in die vorhandene IT-Landschaft (Wartung, Backup, vermutlich
auch verfügbares Know-How) einfügt.
Vergleichbar mit 'ner Klitsche, die nur Windows-Arbeitsplätze hat und an
einen frischen Admin gerät, dessen Hirn zu lang Herrn Jobs' "Reality
Distortion Field" ausgesetzt war, was dann als Antwort auf "Groupware" zu
einem xServe anstelle von Exchange, Domino, Groupwise, Scalix, whatever auf
"in der Situation vernünftigen" Plattformen führt...
Gruss,
Thomas
HK Fried
...
> Vergleichbar mit 'ner Klitsche, die nur Windows-Arbeitsplätze hat und an
> einen frischen Admin gerät, dessen Hirn zu lang Herrn Jobs' "Reality
> Distortion Field" ausgesetzt war, was dann als Antwort auf "Groupware" zu
> einem xServe anstelle von Exchange, Domino, Groupwise, Scalix, whatever auf
> "in der Situation vernünftigen" Plattformen führt...
>
> Gruss,
>
> Thomas
Ok, jetzt sagt mal jeder, was ihm an den anderen stört ... ;-)
Ich mach Urlaub ...
HK
Sebastian Wessel
Oder auch:
"Maybe you should come in twice a week" :)
MfG
Sebastian Wessel
--
Individualitaet ist ok, solange wir es alle zusammen tun
Major Frankling Burns (M*A*S*H)
Hannes Gnad
Hallo!
> Äh, um was geht's Dir eigentlich grad in diesem ganzen Teilthread? Willst Du
> irgendwelche Anekdoten für Mac-Stammtische sammeln oder Pseudo-Argumente, um
> sie potentiellen Apple-Kunden aufs Brot zu schmieren?
Ähm, nein.
Mich interessiert, wie Noses vorgeht, weil ich im Lauf der
Zeit den Eindruck gewonnen habe, daß er von Dingen wie Mail-
servern etwas Ahnung hat.
> "Mailserver zwecks POP- und SMTP-Nutzung". Schon mitbekommen, daß es sowas
> wie einen dedizierten SMTP-Server eh erst mit Exchange 2007 und dem "Edge
> Transport Server" gibt? Also eine Kiste, die man als echte SMTP-Schleuder in
> die DMZ stellen kann ohne gleich die Hälfte der internen Firmen-Strukturen
> mit in die DMZ stellen zu müssen?
Nein. So weit kenne/kannte ich Exchange noch gar nicht.
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Äh, um was geht's Dir eigentlich grad in diesem ganzen Teilthread? Willst
>> Du irgendwelche Anekdoten für Mac-Stammtische sammeln oder
>> Pseudo-Argumente, um sie potentiellen Apple-Kunden aufs Brot zu
>> schmieren?
>
> Ähm, nein.
>
> Mich interessiert, wie Noses vorgeht, weil ich im Lauf der Zeit den
> Eindruck gewonnen habe, daß er von Dingen wie Mail- servern etwas Ahnung
> hat.
Ah, so. Jetzt wird mir in <news:etb19q$rdu$2...@infosun2.rus.uni-stuttgart.de>
endlich die Zeile "5. ...?" klar ;-)
BTW: Das Thema Mailserver an sich und v.a. der Bereich Umzug im laufenden
Betrieb AKA "OP am offenen Herzen" sind wirklich spannend. IMO bleibt aber
nur was hängen, wenn man's auch praktisch umsetzt. Ich habe im April 1999
innerhalb von 2 Tagen verdammt viel gelernt, weil ich mich nur mit bisserl
Fachwissen und maßloser Selbstüberschätzung gewappnet daran gemacht habe,
meinen damaligen Brötchengeber per sendmail ans Netz zu klemmen und intern
hübsch kaskadierend noch diverse andere Mailserver (fast durchweg auch mit
sendmail) mitspielen zu lassen.
Es ging *gar nix* aber ca. 48 Stunden später nach wenig Schlaf, viel Hektik,
der Erkenntnis, daß man auch gestandene Solaris-Server locker alleine durch
hundertausende Bounces in die Knie zwingen kann, waren die Themen DNS, SMTP
und sendmail-Konfiguration durch... und die Erkenntnis gewonnen, daß man
sowas besser den Fachmann machen läßt ;-)
Gruss,
Thomas, auf dem Weg halt _aus Versehen_ selbst zum Fachmann mutiert und sich
dann noch in Sachen MIME (RFCs 2045-2049) per selbst programmiertem SMTP-
Client sattelfest gemacht habend...