When you are deploying Windows Mobile in to your Exchange environment, you should be using an SSL certificate to secure the deployment.
However the number of SSL certificates that Windows Mobile trusts is much smaller than the number supported by Internet Explorer or Firefox on your desktop. This means one of two things.
1. You need to purchase a certificate from one of that small list.
2. You have to import the SSL certificate in to your device.
For the second option, I have instructions elsewhere: http://www.amset.info/pocketpc/certificates.asp
For the first option, which may be preferable if you are going to deploy a large number of the devices, you need to get a certificate that is issued by one of the roots supported by Windows Mobile.
The root certificates can be easily seen in the device, but the name of the certificate does not always match the name of the company who can issue the certificates. The root certificates have changed hands, companies have merged or simply changed their names.
Therefore what I have done is taken the list of root certificates from a standard emulator image, which is what Microsoft would have supplied the hardware suppliers as their base image and then found who is currently issuing the certificates.
You should check whether the root certificate list I have here is the same as what you have in your device, as there have been reports of some root certificates being removed.
Where it isn't clear who is the current owner of a root, I have put a question mark. Also note that not all providers are using the root certificates to issue NEW certificates - they may be using them for legacy support only. You should note that some issuers are using multiple roots and you may have to ask for a certificate to be issued from a specific root to get Windows Mobile support.
If you are deploying a mixture of Windows Mobile 5 and Windows Mobile 6 devices, then use the list of root certificates on Windows Mobile 5 to ensure maximum compatibility.
If you are tempted by wildcard certificates - remember that Windows Mobile 5 does not support any wildcard certificates.
Windows Mobile 6
Thawte Server CA (Thawte)
Thawte Premium Server CA (Thawte)
Starfield Class 2 Certification Authority (GoDaddy - http://www.certificatesforexchange.com/)
Secure Server Certification Authority (Verisign)
http://www.valicert.com (GoDaddy - http://www.certificatesforexchange.com/)
GTE CyberTrust Global Root (GlobalSign)
GoDaddy Class 2 Certification Authority (GoDaddy - http://www.certificatesforexchange.com/)
GlobalSign Root CA (GlobalSign - was InstantSSL.com)
Geotrust Global CA (Geotrust)
Equifax Secure Certification Authority (Geotrust)
Entrust.net Secure Server Certification Authority (Entrust)
Entrust.net Certification Authority (2048) (Entrust)
Class 3 Public Primary Certification Authority (Verisign)
Class 2 Public Primary Certification Authority (Verisign)
Baltimore CyberTrust Root (Cybertrust?)
AddTrust External CA Root (AddTrust)
AAA Certificate Services (Comodo?)
GTE CyberTrust Root (InstantSSL.com)
Windows Mobile 5
Thawte Server CA (Thawte)
Thawte Premium Server CA (Thawte)
Secure Server Certification Authority (Verisign)
http://www.valicert.com (GoDaddy - http://www.certificatesforexchange.com/)
GTE CyberTrust Global Root (GlobalSign)
GTE CyberTrust Root (InstantSSL.com)
GlobalSign Root CA (GlobalSign - was InstantSSL.com)
Equifax Secure Certification Authority (Geotrust)
Entrust.net Secure Server Certification Authority (Entrust)
Entrust.net Certification Authority (2048) (Entrust)
Class 3 Public Primary Certification Authority (Verisign)
Class 2 Public Primary Certification Authority (Verisign)
Having now completed a few Exchange 2007 deployments, upgrades and consulted on a few more, not one of them has featured an Edge server.
Which made me think, what is the point of Edge services for most users?
To use Edge you need to purchase another Exchange 2007 license which isn't cheap. What do you get for your money? Simply the ability to put a machine in a DMZ or similar network.
The edge server is just for SMTP traffic, but the most common concern I hear is for people worried about web traffic and therefore they want to put OWA in the DMZ. With Exchange 2003 this would have been a frontend server, although it is a bad idea to try and put an Exchange 2003 frontend server in to a DMZ.
The anti-spam agents that are installed on Edge can be installed on to another server by simply running a Powershell script, therefore the need for the Edge becomes less. All that it does is move where the spam filtering takes place - and if your main Exchange 2007 server is exposed to the internet then you haven't really lost anything, other than the warm fuzzy feeling that your Exchange server is not directly exposed to the internet.
If Edge was more like ISA, but for Exchange exclusively, so allowing you to have OWA in the DMZ with the small number of ports open similar to what Edge currently requires for SMTP traffic, then it would become something worth considering.
At the moment, if you want to protect SMTP traffic then you have more options if you do NOT use an Edge server. Instead install a standard Windows 2003 Server with IIS. That gives you options to use most third party products that offer a gateway facility.
I have built a few using a third party tool on top of IIS called Vamsoft ORF. This provides the basic option of recipient filtering via an LDAP lookup and can also do greylisting. There is an article on my other site that discusses building this type of server: http://www.amset.info/exchange/gateway.asp
With that product you can even integrate Antivirus software as an agent. Pick up a single copy of a server product different to what you are using internally and you have the multi layer protection that you should be aiming for.
Even after the purchase of Vamsoft ORF and another AV product, you are still easily within the cost of another Exchange 2007 license.
Furthermore by using Windows 2003 standard - i.e. 32 bit software - you could use an old server that you are removing from another role without having to purchase something new. It is a basic configuration, so if the server fails easily replacing it would be simple. You could even put the gateway functionality in to a virtual machine and keep a copy of it. If the physical hardware fails then simply copy the virtual machine on to the replacement hardware.
As you would probably expect, I am a member of a number of email discussion lists based around Microsoft Exchange. These include the lists at Sunbelt Software, msexchange.org (via freelists), Swinc.com and some others.
However what always surprises me is the number of Out of the Office (OOTO) messages that I get from these lists when I make a post.
As Exchange admins they should be able to use distribution lists in a way that ensures OOTO messages do not get returned to list members. This can also ensure that internal information is not broadcast to a large number of strangers. I have talked about the security concerns of OOTO messages before (http://blog.sembee.co.uk/archive/2006/06/08/Out-of-Office-Messages-to-the-Internet.aspx).
At a minimum, if you are using Exchange 2003, then you should look to make the OOTO suppression registry change as outlined here: http://support.microsoft.com/default.aspx?kbid=825370
However the easiest way I have found to work with discussion lists is to use public folders.
Each list gets its own public folder. This public folder is mail enabled. The list is subscribed to using the email address of the public folder. All posts go in to the public folder.
Permissions are configured as required, with at least anonymous having contributor permissions. Everyone else can be hidden by changing the default permissions to none.
To post replies, I subscribe my personal email address, but use the options on the list to "no mail". This could also be listed as a holiday setting or similar wording.
The additional benefit of using a public folder is that more than one person in the company can read the distribution list. New members of staff could also have access to the archives. On my home Exchange server the public folder store is actually bigger than my mailbox store.
One note of caution. If you are using Outlook in cached mode/offline folders, then I would suggest that you do not configure these public folders to be available offline. Many of the large Exchange discussion lists are very high traffic and you may find you are spending a long time waiting for the folders to sync.
Public Folders are not going away for some time, so this method will work for a few years yet. If you have started to use Sharepoint 3.0 then you could do something similar with that, but public folders is very easy to work with for this particular application.
On the 21st June 2007 a UK based Exchange User group called MMMUG (http://www.mmmug.co.uk/) held a community event hosted by Microsoft. This was also attended by some of the other UK user groups.
I attended and assisted with a the breakout sessions for Exchange 2007 along with Nathan Winters of the MMMUG.
During and after the breakout presentations I was asked the same couple of questions more than once. In case you were there and didn't get to ask me those questions, here they are along with the answers.
Q: Where can I get SSL certificates for US$30?
A: This was in relation to the section of our presentation about the SSL issues with Exchange 2007 (discussed elsewhere on this blog: http://blog.sembee.co.uk/archive/2007/01/21/34.aspx).
There are two main sources that I suggest.
1. Go Daddy. http://www.certificatesforexchange.com/
Their certificates are US$20 a year and are compatible with Windows Mobile 5 with the MSFP update and later.
However their certificates are a little more complex to install server side, but it isn't that bad. They also aren't good for .co.uk domains as their authorisation process seems to fail.
2. RapidSSL. http://www.rapidssl.com/
Their certificates are US$60 a year, but if you look around for their resellers you can find them as low as US$30.
RapidSSL also do 30 day trial certificates, which are good to get to grips with the process. If you have a trial certificate and then upgrade you get a discount.
Good for co.uk domains.
However their certificates are not trusted by Windows Mobile, so you have to import the root certificate yourself (http://www.amset.info/pocketpc/certificates.asp).
Q: I would like to test Unified Messaging with Exchange 2007.
A: If you would like to use actual hardware then you need to get a cheap gateway device.
Last year Microsoft ran a trial kit with some partners (http://msexchangeteam.com/archive/2006/09/25/428984.aspx)
The device that they used is readily available - if you can get someone to sell it to you without expensive consultancy.
The device is you need is an AudioCodes MediaPack 114 FXO VoIP gateway. It is an analogue device, so you can plug it in to a standard telephone line. http://www.audiocodes.com/
Q: What is your blog address?
A: In case you are reading this elsewhere, it is http://blog.sembee.co.uk/
I also author content on my company web site at http://www.amset.info/
Q: Can we hire you?
A: Yes of course. Email contact @ amset.co.uk
Kudos to Jason Langridge for this one.
Windows Mobile 6 emulator images are available for download from Microsoft. You will need the emulator installed on your machine, with the various networking components etc.
Unlike the previous SDK images, these work in the standalone emulator.
The emulator is ideal if you are looking at Exchange 2007 as you can see the extra features of Windows Mobile 6 when used with Exchange 2007 and test the auto discover functionality that Windows Mobile 6 provides.
You need version 2.0 of the emulator for these images.
185mb for the Professional version emulator. Watch you get the correct language.
Emulator 2.0 download:
http://www.microsoft.com/downloads/details.aspx?FamilyID=dd567053-f231-4a64-a648-fea5e7061303&DisplayLang=en
Windows Mobile 6 images:
http://www.microsoft.com/downloads/details.aspx?FamilyID=38c46aa8-1dd7-426f-a913-4f370a65a582&DisplayLang=en
Source: http://blogs.msdn.com/jasonlan/archive/2007/05/15/windows-mobile-6-stand-alone-and-localised-device-emulator-images.aspx
