I forgot to mention that you can use the software for free for 60 days and then it's $20 a license for 1-9 licenses.
Click here to see the full license structure: http://www.fileviewer.com/Order.html
I forgot to mention that you can use the software for free for 60 days and then it's $20 a license for 1-9 licenses.
Click here to see the full license structure: http://www.fileviewer.com/Order.html
I'm sure that other people have had this same problem, but I haven't yet been able to find a good solution for it.
We are running Exchange 5.5 SP4 with all of the latest hotfixes (as of 3 weeks ago anyhow).
When remote users connect to the Exchange server using Outlook in MAPI remote connection mode (cached Exchange server mode in Outlook 2003, Offline folder (.OST) mode in previous versions) and try to download a message with a large attachment, their Outlook basically stalls and takes far longer to download the email than it would using POP3.
The users are connected to the internal network using Netsecure VPN software and our firewall is a Netscreen 10.
I don't want to open the holes in the firewall necessary to connect to the Exchange server over RPC because that is a very big security risk. In a few months, after I get everything moved to Active Directory and Exchange 2003, this won't be an issue because of RPC over HTTP, but until then it is an issue.
I have tried the methods suggested in the Technet Document: MS Exchange Server and Outlook: Optimizing Messaging Client Performance, but that hasn't solved the problem.
I see some other things to try in this document about using Outlook 2003 in Cached Exchange mode, but if anyone has any other ideas, please let me know.
One of the problems of being a larger small company (greater than 25 but less than 50) is that most software isn't priced for us. Take SQL server for instance. At a cost of about $7000 per CPU for an unlimited user license (which you need if you have more than 25 users), it is very expensive.
Sure we could buy the Small Biz Server package, but that has some big limitations. It isn't very flexible everything has to be run on one server oh and last time I checked, you were locked into it.
No way to move users and their Exchange data, for instance, off of a SBS server and onto a standard licensed server. Perhaps they changed this after SBS NT, but that was the last time I used it and so am not quite sure. Never have liked the limitations that you had to live with in that product anyhow. Makes sense for a business smaller than 25 people, but NOT if they ever expect to grow larger (startup anyone?).
At any rate, we now have some products that require the use of a SQL server or at least the MSDE runtime of it. We don't currently want to shell out $7000 for the license and $6-7000 for the hardware to run it (server with 2 drives for the OS and 6 for the data).
So we are using the MSDE runtime (OK, this isn't exactly doing it right, but it saves us $14000 in the short run and we probably don't need the full blown license at this point). The MSDE runtime is basically a neutered SQL engine that doesn't come with any of the cool GUI tools, has some limitations on number of databases and isn't as scalable as SQL Server.
It wasn't exactly easy to work with at first. This was my first foray into SQL Serverland and so I had to start from scratch on the Microsoft websites (ain't MSDN grand?). Quickly learned that the command line interface for SQL kind of sucks. So I kept poking around on MS's websites and lo and behold! I found that they offered a web based GUI version of their Enterprise Manager tool.
It's called the MS SQL Web Data Administrator and it gives you most of the functionality of the GUI tool that comes with SQL server and best of all it even works with MSDE! You can either find it on Microsoft's website by searching for "SQL web data administrator" or go to this link: http://www.microsoft.com/downloads/details.aspx?FamilyID=C039A798-C57A-419E-ACBC-2A332CB7F959&displaylang=en.
Some people will probably think of me as a lazy admin for not trying to set the server up with the CLI tools, but sorry, I work much better in a GUI and the proof is in the pudding. Messed with the server for hours trying to get things working with the CLI. Took me around 30 minutes to figure out what was what in the web data GUI.
I'll take a well made GUI any day over a well made CLI. Although most CLIs aren't well made - not intuitive at all and very little documentation. Whereas GUIs are better since they display much more of the interface and since it's visual, you typically don't need much documentation.
So my first dealings with SQL weren't too bad, I suppose. Once I got the right tool that is.
BTW the two pieces of software that we need SQL for are CompuLaw's Vision SQL calendaring software and KI Systems Word Template Package that also includes a contact manager set up specifically for law firms.
For those of you who work with Exchange 5.5 on a regular basis and have logging on the Internet Mail Service turned on enough so that you can see what is going on in order to troubleshoot problems when they arise, you probably have run into the situation where the log files get very large.
I haven't yet found a way to have Exchange 5.5 automatically start new logs in a certain time period and if you forget to do it manually every week, the log files can get to be larger than 1 gig. This presents a problem when you have to go into the log to figure out why a message didn't get through or why an attachment didn't get decoded properly.
Notepad can't open text files that large and Wordpad chokes on them as well, even if your system has the resources to open a file that large.
Well thanks to a link on Joel Spolsky's web page I found this sweet little file viewer called V.
It breaks the text file up into small chunks that are instantly accessible on your system. I'm currently viewing a log file that got to the seriously obese size of 1.8GB without problems on a system with only 512MB of memory.
Way cool.
Recent Comments