Carlos Arellano wrote:

Use samba is easy think to do.. http://us4.samba.org/samba/

I know, but I don't want to manage users on 2 servers... What helps with that? Winbind?

On Wed, 2005-07-27 at 14:22, Bryan J. Smith wrote:

...

I know, but I don't want to manage users on 2 servers... What helps with that? Winbind?

PREABMLE: The fact that you have chosen Exchange 2000 means you are _stuck_ with Active Directory Services (ADS). Unless you want to chuck Exchange, you are _stuck_ with keeping your ADS.

You use 'chosen' above as to suggest that there are equivalent alternatives. Are there - for an organization that lives and dies by the scheduling features and shared folders in exchange?

• Winbind
• Simultaneous ADS and NsDS
• ADS-NsDS Synchronization

Is there some reason you omitted SFU from this list? Recently you said it would work in a similar situation to act as an NIS server with the Linux boxes as NIS clients. And by the way, does anyone know if there are any client license fees for the things provided by SFU?

[ DISCLAIMER: Just so everyone notes, I did _not_ start this tangent. My post was that if you choose Exchange 2000, you are stuck with ADS -- that's a technical fact, pure and simple. ]

On Wed, 2005-07-27 at 16:13, Les Mikesell wrote:

You use 'chosen' above as to suggest that there are equivalent alternatives. Are there - for an organization hat lives and dies by the scheduling features and shared folders in exchange?

This is the type of marketing I'm talking about. Assumptions that Linux can't do something.

Major universities and corporations were deploying LDAP and collaboration with 10,000 of thousands of users _years_ before ADS existed.

"Scot L. Harris" webid@cfl.rr.com wrote:

Like the ones listed here? http://www.linuxjournal.com/article/8333 Note: I have not used any of these but they appear to address most functions currently available via the windows alternative.

The key to understanding Exchange is to break down its _base_ technical features ...

1. X.500 DAP Directory, integrated with LDAP in ADS/2000+ 2. Proprietary MTA, plus IETF ESMTP, POP/IMAP features 3. MAPI and, more recently, XML-RPC store

It does _not_ do scheduling. _Client_ side scheduling (_not_ Server** side) is done, using the store -- be it by Outlook or via Outlook Web Access (OWA). Exchange has _never_ been a server-side scheduling system.

To get equivalent, you want: 1. An IETF LDAP Directory 2. IETF SMTP, POP/IMAP and other features 3. A server-side store 4. [Optionally] A server-side scheduler

#1 and #2 should be obvious, especially if you already have NsDS, Sun One (uses NsDS), etc... deployed in your enterprise.

For #3, there are a variety of options.

Most use a WebDAV (HTTP) store nowdays, because there are countless WebDAV implementations for various things. More on that in a moment.

Bynari InsightConnector (Outlook plug-in) uses a rich, non-email store over IMAP, although the format has changed. Kolab 1 used the same IMAP compatible store as Insight Connector. I believe newer InsightConnector, as well as Kolab 2, are completely different (never personally used these).

Calendar Access Protocol (CAP) is slowly becoming de-facto store over WebDAV for calendar information. Many systems maintain their own, proprietary or non-proliferated formats, even if they use WebDAV.

For clients that don't support standards protocols, a "connector" is needed. E.g., for Outlook, a MAPI Service Provider. That's how 99% of Exchange Alternatives work, and are _just_as_proprietary_ as Exchange. In fact, most of then _only_ support Outlook/MAPI, and do not work with other clients -- i.e., the store is very much proprietary and Outlook-only. Because these "connectors" use Microsoft code to support Outlook/MAPI, they are _never_ GPL.

The problem is Outlook/MAPI, not the server.

The key is to ensure the "back-end" server store is open, which WebDAV+CAP is. Even if you use Outlook, you can still have this, although you're going to pay for the "connector." But at least the store will be in an "open format." Beware that even if IMAP store is used instead (e.g., Bynari), it's not a guarantee that the data is "open" (older Bynari/Kolab1 is).

#4 is actually _rare_. In most systems, including Exchange itself, the _client_ does the scheduling resolution, _not_ the server. It seems like the server does, but it's actually just a "dumb store" in many cases. There are facilities outside the store -- be it a client, or an add-on product -- that uses the store and makes it seem like the server is doing it.

Probably the best "Freedomware" (for #3 with #4) solution is OpenGroupware.ORG (OGo), a release of SKYRiX v4. The server-store is WebDAV (although not CAP yet for Calendaring). It provides various interfaces -- from an intelligent web to its own XML-RPC to Palm.NET (yes, synchronize Palm _directly_, without a "host") to Evolution to Outlook. In the case of Evolution, a "connector" is used (but is free). Same deal for Outlook (but it is not free).

Since the server/calendaring store is in a "unified open" format (unlike most Exchange Alternatives), OGo can and does do _true_ server-side scheduling. This includes direct web, Palm, XML-RPC, Evolution and Outlook scheduling at the _server_, which the client then synchronizes with. Systems that don't do #4 rely on the clients to handle updates to the store, which can create a _mess_ if one screws up.

On Wed, 2005-07-27 at 18:23 -0500, Les Mikesell wrote:

Maybe... Most 'groupware' doesn't do quite what the Exchange/Outlook combination does. One feature that is important to the group I work with is that emailed meeting requests show up in the outlook personal calendar whether the email is opened/accepted or not, and that public calendars can accumulate and show what a group of people will be doing. For example we use one for 'scheduled maintenance' for a large group of people making changes on any network equipment or servers so it is possible to notice potential conflicting changes and back out things if problems are found later.

A _true_ server-side scheduling system will do quite a bit more. Whether or not Outlook is able to represent it is a combination of the MAPI Service Provider or other add-on, and Outlook itself.

On Wed, 2005-07-27 at 18:28 -0500, Les Mikesell wrote:

Do these require extra client-side software installed on every machine?

Of course! Do you think Microsoft would allow anything to be bundled with Outlook that didn't require Exchange? First rule of distribution control, _deny_ your competition. ;->

The reality to remember if you are going to move away from Exchange:

1. Get an open server backend (99% of Exchange Replacements are _not_)

2. Your primary driver should be non-Outlook support -- e.g., Evolution, Palm.NET, etc...

If you're looking for a Freedomware product to remove the fact that you're using a Hostageware client, I think you're not looking at the problem correctly.

Going back to the _original_ post, the reason why Microsoft tied all 2000+ Services to ActiveDirectory Server (ADS) was to corner everything into a Microsoft-only back-end/front-end.

The solutions are out there. But Microsoft does everything it can to prevent Outlook from working with many things. Bynari seems to stay "one step ahead" though, much to the delight of IBM.

On Wed, 2005-07-27 at 23:46 -0500, Les Mikesell wrote:

The recipients don't have to use the same server for meeting requests to work, although when creating one you only see the availability of the people that are.

That's because the servers synchronize their stores. In fact, server distribution is why Microsoft doesn't do server-side scheduling. They merely replicate the stores.

The clients then use those stores. That's why when you are creating, you are limited to seeing only the availability of those people. ;->

Now if you're using "Shared Folders" inside of the client itself (client attached meta-data for calendaring info), that doesn't require a server at all. Of course, most of that automated functionality _breaks_ if you install security patches for various Outlook versions and lock them down.

Evolution supports the standard vCalendar attachment for scheduling without a server-store. Unfortunately, pretty much _nothing_ else does. |-<

What I really want is interoperability among clients, not leaving outlook behind.

As I said, that's the problem. The best way to mitigate is something like OpenGroupware.ORG (OGo). It has a _true_ collaboration back-end. It's based on the source code release of SKYRiX 4, not quite as good as SKYRiX 5, but still one of the bests Freedomware suites out there.

Although you still have to pay for the MAPI Service Provider for Outlook.

When outlook is used in a smtp/pop/imap environment some versions will interoperate with evolution calendar when meeting requests are sent.

Yes, because Ximian is very resourceful, and they've been able to learn how to read the "Shared Folder" attachments inside of Outlook e-mails when they don't have a server store to put them on.

However, when using pre-2000 exchange server and evolution working with it in imap mode, all the attachments show up as non-standard tnef's instead of mime vcal/ical format.

AFAIK, Outlook-TNEF don't do vCalendar, but a variation.

iCalendar (iCal) is not a MIME attachment format, but just way to read (via HTTP) and publish (via FTP) free/busy time.

[ BTW, I forgot that OGo _does_ iCal as well, and can use it for its server-side scheduler with the other stores/methods/interfaces. ]

I'm looking for something that will eliminate the need to keep a windows box on my desk just to beep at me when I'm supposed to join a conference call.

In other words you want a way for Freedomware/Standardware** clients to keep up with the moving target of Hostageware** clients/servers that are being mandated in your organization. It's one thing to expect Freedomware/Standardware** to work with Commerceware**, because Commerceware vendors value their customers and won't break compatibility between versions. But Hostageware vendors do precisely that with each version, to _prevent_ compatibility.

Gartner said it best (paraphrased), "Organizations must be vigilant in Open Source adoption, as a vendor will never offer a way out of lock- in."

That's why I call it Freedomware. User vigilance is not an option left to others. It requires effort against Hostageware vendors.

[ **NOTE: Yes, these are my own, eccentric terms. Freedomware (Open Standard, Open Source) Standardware (Open Standard, Proprietary Source) Commerceware (Proprietary Standard, Proprietary Source) Hostageware (Unmaintained Standard, Unmaintained Source) ]

However I expect most of the other people involved to keep using outlook.

Which means you foresee interoperability with Hostageware in the future. That's the problem.

But, exchange2000 will probably work right with evolution as the client. Does anyone know if the notifications and updates get into the evolution calendar when received even if you don't open/accept the request?

Good question.

Because Exchange is _not_ a server-side collaboration system, but only a store for client-side collaboration, the question becomes ... - Does the Outlook client making the request do this? - Or does the Evolution client receiving the request do this?

Now exchange _is_ an e-mail server, with e-mail rules. So it might be tied into this and the user store. It's a good question.

On Thu, 2005-07-28 at 01:53 -0500, Les Mikesell wrote:

That's only a factor on the availability side. Often you have to just pick a time anyway and let the recipients deal with conflicts. What I mean is that outlook will send meeting requests to email destinations on servers that don't sync and it goes into the recipient's personal calendar regardless.

Okay, then that's the e-mail attachements. Because still, same concept, scheduling is done by the client (Outlook) itself. Whether Outlook retrieves from a server store, or receives an attachment.

Right, but personal calendars still work whether you share anything or not.

Correct.

Outlook will do this too when used without an exchange server. However different versions don't even interoperate with themselves.

EXACTOMUNDO! Read up on Outlook Shared Folders and attachment format. If you connect to a server store, at least the store enforces _some_ interoperability. But not in the attachments.

That's why I don't even call it a "Proprietary Standard," but an "Unmaintained Standard" (hence Hostageware). Again, there is some documentation out there on how different versions of Outlook vary from vCalendar and don't even interoperate with themselves.

The office2000 version has a bug in the mime format that is fixed in the xp/2003 versions but they don't work right with each other.

Ever since SR-1e for Outlook 98 broke Shared Folders, I _always_ use a server store. That's where the MAPI SP really helps "tame" Outlook. Bynari's InsightConnector does the same for IMAP.

Evolution works with these but it was too buggy to depend on back when I tried to use it that way.

??? To Evolution itself? Or just Outlook? Evolution does _true_ vCalendar, and I've _never_ gotten any other e-mail client to read what it sends out.

Hmmm, I think I was running some tnef->mime converter via procmail on my mail server when I had it working without exchange, but that was only needed when the outlook settings were wrong. I haven't found a way to glue that functionality into evolution itself when pulling messages directly from an exchange server via imap. I assume this is unnecessary when using exchange2000 and the evolution adapter.

Yes, because the connector lets Evolution just access the Exchange server store.

The email side is moderately standard. I think even the tnef cruft is understood well enough if someone wanted to deal with those attachments.

TNEF is just an attachment format, not an actual, end-application usable data format. It's like XML, which is just a standards format, not an actual, end-application usable data format. You can decode TNEF, just like XML, but can you understand the data format?

The problem is that Outlook does _not_ have a maintained Calendaring attachment data format.

The problem is that there aren't any great alternatives that combine the features of outlook/exchange and even if some are available now it is too late.

??? Please stop saying that. Honestly. Or at least rephrase it:

"The problem is:

A) There is no Freedomware server looks like Exchange from the standpoint of Outlook and transparently drops in without any client side changes, and

B) There is no Freedomware client that has to work with Outlook's Shared Folder attachments which aren't even a proprietary standard and have changed and seen incompatibility between different Outlook versions itself."

