[CentOS] Re: Using CentOS as a file server on a win2K domain -- nothing to do with alternatives

Bryan J. Smith b.j.smith at ieee.org
Thu Jul 28 19:55:38 UTC 2005


[ We really need to take this off-list ]

Les Mikesell <lesmikesell at gmail.com> wrote:
> Outlook does reasonably well at this as of the office2003
> version

Of course, because Outlook 11 (2003) is the first re-write
of Outlook since Schedule+.  They actually "cleaned up" a
_lot_ of the security.

> with exchange I'd be surprised if the same applies to
> using connectors to other servers.

Depends on how much Microsoft wants to prevent other
products from working.  This is really turning into a
"circular reference" and I can't explain it to you any
better than I have.

> I could have sworn I had 2-way transfers working between
> evolution and Outlook2000 configured for internet-only.

Ah ha!  There's the key!  "Internet-only"!
You can't have Outlook in "Internet-only" mode with Exchange.
You have to use "Corporate E-mail" (MAPI/XML-RPC) mode.

Bynari actually used it in the former, which massively
improved _reliability_.  MAPI is not reliable at all.  I'm
sure Microsoft has been playing games to head off Bynari.

> But I gave up on it because it didn't interoperate with
> OutlookXP 

Are you starting to understand why I call it "Hostageware"?

If you are going to stick with a product, stick with a
product and try to work.  If you expect
Freedomware/Standardware to work with the latest Hostageware,
I don't know what to tell you.

> which some people were starting to use and 
> Evolution kept forgetting to pop the reminders and then
> would do several days backlog at once.
> I can't duplicate it now with Outlook connected to
Exchange.

Correct, because Outlook isn't in "Internet E-mail only"
mode.

> A notice sent from Evolution shows the Vcalendar item in
the
> body of the message instead of an attachment both in
outlook
> and when pulled back to evolution via imap.

Of course.

Just like MS Office for Mac has little trouble reading MS
Office for Windows documents, but not once you send it back
to MS Office for Windows.  Because the Mac version can read
anything, but not the Windows version.

Some of it is intentional.  Some of it is sloppy, non-aligned
x86 programming (e.g., MS Office for Windows -> Mac, ask some
of the developers of the Mac suite what they think of their
counterparts on the Windows version ;-).

The intentional and unintentional inability of software to
maintain even proprietary standards means its _worse_ than
proprietary, but takes your data hostage.  Slowly newer
Freedomware/Standardware reverse engineering services,
protocols and formats, but by the time they do, you're off to
a new version.

Keeping with the latest Outlook version is your problem.

> No, those don't quite describe my problem.  My personal
> problem is that I believe something works when I see it
> working on a reasonable scale.

Because Microsoft defines that scale.
They have you believe that you:  
A) Must have the latest version of Outlook
B) Can only get everything you need from its
Back-end/connector
C) There are no alternatives for either on any platform

Scheduling has been done before Windows, after Windows with
non-Microsoft tools, after Windows NT/95 with non-Microsoft
tools and all-of-the-sudden, Exchange/Outlook appears, and
people think it's the only thing.

Maybe you used Groupwise (which was an issue early on) and
that's why.  But there are countless other server and/or
client software out there -- many of which works with
Outlook.

In a nutshell:

While you wait on the edge of your seat to see if the next
version of Outlook does what you want, many of us have been
doing what you wish for long before it was ever considered at
Microsoft.  Why?

Because Microsoft isn't about delivering new, innovative
solutions.  They are about delivering someone else's
innovative solution exclusively and preventing other access.

> I've seen outlook2003 working with disconnected views of
> shared and personal calendars that sync with the server
when
> connected.  That's just a part of the feature set I
> mentioned, but one that I haven't seen anything else do.

I'm sorry that is the world you live in.  At this point, I
think it's just to let this go because I can't help you see
it otherwise.  Each time I try to explain, you put it back in
marketing terms that Microsoft could kiss you for.

> That's outlook vs. outlook in internet server mode that
> fails. All versions of outlook interoperate when used with
> Exchange server,

And most versions of Outlook interoperate _better_ with a
number of "open" collaboration servers, especially with
non-Outlook clients.

> but pre-2003 versions have other bugs especially in the
> sync-for-offline use configuration.

Correct, because Outlook 8 (97), 8.1 (98), 9 (2000) and 10
(XP) use the _same_ codebase.  Outlook 11 (2003) is the first
re-write since Schedule+ (4.x and 7/95).

> I'm not at all a fan of Microsoft but outlook2003 basically
> works. 

And many other solutions work very well.
The question is that are you willing to look at them?
Or are you insistent that they must work with the latest
Outlook version?

If you have a _true_ scheduling backend, then you can
use the _server_ to communicate scheduling updates.
You don't need the client to do so, which is what
Exchange-Outlook do.

And you don't even need Outlook (although it's typically
an option).  There _are_ other add-ons/MAPI SP capabilities
that do this "automagically" and better, and did before
Outlook 2003.

Of course, as with anything, you're going to have to pay
for it.  But a few of the solutions do use an open server
and an open back-end/store.  It's really up to you.

