MaxExchange versus VPN access

Hey, Psycho.

Even at cable/DSL speeds you probably won't be happy accessing Maximizer directly over a VPN link. See here for more discussion on that.

Reports are that Terminal Services works well once it is set up, although AFAIK Maximizer still doesn't officially support it because their preferred solution is...

MaxExchange. I stopped using it a while ago, so I can't really comment on its current state. I'm told that it's much more reliable now than it was in previous versions, but I can't personally vouch for that.

Hey Gord,

Thanks for the reply and link. OK, VPN access is off the menu. But you have me worried with reliability of MaxExchange...

Please tell me more about the problems you had, especially anything that involved corruption to the main address book. Also I'd be VERY interesred in hearing from anyone using MaxExchnage with Max7.5, as to how well it works in real life...

Pasta

We have a number of clients using MaxExchange 7.5 and have found it to be extremeley reliable, have never seen main database corruption oursleves. It also has the advantage of enabling users access to the Db even though they don't have an internet connection available.

FTP is our preferred transport method particularly when we have users all across the country. Most of our clients are using a dedicated box as the MaxExchange server

If your users are from the same office sync'ing over the network is also very reliable.

I would avoid e-mail transport if possible we only have one client still using it. With all the security issues these days Outlook is a moving target and I have heard that all clients need to be running exactly the same patch level. This can be very hard to control on an individual user basis.

Our experience is thumbs up!

>Please tell me more about the problems you had, especially anything
>that involved corruption to the main address book.

In the ~4 years that I fought with it, corruption of the main Address Book was fortunately not one of MaxExchange's preferred modes of failure. It was the remote copy that would get out of sync with the main AB, and in many cases the only way to fix it properly was to send a refresh to the remote site. Unfortunately (for me) the database in question was several hundred megabytes in size, so sending a refresh to the branch office was a non-trivial exercise.

To avoid turning this into multi-page tirade, I'll just summarize by saying that the versions of MaxExchange I was using (4, 5, and 6) were NOT fault-tolerant. Not even close. I got sick of it breaking on me, so I bailed. I've since been told that Maximizer has put a lot of effort into improving the performance and fault-tolerance of MX7.5, but I'll leave it to others to comment on their own experiences with that version.

THIS IS A TIMELY TOPIC FOR ME AS WELL. THANKS FOR EVERYONE'S INPUT!

Gord makes some good points, early versions of MaxExchange did not support FTP and remote users often used e-mail to sync. Using this method data packets are broken up into smaller packets sent as e-mail attachments and re-assembled at the remote. Refreshing the remote could result in hundreds of e-mails, and all the associated problems with that. With FTP or network sync'ing that isn't a problem.

If the remotes sync regularly data packets are generally small and sync'ing is fast because only changes are sent. Refreshes or setting up a remote user across the country can still present a problem. We have a company with remotes all over N. America. Local users are not a problem we sync them over the network, then change the transport method to FTP and hand over the laptop. Where that is not possible we copy the refresh to a CD and courier it to the client. For some of our clients the db is too big to fit on a CD so we have them download the refresh from our FTP site.

From my experience here are some things to watch for:

Large databases - Plan ahead how you will handle large refreshes if you can't do them over the network or save to disk
Sync only what the user needs - It's asking for trouble to sync a large Db when the user only needs a portion of the Db
User trainiing - make sure they understand regular sync'ing keeps things small and fast
- Importance of MaxExchange Distribution field - used to track what get's sync'd - use default entry feature.
- How Opportunities get sync'd
MaxExchange Server - If you can't provide a dedicated box make sure the machine used is not running a bunch of other intensive apps., adequate disk space etc. for de-compreesing large data packets
- recommended specs are minimum.

Les..

We're using Max 7 under Terminal Services and it seems to be working well. There were definitely teething problems and you need someone who really knows Terminal Services. I really like the centralized admin this offers - the idea of managing multiple client installs through upgrades etc. is my nightmare. Security is also better, as there is no longer any reason for local storage of files - someone leaves and I simply disable their single password.

Hey, Rooster,

That's an interesting idea. Can you give me some idea of what is involved with getting this working?

We currently use NT4 server: I guess we'd need up move to W2k or 2003 server to get Terminal Services? And run Pervasive Server too?

An outline of the infrastructure required would be really useful.

Pasta

I'm the business guy, so I'll send and email to our IT guy and see if he can help.

- R.

You would have to migrate to Win2K or Win2K3 if you want to use terminal services for this. I'd recommend Win2K3.

Depending on number of users, I would recommend that you run Pervasive Server or the SQL Server engines. The database and pervasive/sql server engines SHOULD be run on a seperate computer from your terminal server, mainly due to performance overheads - though with the server versions of these engines, this is not a requirement. Again, this decision comes down to number of users, as well as resource requirements for any other apps that they will be running via terminal services (Office, e-mail clients etc.).

Also, if you have a large number of remote users, then you'll need to ensure that you have sufficient upstream bandwidth accross your WAN, though one of the nice things about TS is that it doesn't require an exorbitant amount of bandwidth to be useful - technically, you can run it over dial-up .

If you've never dealt with TS environments before, you should start by going through the MS guidelines for implementing Terminal Servers in Application mode - specially server sizing, licensing etc.

Since you're still running an NT4 network (domain or otherwise), the licensing and upgrade costs are probably the first things you need to look at, inluding all the different MS upgrade paths available. Though one option you have is to run in Mixed Mode, and delegate one of your existing NT4 servers to be the database server, depending on your current network design and on whether you have enough overhead to go this route.

In other words - yes, terminal services may be a technically practical solution for what you want to accomplish, but it may not be a fiscally practical option . And we haven't even got to the testing and implementation stage yet - you DON"T want to just throw this together and chuck it into production; with Maximizer, you should give yourself enough time to work through all the inevitable teething issues.

This probably raises more questions for you than answers, but hopefully it gives you place to start...

Hi nis-amer,

Thanks for the reply. I gives me enough of a pointer for where to go next.

-Pasta

Having recently tested and then implemented Max7.5 on a live Win2003 Terminal Server i would agree and say this version over Win2k.

Just as an after thought, it went alot smoother than a Win2k Terminal Server install.

Regards
Maxtalk Administrator