Much better.

How you went from admitting that Outlook doesn't operate well with itself to your above statement is beyond me. This is what I'm talking about when I say Linux people are sometimes Microsoft's best marketing agents.

As I understand it, the evolution connector to exchange2000 uses the webmail interface under the covers so the web interface might even play a part here.

Hmmm, interesting. So it act likes an Outlook Web Access (OWA) client? I'll have to read up on the Ximian connector. Novell opened it all up, and there have been additional connectors in development.

We're still on pre-2000 exchange

Then you don't need ADS! Great! Now's the time to switch!

and its web interface sucks,

Every Exchange alternative (even the proprietary back-ends) have a rich, integrated web client. I personally like OpenGroupware.ORG (OGo) because it's a totally open back-end with server-side scheduling -- including iCal, its own WebDAV (plus Evolution/Outlook connectors), Palm.NET, web and its own XML-RPC (don't know any clients that use that yet though).

The only issue with OGo is the initial installation. It's not fun.

so I don't know much about how the newer versions are supposed to work.

They use ADS' now instead of maintaining their own, internal X.500 DAP.

Anyway, I consider it a feature that outlook adjusts calendar updates like the time of a conference call when the mail is received even if you don't open the message.

Server-side scheduling can do this for you too. In fact, relying on client-side scheduling can be a coherency nightmare.