I can offer you a way out.  If you have pre-dispositions
of what you can or can't do, I can't help you.  I can only
make suggestions, send you information, but it's going to
take yourself and some trial software to see if it works
for you.

But if you're using Outlook 11 (2003), I don't know what
to tell you.  Some of the MAPI SPs are just catching up.
And I haven't checked out Bynari recently.

> Until recently we were a small company and the costs of an
> exchange server mattered so we didn't have one.  Now we are
> part of a larger company with a huge existing
change/outlook
> infrastructure and I don't see it going away.

Then _what_ was this post about? 

> However, I'd prefer not to need windows on my desktop to
> access it

Remember this creedo:  

  Linux and other Freedomware will _never_ be a better
  Microsoft solution for the latest, Microsoft designed
  services than Windows.

It is a better OS, it offers many better services --
especially for older Windows releases and services that
Microsoft has dropped compatibility with (remember,
"Hostageware" doesn't maintain even proprietary standards),
but if you insist on using the latest Windows solution, and
working with it, not going to happen.

Examples ...
- MS Office for Linux compatibility would suck as bad as MS
Office for Mac does
- Different SMB clients (especially prior to NT5.1/XP/2003)
have serious issues with newer Windows (NT5.1/XP/2003) itself
- And countless others

> and the only likely approach to that looks like Evolution
> with the exchange connector which won't work until we
> update to exchange2000.

Or you could choose to go another route, while you still have
Exchange 5.5 and can move into a non-ADS tied service.

> Exchange2000 is supposed to be much better too,

Man, re-read that.  ;->

BTW, I'm still waiting for Microsoft to fix serious security
holes with ESMTP from Exchange 5.5 that _still_ plague
Exchange 2000.  I have _refused_ to personally deploy
Exchange  myself since 2000.  I will only build services
around it, largely to fix its difficiencies (e.g., I never
put Exchange's ESMTP on the Internet).

> but the nature of web access means that the client can't
> be as responsive as something native.

But what is "native"?  OWA just provides the "native"
connector in a HTML form.

> Besides, laptops need to continue to work when offline.

And from what you have stated, you have asserted that only
Outlook 2003 does this as if Microsoft is the first ever.
That's the circular reference here, I can't break through.

> I'm not interested in touching every client.

Then you're a leading-edge Microsoft shop.  And being a
leading-edge Microsoft shop means you use _only_ Microsoft
and Microsoft partner products.  I can't help you, that is
your fate.

> But then if you are offline you are out of business.

The off-line client _can_ still send updates to the server! 
Why are you asserting otherwise?

I mean, do you honestly believe that Microsoft is the first
company to address this with Outlook, and have only done it
now with Outlook 2000?

Understand a Mail API (MAPI) Service Provider is the local
connector between the server's back-end and Outlook.  There
is no "MAPI protocol" -- it's an inter process communication
(IPC) that runs locally on the client, almost always a DDL
(built with Microsoft's commercial tools/kits).

It can make the remote mailboxes look as what it wishes,
connection or not.

> Microsoft bugs have caused enough trouble for me in the
> past that I'll never be pro-Microsoft, but I'm trying to 
> stay vendor-agnostic on this issue.

Actually, I would say you're very much vendor-aligned.
What you're expecting is Freedomware/Standardware to be
Microsoft-aligned, not vendor-agnostic.

To a point, many vendors have licensed the MAPI tools and
kits and built MAPI SPs and other services to provide the
client-side interoperability.  Some put logic in the server,
some put it on the client.  Exchange itself puts it _all_ on
the client -- be it Outlook or OWA.

More "enterprise" solutions put it more on the server, or
outside of Outlook, even when Outlook is in-the-loop.

> Outlook2003 seems to have the obvious bugs fixed so
> replacing it would only make sense if it saved money
> or added functionality.
> More importantly in this situation, management people
> already use it and are happy with it,

Then you're a leading-edge Microsoft shop.  Accept it.
Don't fight it.  You're only going to get frustrated and
make the assumptions like you just did -- that there's
no alternative.

E.g., I don't think Ford is useless because they don't
provide parts that work on Chevy's.

> and I think the eventual upgrade to Exchange2000 or newer
> will allow Evolution to work for more than imap.
> But, I'd still like to know about other alternatives for
> interoperability.

But this thread started as Exchange being tied to ADS,
and how you don't need ADS if you don't use Exchange.
How we've gone all the way over to your wish of Freedomware/
Standardware to interoperate better than Outlook itself can,
with Exchange and other Outlook clients, I don't know what
to tell you.

> If the discussion sounds pro-Microsoft it is because the
> alternatives mentioned so far aren't all that attractive.

I rest my case.  You are _not_ looking for alternatives.
You are looking for an e-mail/PIM client on Linux that
interoperates perfectly with Exchange servers and Outlook
clients.

This has _nothing_ to do with Freedomware/Standardware
not offering an equivalent to Exchange and/or Outlook.

Let's take this off-line.



-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)



More information about the CentOS mailing list