Metropol

Not sure if such queries still work here, but they used to. So before I try anything anywhere else, here goes:

At work, our email server is still running Windows 2000 + Exchange 2003. It is very old kit without a 64 bit processor but it still works for what we need it for (our needs are quite small - we only have about 20 users) and so it has remained in service well past the point at which it should have been retired.

Exchange has been set up on this in a somewhat kludged way, but again it's worked that way for 10 years with no problems. Basically, Exchange is not directly connected to the outside world, all email addresses are simply local addresses and the server only sends/receives internally. Where we require external access, we have a third party piece of software which routes emails to/from external addresses hosted by our ISP which in turn translate to our own domain name through our domain service provider so that externally these emails are sent to/from [email protected] but internally these appear as [email protected]. This setup also means we can easily restrict access to untrusted users so that they can get a company email address for company communications without them being able to send emails externally in the company's name.

All the local machines connect to the server over the local network, and machines on other sites along with company laptops and mobile devices use VPN access so that the server thinks they are on the local network. This still enables us to have Outlook and mobile exchange clients running from outside the local network in this configuration. Access on non-company devices is by Outlook Web Access which is enabled simply by changing the port in IIS to a non-standard one (to give a modicum of security rather than just leaving it on 80), opening that port on the router and forwarding it to the exchange server. External users then simply go to company.com:<port>/exchange and can log in from outside.

We are finally migrating to a new server with Windows Server 2008 R2 + Exchange 2010. I've set up a test box and initially I've just been trying to replicate what we already have. I've succeeded apart from external access to Outlook Web App. I note that this is set up to use SSL now. I've tried opening the default port 443 for HTTPS on the router but company.com:443/owa doesn't work, it just 404's out. I am wondering if there is a compatibility issue with https sites on our external domain so was trying to see if OWA could be set to use standard http without SSL but can see no option for this.

Does anyone learned in such things know if this is possible?

I wonder, given the scale of your implementation you are using the correct approach?

Personally, I would just use Office 365 for what you are trying to do, the cost is peanuts compared to maintaining a full exchange and backing it up etc etc.

You haven't got to worry about anything then. The cheapest option is just over £3 per user per month - you can connect a full fat client to the account if you desire, but the browser interface is so usable i only have a handful of people using the full client, and they are PA type people who use the calender, which is as bit nicer in full fat outlook.

I'm not sure of the gradations of back end functionality of all the plans, but it certainly is possible migrate an on-site exchange server to Office 365 and syncronise all the accounts with your active directory if you wish.

In my implementation, I actually just use a simple csv file to add take users away from (as not all users in our directory need an account) and this works very well for us. I don't really have to worry about anything.

But, I suspect, given your question you might be too far down the road to consider that now.

I think there are a couple of approaches, you could, in theory, virtualise the old Windows 2000 implementation on your new server in the short term.

This will give you time to polish your Exchange implementation or decide on what you want to do and give you breathing space just in case the old server dies. I have done this with legacy servers in vmware that i can't upgrade but need to keep running. It works well for me.

Regarding the external access, I believe you have to have a correctly signed wildcard SSL certificate from a trusted registrar for your domain - you'll have to do some additional configuration if your internal and external domain names don't match.

I never got to the point of any external testing with Exchange, but I implemented my companies remote access platform using a Windows Server 2012 RDS Gateway server and Windows Server 2008 R2 Session Hosts (to give the users a WIndows 7 like desktop experience) and that would not work externally without a certificate. Ours cost about £300 for 2 years. Our internal and external domain is different also.

Personally, I think email is one of those commodity things that is best left in the cloud, given the almost universal access requirements - use your new server to give your local storage and infrastructure a boost without the monumental drag of Exchange.

As you say, the problem was that the SSL certificate was self-signed and the browser I was testing was set up to reject this. In the end I did get it to work after lowering security settings and clicking through a plethora of security warnings of impending doom but this wouldn't be acceptable in production, we'd have to get a signed certificate to do this which would be yet more cost.

We are committed to the new server with Win2K8 in order to update our EPOS system to a new version with a 64 bit backend or lose support for it, we haven't yet purchased anything though, I'm playing with trial versions at present.

I've considered 365 but I guess it's just the control freak in me that likes the idea of having everything on-premises rather than relying on hosted solutions - we literally have no cloud-based working at all, everything apart from our website is hosted on our own hardware. As such I assumed that on site Exchange is something I'd want to keep with the costs being justified based on the expected 10 year service life of the new system.

I must admit though that I wasn't prepared for how much more demanding newer versions of Exchange are. Our old server is our only server for everything and runs all Exchange roles alongside being the DC, the file server, the print server, the VPN server, provides RDP access to our EPOS from outside and is the backend for our EPOS system (and half the time gets used as a workstation too) and it copes with all of it admirably. I had assumed that I could implement the same kind of setup with the new hardware but on my test system it's creaking just under the weight of having all the Exchange roles on one box. Granted I am running it on workstation hardware but I can't see a proper server handling all those roles well in one box and we can't justify the cost of anything more than that given our small user base.

I think this may need more thought and it might be time to trust something to the cloud. In the short term I think I'll just demote the current server from DC and retain it as a standalone server for Exchange or re-implement virtually on the new hardware as you suggest.

Would I be right in taking a wild guess at the bit of software that "guesses" where messages come from and sends them to Exchange being VPop3?

I saw that in use at a company with over 150 Exchange users... We took the Office 365 route out in the end as the cleanest solution, and the migration is all basically handled for you.

You're not giving up that much control - authentication goes back to your own domain and you can administer it by powershell.

cdd wrote:Would I be right in taking a wild guess at the bit of software that "guesses" where messages come from and sends them to Exchange being VPop3?

I saw that in use at a company with over 150 Exchange users... We took the Office 365 route out in the end as the cleanest solution, and the migration is all basically handled for you.

You're not giving up that much control - authentication goes back to your own domain and you can administer it by powershell.

It's actually iGetMail, with some judicious filtering setup has always worked fine for us.

I think Office 365 will be the way to go, the more I played with Exchange 2010 the more I drew the conclusion that Exchange has become a much bigger beast than it used to be, and certain analogies involving sledgehammers and walnuts came to mind when seriously considering continuing to use it.

In the short term (which may well become medium term as the real push behind this change is to move to a 64 bit platform for our EPOS system. Our Exchange 2003 email system may be old but it still does everything we need) I'm planning on keeping Exchange 2003 in a virtualised Windows 2000 environment on the new server as suggested. I've looked at various 'proper' means of accomplishing this but based on having only a small number of users I'm thinking it will probably be simplest just to do a bricks-level backup of all the accounts to PST files using ExMerge on the physical server and then build an entirely new environment virtually and import everything back in again on the virtual server.