I'm not sure if I should discuss this further because everything I say something, you turn it into almost a pro-Microsoft viewpoint, which is quite the opposite.

[ We really need to take this off-list ]

Les Mikesell lesmikesell@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.

On Thu, 2005-07-28 at 18:29 -0500, Les Mikesell wrote:

Yes, I do understand that, but I don't see you listing a big set of other interchangable clients/servers. I'm even less interested in being a hostage to some other product that does not allow mixing clients and servers.

Huh? I said _many_ alternatives do. I listed OpenGroupware.ORG because it does _not_ -- it's extremely open on the back-end.

I also didn't see you mention any bug-free alternative.

???

I pointed out that when I was testing Evolution it didn't work right even on its own. Admittedly that was a version or two ago and I haven't tried the reminder notifications lately.

With Evolution or Exchange?

No - but none of the earlier ones worked with free or other vendor's clients either.

Not true. I thought I conveyed that. In fact, before Outlook 2003, there were _better_ connectors for Outlook than to Exchange.

Yes, we did have that here long ago, and yes that's probably why everyone likes outlook by comparison now.

Just like MS Word over Word Perfect 5.1 for DOS. Of course, some of use were running StarOffice in 1995. Did I mention I can still read my documents flawlessly 10 years later? ;-p

When someone shows me the scheduling server that can be transparently replaced with a different type because both use only standard protocols this argument will mean something.

