If you'd like to evaluate Kerio Connect, it is easy to do so without interfering with your existing email system. You'll be able to send and receive local mail within your local network using fake addresses like "email@example.com". Under some situations, you'll be able to send mail from the test system to people in the real world also (though you probably would want to set your Reply-To address to something real to avoid confusion). You won't be able to directly receive mail from the outside world without registering a real domain, but you can test calendaring, free/busy scheduling, mailing lists, public folders and generally every other feature of Kerio Connect that you care to test.
Note: this is also a method to test new versions prior to upgrade.
I often recommend this to new customers, suggesting that they set up a small group of testers who will evaluate Kerio Connect before deploying it to the entire company. They can test Webmail, PC and Mac mail clients, Outlook with the Kerio connector and even smart phones if they can use the local wireless LAN for connectivity.
For those who happen to have more than one public IP address, with just a little more trouble and very minor expense, you can register a domain and test Kerio completely.
What you need
Kerio Connect is available as a free 30 day demo. There are no limitations to the demo; all features are available.
First, you need to decide which system to download. You can run this test on a real or virtual machine, using Windows, Mac OS X and various flavors of Linux. There are also complete VMWare images with a Linux operating system included, ready to be loaded into VMware.
If you are not going to use virtualization, you can install the test server on almost any machine in your network. You don't really need to be concerned about horsepower here - mail servers don't demand a lot of CPU or RAM anyway, and certainly don't need much for a small test like this. This does not need to be a server class machine. If it will only be testing on the local network, you don't have to be concerned about the machine being awake outside of office hours and you probably aren't very concerned about physical or network security, either. You do want to read Kerio's System requirements page, but even there you might be safe fudging a bit for a small test like this.
The same advice applies to a virtual installation: you don't need to commit gigabytes of RAM in the virtual machine to deploy a small test system.
You will need to consider firewalls, conflicting software and possibly Anti-Virus software. Kerio covers all that in their Administration Guide, but you can also call on me for free help and advice in that area. It's best to schedule a block of time that is convenient for both of us, but if you do happen to run into an unexpected snag, just jump on the phone: I'm happy to help.
During the installation, you'll be asked for the domain name and the DNS name of the server. For this sort of test, you can just make up whatever you want: the domain can be "foobar.com" and the DNS name can be "testmail.foobar.com".
Why does this work? You can configure clients to use the server's IP address rather than its name, so they don't absolutely need to find the server in DNS. If the machine you are using already happens to be in local DNS, then you can use that for the DNS name.
You can also use your real email domain rather than a fake like "foobar.com" if you are only doing local testing. However, this has the potential to be confusing to testers, so I'd suggest going the fake route. You can do both: you can add multiple aliases and separate domains once you have installed the system initially.
Once you have access to the system by browser (https://server_name_or_ip:4040/admin by default) you can add the user names who will be involved in the test and do any other initial configuration. You'll note that you can add aliases - "tom_b" can be the same as "tom". This can be done in two ways - either in the Aliases section or as "Email Addresses" when configuring a user.
Although the functionality is identical, there are differences between these methods:
- An alias can be delivered directly to a public folder rather than to a user's INBOX.
- An alias can be "*", meaning that all unrecognized addresses will match.
- An alias can be "*sales*", meaning that all addresses matching "sales" will match.
- If added as additional email addresses, these addresses can be selected as the "From" address in Webmail and will appear in the searchable Global Address list.
This is a good time to have scheduled a conversation with me; I prefer to go over the initial configuration with you if possible. That usually only takes a few minutes and can save annoyance down the road.
If that's not possible, please do read my Basic Kerio Connect configuration guide as well as Kerio's Admin Guide.
Advanced: Kerio Connect can map (or import) users from a directory service. You probably don't want to do that for your test configuration, but do keep that in mind for later.
For your very first test, I recommend logging into Webmail (https://your_machines_ip by default). If you've created more than one email domain, remember that you'll need to add "@fakedomain.com" for any login that is not in the domain you designated as the "primary". If you initially setup an admin login at one domain and then switched another to be the primary, you may need to add "@fakedomain.com" for your admin also - see Locked out of Kerio Administration for more on that.
Send mail to the other users you defined; they'll be able to read it instantly in their own webmail sessions. Note that Kerio Webmail is cross-platform; it works with almost all modern browsers and supports drag and drop, and right click actions for many tasks. You can send and receive mail with your other testers, set up shared folders, calendars and use public folders. This should give you a good overview of Kerio Connect features
It may very well be that using webmail is sufficient for your testing. However, most potential customers will want to try out other email clients, so let's look at how you'd do that.
Kerio Connect supports POP3, IMAP and its own KOC (Kerio Outlook Connector, an Outlook plugin). For READING mail that was sent during your webmail testing, all you need to do is add a POP or IMAP account to your existing client. Use the test machines IP address for the incoming server and your normal outgoing configuration for the rest.
Advanced: if you use local DNS and can configure it to return an MX record for the fake domain AND are currently running another mail server inside your network, you don't necessarily have to do any special client configuration. Alternately, some servers (Exchange, for example) can be configured to know about local domains - see an example of that at my MMDF to exchange and back!. With this type of configuration, your client may be able to both send and receive mail from "fake domain.com".
New profile or new user?
You can add a new user to your client machine and setup the connection to the fake server that way. With some clients (Outlook being the best example), you can create an alternate mail profile for this purpose.
Either way, you are ready to start testing. If you want to take full advantage Kerio Connect with Outlook, you'll want to install the free Kerio Outlook Connector. This allows full access to all Kerio Connect features from Outlook.
I do want to suggest that you make use of Kerio's automatic configuration tools. You can access those from the Webmail login screen or at https://server_name_or_ip/integration/. These are the easiest way to configure desktop machines and I strongly recommend that you use them..
Your fake mail server may not be able to deliver mail outside of its own domain. It may be blocked by local network policy or may be rejected by the receiving domain. As mail arriving from a fake domain address would certainly be confusing, that's not necessarily bad.
However, if you really want to run Kerio Connect through all its paces, including smart phones on carrier networks, you may be able to set up a more complete test. You'll need to register a domain name or use one you already own that is not currently being used for email. If you are already running a local mail server, you'll need a spare public IP address for the server and your local network policy (and your ISP) will need to allow outgoing mail ports. If the machine is NATed behind a firewall, you'll need inbound port forwarding rules. You can call on me for assistance if all of that confuses you.
Alternately, you could install this test server in the Cloud and avoid any local issues completely.
You'd need to configure an MX record to route mail to this domain and you'll also want your ISP to provide a PTR record. Again. if these are not things you have done before, ask me for assistance - I'm happy to help.
I hope this guide was helpful and that your testing goes well. If you need more than 30 days to evaluate this, contact me and I can arrange for a license extension.
Note: I am only available to U.S. customers. If you are not in the U.S., contact a Kerio reseller in your country.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Anthony Lawrence
Find me on Google+
© 2012-07-02 Anthony Lawrence