??? I thought I basically laid that out with OpenGroupware.ORG (OGo) ???

I'm still trying to figure out what you mean ... you're liking holding up much, much higher standards than for Exchange-Outlook.

I just want them to drive on the same road.

That's like saying you want them to be on the same network, but they don't talk to each other. ;->

greetings,

please excuse my extreme lack of specific knowledge on this subject, yet what are large companies using that are not using on the M$ server side?

ummmmm and specifically, what does Redhat use to accomplish these goals that you folks are talking about?

i'm surprised that this specific question has not been asked before re: Redhat or other large companies that make their living via open source software or close proximity to it.

regards,

- rh

-- Robert Hanson Abba Communications http://www.abbacomm.net

On Fri, 2005-07-29 at 07:01, Bryan J. Smith wrote:

...

please excuse my extreme lack of specific knowledge on this subject, yet what are large companies using that are not using on the M$ server side?

Excluding Novell eDirectory (fka NDS) from considerations, _every_ Fortune 100 company I've been at either uses a NsDS based tree (including Sun One) for their enterprise, and syncs ADS to/from it, or segments with another LDAP solution (e.g., Netegrity, many others). The NsDS or other LDAP solution almost _always_ pre-dates ADS adoption, simply because it was necessary to manage countless numbers of users and systems.

Back up a step and I think you'd find that those companies had mainframe X.500 systems that predate any PC or unix implementations because at the time only a mainframe had the necessary capacity. Some may still be running the master copy on mainframes. Remember that the L in LDAP means 'lightweight' which only makes sense in comparison to X.500, and that from the start LDAP was designed to work as a tcp front end query mechanism to X.500 directories as well as a standalone database for smaller systems.

} Les Mikesell } Subject: Re: [CentOS] RE: Using CentOS as a file server on a win2K domain- } -nothing to do with alternatives } } On Fri, 2005-07-29 at 07:01, Bryan J. Smith wrote: } > } > Excluding Novell eDirectory (fka NDS) from considerations, _every_ } > Fortune 100 company I've been at either uses a NsDS based tree } > (including Sun One) for their enterprise, and syncs ADS to/from it, or } > segments with another LDAP solution (e.g., Netegrity, many others). The } > NsDS or other LDAP solution almost _always_ pre-dates ADS adoption, } > simply because it was necessary to manage countless numbers of users and } > systems. } } Back up a step and I think you'd find that those companies had mainframe } X.500 systems that predate any PC or unix implementations because at the } time only a mainframe had the necessary capacity. Some may still be } running the master copy on mainframes. Remember that the L in LDAP } means 'lightweight' which only makes sense in comparison to X.500, and } that from the start LDAP was designed to work as a tcp front end query } mechanism to X.500 directories as well as a standalone database for } smaller systems. } } -- } Les Mikesell } lesmikesell@gmail.com

maybe i asked the original question improperly and im almost sure this one isnt posed perfectly either.

what do really large companies use that do not allow or have 100% migrated away from "M$ windows servers" in their networks yet allow "windows clients" in their networks "and" must service all their windows clients needs just as *if* their were M$ servers on their networks?

does this make better sense?

i believe this is what everyone is getting at in all these threads and yet there appears to be no 100% functional open source solution right now, is there?

-- Robert Hanson Abba Communications http://www.abbacomm.net

"Bryan J. Smith" b.j.smith@ieee.org wrote:

Until Red Hat bought Netscape Directory Server, no, OpenLDAP left much to be desired.

But even still, you _can_ get away with 0% Windows Servers and _still_ implement a _lot_ of Windows client management using various directory services, Samba and/or pGINA, various open source tools, etc...

But no, if you want to use "User and Group Manager for Domains" from a Windows XP Pro client, and manage everything about your Linux server, that is _never_ going to happen.

I think too many people think the built-in clients that come with Windows are the only way to manage servers and systems. If that is the case, _no_solution_ will ever work except what comes from Microsoft, because Microsoft will _never_ bundle "open" (not even "open standard") tools.

Les Mikesell lesmikesell@gmail.com wrote:

Mostly you need to plan a 'forklift' upgrade where you toss all your old client software the day you replace the server - not something a large organization ever wants to do.

Not true at all.

In the late '90s, I used to run HP OpenMail to Schedule+ and, later, Outlook 97/98/2000 clients using it's MAPI SP.

Turn of the millenium, I used to use Bynari InsightConnector for Outlook 98/2000 clients using its more stable connection than a MAPI SP.

And there are countless other examples.

But no, you can't just drop in one vendor's solution for another without some changes. I don't know any solutions in the world that work that way.

But I can tell you it's far, far less painful to upgrade to a Samba server (and a _real_ enterprise backend) from a NT4.0 domain than to ADS.

You use 'chosen' above as to suggest that there are equivalent alternatives. Are there - for an organization that lives and dies by the scheduling features and shared folders in exchange?

Samsung Contact, and Open exchange are two very capable alternatives that work natively with outlook, i.e. outlook thinks it has an exchange server at the other end...

P.

Les Mikesell wrote:

On Wed, 2005-07-27 at 14:22, Bryan J. Smith wrote:

...

...

I know, but I don't want to manage users on 2 servers... What helps with that? Winbind?

PREABMLE: The fact that you have chosen Exchange 2000 means you are _stuck_ with Active Directory Services (ADS). Unless you want to chuck Exchange, you are _stuck_ with keeping your ADS.

You use 'chosen' above as to suggest that there are equivalent alternatives. Are there - for an organization that lives and dies by the scheduling features and shared folders in exchange?

...

• Winbind
• Simultaneous ADS and NsDS
• ADS-NsDS Synchronization

Is there some reason you omitted SFU from this list? Recently you said it would work in a similar situation to act as an NIS server with the Linux boxes as NIS clients. And by the way, does anyone know if there are any client license fees for the things provided by SFU?

...

Samsung Contact, and Open exchange are two very capable alternatives that work natively with outlook, i.e. outlook thinks it has an exchange server at the other end...

Do these require extra client-side software installed on every machine?

Yes, they need Outlook plugins to talk to the backend. eg: You can use open source Open Xchange on the backend but you still need to cough up the money for Outlook to talk to OX.